Permanent ID: Unterschied zwischen den Versionen
Stefan (Diskussion | Beiträge) |
Stefan (Diskussion | Beiträge) |
||
Zeile 7: | Zeile 7: | ||
* 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 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. | * 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 | + | * 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): | So a stable Permanent ID could have the following form (which leads to a fixed length string of 35 chars in total): | ||
Zeile 25: | Zeile 25: | ||
R0001169711#0005+47.45840+008.74343 | R0001169711#0005+47.45840+008.74343 | ||
− | Service: | + | Service: In order to be really useful, a service should be implemented, which returns most recent Permanent ID even if a an object has been changed (thus having another Permanent ID). |
+ | |||
+ | == Instant Solution == | ||
+ | |||
+ | For all those services which can't wait until a Permanent ID solution has been adopted by the OpenStreetMap software stack and community, following instant solution is proposed: | ||
+ | |||
+ | * Use OSM ID number (biginteger) together with OSM type (Node, Way, Relation) | ||
+ | ** either with preceeding N,W,R as string. | ||
+ | ** or as biginteger 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 [https://docs.mapbox.com/vector-tiles/reference/mapbox-streets-v8/#openstreetmap-ids]). | ||
+ | * Additionally optionally store Latitude and Longitude (as centroid from line and polygons) as scaled integers 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. |
Version vom 10. April 2019, 20:28 Uhr
This is an unofficial proposal for a "permanent ID" 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 is left-padded with zeros to get 10 chars ("digits").
- version is 4 digits left padded with zeros.
- coordinates have 5 fixed decimal places (lat is 2 and lon is 3 digits wide, both are signed and left-padded with zeros).
Example: "Schloss Kyburg" (Castle Kyburg) has relation 1169711, version #5 at coordinates 47.4584, 8.74343 which becomes following Permanent ID:
R0001169711#0005+47.45840+008.74343
Service: In order to be really useful, a service should be implemented, which returns most recent Permanent ID even if a an object has been changed (thus having another Permanent ID).
Instant Solution
For all those services which can't wait until a Permanent ID solution has been adopted by the OpenStreetMap software stack and community, following instant solution is proposed:
- Use OSM ID number (biginteger) together with OSM type (Node, Way, Relation)
- either with preceeding N,W,R as string.
- or as biginteger 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 optionally store Latitude and Longitude (as centroid from line and polygons) as scaled integers 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.