Permanent ID

This is an unofficial proposal for a "permanent ID" (osm_pid) for OpenStreetMap (OSM).

See https://wiki.openstreetmap.org/wiki/Permanent_ID for a more official state of discussions.

The goal is to get an opaque fixed length ASCII string. And that are the design considerations:

• The OSM id alone is not stable enough (as probably most agree); and it can represent many concepts (and that's by design in OSM).
• The version no. of the object is needed which makes clear which tags are (or have been) referred to.
• Coordinates are needed, because a change of the way and area geometries does not increment the version number.

So a stable Permanent ID could have the following form (which leads to a fixed length string of 35 chars in total):

 [N|W|R]<osm_id>#<version>[+|-]<lon>[+|-]<lat>

where:

• N,W,R stands for Node, Way, or Relation.
• osm_id ann unsigned big integer ("digits").
• version is an unsigned integer with a hash in front.
• coordinates (lat/lon) are signed floats (always showing the +/- sign), with a maximum of 6 digits. In case of a line (linestring) or an area/relation (polygon) geometries the coordinates taken into account are the lat/lon minimum of the geometry.

Example: "Schloss Kyburg" (Castle Kyburg) has relation 1169711, version #5 at coordinates 47.4584, 8.74343 which becomes following Permanent ID:

 osm_pid = R1169711#5+47.4584+8.74343

Service: In order to be really useful, a service should be implemented, which returns most recent Permanent ID even if an object has been changed (thus having another Permanent ID).

Alternative Encodings

Same "triple" values as above (osm type/id, version and coordinates) but with different encodings:

Use OSM ID number (big integer 64 bit) together with OSM type (Node, Way, Relation)

• either with preceeding N,W,R as string.
• or as integer (32 bit) with following formula: osm_id = <node id> × 10 (eg. 123 → 1230), osm_id = (<way id> × 10) + 1 (eg. 123 → 1231), osm_id (<relation id> × 10) + 4 (eg. 123 → 1234). (Source: Mapbox, see [1]).

Additionally use these values for validation, separated e.g. by a "#":

• version (small integer 16 bit)
• Latitude and Longitude (as centroid from line and polygons) as signed integers (32 bit) with a scale factor of 1e7, so an integer Latitude of -412870685 equates to -41.2870685 (as the original OSM database schema in "Rails port"), in order to retain a stable reference.

Example: "Schloss Kyburg" having relation id 1169711 with version 5 at coordinates 47.4584, 8.74343 (see also above) becomes following Instant ID:

 osm_pid2 = 11697114#5#474584000#87434300 => 11697114 plus osm_version = 5, osm_lat = 474584000, osm_lon = 87434300