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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
