Permanent ID for OSM: Unterschied zwischen den Versionen

Aus Geoinformation HSR
Wechseln zu: Navigation, Suche
(→‎Alternatives)
K (→‎Overpass API Permanent ID)
 
(27 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
   This is an '''unofficial proposal for a "OSM permanent ID" (osm_pid) for OpenStreetMap (OSM)'''.  
 
   This is an '''unofficial proposal for a "OSM permanent ID" (osm_pid) for OpenStreetMap (OSM)'''.  
−
   See [https://wiki.openstreetmap.org/wiki/Permanent_ID here] for a more well known place for discussions.  
+
 
 +
   See https://wiki.openstreetmap.org/wiki/Permanent_ID for an official place for discussions.  
  
−
=== Goals and Requirements ===
+
== Status of OSM id ==
  
−
The goal is to get an opaque (eventually fixed) length ASCII string for an OSM id.  
+
One can use OSM id nevertheless (at own risk)! Many variants are known in order to get a single unique identifier value. Some are of type string and others calculate a value of type big integer.  
  
−
That are the design considerations:
+
String type based - using OSM ID number plus a code for Node, Way, Relation e.g. in front (e.g. way/417258377).
−
* 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.
 
−
 
 
−
=== Status of OSM id ===
 
−
 
 
−
One can use OSM id nevertheless (at own risk)! Many variants are known:
 
−
 
 
−
'''As is with OSM id (bigint)''' and a code for Node, Way, Relation e.g. in front (e.g. way/417258377).
 
 
Currently many applications depend on plain osm_id, eventually preceeded by node,way,relation (or N/W/R), like theses web applications (given example of "Denner Hombrechtikon" https://www.openstreetmap.org/node/6313169265):  
 
Currently many applications depend on plain osm_id, eventually preceeded by node,way,relation (or N/W/R), like theses web applications (given example of "Denner Hombrechtikon" https://www.openstreetmap.org/node/6313169265):  
−
* Qwant Maps: Example Denner Hombrechtikon https://www.qwant.com/maps/place/osm:node:6313169265@Denner#map=18.00/47.2519793/8.7681836
+
* "Qwant Maps": Example Denner Hombrechtikon https://www.qwant.com/maps/place/osm:node:6313169265@Denner#map=18.00/47.2519793/8.7681836
−
* Castle Map: Example Schloss Rapperswil https://castle-map.infs.ch/#46.805,8.205,8z,W417258377  
+
* "Castle Map": Example Schloss Rapperswil https://castle-map.infs.ch/#46.805,8.205,8z,W417258377  
−
* Mapbox Vector Tiles: rely also on OSM id plus Node, Way, Relation: see below.
 
  
−
Another adoption of osm_id with enhanced type space (length) properties is to convert it to a '''single big integer''': It's possible to encode the type (Node, Way, Relation) into the OSM id as a single integer (64 bit). (Source: Mapbox, see [https://docs.mapbox.com/vector-tiles/reference/mapbox-streets-v8/#openstreetmap-ids]). Example: "Schloss Kyburg" is a relation with id 1169711, so it becomes 11697114.
+
Integer type based - using shifting on the three elements of OSM ID numbers:
 +
* "Overpass": Overpass uses an own schema to calculate an id of integer-type : https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#By_area_.28area.29
 +
* "Mapbox Streets V7": Another adoption of osm_id with enhanced type space (length) properties is to convert it to a '''single big integer''': It's possible to encode the type (Node, Way, Relation) into the OSM id as a single integer (64 bit). (Source: Mapbox, see older Version V7  of Mapbox Streets [https://docs.mapbox.com/vector-tiles/reference/mapbox-streets-v7/#openstreetmap-ids]). Example: "Schloss Kyburg" is a relation with id 1169711, so it becomes 11697114. See also [https://github.com/openmaptiles/openmaptiles/issues/303#issuecomment-396654079 OpenMaptiles]
  
 
   for Nodes: osm_id = <node id> × 10  (eg. 123 → 1230),  
 
   for Nodes: osm_id = <node id> × 10  (eg. 123 → 1230),  
Zeile 27: Zeile 20:
 
   for Relations: osm_id = (<relation id> × 10) + 4  (eg. 123 → 1234).
 
   for Relations: osm_id = (<relation id> × 10) + 4  (eg. 123 → 1234).
  
−
=== Recommendations ===
+
I, Stefan, prefer W417258377 for a string typed id, and Mapbox Streets V7 for number based.
 +
 
 +
== Recommendations ==
  
−
These is what we currently recommend, depending on the setting (see explanations below):  
+
These is what we currently recommend, depending on the setting (by the exampleof Castle Kyburg, see explanations below):  
  
−
# Node-Way-Relation OSM id (at own risk).
+
# OSM id with Node-Way-Relation code (at own risk). Example 'relation/1169711'.
−
# Wikidata QID with OSM backlink.
+
# Wikidata QID with OSM backlink. Example 'Q573643'.
−
# Overpass Permanent ID with objekt-group-specific ID.
+
# Overpass Permanent ID with objekt-group-specific ID. Example '[out:custom];rel[wikidata=Q573643];out;'
−
# OSM Permanent ID with geo URL
+
# OSM Permanent ID with geo URI. Example 'geo:47.45835,8.74375?q=relation/1169711#5'.
  
−
=== OSM Permanent ID with geo URL ===
+
== OSM Permanent ID with geo URI ==
  
−
A stable Permanent ID could have the following form using the 'geo' URI scheme (variable length to a maximum of currently 42 chars):
+
  This proposal is now also on the official OSM Wiki page: https://wiki.openstreetmap.org/wiki/Permanent_ID#OSM_Permanent_ID_with_geo_URI
 +
 
 +
The goals and requirements of this new proposal are to get a compact human readable string as an OSM id.
 +
* The OSM id alone is not stable enough (as stated above) and it can represent many concepts (and that's by design in OSM).
 +
* The version no. of the OSM object is needed which makes clear which tags are (or have been) referred to.
 +
* Coordinates are needed also, because a change of the way and area geometries does not increment the version number. Coordinates plus parameters fit well to the international 'geo' URI scheme.
 +
 
 +
Thus, a stable OSM Permanent ID could have the following form using the 'geo' URI scheme:
  
 
   'geo:'[+|-]<lon>[+|-]<lat>'?q='[node|way|relation]'/'<osm_id>#<osm_version>
 
   'geo:'[+|-]<lon>[+|-]<lat>'?q='[node|way|relation]'/'<osm_id>#<osm_version>
Zeile 46: Zeile 48:
 
* osm_id an unsigned big integer ("digits").  
 
* osm_id an unsigned big integer ("digits").  
 
* osm_version is an unsigned integer with a hash in front.
 
* osm_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 (multipolygon relation) geometries, the coordinates taken into account are the lat/lon minimum of the geometry.
+
* coordinates (lat/lon) are signed floats (always showing the +/- sign), with no more than 6 digits if possible. In case of a line (linestring) or an area (multipolygon relation) geometry, the coordinates either are taken from any node of the geometry, or calculated e.g. from the center of the geometry.
  
−
Example: "Schloss Kyburg" (Castle Kyburg) has relation 1169711, version #5 at coordinates 47.4584, 8.74343 which becomes following '''OSM Permanent ID''' (osm_pid):
+
The OSM Permanent ID is mainly numeric plus some fixed tokens and it has a variable length of a maximum of 42 chars.
  
−
  '''osm_pid = geo:47.4584,8.74343?q=relation/1169711#5'''
+
Example: "Schloss Kyburg" (Castle Kyburg) has relation 1169711, version #5 at coordinates 47.45835, 8.74375 - and becomes following '''OSM Permanent ID''' (osm_pid):
  
−
=== OSM Permanent ID Service ===
+
  '''geo:47.45835,8.74375?q=relation/1169711#5'''
 +
 
 +
There's an implementation by '''[https://mangrove.reviews/standard Mangrove.reviews]''' with some different parameters q=<name> and u=30 (u = 'uncertainty' in meters). Example: 'geo:47.45835,8.74375?q=Kyburg&u=30' => [https://mangrove.reviews/search?sub=geo%3A47.45835,8.74375%3Fq%3DSchloss%20Kyburg%26u%3D30]
 +
 
 +
  Note: The geo URI looks like a web link (URL). Unfortunately almost no browser supports this URI 'out of the box', only Android systems.
 +
 
 +
== OSM Permanent ID Service ==
  
 
In order to be really useful, a service should be implemented, which returns most recent object given a possibly old Permanent ID if an object has been changed; thus having another Permanent ID where any of it's parts may have changed (most probably just the version no.). Such a service must have access to the fully planet including the history and it must be reliable and responsive.
 
In order to be really useful, a service should be implemented, which returns most recent object given a possibly old Permanent ID if an object has been changed; thus having another Permanent ID where any of it's parts may have changed (most probably just the version no.). Such a service must have access to the fully planet including the history and it must be reliable and responsive.
  
−
== Alternatives ==
+
== Wikidata QID with OSM backlink ==
 +
 
 +
If all objects in question are allowed to become a Wikidata (WD) object, add the Wikidata QID with key 'wikidata' to the OSM object. This one-way link from OSM to Wikidata then can be turned into a two way relationship using database techniques of JOINs. On the other hand you can add to a Wikidata object the coordinates (P625) and the OSM relation id (P402). Many mashups of OSM, Wikidata and Wikipedia use this solution, like the castle dossier (Burgen-Dossier) and others.
 +
 
 +
Example for Castle Kyburg: Q573643.
  
−
   See https://wiki.openstreetmap.org/wiki/Permanent_ID for a more official state of discussions.
+
   Warning: Don't shoehorn all OSM objects to relations just because Wikidata only knows OSM relation id (and no node/way id)!
  
−
=== Wikidata QID with OSM backlink ===
+
== Overpass API Permanent ID ==
  
−
If all objects in question are allowed to become a Wikidata (WD) object, add the Wikidata QID with key 'wikidata' to the OSM object. This one-way link from OSM to Wikidata then can be turned into a two way relationship using database techniques of JOINs. Many mashups of OSM, Wikidata and Wikipedia use this solution, like the castle dossier (Burgen-Dossier) and others.
+
The Permanent_ID from Overpass is a solution where one expects to see the details (= "Link to Browse Object") and which relies purely on (non-geographic) tags: https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID .
  
−
  Warning: Don't shoehorn all OSM object to relations just because of the restriction that Wikidata only knows OSM relation id (P402)!
+
Note that the user has to choose at least coordinates and an "around" parameter in Meters plus an identifying property (i.e. a key or a tag). Without this property e.g. OSM objects can't be disambiguated which are on different levels, like shops or rooms (see below).
  
−
=== 'geo' URI as OSM Permanent ID ===
+
=== Examples ===
  
−
For the use case to really permanently refer to an OSM object see also the URI Scheme "Uniform Resource Identifier for Geographic Locations " ('geo' URI).
+
Castle "Kyburg":
 +
* Coordinates: geo:47.45836,8.74345
 +
* Properties: Wikidata item no. Q573643.
 +
* Overpass Query: <code>[out:custom];rel[wikidata=Q573643];out;</code> (note the minimal output without meta data)
 +
* Alternate Overpass Query: <code></code> (note the minimal output without meta data)
 +
* Overpass Permanent ID with JSON output (API): https://overpass-api.de/api/interpreter?data={{urlencode:[out:json];rel[wikidata=Q573643];out;}}
 +
* Overpass Permanent ID with browse OSM.org: https://overpass-api.de/api/interpreter?data={{urlencode:[out:custom];rel[wikidata=Q573643];out;}}
  
−
For a promising implementation see [https://mangrove.reviews/standard Mangrove.reviews].
+
Castle "Ruine Bernegg":
 +
* Coordinates: geo:47.30888,8.86706
 +
* Properties: type 'historic'
 +
* OSM.org: https://www.openstreetmap.org/way/289329862#map=19/47.30888/8.86706
 +
* Overpass Query: <code>[out:json];nwr(around:5,47.30888,8.86706)[historic];out meta center;</code>
 +
* Overpass Permanent ID with JSON output (API): https://overpass.osm.ch/api/interpreter?data=%5Bout%3Ajson%5D%3Bnwr%28around%3A5%2C47.30888%2C8.86706%29%5Bhistoric%5D%3Bout%20meta%20center%3B
 +
* Overpass Permanent ID with browse OSM.org: https://overpass.osm.ch/api/interpreter?data=%5Bout%3Acustom%5D%3Bnwr%28around%3A5%2C47.30888%2C8.86706%29%5Bhistoric%5D%3Bout%20meta%20center%3B
  
−
Example: Supermarket Denner Partner, Hombrechtikon, https://www.openstreetmap.org/node/6313169265
+
Restaurant "Mensa OST RJ":
−
* geo:47.2520925,8.7683656?q=DennerPartner&u=30 
+
* Coordinates: geo:47.2229817,8.8163386
−
* [https://mangrove.reviews/search?sub=geo%3A47.2520925,8.7683656%3Fq%3DDenner%20Partner%26u%3D30&q=Denner,%20Hombrechtikon in Mangrove.reviews]
+
* Properties amenity=restaurant (at ground level).
 +
* OSM.org: https://www.openstreetmap.org/node/1706090806
 +
* Overpass Query: <code>[out:json];nwr(around:5,47.2229817,8.8163386)[amenity="restaurant"];out meta center;</code>
 +
* Overpass Permanent ID with JSON output (API):  https://overpass.osm.ch/api/interpreter?data=%5Bout%3Ajson%5D%3Bnwr%28around%3A5%2C47.2229817%2C8.8163386%29%5Bamenity%3D%22restaurant%22%5D%3Bout%20meta%20center%3B
 +
* Overpass Permanent ID with browse OSM.org:  https://overpass.osm.ch/api/interpreter?data=%5Bout%3Acustom%5D%3Bnwr%28around%3A5%2C47.2229817%2C8.8163386%29%5Bamenity%3D%22restaurant%22%5D%3Bout%20meta%20center%3B
  
−
=== Overpass' Permanent ID ===
+
Room "Auditorium OST RJ":
 +
* Coordinates: geo:47.223115,8.8164985
 +
* Properties: room="auditorium" (at level 1, note that's at same coords as Mensa below).
 +
* OSM.org: https://www.openstreetmap.org/way/903296474
 +
* Overpass Query: <code>[out:json];nwr(around:10,47.2229817,8.8163386)[room="auditorium"];out meta center;</code>
 +
* Overpass Permanent ID with JSON output (API): https://overpass.osm.ch/api/interpreter?data=%5Bout%3Ajson%5D%3Bnwr%28around%3A10%2C47.2229817%2C8.8163386%29%5Broom%3D%22auditorium%22%5D%3Bout%20meta%20center%3B
 +
* Overpass Permanent ID with browse OSM.org: https://overpass.osm.ch/api/interpreter?data=%5Bout%3Acustom%5D%3Bnwr%28around%3A9%2C47.2229817%2C8.8163386%29%5Broom%3D%22auditorium%22%5D%3Bout%20meta%20center%3B
 +
* Overpass Permanent ID with browse OSM.org (worldwide instance): https://overpass-api.de/api/interpreter?data=%5Bout%3Acustom%5D%3Bnwr%28around%3A10%2C47.2229817%2C8.8163386%29%5Broom%3D%22auditorium%22%5D%3Bout%20meta%20center%3B
  
−
The Permanent_ID from Overpass is a solution where one expects to see the details (= "Link to Browse Object") and which relies purely on (non-geographic) tags: https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID
+
Building "OST RJ Gebäude 4":
 +
* Coordinates: geo:47.223115,8.8164985
 +
* Properties: name~"Gebäude 4" (note that's still at same coords this time referring to an enclosing feature; around was increased again due to the larger object extension).
 +
* OSM.org: https://www.openstreetmap.org/way/34754484
 +
* Overpass Query: <code>[out:json];nwr(around:15,47.2229817,8.8163386)[name~"Gebäude 4"];out meta center;</code>
 +
* Overpass Permanent ID with JSON output (API): https://overpass.osm.ch/api/interpreter?data=%5Bout%3Ajson%5D%3Bnwr%28around%3A15%2C47.2229817%2C8.8163386%29%5Bname~%22Geb%C3%A4ude%204%22%5D%3Bout%20meta%20center%3B
 +
* Overpass Permanent ID with browse OSM.org: https://overpass.osm.ch/api/interpreter?data=%5Bout%3Acustom%5D%3Bnwr%28around%3A15%2C47.2229817%2C8.8163386%29%5Bname~%22Geb%C3%A4ude%204%22%5D%3Bout%20meta%20center%3B
  
−
=== Others ===  
+
== Others ==
  
 
* OpenLR (Location Referencing) - a free spec. by TomTom for linear geometries like streets [http://www.openlr.org/].
 
* OpenLR (Location Referencing) - a free spec. by TomTom for linear geometries like streets [http://www.openlr.org/].
 
* The geographical object IDs from authorities like Ordnance Survey UK or Swisstopo CH.
 
* The geographical object IDs from authorities like Ordnance Survey UK or Swisstopo CH.

Aktuelle Version vom 21. Februar 2021, 22:55 Uhr

 This is an unofficial proposal for a "OSM permanent ID" (osm_pid) for OpenStreetMap (OSM). 
 
 See https://wiki.openstreetmap.org/wiki/Permanent_ID for an official place for discussions.

Status of OSM id

One can use OSM id nevertheless (at own risk)! Many variants are known in order to get a single unique identifier value. Some are of type string and others calculate a value of type big integer.

String type based - using OSM ID number plus a code for Node, Way, Relation e.g. in front (e.g. way/417258377). Currently many applications depend on plain osm_id, eventually preceeded by node,way,relation (or N/W/R), like theses web applications (given example of "Denner Hombrechtikon" https://www.openstreetmap.org/node/6313169265):

Integer type based - using shifting on the three elements of OSM ID numbers:

  • "Overpass": Overpass uses an own schema to calculate an id of integer-type : https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#By_area_.28area.29
  • "Mapbox Streets V7": Another adoption of osm_id with enhanced type space (length) properties is to convert it to a single big integer: It's possible to encode the type (Node, Way, Relation) into the OSM id as a single integer (64 bit). (Source: Mapbox, see older Version V7 of Mapbox Streets [1]). Example: "Schloss Kyburg" is a relation with id 1169711, so it becomes 11697114. See also OpenMaptiles
 for Nodes: osm_id = <node id> × 10  (eg. 123 → 1230), 
 for Ways: osm_id = (<way id> × 10) + 1  (eg. 123 → 1231), 
 for Relations: osm_id = (<relation id> × 10) + 4  (eg. 123 → 1234).

I, Stefan, prefer W417258377 for a string typed id, and Mapbox Streets V7 for number based.

Recommendations

These is what we currently recommend, depending on the setting (by the exampleof Castle Kyburg, see explanations below):

  1. OSM id with Node-Way-Relation code (at own risk). Example 'relation/1169711'.
  2. Wikidata QID with OSM backlink. Example 'Q573643'.
  3. Overpass Permanent ID with objekt-group-specific ID. Example '[out:custom];rel[wikidata=Q573643];out;'
  4. OSM Permanent ID with geo URI. Example 'geo:47.45835,8.74375?q=relation/1169711#5'.

OSM Permanent ID with geo URI

 This proposal is now also on the official OSM Wiki page: https://wiki.openstreetmap.org/wiki/Permanent_ID#OSM_Permanent_ID_with_geo_URI

The goals and requirements of this new proposal are to get a compact human readable string as an OSM id.

  • The OSM id alone is not stable enough (as stated above) and it can represent many concepts (and that's by design in OSM).
  • The version no. of the OSM object is needed which makes clear which tags are (or have been) referred to.
  • Coordinates are needed also, because a change of the way and area geometries does not increment the version number. Coordinates plus parameters fit well to the international 'geo' URI scheme.

Thus, a stable OSM Permanent ID could have the following form using the 'geo' URI scheme: 

 'geo:'[+|-]<lon>[+|-]<lat>'?q='[node|way|relation]'/'<osm_id>#<osm_version>

where:

  • the form 'relation/1169711' is the same as e.g. Overpass JSON output produces as @id.
  • osm_id an unsigned big integer ("digits").
  • osm_version is an unsigned integer with a hash in front.
  • coordinates (lat/lon) are signed floats (always showing the +/- sign), with no more than 6 digits if possible. In case of a line (linestring) or an area (multipolygon relation) geometry, the coordinates either are taken from any node of the geometry, or calculated e.g. from the center of the geometry.

The OSM Permanent ID is mainly numeric plus some fixed tokens and it has a variable length of a maximum of 42 chars.

Example: "Schloss Kyburg" (Castle Kyburg) has relation 1169711, version #5 at coordinates 47.45835, 8.74375 - and becomes following OSM Permanent ID (osm_pid): 

 geo:47.45835,8.74375?q=relation/1169711#5

There's an implementation by Mangrove.reviews with some different parameters q=<name> and u=30 (u = 'uncertainty' in meters). Example: 'geo:47.45835,8.74375?q=Kyburg&u=30' => [2] 

 Note: The geo URI looks like a web link (URL). Unfortunately almost no browser supports this URI 'out of the box', only Android systems.

OSM Permanent ID Service

In order to be really useful, a service should be implemented, which returns most recent object given a possibly old Permanent ID if an object has been changed; thus having another Permanent ID where any of it's parts may have changed (most probably just the version no.). Such a service must have access to the fully planet including the history and it must be reliable and responsive.

Wikidata QID with OSM backlink

If all objects in question are allowed to become a Wikidata (WD) object, add the Wikidata QID with key 'wikidata' to the OSM object. This one-way link from OSM to Wikidata then can be turned into a two way relationship using database techniques of JOINs. On the other hand you can add to a Wikidata object the coordinates (P625) and the OSM relation id (P402). Many mashups of OSM, Wikidata and Wikipedia use this solution, like the castle dossier (Burgen-Dossier) and others.

Example for Castle Kyburg: Q573643. 

 Warning: Don't shoehorn all OSM objects to relations just because Wikidata only knows OSM relation id (and no node/way id)!

Overpass API Permanent ID

The Permanent_ID from Overpass is a solution where one expects to see the details (= "Link to Browse Object") and which relies purely on (non-geographic) tags: https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID .

Note that the user has to choose at least coordinates and an "around" parameter in Meters plus an identifying property (i.e. a key or a tag). Without this property e.g. OSM objects can't be disambiguated which are on different levels, like shops or rooms (see below).

Examples

Castle "Kyburg":

Castle "Ruine Bernegg":

Restaurant "Mensa OST RJ":

Room "Auditorium OST RJ":

Building "OST RJ Gebäude 4":

Others

  • OpenLR (Location Referencing) - a free spec. by TomTom for linear geometries like streets [3].
  • The geographical object IDs from authorities like Ordnance Survey UK or Swisstopo CH.
Von «https://giswiki.hsr.ch/index.php?title=Permanent_ID_for_OSM&oldid=68052»