[OSM-dev] OSM export incompatibilities between JOSM and Merkaartor

Till Harbaum / Lists lists at harbaum.org
Sun Sep 21 12:42:04 BST 2008


Hi,

Am Sonntag 21 September 2008 schrieb Chris Browet:
> > files is the same format used by many other tools, and is the format
> > expected by the API when uploading new entities, so it was a natural fit. If
The API doesn't expect any id when uploading new items. So this is about an
issue that doesn't apply to the api: Storing new items before they get their
id during an upload.

> I'm not trying to convince anyone to use text ID by itself.
> I'm just a bit pissed off by "non-written established JOSM based" standards.
The only standard is the API. The API is meant to connect a client app to the server.
What you want is a exchange between two client apps. The API just doesn't
cover this. To make thinks worse: I faced the same problem with my n800/n810
osm editor and took an entirely different approach as i don't store anything
in my local copy of the downloaded data, but store changes in a seperate diff
file (for those who wonder why i did this: I thought it would be a nice option
to be able to update the OSM data from the server without loosing the changes
one did to the local copy). 

> Far from saying there should be no standards on OSM, I'm strongly for it,
> for consistency, but they should be assumed, agreed upon and documented.
> To be short: OSM lacks governance.
I am sure we all agree on this. But someone has to actually do that job.

> > I can answer one reason why some "other apps" convert xml text attributes
> > to numeric IDs. For Osmosis, anyway, it deals with OSM data in a pipelined
I use numeric ids because they use up less precious memory on a mobile device.

BTW: Is there some limit for the size of the ids? What max size should my app be
able to cope with? I assume that 32 bits (or 31 for positive ids) aren't sufficient,
or at least will not be sufficient for very long ...

Ciao,
  Till




More information about the dev mailing list