0
2

This question is not about "natural changes" (e. g. user editions deleting something), is about system-maintenance events that changed (or will change) the value of the osm_id.


Any relation have an unique ID, the so-called osm_id, as in an XML element, <relation id="123">. Ways and nodes also have respectives osm_ids. The osm_id is also used in SQL data dumps, etc. URLs use the notation relation/123 or way/123 or node/123.

As we can check, some osm_id was preserved, the element's osm_id value stay unchanged many years: node 1 is there! ... But "all OSM people" say that a maintenance event can change osm_id values, the system can rebuild it. Therea are a "risk of change". The focus here is this kind of "unsolicited changes" of the maintenance/recovery events, and the risk of an event changing the osm_id value (whitout editions).

NOTE: is natural to change, the reality is dynamic (an earthquake destroys map features) and the community enhance map features editing it (e. g. a node is deleted to become a complete relation)... But the focus here is not the "natural changes".
A crash in the OSM servers or a big technical change can enforce the system to rebuild osm_id's (some or all). Whe can label this kind of changes as unsolicited changes.

For many applications is possible to suppose that, in the application's "time perspective", the osm_id not changes. But in a digital preservation perspective, and other more specific applications, the "risk of osm_id change" exists. In a perspective of 10 years, the change will occur... Is it?

Where the information about unsolicited changes of osm_id?

With some basic information we can ask any question about "unsolicited changes of osm_id".

How many times the osm_id changed for all elements since 2009? A specific group of elements (how many?) suffered a technical maintenance that affected its osm_id?

What the risk that an element created today experiencing unsolicitedly-change of its osm_id before 2020?

asked 31 Oct '18, 01:22

ppKrauss's gravatar image

ppKrauss
95182225
accept rate: 0%

edited 31 Oct '18, 10:04

2

But "all OSM people" say that a maintenance event can change osm_id values, the system can rebuild it. Therea are a "risk of change".

No, "all OSM people" do not mean maintenance events when warning about referencing OSM IDs and talking about permanent IDs. The "risk of change" refers to edits that make an ID reference loose it's original meaning, which depends on the use-case.

the element's osm_id value stay unchanged many years: node 1 is there!

Well, the ID itself is still there, but the element node 1 represents has changed many times: tree in Germany (v13), buoy in the Atlantic Ocean (v15), memorial stone in London (v17), bike rental in Edinburgh (v19). Not what data consumers would expect (but still OK in this case because of the deletes in between). This is not a problem if you update a regular osm2pgsql rendering database, but it is e.g. if you link your restaurant rating database to OSM IDs and suddenly you are rating a tree (v13) instead of a restaurant (v11) – and the restaurant you actually meant now has node ID 2614114739.

(01 Nov '18, 17:26) ikonor

4 Answers:
4

There is no reason why a technical event (aka server crash etc) would require a renumbering of OSM objects, the ids are one of the objects attributes and not a transient database row id or similar.

Naturally some of the data model changes that are in discussion (area types, doing away with way nodes and similar) could potentially lead to a large number of objects being removed and new ones with different id being created, however any such change would be discussed and prepared well in advance.

So to answer your question, the likelihood of any such change happening before 2020 is minimal.

Note: none of the above makes relying on stable OSM ids less technically defective.

permanent link

answered 31 Oct '18, 09:58

SimonPoole's gravatar image

SimonPoole ♦
40.0k13297634
accept rate: 19%

edited 31 Oct '18, 10:07

Thanks @SimonPoole, good answer. Well, there are "no risk"? The "no risk" is a goos news (!), but not seems a reliable information (is it? some link to authoritative assertion?)... It is a contradiction with the motivations that lead people to propose a perma_id.

(31 Oct '18, 10:08) ppKrauss
2

@ppKrauss - if you're trying to have a general discussion about something, then the help site's question-and-answer format isn't well suited to it. You'd be better off on one of the mailing lists.

(31 Oct '18, 10:13) SomeoneElse ♦
2

Note the help site is not a general discussion facility. Still just one point, the problem with perma ids for POIs and similar objects is, that it is simple to determine that an object is unchanged and can retain the same id, but that it is practically impossible to achieve consensus on what an id changing event should be.

Consider a restaurant and all the different ways certain fundamental attributes of it can change.

(31 Oct '18, 10:16) SimonPoole ♦

@SimonPoole, no need for mailing lists... And sorry my English. If there are a place with the "official information" that osm_id not changes, will be a complete answer. You have my up-vote, it is only a complement to mark as accepted: request for authoritative URL is usual at Stackoverflow.

(31 Oct '18, 10:21) ppKrauss

The nature of the id is essentially implicit through the data model and API definition. In practical terms you should probably refer to the rails-port database definition https://github.com/openstreetmap/openstreetmap-website/blob/master/db/structure.sql

(31 Oct '18, 10:28) SimonPoole ♦

Thanks, good link, now I have a better "big picture"... Well, sorry to ask again, is only a last check: no event of schema_migrations changed (some) osm_id values? (... and I not see if schema_migrations is only a "rails-port database" schema)

(31 Oct '18, 10:37) ppKrauss

All migrations back to 2007 https://github.com/openstreetmap/openstreetmap-website/commits/master/db/migrate can be found here. Naturally a renumbering could have happened by a different mechanism. In any case since the introduction of API 0.5 (removal of segments) there have been no changes to the data model that have changed ids.

(31 Oct '18, 10:44) SimonPoole ♦

Thanks a lot @SimonPoole (!). For readers: I selected this answer as "correct" by these additional information posted as comments. PS: the link is saved as evidence at https://web.archive.org/web/20181031110330/https://github.com/openstreetmap/openstreetmap-website/commits/master/db/migrate

(31 Oct '18, 10:55) ppKrauss
showing 5 of 8 show 3 more comments
4

As you wrote osm_ids refer to nodes, ways and relations. Mappers can at any time change the "definition" of such an object. An example a node that represents a postal_box today, can be moved by any mapper, the tags can be changed and it can represent a shop=toys at the next moment. The same is true for ways and relations. Things that are mapped as a node today, might be mapped as a closed way tomorrow. The original node can become one of the nodes of the closed way, but it lost all it's tags and no longer represent the POI.

Some changes are unlikely, but you can never assume that the osm_id represents the same object between 2 data dumps. To answer your question "how many times the osm_id changed since 2009, well it depends on the object you are looking at. Some might never have changed (i.e. they still represent the original object), others might have changed several times.

There was also a technical change since the beginning of the project, ids were changed from 32 bit to 64 bit.

permanent link

answered 31 Oct '18, 05:22

escada's gravatar image

escada
18.7k16159298
accept rate: 20%

Thanks @escada. Where the information (to audit) about what you expressed as "changed several times", can I count or check time-line? About "it depends on the object you are looking at", I not looking for user-deletions, etc. But unsolicited or undesired changes, like something caused by a server crash or techinal changes (imagine something as the change to 64 bit changing all osm_id values).

(31 Oct '18, 08:47) ppKrauss
2

I have personally deleted relations and re-created them under a new ID when their version counter reached four digits, adding a "note" or similar link to point to the old ID. This is not super elegant but easier to handle for mappers who would otherwise often see a timeout when trying to access object history.

permanent link

answered 31 Oct '18, 08:49

Frederik%20Ramm's gravatar image

Frederik Ramm ♦
73.3k866641137
accept rate: 24%

Hi @FrederikRamm, I edited the question, now I am defining what is unsolicited change of the osm_id... Please explain this problem of "version counter reached four digits", I never see: the system enforced you to delete? Was not a "natural change" to enhance the map feature?

(31 Oct '18, 09:05) ppKrauss
1

It depends. What sort of object is it? Was it roughly drawn or imported and likely to be refined later? Is it in an area where people are more likely to remap rather than ensure object ID reuse?

Rather than guessing, what I'd suggest that you do is it look at some of the objects of the type that you are interested in in an area that you are interested in and see how much reuse has occurred over the years (since the licence change). That, and only that, will start to answer your question.

permanent link

answered 31 Oct '18, 09:05

SomeoneElse's gravatar image

SomeoneElse ♦
33.0k65343778
accept rate: 16%

2

Node 1 has been various things in various places over the years as one example: https://www.openstreetmap.org/node/1/history

(31 Oct '18, 09:11) EdLoach ♦

Hi @someoneElse I edited the question's title to avoid confusion, it is about unsolicited changes of the osm_id values, as in a technical maintenance event.

(31 Oct '18, 09:18) ppKrauss
2

Low-ID nodes are especially prone to movement, partly by accident (node 1 was accidentally moved only yesterday, which resulted in the historical "Greenwich Meridian" being somewhat inaccurate in OSM), and partly by design (mappers have been known to replace low-id nodes in features with higher ones to prevent accidental moves)

(31 Oct '18, 10:25) SomeoneElse ♦

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×67
×6

question asked: 31 Oct '18, 01:22

question was seen: 1,037 times

last updated: 01 Nov '18, 17:37

powered by OSQA