2017-11-30 7:42 GMT+01:00, Yuri Astrakhan <yuriastrak...@gmail.com>: >> * What if the shop moves to a new address ? What if someone already >> recorded the shop at the new location, how do we merge the IDs? > If we decide that a moved shop should have the same id, than this is a case > for merge+making one redirect to the other.
what if the shop moves to 2 different addresses? In this case the ID wouldn't be unique any more (or we'd have to create a relation to hold the ID, i.e. change our mapping technique due to the ID concept, i.e. more complexity). >> * A restaurant POI and the building it resides in are 2 different >> concepts, they both need their own permanent ID. How can we >> distinguish them ? > > If the entire building is a restaurant (e.g. a standalone McDonald's), than > it should probably be the same id. But if restaurant is occupying the first > floor of a residential bldg, probably two. No, I don't think it is a good idea to have the same ID, because many properties will still be different (e.g. start date, architect of shop will often be different to that of the building, operator might be different, etc.) and many properties will only apply to one (e.g. a building doesn't have a "cuisine" in the OSM tag sense). > How does the software knows this when someone "joins" the POI and the >> building ? > Software wouldn't know, but an editor should always keep this in mind, and > there tools should offer some "join" mechanism. IMHO buildings and users of the building should in most cases be distinguished. >> * What do you do when a modern part is attached to a listed building ? >> Will the building parts have permanent IDs ? > If the building or a road is extended, it should keep the old id. If the > new part is notable on its own, the part may get a new id as well, while > also being part of the old id. "notable"? That wasn't an OSM concept until now. IMHO we would have to have a mechanism that keeps trace of what happens to IDs (e.g. this ID is now part of this ID, or has become this ID, or was deleted because of a / b / c / d etc.) Ultimately, we'll need an ID for every tag, and for every combination of tags, of an object (i.e. a lot of IDs for every object). So every need can be suited ;-) I still believe OSM IDs together with versions / timestamps, are already suitable for referring to a certain state at a given point in time. Additional IDs introduce more problems than they promise to solve (because mappers will have to decide what to do with them when modifying the map, and therefore the IDs would either have to be very finegrained (as stated above, one for every tag, and for every combination of tags), or would sooner or later brake for some of the usecases for which people rely on them (e.g. one mapper seeing the ID referring to the restaurant, the other to the building). Cheers, Martin _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
