Wikidata:Property proposal/OpenStreetMap node ID
OpenStreetMap node ID edit
Originally proposed at Wikidata:Property proposal/Place
Description | OpenStreetMap node ID |
---|---|
Represents | OpenStreetMap node (Q42375175) |
Data type | External identifier |
Allowed values | [1-9][0-9]{0,10} |
Example 1 | Mount Everest (Q513) → 8827029797 |
Example 2 | Switzerland (Q39) → 1504546320 |
Example 3 | Embassy of Switzerland, Stockholm (Q10663823) → 372823595 |
Planned use | transfer all existing OpenStreetMap node IDs from Property:P10689 immediately after property creation |
Number of IDs in source | 8275903044+ |
Formatter URL | https://www.openstreetmap.org/node/$1 |
Single-value constraint | yes |
Distinct-values constraint | yes |
Motivation edit
While one of the three types of OpenStreetMap element, namely the OpenStreetMap relation, has their IDs stored in one property that doesn't store an additional prefix, the two other types, namely OpenStreetMap node and OpenStreetMap way, have their IDs stored in a combined property that stores the additional prefixes "node/" or "way/".
The current setup makes data management including querying, preventing wrong data (e.g. via constraint checks) and comparing with external data sets more difficult and requires more storage space.
Moving the OpenStreetMap node IDs to a dedicated property:
- results in mapping the IDs of the three subclasses of OpenStreetMap elements to one property each
- saves storage space
- makes it easier to extract the IDs, e.g. without the need to split strings, and to sort them numerically
- allows for an easier statement of the external quantity of IDs in the property page
- allows for easier reporting of the quantity of property usage, especially as main statement and easier tracking where not used as main statement
- makes it easier to perform constraint checks
- e.g. on items of which type an OpenStreetMap node ID can be used (maybe items about roads, streets and rivers shall store only way IDs and those for mountain peaks only node IDs)
- e.g. implement a single value constraint check - there should probably be only one node for each item in Wikidata, while there can be several OpenStreetMap ways for e.g. a street.
While in OpenStreetMap more nodes than ways exist, in Wikidata currently fewer node IDs than way IDs are stored. As is currently recommended at Property:P10689 "OpenStreetMap element" to store OpenStreetMap relation IDs instead, if available, the page for the OpenStreetMap node ID could recommend to store OpenStreetMap way IDs instead, if available.
Two lists of all current pairs of items and OpenStreetMap way or node IDs containing the prefix can be obtained via WDQS:
- "node": https://w.wiki/6Sgy - 8946 results
- "way": https://w.wiki/6Sh8 - 16359 results
Item label | Item ID | Property label | Property ID | Property usage | OSM documentation | OSM statistics |
---|---|---|---|---|---|---|
OpenStreetMap numeric user ID | Q116153645 | OpenStreetMap numeric user ID | P8754 | 10 123 236 | ||
OpenStreetMap element | Q114733246 | https://wiki.openstreetmap.org/wiki/Elements | 9 214 533 524 | |||
OpenStreetMap relation | Q100320716 | OpenStreetMap relation ID | P402 | 245 977 | https://wiki.openstreetmap.org/wiki/Relation | 10 755 657 |
OpenStreetMap way | Q100320715 | (OpenStreetMap way ID) | (P10689) | (~16 300) https://w.wiki/6Sgq | https://wiki.openstreetmap.org/wiki/Way | 927 874 823 |
OpenStreetMap node | Q42375175 | (OpenStreetMap node ID) | (P11...) | (~8 900) https://w.wiki/6Sgv | https://wiki.openstreetmap.org/wiki/Node | 8 275 903 044 |
(OpenStreetMap way or node) | - | OpenStreetMap element | P10689 | 25 301 | 9 203 777 867 |
After transfer of values the current Property:P10689 "OpenStreetMap element" (actually "OpenStreetMap way or node ID") can be restricted to way IDs, be renamed to "OpenStreetMap way ID" and the prefix "way/" can be removed.
GeoGQL (talk) 13:02, 14 March 2023 (UTC)
Property | node | way |
---|---|---|
single value constraint | probably yes | not for some types, e.g. streets can consist of multiple "ways" |
conflicts with OpenStreetMap relation ID | not for some types, e.g. countries | probably yes |
Wikidata item type | probably not for streets and rivers | maybe any type is possible |
format string | probably more digits since more values exist in OSM | probably fewer digits since fewer values exist in OSM |
reference for coordinates of a point | possible | less likely since a way may contain coordinates for several points |
GeoGQL (talk) 07:21, 16 March 2023 (UTC)
Discussion edit
- @MasterRus21thCentury: you created Property:P10675, @Pamputt: you deleted the former and created Property:P10689 - can you have a look at the proposal and give feedback? If anything is fine, could you create it? GeoGQL (talk) 13:01, 15 March 2023 (UTC)
- @Jura1, GZWDer, NMaia, Artoria2e5, Bluerasberry, Arminus68:, @Abbe98, Waldyrious, Pigsonthewing, Marty5550, Nate Wessel: who took part in the previous discussion Pamputt (talk) 09:24, 16 March 2023 (UTC)
- Support --Waldyrious (talk) 10:43, 16 March 2023 (UTC)
- Support --sk (talk) 11:59, 16 March 2023 (UTC)
- Comment - as reminder: OSM node and way and relation ids are not promised to be stable and may change without warning. It may work better to look for objects tagged with https://wiki.openstreetmap.org/wiki/Key:wikidata (though some are broken and wait for fixes) Mateusz Konieczny (talk) 19:04, 16 March 2023 (UTC)
- That they can change is even more a reason to move the node IDs to their own property. The better the setup the easier it will be to find and fix errors. PS: The link https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/ points to something related to Wikipedia, not Wikidata. GeoGQL (talk) 20:41, 16 March 2023 (UTC)
- Support -- it's better than shoving URLs everywhere! --Artoria2e5 (talk) 04:19, 21 March 2023 (UTC)
- Support -- Nate Wessel (talk) 15:19, 27 March 2023 (UTC)