Using OpenStreetMap id as permanent identifiers
Often, programmers want to permanently reference to OpenStreetMap-objects by using the OpenStreetMap-id, especially for long term references. Think for example a third-party review website, using the OSM-id as sole means to identify _what_ they are reviewing.
This is a bad idea, because the OSM-id might change. While it can help as a pragmatic way to link items from another dataset and OSM together, other mechanisms must exist to tie them together.
This page serves to explain why this is and is meant to be linked to from documentation from various services.
The ID might change when the map is updated
A POI (for example a restaurant) might be tagged with a node, e.g. _node/1234_. Reviews are made, items are linked to this.
After a few years, another contributor gets access to newer imagery and uses this to draw the outline of the restaurant building. This contributor removes the original node representing this; resulting in the id _way/5678_. All the original links are now completely useless.
Multiple POI might refer to the same object
In some cases, multiple OSM-objects might refer to the same entity. For example, countries, cities, municipalities, ... are often represented by both a relation (describing the boundary) and a 'centerpoint' node, where the label is placed. What object should be refered to in this case?
A mapping error might also be the cause of duplicated elements, e.g. one contributor adding an OSM-object for an entity that already had an OSM object representing it. This contributor might make this error because of many reasons, such as:
- The map app they are using has outdated map data (such as OsmAnd), meaning the mapper didn't see the object
- The location might be wrong on one of the objects
- The tagging might be different
- Multiple objects are used to describe different aspects of the entity, e.g. a place that acts as both a restaurant and a hotel. People may stay in the hotel and eat in the restaurant, but can also stay without eating there or eat there without staying there. In OSM, this might be represented by a restaurant-node and a hotel-node, but the owners might not think of this in different terms.
An OSM-object can mean multiple things during its lifetime
An OSM-object can be repurposed during the lifetime of the object. For example, a venue might start as a pub, start serving food and become a restaurant over the years. The OSM-object's tagging can evolve together, changing from {Tag|amenity|restaurant} to {Tag|leisure|pub} when the time is right.
In the same vein, someone can take a POI (say - representing a devout monastery which admits guests to stay for a few days), drag it to a completely different place and update all tags to correctly represent this new place (for example a brothel). This changes the context completely for third-party platforms referencing OSM through the identifier. For example, a review referencing `node/1234` about "how hospitable they are, and how kind Maria is" is quite different now...
To prevent this kind of hijacking, the _version number_ of the OSM-object should be included. See Using version numbers for some more info. A timestamp is not enough - someone might make a review when using an old version of the map data.
When is an object the same object?
On a more philosophical level: when does an object need a new identifier? When a building is torn down and completely rebuilt, a new identifiers is justifiable; but what amount of renovations are needed to trigger a new identifier? In the case of a restaurant, is a change of ownership a trigger for a new identifier? A change of name? A change of location, with the same owner and equipment?
No clear-cut answers exist; most people will have different-cutoff points. While OpenStreetMap deals pragmatically with this, this is especially hard for review services: when are reviews no longer applicable for a business?