Permanent ID for OSM: Unterschied zwischen den Versionen
Stefan (Diskussion | Beiträge) |
Stefan (Diskussion | Beiträge) |
||
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 here] for a more well known place for discussions. | ||
− | + | == Status of OSM id == | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
One can use OSM id nevertheless (at own risk)! Many variants are known: | One can use OSM id nevertheless (at own risk)! Many variants are known: | ||
Zeile 27: | Zeile 19: | ||
for Relations: osm_id = (<relation id> × 10) + 4 (eg. 123 → 1234). | for Relations: osm_id = (<relation id> × 10) + 4 (eg. 123 → 1234). | ||
− | + | ||
+ | == Recommendations == | ||
These is what we currently recommend, depending on the setting (by the exampleof Castle Kyburg, see explanations below): | These is what we currently recommend, depending on the setting (by the exampleof Castle Kyburg, see explanations below): | ||
Zeile 36: | Zeile 29: | ||
# OSM Permanent ID with geo URL. Example 'geo:47.45835,8.74375 ?q=relation/1169711#5'. | # OSM Permanent ID with geo URL. Example 'geo:47.45835,8.74375 ?q=relation/1169711#5'. | ||
− | |||
− | + | == OSM Permanent ID with geo URL == | |
+ | |||
+ | Goals and Requirements: The goal is to get an opaque (eventually fixed) length ASCII string for an OSM id. | ||
+ | * 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. | ||
+ | |||
+ | Therefor, a stable OSM Permanent ID could have the following form using the international '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 47: | Zeile 46: | ||
* 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 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. | ||
+ | |||
+ | It has a variable length to a maximum of currently 42 chars. | ||
Example: "Schloss Kyburg" (Castle Kyburg) has relation 1169711, version #5 at coordinates 47.45835, 8.74375 which becomes following '''OSM Permanent ID''' (osm_pid): | Example: "Schloss Kyburg" (Castle Kyburg) has relation 1169711, version #5 at coordinates 47.45835, 8.74375 which becomes following '''OSM Permanent ID''' (osm_pid): | ||
Zeile 52: | Zeile 53: | ||
'''osm_pid = geo:47.45835,8.74375?q=relation/1169711#5''' | '''osm_pid = 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 (for 'uncertainty' in meters). | + | There's an implementation by '''[https://mangrove.reviews/standard Mangrove.reviews]''' with some different parameters q=<name> and u=30 (for '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 == | == OSM Permanent ID Service == |
Version vom 22. Juli 2020, 21:30 Uhr
This is an unofficial proposal for a "OSM permanent ID" (osm_pid) for OpenStreetMap (OSM).
See here for a more well known place for discussions.
Inhaltsverzeichnis
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):
- 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
- 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 [1]). Example: "Schloss Kyburg" is a relation with id 1169711, so it becomes 11697114.
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).
Recommendations
These is what we currently recommend, depending on the setting (by the exampleof Castle Kyburg, see explanations below):
- OSM id with Node-Way-Relation code (at own risk). Example 'relation/1169711'.
- Wikidata QID with OSM backlink. Example 'Q573643'.
- Overpass Permanent ID with objekt-group-specific ID. Example '[out:custom];rel[wikidata=Q573643];out;'
- OSM Permanent ID with geo URL. Example 'geo:47.45835,8.74375 ?q=relation/1169711#5'.
OSM Permanent ID with geo URL
Goals and Requirements: The goal is to get an opaque (eventually fixed) length ASCII string for an OSM id.
- 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.
Therefor, a stable OSM Permanent ID could have the following form using the international '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 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.
It has a variable length to a maximum of currently 42 chars.
Example: "Schloss Kyburg" (Castle Kyburg) has relation 1169711, version #5 at coordinates 47.45835, 8.74375 which becomes following OSM Permanent ID (osm_pid):
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 (for '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.
Alternatives
See https://wiki.openstreetmap.org/wiki/Permanent_ID for a more official state of discussions.
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' 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
Example for Castle Kyburg: '[out:custom];rel[wikidata=Q573643];out;' => Q573643
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.