Data Stability

Hi there,
I have a question regarding how “stable” the data of OSM is in the following sence:
can one trunst on one OSMID beeing tomorrow if it was in the Database yesterday ?
Background is I am thinking about building a Webapp that could use the OSM IDs as sort of primary key for its own datamodel.
But that would of course break if OSM entities / ids would be deleted on a regular basis to be substituted by another osm ID:.
Is there a rule of thumb or any hint ?

Thanks in advance

OSM IDs often happen to be stable for some time, but that’s in no way guaranteed. There are many editing operations (such as merging two ways, or replacing a POI node with an outline) which affect objects’ IDs and might be performed at any time. It’s sometimes not practical to prevent changing IDs, and doing so is not part of standard mapping practice. It’s even possible for an OSM element to represent a completely different object with different tags and a different position tomorrow. The latter event is rare and usually not considered desirable, but will occasionally happen.

Nevertheless, OSM IDs might be static enough to be of some practical use, if accompanied by a fallback. It has been suggested that OSM IDs could be used most of the time because of ease of use or performance benefits, but if the object’s deletion is detected, stored information could be used to retrieve the new ID of the same real-world entity - an operation that would of course be much more costly than the regular ID-based access, but wouldn’t have to be performed frequently. I could imagine that a coordinate and some information from tags (such as rough object category, address and/or name, with the exact tags probably best chosen dependent on the use case) could work most of the time. I’m not aware of any public implementation of such fallback mechanisms.

Despite the obvious problems of the IDs, there actually are external services which use OSM IDs with no fallback solution (as far as I know) for linking to OSM, such as Flickr. However, it’s only a low-priority feature in that case, and I still wouldn’t recommend to rely on raw OSM IDs for important functionality.


thanks a lot for this really helpful and informative answer. I will go through my concept again considering the workarounds you mentioned.
Thanks again.