Re: [OSM-dev] [Imports] Inserting OSM data

[Sam Vekemans]

Hi,
Im just tagging on to this thread for the archives. As it was just sent to
the imports@ list, but not dev@ list,

It attempts to solve the ideas that jaak noted below.
http://lists.openstreetmap.org/pipermail/talk-gb/2010-March/005544.html

(I was going to respond last week on this thread) ... with 'OpenImportsMap'
.  Perhaps the wiki can be expanded, i added my notes tot he talk page of
it, and  will attempt to incorporate the ideas from this thread also.
  http://wiki.openstreetmap.org/wiki/Importing_Government_Data

It was in response to:
from steveC original post about  Announce: openOS  (Ordinance survey
releasing data)
http://lists.openstreetmap.org/pipermail/talk-gb/2010-March/005543.html

Cheers,
Sam

On Sat, Mar 27, 2010 at 10:28 AM, Jaak Laineste  wrote:

> > > some kind of priority over the others. Like possibility to
> > > lock/protect some parts of the data. It could be done in several
> levels:
> >
> > > 1) my inserted data (tag, node, relation, way - any of them) can be
> > > defined as private, nobody else can not even see it.
> > > 2) my data is protected - you can see, but not modify
> > > 3) my data has group privacy/protection under my control: I can give
> > > view/ modify / delete permissions to specific users/groups
> >
> > These three are, in my opinion, not compatible with the spirit of OSM.
> > If you want your own data, store it somewhere else ;-)
>
> There could be quite good reasons to protect some of the data at least
> temporarily. Very technical reason: to avoid accidental deletion of nodes
> during bulk import (which takes days sometimes). Well, maybe bulk import in
> general is not really fully compatible the spirit of OSM after all. What is
> more important purpose of OSM: is it the biggest outdoor mapping capturing
> tool, or does it want to be the world largest and best community-created
> map
> database? If outdoor mapping is the primary aim, then right, the corporate
> imports are not needed, maybe even need to be banned. If the database
> contents and quality the is target, then the imports and database links
> must
> be as plentifyl, good and made contributor friendly as possible. My
> implicit
> assumption was that OSM wants to be as good database as possible, but I
> could also have totally missed the point of OSM. Anyway, my preference is
> that OSM aim is to be as good database as possible, and outdoor mapping is
> just one of the great ways to create and update data.
>
>  There are good datasources (from public sector) who have 80% of their data
> open and in principle well compatible with OSM, but 20% of them should have
> some protection. Technically splitting the data could be so complicated
> that
> their only option now is not to share anything, i.e. just not to use OSM.
>
>  I have a particular example: a friend just called me, and he is in board
> of
> national assiocation of museums. They have and maintain kind of official
> database of all museums in the country. They wanted to have them on web
> map,
> and I suggested to use OpenStreetMap, and not only as background image, but
> also insert their data as points to the OSM. This bought me several
> questions:
> - is the only legitimate way to have one-time bulk import, and then just
> hope that community will only improve it? Or could they have a bit more
> special control (external IDs, notifications, soft locking of some tags
> etc)
> over the data, at least to make their data maintenance easier. To enable
> more automatic sync with their in-house data maintenance systems and
> procedures.
> - Today the only way for them is anyway double maintenance: they maintain
> their internal/primary database, and maybe they care to copy their
> day-to-day updates manually also to OSM. Is there a way to make maintenance
> of only their specific data in OSM easy? One complicated solution would be
> to use JOSM+XAPI to make extracts based their own tags. But this is risky,
> you can easily create reduntant data if you do not see the data around each
> node. Also I cannot imagine this type of "once a month" users actually
> using
> hard-core mapping beasts like JOSM, maximum what they could care to learn
> would be somewhere in Potlatch (but without the roads!) / Mapzen level.
>
>
> Jaak
>
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/imports
>
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [OSM-talk] OSM front page design concept

[Sam Vekemans]

One idea is to leverage IRC power, by having an international channel,
where any language is permitted.
And people can respond & live translate, and people can get their answer.

Having this IRC weblink directly on the feedback box will help a great deal.

Many have abandoned this talk@ list because IRC is more efficient.
(kind of like twitter, but the useful version)
and it could be better with more languages permitted.

Imo,
Sam

On 2/20/10, SteveC  wrote:
>
> On Feb 20, 2010, at 11:20 PM, Frederik Ramm wrote:
>
>> Hi,
>>
>> SteveC wrote:
>>> Wrong. Map bugs. Did you read my post Fred ? :-)
>>
>> So you meant to integrate uservoice.com instead of integrating
>> openstreetbugs? But can their system tie notes to map locations?
>
> Well I'll go further.
>
> openstreetbugs is basically there but has a crappy UI. It needs to be
>
> 1) click 'feedback' or 'problem'
> 2) enter problem
> 3) click ok
>
> the extra step of clicking where the problem is should not happen, we should
> get that from the bbox or center point plus zoom. So with some changes I
> think we can integrate OSB and expose it front and center to help fix up the
> bugs.
>
> I think in an environment where every other map on the planet is trying to
> hide their bugs, we should expose ours and fix them quickly while showing
> everyone what they got wrong.
>
> As for your comments about people entering bugs and feature requests we
> can't handle... look. I understand it's a case of matching requests to
> people who can be bothered to do them. And I understand that people here
> today can't be bothered to fix most of the things that are wrong in OSM
> because we're all happy to work around them... but it's bonkers to be
> dismissive about 'granny' because it's all those grannies out there who are
> going to help us fix this map.
>
> If I think about all the people who can help today in OSM, I immediately
> think of my brothers and sister, my parents and so on... and the only way is
> if we go through a big complicated loop with walking papers. A bug system
> like the above should be where we're headed. It will make so many more
> people help us, and we will be able to fix so many more things.
>
> So as for features and software bugs... I think we should turn up the volume
> of the people who want things changed. One, we might learn something about
> what the users actually want (because trac is a poor, poor reflection) and
> two... look we should be the first people to welcome input on what people
> think we should do. We can't all hide in our basement and hack on Java any
> more. We have to help these people who are crying out for it.
>
> I'll add two more things
>
> 1) Using "google insight" (bing for it) and many other tools it's very very
> clear that the german community is by far and away huge. That's wonderful,
> but we don't have Germans all over Europe and the US - we need these tools
> out here Frederik to help us fix the map.
>
> 2) We have to be very clear that the openstreetmap.org website is _awful_.
> Horrendous. A total PITA. We're all here because we're persistent with it.
> But the wonderful thing is - we don't have to make the tools and site easy
> to use if we can expose a simple bug system. It's very clear that nobody can
> convince Richard to actually write something any muggle would really want to
> use, you can scream at him to finish the mythical Potlatch 2 all you want,
> but he doesn't give a shit and lives on a boat in bliss. That's his choice,
> and it's totally fine, but if we all feel that way then we have to deal with
> the downside that every single day we lose tens of thousands of edits
> because of that monopoly on bad UI. All I'm suggesting is we sidestep the
> problem and connect people who can report a map bug but can't be bothered to
> deal with pain and suffering of potlatch with the people who can deal with
> it, at least until Richard gets his act together and stops fixing every
> stupid thing in the old codebase. You have to take a step back here and
> realise what we're missing out on.
>
> Yours &c.
>
> Steve
> ___
> talk mailing list
> t...@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>


-- 
Twitter: @Acrosscanada
Blog:  http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
OpenStreetMap IRC: http://irc.openstreetmap.org
@Acrosscanadatrails

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Map Features sub:sub:sub types

[Sam Vekemans]

Hi all, (dev list)
Is there a technical reason why on the main map features page only the sub
values of each main type, and not the sub sub values, so then each can be
found with a hyper-link?
... also we need to add 'surface' as 1.1.6  that would make sence IMO.


   - 1 Physical 
  - 1.1 Highway
 - 1.1.1 Roads
 - 1.1.2 Paths
 - 1.1.3 Intersection Features
 - etc.
 - 1.2 Barrier
 - 1.2.1 Linear barrier
 - 1.2.2 Linear barrier with sides
 - etc.
 - 1.3 
Cycleway
  - 1.4 Tracktype
  - 1.5 Waterway
  - 1.6 Railway

Cheers,
Sam

Twitter: @Acrosscanada
Facebook: http://www.facebook.com/sam.vekemans
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Deleting TIGER node tags & OSM 'best practice'

[Sam Vekemans]

Hi talk-us, talk-ca and dev lists,

re: Deleting TIGER node tags

Yup, its great to learn from others  experiences.
I too agree about having the extra tags. .. hence why the CanVec import is
taking so long to get out of BETA phase.
We do have some more of the GeoBaseNHN data imported (rivers in Quebec), and
for the Roads, All of Alberta and all of Ontario and parts of other
provinces have already been imported.  (with maybe too many tags, but that's
still debatable)

What I have a difficult time trying to convey to people asking about the
import, is that "importing" the data, is exactly that.  It's an "Import" so
it is not a 'Sync'.   It's a one-way import.

Yes, we do have tools which we can use such as OpenJUMP, RoadMatcher, so
then as new data becomes available, we can simply compare it with what
exists. Then, 'enhance the data' with what new information is available.

The purpose of OpenStreetMap is to create the worlds best and most accurate
'current map'.   So by default, ALL data that gets imported, should be
considered as "old" and be treated as data to be added-to the current map.
So... just because i have a lot of data to contribute... doesn't mean that i
have any power over what the existing map is like. (BTW, after +1 day all
data is old, since your not physically there :)

Sure, (for me and whoever is preforming manual import) its some work, were i
need to manually remove the duplicate imported data in favour of the OSM
version. ... but it isn't more work for the local area mappers.  Why should
they have to spend time removing duplicate stuff that i dropped in there?
... they shouldn't. (I can ask them to help, but that's all i can do)

That said, it's MORE important that these .osm files would become available
so that everyone has access to it, and can import it as they like. .. rather
than forcing an import on areas where it's not really needed.   The imported
data is ALWAYS a 'helper-data'. (and IMO should be thought of that way)

Ie. the other day, i was looking at a lake that someone else traced from
yahoo imagery (the lake was 7 nodes polygon).  When my version (from
GeoBasdeNHN) is 50 nodes polygon. ... which is more accurate so other
features can be shown.  The 'best practice' is that I take time and contact
that person who drew in that lake, and let them know that i have something
better. .. that will 'improve the map'.   (regardless of the source).  So
once i heard back. THEN i can replace. .. but not before.   Sure, it takes
extra time on my part, BUT it makes the map better overall.   That person
can then see the new data, and work on further adding details (adjusting the
piers and showing where park areas trails are etc.)

So anyway, having tags that are "supposed" to be used as cross-reference..
doesn't really make sense.  Since this is an "open" street map, where anyone
who has local knowledge of how the map should be, would know better than
what the import data says.

Anyway,
Good call,
Happy Mapping

Cheers,
Sam Vekemans
Across Canada Trails

Twitter: @Acrosscanada
Facebook: http://www.facebook.com/sam.vekemans
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] shp-to-osm Response Code=400 error

[Sam Vekemans]

Good news,
The basic part of Ian's script still works.
Im able to copy things from the BS_1370009_2residential_area.osm0 layer to
the Data Layer
then hide the BS_1370009_2residential_area.osm0 layer.  and upload.  I then
delete those selected features from the BS_1370009_2residential_area.osm0
layer, because i know that they have been uploaded, and the rest hasn't.
I can then save that file and share it, so the team working  in the area
knows what features are left to upload.

http://www.openstreetmap.org/?lat=48.50146&lon=-123.39264&zoom=15

It now shows the french accents on the tags.

This is exactly what is intended for this script, perhaps (for me) it would
take selecting all the features in that layer, copy,and paste in the Data
layer, then upload.

Maybe an extra step, but it does ensure that the user doing this, is more
aware of what they are doing and aware that they are adding in more data.
(just like after i go out mapping with gps) and tracing my tracks.  I'm
aware that all that i add needs to be in a change set, and that entire
changeset can be reversed if needed, but not segments of it.

A big relief for me, id say :0)

(my solution was to trick JOSM into thinking the shape was done my me
drawing it, rather than an imported shape) :-)

Cheers,
Sam

Twitter: @Acrosscanada
Facebook: http://www.facebook.com/sam.vekemans


On Tue, Jun 16, 2009 at 1:57 PM, Shaun McDonald
wrote:

> The program that is uploading the file should be adding the changeset id
> for every node, way and relation.
> The initial generation shouldn't include them, as you probably don't know
> what the changeset will be until the upload starts.
>
> Shaun
>
> On 16 Jun 2009, at 21:39, Ian Dees wrote:
>
> As soon as someone points me to the correct file format to write out in
> order to facilitate the upload of OSM data, shp-to-osm will work again.
>
> It's not clear to me what the ideal format to upload large data sets like
> this is.
>
> On Tue, Jun 16, 2009 at 3:36 PM, Sam Vekemans <
> acrosscanadatra...@gmail.com> wrote:
>
>> Argh!
>>
>> Then it's off to school for me.  and a deeper learning curve for me. :)
>> I'll be learning more about how to work with shp2osm as there MUST be a
>> way to create some kind of cool GUI that will automagically input shp files,
>> and output OSM files, so to customize it how we want.  So that its able to
>> merge the benifits of osmosis, OpenJUMP, xapi. OSMCut, mkgmap, kosmos,
>> bulkimport.pl ... etc. ... so that all sides of the table will be happy.
>>  I think the community has enough brilliant minds here to make it happen
>> :-)
>> We all have pieces of the puzzle :-)
>>
>> Cheers,
>> Sam Vekemans
>> Across Canada Trails
>>
>> Twitter: @Acrosscanada
>> Facebook: http://www.facebook.com/sam.vekemans
>>
>>
>> On Tue, Jun 16, 2009 at 1:26 PM, Ian Dees  wrote:
>>
>>> The error has nothing to do with any of that. None of the shp-to-osm jar
>>> files will work now because the server is now checking for the changeset id,
>>> which is not in the XML I generate.
>>>
>>> Earlier, the server did not check so there was no error.
>>>
>>>
>>> On Tue, Jun 16, 2009 at 3:22 PM, Sam Vekemans <
>>> acrosscanadatra...@gmail.com> wrote:
>>>
>>>> Interesting,
>>>> Yup, using JOSM.
>>>> Im going to now try and use the old shp-to-osm0.3.jar as i dont think it
>>>> should have that problem (wont make the accents appear), but would still
>>>> upload.
>>>>
>>>> I don't pretend to know the answer, just trying to turn all stones :)
>>>>
>>>> Your new version takes all the lib files and puts them all together,
>>>> into 1 script right? then adds a bit of code so that it will encode the txt
>>>> file right?
>>>>
>>>> What about keeping those lib files in a directory?  Maybe there was an
>>>> error where the script didn't pick up all the lib files? (kinda like my
>>>> error when it was a ":" rather than a ";")
>>>>
>>>> Perhaps it was an error in the script where it divides the +50,000 item
>>>> shp files.?
>>>>
>>>> I saw on the latest JOSM notes that api 0.6
>>>>
>>>> ***
>>>> 2009-05-30 (1628)
>>>> Settings are now stored in UTF-8. Users with non-latin GUI may need to
>>>> fix own texts or reset configuration.
>>>> ***
>>>>
>>>> So thats probably what your refering too.
>>>> But that's kind of odd, as i have 

Re: [OSM-dev] shp-to-osm Response Code=400 error

[Sam Vekemans]

Argh!

Then it's off to school for me.  and a deeper learning curve for me. :)
I'll be learning more about how to work with shp2osm as there MUST be a way
to create some kind of cool GUI that will automagically input shp files, and
output OSM files, so to customize it how we want.  So that its able to merge
the benifits of osmosis, OpenJUMP, xapi. OSMCut, mkgmap, kosmos,
bulkimport.pl ... etc. ... so that all sides of the table will be happy.
 I think the community has enough brilliant minds here to make it happen :-)
We all have pieces of the puzzle :-)

Cheers,
Sam Vekemans
Across Canada Trails

Twitter: @Acrosscanada
Facebook: http://www.facebook.com/sam.vekemans


On Tue, Jun 16, 2009 at 1:26 PM, Ian Dees  wrote:

> The error has nothing to do with any of that. None of the shp-to-osm jar
> files will work now because the server is now checking for the changeset id,
> which is not in the XML I generate.
>
> Earlier, the server did not check so there was no error.
>
>
> On Tue, Jun 16, 2009 at 3:22 PM, Sam Vekemans <
> acrosscanadatra...@gmail.com> wrote:
>
>> Interesting,
>> Yup, using JOSM.
>> Im going to now try and use the old shp-to-osm0.3.jar as i dont think it
>> should have that problem (wont make the accents appear), but would still
>> upload.
>>
>> I don't pretend to know the answer, just trying to turn all stones :)
>>
>> Your new version takes all the lib files and puts them all together, into
>> 1 script right? then adds a bit of code so that it will encode the txt file
>> right?
>>
>> What about keeping those lib files in a directory?  Maybe there was an
>> error where the script didn't pick up all the lib files? (kinda like my
>> error when it was a ":" rather than a ";")
>>
>> Perhaps it was an error in the script where it divides the +50,000 item
>> shp files.?
>>
>> I saw on the latest JOSM notes that api 0.6
>>
>> ***
>> 2009-05-30 (1628)
>> Settings are now stored in UTF-8. Users with non-latin GUI may need to fix
>> own texts or reset configuration.
>> ***
>>
>> So thats probably what your refering too.
>> But that's kind of odd, as i have been using your program many times in
>> June and it works fine.
>>
>> Cheers,
>> Sam
>>
>> Twitter: @Acrosscanada
>> Facebook: http://www.facebook.com/sam.vekemans
>>
>>
>> On Tue, Jun 16, 2009 at 6:02 AM, Ian Dees  wrote:
>>
>>> You're using JOSM, right? I'm running into this problem, too. It sounds
>>> like the server is now explicitly looking for the changeset ID number where
>>> it didn't do that before. I started a thread on osm-dev and josm mailing
>>> lists and will implement whatever fixes need to happen in order to make it
>>> work.
>>>
>>> I'll let you know what happens.
>>>
>>>
>>> On Tue, Jun 16, 2009 at 1:51 AM, Sam Vekemans <
>>> acrosscanadatra...@gmail.com> wrote:
>>>
>>>> Hi,
>>>> Dout!
>>>> Im getting an error when i attempt to upload the .osm0 file.
>>>>
>>>> "ResponceCode=400, Error Header=>>> >>>
>>>> Im going to try and use that last version of shp-to-osm.jar file you
>>>> sent, as i didn't quite follow what what was fixing.  So you might have
>>>> fixed it already.
>>>> shp-to-osm-0.4.1-SNAPSHOT-jar-with-dependencies
>>>>
>>>> my computer is giving me a low disk space error, so it might also be
>>>> from my end here.
>>>>
>>>> I'll keep ya posted.
>>>> Cheers,
>>>> Sam
>>>>
>>>> Twitter: @Acrosscanada
>>>> Facebook: http://www.facebook.com/sam.vekemans
>>>>
>>>>
>>>> On Mon, Jun 15, 2009 at 3:42 PM, Ian Dees  wrote:
>>>>
>>>>> Currently, the limit of changes-per-file limit is hard coded, but can
>>>>> (and probably should) be settable with a code change.
>>>>>
>>>>> I've successfully uploaded several OSM files via JOSM that were greater
>>>>> than 5MB in size. It took a long time to process (20-30 minutes), but it
>>>>> worked.
>>>>>
>>>>> I use Maven to build the jar. I can give instructions on how to use it
>>>>> if you'd really like to build the jar yourself.
>>>>>
>>>>> Also, the wiki could be updated, but I don't really have time to
>>>>> updated it.
>>>>>
>>>>> -Ian
>>>>>
>>>>>
>>>>> On Mon, Jun 15, 2009 at 5:15 PM, Sam Vekemans <
>>>>> acrosscanadatra...@gmail.com> wrote:
>>>>>
>>>>>> Hi Ian,
>>>>>> cc: Jon
>>>>>>
>>>>>> Great work on the update :)
>>>>>> I fixed the canvec2osm script so now its much better. and all the
>>>>>> french accents seems to work, the people at the federal level will be
>>>>>> happy, and everyone Quebec too. .. and anyone who is native to the
>>>>>> french language :)
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Max size of changeset with josm (in kb)

[Sam Vekemans]

I guess with osmosis there is no way to avoid having to enter in the
center coordinates of the osm file?

And in josm, is there (or will there be)? An option to invert selection?
Having that option i could chop the file into doughnuts and timbits.

Is there an easy way to slice a SHP file then?

Thanks,
Sam

On 6/2/09, Karl Newman  wrote:
> On Sun, May 31, 2009 at 9:52 AM, Chris Jones  wrote:
>
>>
>> On 31 May 2009, at 15:40, Sam Vekemans wrote:
>>
>> > Hi,
>> > I already got part of the answer - 50,000 (things; nodes, lines, areas
>> > -total) so now i want to know, what approx size (in mb, kb) is safe?
>> > I loaded a changeset of 358 kb and it seemed happy. Would 1 meg be
>> > too much?
>>
>> Size all depends on the volume of tags attached to the objects.
>>
>> > I know that there is a max geographical download area built in, (it's
>> > say's "download area OK, size probably acceptable by server") but is
>> > there a time out or an exact max file size to download? (a squak
>> > level) (i know that i download a large area when im tracing from my
>> > GPS Tracks.  (Victoria is about 8 megs) and so it takes a little time
>> > to load, so i dont load that big area any more, i just open that old
>> > Victoria file, then zoom to the area im working in, then get the
>> > latest updates for that small area.
>>
>> There a limits (on the main api) on both area 0.25 degree squares and
>> number of objects returned.
>>
>> See http://api.openstreetmap.org/api/capabilities
>>
>> > Also, is there an easy way i can chop the .osm file into 4 or 16 happy
>> > geographical area chunks? Thus, smaller file sizes to deal with.
>>
>> Osmosis - http://wiki.openstreetmap.org/wiki/Osmosis
>>
>
> Be careful using Osmosis for this purpose. It's fine for cutting out one
> area, but for cutting an input file into multiple adjacent areas, it's less
> than ideal. You'll either get duplicate data (completeWays=yes) in adjacent
> areas or incomplete/mangled data (gaps at the border). If you're going to
> process the output offline, it's no big deal, but if you plan to upload it,
> it matters.
>
> Karl
>

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] using osmosis (was Re: Max size of changeset with josm (in kb))

[Sam Vekemans]

Thanks,
Im slowely figuring it out. :)

I got osmosis to run, and now playing with the .bat file to make it work.

It stalled with an error
"thread for task 1-read-xml failed"
and "unable to read XML file.
and "Invalid byte 2 of 3-byte UTF-8 sequence"

Does the script need to call any files from the lib/ directory?

Who is the creator of this program that might be able to help?

Unfortunately it still asks me to put in the bounding box coordinates.  I
guess there isn't a way to simply slice the .osm file in 16  (it looks like
it has to be .bz2)

Thanks,
Sam

On Sun, May 31, 2009 at 9:52 AM, Chris Jones  wrote:

>
> On 31 May 2009, at 15:40, Sam Vekemans wrote:
>
>  Hi,
>> I already got part of the answer - 50,000 (things; nodes, lines, areas
>> -total) so now i want to know, what approx size (in mb, kb) is safe?
>> I loaded a changeset of 358 kb and it seemed happy. Would 1 meg be too
>> much?
>>
>
> Size all depends on the volume of tags attached to the objects.
>
>  I know that there is a max geographical download area built in, (it's
>> say's "download area OK, size probably acceptable by server") but is
>> there a time out or an exact max file size to download? (a squak
>> level) (i know that i download a large area when im tracing from my
>> GPS Tracks.  (Victoria is about 8 megs) and so it takes a little time
>> to load, so i dont load that big area any more, i just open that old
>> Victoria file, then zoom to the area im working in, then get the
>> latest updates for that small area.
>>
>
> There a limits (on the main api) on both area 0.25 degree squares and
> number of objects returned.
>
> See http://api.openstreetmap.org/api/capabilities
>
>  Also, is there an easy way i can chop the .osm file into 4 or 16 happy
>> geographical area chunks? Thus, smaller file sizes to deal with.
>>
>
> Osmosis - http://wiki.openstreetmap.org/wiki/Osmosis
>
> --
> Chris Jones, SUCS Admin
> http://sucs.org
>
>
>
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Max size of changeset with josm (in kb)

[Sam Vekemans]

Hi,
I already got part of the answer - 50,000 (things; nodes, lines, areas
-total) so now i want to know, what approx size (in mb, kb) is safe?
I loaded a changeset of 358 kb and it seemed happy. Would 1 meg be too much?

I know that there is a max geographical download area built in, (it's
say's "download area OK, size probably acceptable by server") but is
there a time out or an exact max file size to download? (a squak
level) (i know that i download a large area when im tracing from my
GPS Tracks.  (Victoria is about 8 megs) and so it takes a little time
to load, so i dont load that big area any more, i just open that old
Victoria file, then zoom to the area im working in, then get the
latest updates for that small area.

Also, is there an easy way i can chop the .osm file into 4 or 16 happy
geographical area chunks? Thus, smaller file sizes to deal with.
Thanks,
Sam

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Duplicate nodes

[Sam Vekemans]

forgot to cc dev list :)

On Tue, Apr 14, 2009 at 1:18 PM, Sam Vekemans
wrote:

> Just jumping in here :)
>
> When i have my ready-to-import.osm file, and hit upload, im prompted
> to agree on what to upload, it would be great to be able to select
> only the nodes/ways/areas that i want. This way im not uploading those
> 'extra' intersecting nodes.
> It was only on my last upload that i just selected the features that
> were part of something or had a name. -but i think (almost sure) it
> uploaded them all anyway.
>
> Because im switching user logins, it would be a good idea to have the
> username that im using shown at the import prompt: to complete the
> statement.
> "you (user xy) are about to upload these nodes/ways/relations, are you
> sure?"
>
> also, 1st checking the db for errors, indicating none/yes-list, then
> uploading as part of the upload sequence would help.
> I know potlatch does this instantly, but josm is a different kind of
> editor ie. Mac vs. PC vs. Android
>
> i just jumped in as i'll (probably) be the 2nd largest contributor by
> the end of the year :-)
> so mistakes i make, could add up to a gig of nodes. Fortunatly, i'll
> be going slow as Dave Hansen did, so mistakes will be caught ...
> Hopefully :-)
>
> look forward to API 6.
>
> Sam Vekemans
> Across Canada Trails
>
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Bulk import as a data layer (like gpx currently is)

[Sam Vekemans]

+1 for that!!!

I could easily create and store all the canvec2osm created files on my
GoogleApps website www.acrosscanadatrails.com
(as well as the geobase2osm NRN data, which is already being archived on
http://www.mediafire.com)

I would of-course have it all in a single layer, (but better to have it as
separate OSM files feeding to the same source) ... better for what? I don't
know... it would solve the problem for when the new canvec/geobase DB is
available (+ the UUID's will be held in safekeeping) :-)

These files can be copied to a master server somewhere. (The Bulk Import
o-sphere, which is just below the OSM-node-o-sphere... which is WAY above
the blog-o-sphere!... and close to the GPX track-o-sphere) ... plus the map
can ALSO be rendered and available to view, for when using potlatch :)

So having the ability to only 'pull' a select section, to use it, select it
all and 'drop' in onto the current 'osm data working layer'  (... as well as
the ability to 'select items which are to be uploaded' would really help.)
Having your userID with the automatic reference tag added ie.
 "canvec:Acrosscanadatrails" for times when you download data.
(that's covered because you now have to 'login' BEFORE you upload any new
data to the server.)

Also, having all the tags that are stored as reference tags also come in as
the user 'pulls' the data from the "Bulk Import Data Layer"

So then only users who have added themselves to the 'Bulk Import Data'
database acess list can submit data to this, using the "DATASOURCE:username"
tag.  (and have agreed to the ODbl licence?)

FYI, AFAIK, just because i edited the rules.txt file and created the
canvec2osm.bat (DOS instructions file), that wouldn't necessarily mean that
i am the "created-works" importer, i just created the "tool" so the
creativity was in the 'linking of the data', i made the chain links to fit
together, but not the entire spool of chain. ... PLUS, the tool was created
acquired knowledge from others.

This MAY solve the database Quagmire :-) ?

Cheers,
Sam Vekemans
Across Canada Trails

Message: 10
>
Date: Sat, 14 Mar 2009 20:42:34 +0800
>
From: Eugene Alvin Villar 
>
Subject: Re: [OSM-talk] immutable=yes Fwd: DEC Lands
>
To: Jukka Rahkonen 
>
Cc: t...@openstreetmap.org
>
Message-ID:
>
  
>
Content-Type: text/plain; charset="iso-8859-1"
>

> On Sat, Mar 14, 2009 at 7:33 PM, Jukka Rahkonen
>
wrote:
>

> > Why not to store this kind of datasets as own layers in the database?
>  DEC
>
> data
>
> could be on its own, non-editable layer, but if there's something that
>
> people
>
> would like to edit those features could be copied or lifted to anothet,
> OSM
>
> layer.  That would make DEC updates easier as well, they would just update
>
> the
>
> DEC layer.  The same approach would suit other data of similar nature as
>
> well,
>
> like TIGER or cadastrial data.
>
>
>
>
>
+1
>

> Having multiple separate "layers" in OSM would be good for various
> purposes.
>
The GPS traces "layer" is already one we use.
>

> Eugene / seav
>
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev