|This is a work in progress, feel free to improve, correct, or suggest ideas on the discussion page|
|For Permanent IDs in the context Overpass API, see Overpass API/Permanent ID|
A concept of a "permanent ID" has been frequently floated in the recent email discussions. This page attempts to document the expectations and requirements for such features.
A permanent ID is some opaque string, whose value will always represent the same OSM feature, such as a street, a building, a country outline, or a point of interest. The ID must remain valid even if the country outline geometry is changed, a POI gets renamed, or if the street gets split into multiple segments.
- Permanent ID represents a "concept"
- As editors improve data, any aspect of that data may change. A restaurant node POI may become a building or a relation, and its name may be corrected. A single way representing a street may be split into multiple ways due to a partial speed restriction, or may become two ways separated by a divider. The ID must still point to the original "concept". Consequentially, not every OSM feature needs to have a permanent ID.
- Support ID redirection
- Duplicates happen. As data gets corrected, multiple permanent IDs may be discovered to represent the same concept, and should be merged. Yet, both IDs must remain, and point to the same feature.
- Historical view
- It should be possible to view change history for a given permanent ID.
- API support
- OSM APIs should support basic ID manipulation, such as attaching a new ID to a feature, moving ID from one feature to another, merging duplicates, reverting bad merges, etc.
- Tool support
- As editors modify existing objects, all editing tools need to help editors with maintaining permanent IDs. For example, if an editor splits the road into multiple speed zones, editing tool should create a relation with both segments, and ensure the permanent ID points to that relation.
- Data dump support
- Permanent IDs should become part of the regular data downloads.
- Community education
- Editors should always be aware of the permanent IDs, and should try as much as possible to maintain ID continuity.
Discussion: Relations as Permanent IDs
A relation ID is the closest to satisfying above requirements. Very often a relation represents a concept (e.g. a country or a road), and tends to change the least. The minimum viable product would be to introduce redirects (could be done as a relation with just one relation member, and a single tag redirect=true). A significant work would still be required for tool support and community education.
The use of Key:wikidata is, perhaps, the most stable and reliable manner to obtain Permanent ID of relevant spatial features. Example: the oldest German motorway, the A 555, that is the entity Q17061 at Wikidata, so Q17061 is also a "permanent ID", and as reciprocal use it is pointing to the OSM relation 23092.