[OSM-talk] Tagging OSM objects with UUIDs

John Smith deltafoxtrot256 at gmail.com
Mon Jun 7 09:26:22 BST 2010


On 7 June 2010 17:58, Peter Körner <osm-lists at mazdermind.de> wrote:
> I don't think that your uuid-tags will be more stable either - they are
> subject to thousands of editors that will sometimes delete tags they don't
> know or that won't take over those tags to the ways when they create polys
> for them.

The proposal covers those situations by tracking deleted UUIDs and
duplicated UUIDs, with your logic we should ban all the editors
because they can create duplicate nodes.

> About explicit editor support: I disapprove proposals that won't work
> without explicit editor support (eg. because they are too complex to handle
> in a manual fashion).

Most of the semi-complex to complex features never had editor support
at one stage but if this proposal is deemed suitable by enough people
the editors will figure out some new snazzy way to incorporate support
to varying degrees, just like support for relations has improved over
time as people found them increasingly useful for various things.

> Doing sth. automatically in osm is always a bad idea, especially if the
> thing you're trying to do is still in a proposal state -- so please do not
> run it agaianst the main api as long as it's not approved by a wide-enough
> audience.

I think you have misunderstood or at least not comprehended the
potential for being able to easily share the same ID with other
databases without needing to do special or complex bbox searches like
you suggest. At no stage didn't I ever suggest that any script should
simply mass tag nodes with UUIDs, these should only be generated if
there is an actual need for them.

> I like Tim's Query-to-map [1] which accomplishes this task already and
> doesn't rely on any extra tagging, by combining bbox+[ref|name] -- tags that
> don't vanish as fast as some mysterious uuid tag.

There is a lot of ID tags in the database and they seem to be a lot
more stable than OSM IDs.

It might do so, but it's horribly inefficient as a result of needing
to do searches across areas, and can't cope with an occupant such as a
business moving across town without an even more inefficient brute
force search which may not work if the tags fix the name due to
spelling mistakes etc etc etc.




More information about the talk mailing list