Re: [OSM-talk] What is an ID?
On 3 Aug 2011, at 15:45, Claudius wrote: Am 03.08.2011 02:34, Lester Caine: Tom Hughes wrote: Nobody has setup a system to reuse anything. All you are seeing there is the result of badly written programs and the like doing perfectly normal REST writes to node 1. When such mistakes are made people revert them. Shit happens, and we deal with it. How exactly do you suggest that we disable that corruption? I just started at '1' to see how good things were, and a few of the nodes I then worked through showed questionable changes ... Actually it's interesting looking at some of the raw history. There are a block below 1400, many of which are original nodes, but some seem to have these strange edits, then there is a jump to 77858, which I presume was a hick-up somewhere along the line very early on, except that the 1300 series nodes post date 77858, so something is/was going wrong somewhere? Some of these early node numbers have been edited earlier this year ... Shit happens, and we deal with it. still has the problem of identifying where the shit has happened and working out how to deal with it. You are probably aware that version numbers were added in 2009 with the API 0.6 change [1]. So judging from the changedate the low number anomalies you have discovered are probably related to those early testing and fixing phase. Eh? As part of the API 0.6 development we started setting up dev apis, specifically for API testing, rather than polluting the production data. Shaun Claudius [1] http://wiki.openstreetmap.org/wiki/API_changes_between_v0.5_and_v0.6 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is an ID?
Am 03.08.2011 02:34, Lester Caine: Tom Hughes wrote: Nobody has setup a system to reuse anything. All you are seeing there is the result of badly written programs and the like doing perfectly normal REST writes to node 1. When such mistakes are made people revert them. Shit happens, and we deal with it. How exactly do you suggest that we disable that corruption? I just started at '1' to see how good things were, and a few of the nodes I then worked through showed questionable changes ... Actually it's interesting looking at some of the raw history. There are a block below 1400, many of which are original nodes, but some seem to have these strange edits, then there is a jump to 77858, which I presume was a hick-up somewhere along the line very early on, except that the 1300 series nodes post date 77858, so something is/was going wrong somewhere? Some of these early node numbers have been edited earlier this year ... Shit happens, and we deal with it. still has the problem of identifying where the shit has happened and working out how to deal with it. You are probably aware that version numbers were added in 2009 with the API 0.6 change [1]. So judging from the changedate the low number anomalies you have discovered are probably related to those early testing and fixing phase. Claudius [1] http://wiki.openstreetmap.org/wiki/API_changes_between_v0.5_and_v0.6 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] What is an ID?
Rather than comment on the id stability thread, I though it better to turn the question around ... In my own data trail, an ID *IS* unique, and is directly linked to the piece of data it relates to. If I change the data then the version number goes up. If I delete the data, then the ID number remains since it identifies the HISTORY relating to that item. The idea that someone is going to 'reuse' id's because they are no being used raises alarm bells. I thought we had history relating to every element nowadays, so how do you know what the history relates to if you reuse the ID? Also the idea of 'renumbering' everything is equally alarming, given that every old changeset would have to be updated? If we are running out of ID's, then a switch to 64 bit is an urgent requirement simply to prevent the existing data and history trail from being corrupted. Now having said all that ... USING the internal ID for external purposes, while potentially practical, is not the most sensible way forward as has been highlighted in several ways. I'm probably in agreement on a 'link server' approach, but I think that there are a number of areas where additional 'ID's need to be stored in the database and managed in parallel. Postcodes, bus/tramstop id's, Airport codes, telephone area codes, and so on. We had a little discussion on parallel databases, and that slots in with the 'link server', but I think that in order to make ANY parallel database system work, then the core ID's have to be stable and consistent, even if they do return 'deleted' ... at which point on needs to be able to ask 'why' and possibly roll back a change that should not have happened? If a item has history then it's ID can't be reused. http://www.openstreetmap.org/browse/node/xxx/history simply has to be consistent? Then what may be missing IS a tag for 'split_from' or 'merged_with' but the linked ID's must also be consistent? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is an ID?
Richard Mann wrote: I think he was joking about reusing ids (he was illustrating the point with the sort of daft temporary fix that someone might do ... if they were daft) Well someone has set up the system to reuse them http://www.openstreetmap.org/browse/node/1/history THAT is a joke :( PLEASE can someone disable that corruption before it goes too far? On Tue, Aug 2, 2011 at 5:35 PM, Lester Caineles...@lsces.co.uk wrote: Rather than comment on the id stability thread, I though it better to turn the question around ... In my own data trail, an ID *IS* unique, and is directly linked to the piece of data it relates to. If I change the data then the version number goes up. If I delete the data, then the ID number remains since it identifies the HISTORY relating to that item. The idea that someone is going to 'reuse' id's because they are no being used raises alarm bells. I thought we had history relating to every element nowadays, so how do you know what the history relates to if you reuse the ID? Also the idea of 'renumbering' everything is equally alarming, given that every old changeset would have to be updated? If we are running out of ID's, then a switch to 64 bit is an urgent requirement simply to prevent the existing data and history trail from being corrupted. Now having said all that ... USING the internal ID for external purposes, while potentially practical, is not the most sensible way forward as has been highlighted in several ways. I'm probably in agreement on a 'link server' approach, but I think that there are a number of areas where additional 'ID's need to be stored in the database and managed in parallel. Postcodes, bus/tramstop id's, Airport codes, telephone area codes, and so on. We had a little discussion on parallel databases, and that slots in with the 'link server', but I think that in order to make ANY parallel database system work, then the core ID's have to be stable and consistent, even if they do return 'deleted' ... at which point on needs to be able to ask 'why' and possibly roll back a change that should not have happened? If a item has history then it's ID can't be reused. http://www.openstreetmap.org/browse/node/xxx/history simply has to be consistent? Then what may be missing IS a tag for 'split_from' or 'merged_with' but the linked ID's must also be consistent? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is an ID?
On 02/08/11 18:43, Lester Caine wrote: Richard Mann wrote: I think he was joking about reusing ids (he was illustrating the point with the sort of daft temporary fix that someone might do ... if they were daft) Well someone has set up the system to reuse them http://www.openstreetmap.org/browse/node/1/history THAT is a joke :( PLEASE can someone disable that corruption before it goes too far? Nobody has setup a system to reuse anything. All you are seeing there is the result of badly written programs and the like doing perfectly normal REST writes to node 1. When such mistakes are made people revert them. Shit happens, and we deal with it. How exactly do you suggest that we disable that corruption? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is an ID?
Tom Hughes wrote: On 02/08/11 18:43, Lester Caine wrote: Richard Mann wrote: I think he was joking about reusing ids (he was illustrating the point with the sort of daft temporary fix that someone might do ... if they were daft) Well someone has set up the system to reuse them http://www.openstreetmap.org/browse/node/1/history THAT is a joke :( PLEASE can someone disable that corruption before it goes too far? Nobody has setup a system to reuse anything. All you are seeing there is the result of badly written programs and the like doing perfectly normal REST writes to node 1. When such mistakes are made people revert them. Shit happens, and we deal with it. How exactly do you suggest that we disable that corruption? I just started at '1' to see how good things were, and a few of the nodes I then worked through showed questionable changes ... Actually it's interesting looking at some of the raw history. There are a block below 1400, many of which are original nodes, but some seem to have these strange edits, then there is a jump to 77858, which I presume was a hick-up somewhere along the line very early on, except that the 1300 series nodes post date 77858, so something is/was going wrong somewhere? Some of these early node numbers have been edited earlier this year ... Shit happens, and we deal with it. still has the problem of identifying where the shit has happened and working out how to deal with it. Increasingly looking at the history I've been spotting places where useful tags have been removed when later edits were added but there is no mechanism to flag what is being deleted? I've not noted down the node numbers, but a series of edits relating to wheelchair access seem to have removed the name or other tags rather than maintaining them ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
