Proposed features/new id
|Definition:||replacement ID for deleted OSM IDs|
- 1 Summary
- 2 Details
- 3 Example Use Cases
OSM internal ID's do not describe physical objects but geometrical objects on a map.
If such a object gets deleted it should be possible to tag a supersede ID if appplicable. This could provide some sort of ID stabilization and traceability of ID's.
The key is "osm:new_id" the value "type:ID". The type can be "node", "rel", "way". The ID is the OSM ID of the replacement.
A rule of thumb is that this key should only be applied to deleted IDs.
Example Use Cases
expansion of POI nodes into buildings
node A is deleted, new building B A.osm:new_id = way:B
splitting of ways (old ID would then point to only half)
A split to A,B no ID gets the tag because none is deleted
merging (old ID would become invalid in 50% of cases)
- example 1: Relations for long-distance routes created in several places until they "meet", and are merged, with one of them being deleted.
- example 2: a POI node might later be joined to be part of an area representing a shop; this shop area might later be joined to others to represent an entire building that contains several shops
A,B gets merged to way A: B deleted (visible=false) B.osm:new_id = way:A
supersede multiple objects (a merge operation)
A,B,C gets replaced by rel C A.osm:new_id = rel:C B.osm:new_id = rel:C A,B deleted (invisible)
re-mapping of stuff
- in the course of the license change
- re-structuring of relations
- 0.7 area data type (lots of existing areas get a new ID)
mapping error (mistake)
delete ID, no new_id tag
real object moves
Restaurant moves should it keep the same ID? If it is renamed? If it goes bankrupt, is sold, renovated, and reopened by a different owner.
the node describes a point on the map, not a restaurant, therefore no new ID in this cases.