Proposal talk:Relation:feature

linking

"If a data consumer wanted to reference the office in a database, making sure it would remain there, even if the tags might be changed, they would reference the Node ID." - data consumer may reference using both object id and using position + important tag match. See also Overpass API/Permanent ID and Permanent ID Mateusz Konieczny (talk) 08:42, 12 January 2021 (UTC)

Permanent IDs would be nice, but aren't practical.

Whilst the idea of permanent IDs would be amazing in theory, it isn't practical in actual usage. Things are often split up to make them more detailed or something may be split in two, breaking the idea of an ID representing that one thing. This would also bring up the problem of when something should have it's ID changed, e.g. if a shop is closed and a new one opens, should the ID change as it is a new shop, or remain the same? For features of note, Wikidata is what we should be using to give them an ID. --GoodClover (talk) 09:34, 12 January 2021 (UTC)

@GoodClover
If a shopping center is split into multiple buildings instead of one, then all of the new buildings could be added to the relation.
If a shop is closed and a new one is opened, then a new relation should be created because that is now a different POI. That indicates to data consumers that there is no longer any physical referent for the former store. It should probably be deleted after a period of time too since we only store existent items in the database. Lectrician1 (talk) 03:15, 9 January 2023 (UTC)