Talk:Permanent ID

This is the talk page for discussing improvements to the Permanent ID article and its related topics.
Please sign and date your posts by typing four tildes ~~~~ at end of your messages. Put new text under old text. Click here to start a new topic. New to OpenStreetMap? Take a look at the Beginners' guide. Respect your fellow mappers. Be gentle, constructive, and assume good faith.

old_id=*

This may work as follows: Then correspondent element is changed (for example, node moved or replaced with area, or simple polygon replaced with the multipolygon), old_id=* (containing letter "n", "w" or "r", and actual id of the previous OSM element in decimal form) may be added. Something B (talk) 08:27, 24 May 2023 (UTC)

Concepts

The problem is that OSM does not support a conceptual model so there will never be agreement on what concepts you want to support. The trivial case is a pub or bar added as amenity=pub: this typically enshrines at least 3 conceptual elements:

• A place where members of the public can buy (alcoholic) drinks
• A retail business
• A liquor licence
• Retail premises where the bar is situated
• A building which may be identical with the retail premises or the bar may just occupy some of the building.

Over time in OSM some of these elements may be made more explicit: the building is added, an operator tag is added etc.

In building permanent IDs one has to take account of this kind of partial information: either instantiate the lot on first appearance, or have some mechanism to generate new ones as data gets refined.

The editors, in general, only deal with the objects in the OSM API. Creating a set of rules for dealing with the semantics of permanent IDs would be orders of magnitude more complex than current tag presets.

See, a very old, blog post setting out my views on the subject: POSSUMs —Preceding unsigned comment added by SK53 (talk • contribs)

Hi @SK53, as you say "permanent IDs would be orders of magnitude more complex", and I agree. We need to see Permanent ID as a persistent ID living together ordinary ID... Step-by-step scenario and algorithm:

1. Usual osm_nodeId is attributed to a node at OSM, representing the pub added to OSM;
2. Something like place_id of Nominating (let's label it perma_id with detalils below) is also generated when amenity=pub is attributed to the node;
   (it is a good ID to preserve when the pub grows and node is promoted to a relation, but it is not permanent)
3. After time and relevance perceived by community, an Wikidata ID (wdId) is attributed to the pub at Wikidata and the wikidata key added at OSM... So, now perma_id will be Permanent.
4. After some "OSM refresh event", restoring OSM:
   1. the perma_id have a backup that can be used in all features (node, way or relation) that have a wikidata key (it can be cached in a lookup like this),
   2. all other perma_id are generated with no commitment of persistence.

--Krauss (talk) 21:05, 7 July 2018 (UTC)

Nominatim's place_id is an internal identifier. It has absolutely zero meaning outside of of Nominatim, and even differs from one Nominatim instance to the other IIRC. Just don't use it for about anything, really. Mmd (talk) 21:20, 7 July 2018 (UTC)

@Mmd sorry my English... Was not necessary, but to avoid confusion I am changing text above to "perma_id" (see new bold explanation).
About my text, I not say "use it", I say "something like place_id ... will be Permanent". For more details see below #Wikidata is a first step where I add explicit "... but changing the 'regeneratig all IDs' stupid algorithm...". --Krauss (talk) 14:04, 8 July 2018 (UTC)

Name Permanent ID already used for other projects

How about adding a proper disambiguation page? Mmd (talk) 12:30, 1 December 2017 (UTC)

Sure. Technically this page is not about Permanent ID in itself, but rather a requirement gathering page. UUID and OT offer a specific solution. Feel free to reorg. --Yurik (talk) 19:34, 1 December 2017 (UTC)

Why not wikidata?

Why not just use wikidata? If somebody really wants an uniques identifier for object without Wikidata entry, one may create it. Permanent ID support described on this page would require massive amount of work, including ongoing support from mappers and benefits over using wikidata ids are minor Mateusz Konieczny (talk) 17:07, 7 December 2017 (UTC)

I don't think Wikidata will be happy if someone starts adding every single stop sign or building to it. I agree that in many cases, a Wikidata ID is a good solution, but several people have mentioned a permanent ID as an alternative, so I tried to sum-up the requirements of that route. --Yurik (talk) 18:22, 7 December 2017 (UTC)

According to https://www.wikidata.org/wiki/Wikidata:Notability adding every single building and traffic sign would be OK Mateusz Konieczny (talk) 18:35, 7 December 2017 (UTC)

Not sure what you are referring to. I think this is the closest snippet:

It refers to an instance of a clearly identifiable conceptual or material entity. The entity must be notable, in the sense that it can be described using serious and publicly available references. If there is no item about you yet, you are probably not notable.

From my reading, a small tool shed in a backyard wouldn't be described using serious and publicly available reference. --Yurik (talk) 22:39, 7 December 2017 (UTC)

Entities that are so unimportant that no "serious and publicly available references" exists are not worth massive effort proposed on this page to establish permanent ids for them. Mateusz Konieczny (talk) 14:38, 15 December 2017 (UTC)

Is it possible to count building databases (existing in some countries but not all), aerial images or OSM as "serious and publicly available reference"? Mateusz Konieczny (talk) 14:39, 15 December 2017 (UTC)

@Mateusz Konieczny:, you do have a point, so establishing a new system just to cover inconsequential buildings seems like a waste of time... It might be difficult for OSM community to embrace Wikidata to this extent. Also, loading Wikidata with all the buildings on the planet might be a fun project in itself... Hopefully WD won't blow up. --Yurik (talk) 16:43, 22 June 2018 (UTC)

CC: @Krauss: (who added Wikidata comment at the bottom of the page) --Yurik (talk) 16:34, 22 June 2018 (UTC)

Hi, about notability (relevance) discussion, is important to check "who say that something is important?"... And adopt a mechanism to create Permanent ID only for a thing that is important... It can be so simple as a "watch it" click of Github or Wikipedia pages, but closed concept of the necerrary mechanism is the "capture" concept of Archive.org: eg. the archived openstreetmap.org (other example) need a "COLLECTED BY", indicating person or team that support the link as "relevant" one. At OSM is easy to use something like first-watcher and many endorser-watchers. --Krauss (talk) 16:22, 10 July 2018 (UTC)

Wikidata is a first step

At July 2018 there are:

~1,123,500 OSM features with a wikidata key.

~63,000 Wikidata entities with the OSM relation ID (P402) property pointing to OSM.

It is a good "first step" (!) to be mature in the future. Since now to create and enhance a Permanent ID... Will be easy to generate a really usefull tool, with minimum impact at OSM architecture and infrastruture. The second step will be later, after a good first experience.

As each OSM feature with a key wikidata=specificValue is unique by OSM-type (node/way/relation) we can suppose that "backup recover" or "rebuild OSM" tasks can use it to generate stable IDs before start serial ID.

The "relevance" or "notability" of the OSM feature is also important when there are technical cost or barrier to generate stable IDs. So, as first step we can ellect as "relevant" (to justify the cost) all features that was ellectd by Wikidata as "notable".

About reliability of all checking process: another cost, but we can to control it by software and a little team, and it is the proposal,

details at https://github.com/OSMBrasil/semantic-bridge

PS: about "the ID", osm_relataionId is not good, we need also the osm_wayId... Lets use similar infrastructure that used by Nominating as place_id (eg. Berlim is not Q64 neither the relation 62422 but a generic entity place_id=178741737), but changing the "regeneratig all IDs" stupid algorithm to a "read lookup first" to preserve reciprocal-Wikidata stable place_id's... And, labeling it perma_id to avoid confusion with the stupid (non-smart non-permanent) place_id... Although "place_id" is a good label.

Is it active?

Is "This is a work in progress" still true? Mateusz Konieczny (talk) 10:10, 11 May 2020 (UTC)

Hi @Mateusz Konieczny:, yes... But waiting collective decisions... Maybe the implementation will be not here (at openstreetmap.org domain). We are preparing (for end of 2020) a new domain as PURL, the osm.codes. It will be a long-term stable preservation (warranty of ~15 years), and a transparent and democractic condominium (formal collective property rights), to host OSM permanent IDs, aliases (Wikidata, GeoURI and popular geocodes). --Ppkrauss (talk) 13:09, 11 May 2020 (UTC)

Hi @Ppkrauss:, that is great news! Is there any information publicly available about the planned implementation? I would be very interested to know more about it for future features of AnyFinder. I am especially interested in the handling of edge cases like when the owner, name and cuisine of a restaurant in a building changes or when a shop at some point in time is turned into a café, etc. Also I would like to understand the mapping mechanism of an OSM entity and the external ID, like if I would receive the perm_id when I query OverPass for certain POIs. Thanks! --Beaconeer (talk) 09:48, 22 May 2020 (UTC)

Hi @Beaconeer:, can you send me an e-mail?

Hi @Ppkrauss:, sure. I could not find your email address but I sent you a message on OSM. You can also email me at hello(_at_)anyfinder.info. Cheers.

Data around persistence?

Understanding that an `osm_id` is not permanent...

For a place like a city (Columbus, OH), is there any data on the relative permanence of a city's osm_id? R182706 is Columbus OH.

I ask because while I understand that roads may be often split and redrawn, a "city" or "town" is, I would hope, rather less likely to be changed. I'd really appreciate learning how often an OSM ID is changed for something like this, and whether it is sensible to reply on the permanence of the `osm_id` value for a city or town.

I'm trying to get OSM as part of a specification for podcast locations, and the lack of a permanent ID is a show-stopper; but I'm also aware that there is no such thing as a permanent ID for a description of a place in any case.

In short - is an OSM ID "good enough" to describe Los Angeles? --Jamescridland (talk) 01:42, 12 October 2020 (UTC)

"rather less likely to be changed" - yes, it is less likely. "lack of a permanent ID is a show-stopper" - you can use one of unique tags or combination of tags + location to identify it. In case of https://www.openstreetmap.org/relation/182706 wikidata=Q16567 should match exactly one relation (see https://overpass-turbo.eu/s/Z0A ). Or you can assume that relation id will be stable (it is not really true but it may be a good enough). "specification for podcast locations" - why not latitude/longitude? Mateusz Konieczny (talk) 07:38, 14 October 2020 (UTC)

Thanks, Mateusz. The current suggestion is:

<podcast:location latlon="51.49942,-0.12444" osmid="R1567699">GB|Houses of Parliament, London</podcast:location>

The latlon is mandatory, and the osmid, which starts with the type, is currently just "recommended".

This example shows, I hope, why latlon isn't the only answer: this podcast isn't from "London", nor "Westminster", but is specifically from the Houses of Parliament, which has a rather smaller bounding-box than all of London. (OSM calls it the Palace of Westminster, by the way, which is correct but not what the podcaster in this instance wishes to describe the location as).

There is no programmatic way to find Wikidata IDs from OSM that I can see - at least, this call has no Wikidata ID visible. With 1.3m podcasts out there, it would be rather nicer to have them use and understand OSM. I think the location ID in this case should be relatively stable, and at least we have a latlon to fall back on if it isn't. Any other suggestions would be welcome.

I am also trying to understand the licence requirements for this. If a license is required to quote an OSM ID, then that's going to be hard in the context of an RSS feed! --Jamescridland (talk) 08:45, 14 October 2020 (UTC)

https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline is likely to be relevant for your use case (note that I am not a lawyer etc) Mateusz Konieczny (talk) 09:26, 14 October 2020 (UTC)

Thanks. The most important bit is this (for a store database): "The Geocoded Results added to the store location database are not subject to the share-alike requirements, and the store location database records themselves need not include attribution to OpenStreetMap because the Geocoding Results used are an insubstantial extract or contain no OSM data." ...and therefore that's clear that attribution is not required. That's helpful. --Jamescridland (talk) 10:25, 14 October 2020 (UTC)

"There is no programmatic way to find Wikidata IDs from OSM that I can see" - you can make Nominatim call, extract object type and id and the get all tags you want from a given object Mateusz Konieczny (talk) 09:26, 14 October 2020 (UTC)

Can I just confirm - this page says that "Ways and nodes are not considered stable IDs" but that Relation IDs are stable enough for Wikidata to link to. This is all we wish to link to in any case. Is there any data showing the comparative stability of Relation IDs? --Jamescridland (talk) 10:25, 14 October 2020 (UTC)

"Relation IDs are stable enough for Wikidata" - note that it is an internal decision of Wikidata community, not reccommendation or guarantee by OpenStreetMap community. I am not aware about any specific data, but it should be fairly stable with rare breakage Mateusz Konieczny (talk) 11:54, 15 October 2020 (UTC)