Hi, You wrote: > - it's roughly in that bounding box (e.g. the city or a given part of
A soon as you use the word "roughly" - the id approach is doomed to fail. According to OO and database technology an id is a well-defined surrogate with a well-defined data type. Yours, Stefan 2013/5/7 Peter Wendorff <wendo...@uni-paderborn.de>: > Am 07.05.2013 09:43, schrieb Stefan Keller: >> Hi, >> >> All use cases you describe are valid. It's up to the users of OSM >> permanent id to keep track of changing OSM ids - it's an offer of OSM. >> The only constraint I would propose is to avoid to delete and recreate >> a new id only because of a tool (like an editor) likes to do it like >> this. >> >> The concept of permanent, unique and never-reused object ids is a >> well-known property in the Object-Oriented and Linked Data technology. >> >> As I said: The killer criteria not to use overpass-approach is that >> there exist many OSM objects which have too few or no tags at all. And >> using coordinates as identifiers is no solution neither because it's a >> float number with different precision and implementation dependent. OO >> overcame exactly this restriction of the relational paradigm (which >> identified a tupel by the set of it's values). > > But even then overpass is slightly better: > Let's say I only know I want to link a given supermarket. > Let's say that supermarket is not tagged in more detail then > shop=supermarket. > Linking to node 123 would break soon when that get's a polygon (not to > mention mappers who don't know or care about theory of data management > and reuse that node directly to map a waste_basket instead of creating a > new object). > Best case here would be a mapper that includes that node as one of the > nodes building the polygon - but who knows? > > Overpass in contrast could add information about: > - we want to link a supermarket > - it's roughly in that bounding box (e.g. the city or a given part of > the city) > > Of course this can break, too - but it's more stable than the ID alone, > even without any tag at all. > > regards > Peter > _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk