|
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 Any relation have an unique ID, the so-called As we can check, some 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". For many applications is possible to suppose that, in the application's "time perspective", the Where the information about unsolicited changes of osm_id?With some basic information we can ask any question about "unsolicited changes of How many times the What the risk that an element created today experiencing unsolicitedly-change of its |
|
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. 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
(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
(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
(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
|
|
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. 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
(31 Oct '18, 08:47)
ppKrauss
|
|
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. Hi @FrederikRamm, I edited the question, now I am defining what is unsolicited change of the
(31 Oct '18, 09:05)
ppKrauss
|
|
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. 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
(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 ♦
|
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.
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.