[Tagging] Permanent IDs RFC (was part_of:wikidata)

Martin Koppenhoefer dieterdreist at gmail.com
Thu Nov 30 09:14:17 UTC 2017

2017-11-30 7:42 GMT+01:00, Yuri Astrakhan <yuriastrakhan at 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).


More information about the Tagging mailing list