Property talk:P402/Archive 1

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Notes

See http://wiki.openstreetmap.org/wiki/Relation for reference. --fryed-peach (talk) 08:47, 9 April 2013 (UTC)

Deletion request

See Wikidata:Properties_for_deletion#Property:P402. --  Docu  at 09:41, 25 April 2013 (UTC)

There was also some discussion about it at Wikidata_talk:List_of_properties#ID_OpenStreetMap. --  Docu  at 09:43, 25 April 2013 (UTC)

The deletion request discussion is now archived at Wikidata:Requests for deletions/Archive/2013/Properties/1#Property:P402. --Stevenliuyi (talk) 10:00, 11 May 2013 (UTC)

See also:

• archived Wikidata_talk:List_of_properties/Archive/2013/04#ID_OpenStreetMap
• Wikidata:Project_chat/Archive/2013/05#Property_P402_and_OpenStreetMap
• en:Wikipedia talk:WikiProject Geographical coordinates/Archive 28#Wikidata.2C_.7B.7Bcoord.7D.7D.2C_and_OpenStreetMap_relations Unfortunately the objections to this implementation by the most competent OSM-tool-developers of Wikipedia, Dschwen and Kolossos, were ignored. --Atlasowa (talk) 23:56, 15 January 2014 (UTC)

Alternatives

The OpenStreetMap-API is designd to serve editing purposes in OpenStreetMap. The primary goal of this api is to serve data to openstreetmap-contributors to enhance, update and edit the geo-database. For Wikidata and the osm-relation property this has several consequences:

1. 1) In the long term it should NOT be the usual case to directly link to the osm api as it is the case now. If we asssume the wikidata properties are used widely in the wikimedia projects as well as elsewhere in the web, this would produce a lot of traffic on an api that is not primarily designed to serve data for this purpose.

Of course as osm is free data this could be solved by linking to another osm readonly database hosted somewhere else with appropriate caching mechanisms.

1. 2) OSM-IDs are NOT STABLE. This has been discussed several times afaik even in the wikidata context. To sum up: any OSM ID may change it's semantical meaning (this is bad style in osm, but possible and not forbidden). Any real object represented by something in OSM may be refined and further be represented by another ID (even by another type). IDs to relations could be seen as more stable as the probability to replace them is lower, but this isn't a rule, it's more something we could assume out of statistics. This may change in future, too, e.g. with new Versions of the osm api.

To prevent changing IDs to harm the wikidata project by creating missing links, we may use th Overpass-API instead, see Overpass Permanent ID. This is more a query, but as it defines a link in terms of properties of the object, a broken link would refer to something semantically problematic, and the chance to get a technically working link to a semantically different object is much lower than with links to osm ids. --Jongleur1983 (talk) 12:39, 12 August 2013 (UTC)

OSM relation ID is as stable as name of Wikipedia page. Thus there can be changes for new relation (mainly if it is incomplete, thus multiple relations for one subject are created and then merged), but it is pretty stable for existing complete relations, while there is no reason to change it. As we link almost exclusively to complete relations, in reality the change of id will be very rare and thus not need any complicated solution (i think bot checking from time to time if osmrelations linked form WD were not deleted is sufficient). --Jklamo (talk) 09:20, 29 August 2013 (UTC)

Just to mention it another time: there is a difference in steadiness of OSM-IDs in comparison to wikipedia article names: three examples

• if you have a street referenced by ID, it might be split up into two parts, for example because a part of it gets another speed limit. After the split only the old part of the street is referenced.
• when an object in OSM has to many elements (above 2000?), it is a candidate for splitting it up into different parts and create a relation for it. This ends up in a new ID (for the relation and at least for n-1 parts of the relation).
• There are also objects, which have a very "long" history ... at least in the past this was also a reason for creating new objects to have a "short" history.

And there are more cases in reality, also for relations. So the ID of an object in OSM sometimes changes just for technical reasons. This is a difference to wikipedia, where the link only changes, if the naming of the article was not correct (for different reasons of course). There were some discussions about that (for example http://gis.19327.n5.nabble.com/OSM-relation-ID-property-in-Wikidata-td5759480.html). WIWOSM solved this problem in a special way, may not be the right way, but it works. You should at least consider the OSM-ID as a subject to change and be prepared to change the wikidata way of referring to osm :-) Greetings -- Schusch (talk) 09:13, 26 October 2013 (UTC)

Alternatives to this property

From everything I heard so far, it seems having an OSM id in Wikidata is wrong because of its instability. I think OSM DB should link to Wikidata IDs (but not to Wikipedia, because article names are also unstable). Our new maps service could eventually allow WikidataID-based way to get that data out, e.g. given a wikidata id, get the shape outlining a city. --Yurik (talk) 17:01, 25 May 2016 (UTC)

Why "Relation"?

AFAIK, OSM has points, lines, and more structured records which I guess are called Relations. But just because something is called Relation in OSM, doens't mean htat "Relation" is a good name for this prop.

Berlin is a place, it's not a Relation. Please let's rename this to "OpenStreetMap ID" (or "OpenStreetMap place ID"). Thanks! Vladimir Alexiev (talk) 11:08, 15 June 2016 (UTC)

That wouldn't work that easy because

1. A relation may represent other stuff than just places and
2. places may also be represented by ways or nodes, for which the OSM item's type would need to be known.

On the other hand, there seems to be no Property for Ways and Nodes, but it's (from the OSM side) not recommended to use their IDs for reference anyway, because the ID can change very easily and might even represent a completly different real-world object then. --Nenntmichruhigip (talk) 11:30, 16 June 2016 (UTC)

Decision subject to change, depending on near-future Permanent_ID implementation (as generic "place ID" independent of geometry). --Krauss (talk) 17:22, 10 July 2018 (UTC)

Unstable property ?

At https://phabricator.wikimedia.org/T145284 , use of this property was rejected due to stability issues. If this is confirmed, I wonder if we should keep it.
--- Jura 16:50, 1 November 2016 (UTC)

It's better to use the key:wikidata on OSM as said on WIWOSM. Here's a video guide to add it easily with iD. The RedBurn (ϕ) 13:14, 12 October 2017 (UTC)

NOTE: depending on near-future Permanent_ID implementation (as stable/persistent ID), it will ne not a problem. --Krauss (talk) 17:24, 10 July 2018 (UTC)

Which is better?

Is it better to create P402 links to OSM, or wikidata: properties on OSM? Is there a bot that automatically creates the inverse links in either direction?

The English Wikipedia infobox mapframe seems to pick up the boundary if it is linked from OSM, but the documentation suggests it needs P402, so I'm not sure if there are hidden features, or magic translations. --ScottDavis (talk) 05:03, 28 September 2018 (UTC)

P402 is not needed for the infobox. The wikidata tag + identifier on related OSM objects is all that's needed. --Hjart (talk) 07:56, 31 January 2019 (UTC)

Please, do you support the implementation of a new Wikidata-to-OSM service

The new service will solve the cited problem of "only relations": will be possible to point OSM Map Features represented by nodes or ways.

The new server must br hosted at the Openstreetmap-side, but needs the support of the Wikidata community also. The service will redirect Wikidata item "Q" identidiers by http://osm.org/Q$1 (or wikidata.osm.org or other) to the respective geometry. Examples:

• Relation. The Wikidata item that represents the concept of the country Brazil (Q155), on OSM is a relation,
    http://osm.org/Q155 will redirect to https://www.openstreetmap.org/relation/etc

• Way. The Wikidata item that represents the concept of the Fraternity Bridge (Q2679759), on OSM is a way,
    http://osm.org/Q2679759 will redirect to https://www.openstreetmap.org/way/etc

• Node. Wikidata item of the Number zero survey marker of the city of São Paulo, (Q10325364), on OSM is a node,
    http://osm.org/Q10325364 will redirect to https://www.openstreetmap.org/node/etc

See more details at the wiki.openstreetmap.org Proposal-QID. --Krauss (talk) 00:02, 28 August 2018 (UTC)

Great idea, Krauss! As a workaround, we're currently using {{Overpasslink}}, which is clearly less adequate. What kind of support do you need? Maybe just consensus? Perhaps some technical advice? --abián 12:01, 30 August 2018 (UTC)

Nice idea. Be aware that you also could extend Nominatim, the search engine, to accept Wikidata IDs. And BTW: There exists https://wiki.openstreetmap.org/wiki/Sophox as a sevice which allows to query OSM and Wikidata together using SPARQL. It's not yet ready to filter spatially though (see [1]). --Geonick (talk) 23:56, 13 February 2019 (UTC)

Please check error

I deleted https://www.openstreetmap.org/relation/6365444 from https://www.wikidata.org/wiki/Q31063

Please enhance domain of this property with explicit citation of https://en.wikipedia.org/wiki/Territorial_waters I am using as example https://www.openstreetmap.org/relation/535774

Oops (!!!!), same for

• country-code "FO", Q4628, deleted https://www.openstreetmap.org/relation/3067431
• IM, Q9676, 62269 and 6041206
• JE, Q785, 367988 and 6956667
• MQ, Q17054, 1891495 and 7112170
• JM, Q766, 555017 and 7117041
• NU, Q34020, 3548481 and 1558556

It is also a problem with the "reciprocal ID", it is not one-to-one (as people expected), because OSM must point twice the Wikidata-ID.

--Krauss (talk) 12:05, 12 April 2019 (UTC)

PS: using this SparQL query.
... Another typical source of confusion (wrong edits) is "constituent country" vs "sovereign state, including its territories", for example to Q55 (Netherlands) and Q29999 (Kingdom of the Netherlands).

ALL DELETED

Ok, no answer and perhaps no problem... I deleted all duplicates. --Krauss (talk) 17:22, 12 April 2019 (UTC)

See this query for future control.

Don't use property P402 - use coordinates P625 instead!

There is not only the problem of asymetry, of only supporting OSM relations and no nodes or ways in Wikidata (which - among others - encourages naive OSM mappers to turn OSM nodes and ways into unnecessarily complex OSM relations!). There's still the issue, that OSM Ids - including OSM relation Ids - are neither stable nor representing "concepts" as one may think (and as discussed elsewhere extensively).

As an alternative, use "coordinate location" property (P625) in Wikidata. Coordinates are unique and stable. They help also to use the Wikidata-to-OSM service.

In order to get coordinates, simply go to www.osm.org, navigate (search, zoom, pan) to object in question, get context menu (right-click or long press), then choose "Show address". "Show address" shows the lat/lon coordinates. There could be or are similar tools like https://tools.wmflabs.org/locator-tool/ which could make the process of adding coordinates to Wikidata even easier. --Geonick (talk) 23:35, 13 February 2019 (UTC)

OSM relations (at least admin boundaries and long routes) in my experience tend to be quite stable and I see no reason not to point to those directly. If you worry about stability please note that wikidata items aren't necessarily rock stable either. --Hjart (talk) 08:29, 14 February 2019 (UTC)

Not sure if OSM is ok with Geonick's suggestion.
It's ok to add relations where available. --- Jura 18:43, 15 February 2019 (UTC)

 Oppose @Geonick: coordinate location (P625) Can only work if something is a point, but do you know if how can a rail line or a highway line be just a point? --218.68.229.149 01:01, 30 March 2019 (UTC)

 Oppose Per above, it's really unfair to specific a line object by coordinate location (P625), as you have to insert too many batches of it for just one random item. --Liuxinyu970226 (talk) 04:58, 2 April 2019 (UTC)

 Neutral Not necessarily opposed to this, I think both options have their own benefits. However, I do take issue with the suggestion about copying data from OpenStreetMap, please DO NOT do this! Wikidata uses the public-domain style Creative Commons CC0 license which does not contain any attribution or share-alike provisions (see: Importing data from OSM into Wikidata (OSM Wiki)). It is unfortunate and not the way that I would have done it had I had the initial choice of license, but it is the case and should be respected. --Aluxosm (talk) 17:59, 27 August 2019 (UTC)

Listen, guys: My reasoning here is the result of many discussions about Permanent-IDs in OSM (see https://wiki.openstreetmap.org/wiki/Permanent_ID and talk), and consensus in OSM is, that OSM ids are _not_ stable:

• The OSM id alone is not enough; it does represent many concepts and that's by design in OSM.
• Version no. is needed; that makes clear which tags have been originally referred to.
• Coordinates are needed because a geometry change does not increment the version number.

So a really realistic stable OSM ID has the following form (which leads to a fixed length of 33 chars):

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

Example: "Schloss Kyburg" (Castle Kyburg) with relation 1169711, version #5 at coordinates 47.4584, 8.74343 gets the following Permanent-ID (without parantheses): "R0001169711#0005+47.45840+008.74343". So, again, as long as there is no established Permanent-ID, pls. don't use property P402 (OSM relation id), use P625 (coordinates ) instead. I've seen cases where naive mappers turned simple POIs into a relation just to be able to be referenced by Wikidata. That's detrimental to OSM. --Geonick (talk) 23:15, 3 April 2019 (UTC)

For smaller objects like buildings I agree with using P625 only. For larger ones (like countries/administrative regions/large lakes, auto/bicycle routes etc) P402 definitely is useful and (in my experience sufficiently stable). Please also note that I'm a major OSM contributor (in the top 100, last I checked). So much for "consensus". --Hjart (talk) 10:25, 12 April 2019 (UTC)

If there is a problem you are trying to solve at OSM, please do that there. Thanks. --- Jura 12:56, 7 April 2019 (UTC)

Jura: Did you read my first paragraph? Besides the data modeling issue (lack of line and point property), be aware that in OSM there's not one "concept" as in Wikidata: A building entity in OSM can represent many concepts. Pls. look up the discussions at Permanent_ID and on OSM talk lists, or ask Kolossos (you can also try to revive the discussion yet another time at a OSM talk lists). --- Geonick (talk) 23:28, 31 January 2020 (UTC)

I agree that it's a bad idea to use this P402 property, but the right way to link OSM to Wikidata (and Wikidata to OSM) is to add a wikidata=* key to all relations related to a Wikidata item (see https://wiki.openstreetmap.org/wiki/Wikidata). The RedBurn (ϕ) 09:48, 23 April 2020 (UTC)

P625 required constraint

@Liuxinyu970226, NMaia:

So, a short recap for everybody to understand:

• NMaia added a P625 required constraint
• the constraint was wrongly written, so I corrected it as I thought it was still a good constraint
• Liuxinyu970226 reverted me as this constraint cause some problem

Here we are now. What should we do? True there is some few item where coordinate location (P625) doesn't make sense but it's only a small portion of them (roughly 10 %, more or less some with false positive and such) so we still need some kind of checking to add P625 where they miss. Maybe we could built a complex constraint but how to filter what need P625 or not? (here a query w.wiki/3pX to give ideas)

Cheers, VIGNERON (talk) 09:35, 10 May 2019 (UTC)

@VIGNERON: See also Property_talk:P625#Can_we_please,_as_I'm_crying_with_tears_to_request,_STOP_using_this_property_for_roads?, the actual actual and actual problem is that P625 is spamly "required" by too many pages for properties, where non of them always share concepts with coordinates. --Liuxinyu970226 (talk) 09:41, 10 May 2019 (UTC)

Note that there are also a lot of examples, where coordinates' values are wrong, but too hard to fix, so users (or for bots, their operators) who added them mis-thinked these as "true values", Therefore, I think instead of concern the constraints, the really-needed thing to concern is the coordinate location (P625) property. --Liuxinyu970226 (talk) 10:08, 10 May 2019 (UTC)

Single value constraint

The single value constraint has a separator applies to part (P518), but where I've seen more than one value, for example West Sussex (Q23287)), subject has role (P2868) would be more accurate. Is this property used (or intended to be used) to link to relations for different parts, or only different roles or definitions of an entity? Peter James (talk) 16:08, 6 December 2020 (UTC)

More than 9 digits in OpenStreetMap relations ID

I have tried to add OpenStreetMap relations ID to Centrum Island https://www.wikidata.org/wiki/Q110721775, but the ID is longer than the current contrains (https://www.openstreetmap.org/way/1025638527). Is there anyone who help with that? Thanks in advance. IBDJacobsen (talk) 20:58, 28 January 2022 (UTC)

Well, you've tried to add a way id, not a relation id ;) --Katpatuka (talk) 05:48, 2 February 2022 (UTC)

Hi, I. also added a way id at https://www.wikidata.org/wiki/Q327265 because the related OSM entry is only a way not a relation.

I guess the cleanest way would be to have also Wikidata properties for OSM Ways & Node. Dakoller (talk) 04:45, 10 June 2022 (UTC)

Mixing OSM and WDQS

Hello, is there a possibility to pick-show a relation OSM in a map with a WDQS query?

Question 2. is it normal to see a sea map for instance here https://www.wikidata.org/wiki/Q115689932#P402 ? Bouzinac ^{💬●✒️●💛} 21:15, 13 December 2022 (UTC)