Re: [OSM-talk] Proposal superseded_by tag for ID stabilisation
On Fri, Aug 5, 2011 at 2:15 PM, Gregor Horvath gre...@ediwo.com wrote: I am not a native English speaker, so if new_id is better than superseded_by than I vote for new_id. Regarding the added semantics I am very cautious. Because it will be impossible to model all semantics of ID meaning changes that possibly exist. I would prefer to stick with the simplest possible solution and that is provide a dirt simple replacement link for a deleted (for whatever reason) object. Yeah, my thinking was new is a less specific, more flexible term than superseded by, which is quite precise in meaning. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal superseded_by tag for ID stabilisation
Steve Bennett wrote: In general I think there's some value in what you're describing here, not just for id stability, but in better understanding the history and provenance of objects, which helps with attributing authorship. Some sort of more generic meta-tagging scheme might be good (superseded_by could easily be interpreted as referring to the actual physical objects, not the OSM objects), so maybe something like osm:new_id=xxx, osm:merge_into=xxx etc. new_id=xxx is an interesting thought especially if it can be used to manage the back linking of history when a split is instigated. So that an older id may well have several new_id tags as splits of the element happen? superseded_by only sounds appropriate where the original id does become historic redundant data? I think people have lost sight of the start_date and end_date though? I think that still provides an important element if people ARE will to accept that there is historic data now being accumulated? Deleting a building as demolished has a date, and creating a new building on the site has a date. While they are physically located at a similar point, they are not the same object, but it is necessary to maintain the history of that change, and similar things such as change of use ... I still live in the hope of being able to draw a map of an area with a particular date to go with my genealogical work ... -- 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] Proposal superseded_by tag for ID stabilisation
Hi, I have thought through this again and think we should keep it simple and stupid (KISS): Am Wed, 3 Aug 2011 20:36:38 +0200 schrieb Gregor Horvath gre...@ediwo.com: ** splitting of ways (old ID would then point to only half) A split to A,B: A.superseded_by = B A does not get deleted In this case A does not get deleted. It alters it's meaning because the old ID points only to the half. But that is not different to adding or editing a tag of that ID. This can also change the meaning of the ID. I think it is not possible to manage a change history of ID meanings. All we can do is provide a replacement ID when an ID is deleted. This can not be an exact replacement, just a hint. Therefore a rule of thumb is this tag can only be applied to deleted IDs. ** merging (old ID would become invalid in 50% of cases) - example 1: Relations for long-distance routes created in several places until they meet, and are merged, with one of them being deleted. - example 2: a POI node might later be joined to be part of an area representing a shop; this shop area might later be joined to others to represent an entire building that contains several shops A,B gets merged to A: A.superseded_by = B B deleted (visible=false) B.superseded_by = A same here: A does not get the tag, because it is not deleted. ** supersede multiple objects (a merge operation) A,B,C gets replaced by C A.superseded_by = C B.superseded_by = C C.superseded_by = A C.superseded_by = B A,B deleted (invisible) same here C does not get the tag, because it is not deleted. -- Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal superseded_by tag for ID stabilisation
Hi Steve, Am Thu, 4 Aug 2011 10:56:49 +1000 schrieb Steve Bennett stevag...@gmail.com: In general I think there's some value in what you're describing here, not just for id stability, but in better understanding the history and provenance of objects, which helps with attributing authorship. Some sort of more generic meta-tagging scheme might be good (superseded_by could easily be interpreted as referring to the actual physical objects, not the OSM objects), so maybe something like osm:new_id=xxx, osm:merge_into=xxx etc. I am not a native English speaker, so if new_id is better than superseded_by than I vote for new_id. Regarding the added semantics I am very cautious. Because it will be impossible to model all semantics of ID meaning changes that possibly exist. I would prefer to stick with the simplest possible solution and that is provide a dirt simple replacement link for a deleted (for whatever reason) object. -- Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Proposal superseded_by tag for ID stabilisation
Hi, critique welcome: Proposal superseded_by tag -- OSM ID's do not describe physical objects but geometrical objects on a map. If an a geometrical object supersedes another one with a different ID it should be possible to tag this relationship for some better stabilisation and traceability of ID's. * new TAG superseded_by=type:ID example: superseded_by=way:7867678 superseded_by=node:67668 superseded_by=rel:7897789 I do not think that a superseded tag on the new object is necessary because it is redundant data and an unnecessary maintenance burden. * Use Cases ID deletion Below are the cases for deleting a ID mentioned on the mailing list. I've added the proposed solution. ** expansion of POI nodes into buildings node is deleted and gets superseded_by tag pointing to the building ** splitting of ways (old ID would then point to only half) A split to A,B: A.superseded_by = B A does not get deleted ** superseded by several objects (a split operation). A gets replaced by B,C A.superseded_by = B A.superseded_by = C ** merging (old ID would become invalid in 50% of cases) - example 1: Relations for long-distance routes created in several places until they meet, and are merged, with one of them being deleted. - example 2: a POI node might later be joined to be part of an area representing a shop; this shop area might later be joined to others to represent an entire building that contains several shops A,B gets merged to A: A.superseded_by = B B deleted (visible=false) B.superseded_by = A ** supersede multiple objects (a merge operation) A,B,C gets replaced by C A.superseded_by = C B.superseded_by = C C.superseded_by = A C.superseded_by = B A,B deleted (invisible) ** re-mapping of stuff in the course of the license change - re-structuring of relations - 0.7 area data type (lots of existing areas get a new ID) superseded_by tag ** mapping error (mistake) delete ID, no superseded_by ** restaurant moves, should it keep the same ID? If it is renamed? If it goes bankrupt, is sold, renovated, and reopened by a different owner the node describes a point on the map, not a restaurant, therefore no new ID in this cases. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal superseded_by tag for ID stabilisation
Hi, I must say wow, as I did not expect my mail to trigger such a long discussion, that even already brings up proposals. I was busy with some tasks and therefore did not reply in the past three days. But its great to see such response ;) So as it was pointed out multiple times already, there are the version numbers, and an (ID, version) pair unambiguously refers to the state of an entity at some point at time - right?. So from my point of view, the question is then, how these unique ids can be related to each other. I would have thought of a separate service, that automatically attempts to figure out the relations between (ID, version) pairs, and also allows for manual overrides, in cases where the automatic decision is wrong, and some human is interested in getting it right. This automatic analysis could be based on domain specific rules. (For instance if there was a deletion and re-upload of a node where only the spelling of a name was fixed, it is very likely that there will be a high string similarity, and at some threshold it will be assumed to be the some thing as a previous one, unless someone manually sais something different). The proposed solution with the superseded_by tag might be something like a way for storing the outcome of such an analysis that, but I need give it some more thought. (So this mail is mainly about saying I am still alive ;) In general, I agree that OSM should not force themselves into somehow making internal IDs stable (if that is even possible). On the other hand, the currently stable-enough-at-least-for-my-demo-use-cases-IDs are way too useful for making them deliberately unstable. (Such as by renumbering them ;) ) Cheers, Claus On 08/03/2011 08:36 PM, Gregor Horvath wrote: Hi, critique welcome: Proposal superseded_by tag -- OSM ID's do not describe physical objects but geometrical objects on a map. If an a geometrical object supersedes another one with a different ID it should be possible to tag this relationship for some better stabilisation and traceability of ID's. * new TAG superseded_by=type:ID example: superseded_by=way:7867678 superseded_by=node:67668 superseded_by=rel:7897789 I do not think that a superseded tag on the new object is necessary because it is redundant data and an unnecessary maintenance burden. * Use Cases ID deletion Below are the cases for deleting a ID mentioned on the mailing list. I've added the proposed solution. ** expansion of POI nodes into buildings node is deleted and gets superseded_by tag pointing to the building ** splitting of ways (old ID would then point to only half) A split to A,B: A.superseded_by = B A does not get deleted ** superseded by several objects (a split operation). A gets replaced by B,C A.superseded_by = B A.superseded_by = C ** merging (old ID would become invalid in 50% of cases) - example 1: Relations for long-distance routes created in several places until they meet, and are merged, with one of them being deleted. - example 2: a POI node might later be joined to be part of an area representing a shop; this shop area might later be joined to others to represent an entire building that contains several shops A,B gets merged to A: A.superseded_by = B B deleted (visible=false) B.superseded_by = A ** supersede multiple objects (a merge operation) A,B,C gets replaced by C A.superseded_by = C B.superseded_by = C C.superseded_by = A C.superseded_by = B A,B deleted (invisible) ** re-mapping of stuff in the course of the license change - re-structuring of relations - 0.7 area data type (lots of existing areas get a new ID) superseded_by tag ** mapping error (mistake) delete ID, no superseded_by ** restaurant moves, should it keep the same ID? If it is renamed? If it goes bankrupt, is sold, renovated, and reopened by a different owner the node describes a point on the map, not a restaurant, therefore no new ID in this cases. ___ 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] Proposal superseded_by tag for ID stabilisation
On Thu, Aug 4, 2011 at 4:36 AM, Gregor Horvath gre...@ediwo.com wrote: ** re-mapping of stuff in the course of the license change - re-structuring of relations - 0.7 area data type (lots of existing areas get a new ID) superseded_by tag That's an interesting use case - let's say A describes a certain building, and is deleted (the author didn't agree to CTs), and then B describes the same building. You want to be careful about linking B to A, lets B be considered a derivative work... In general I think there's some value in what you're describing here, not just for id stability, but in better understanding the history and provenance of objects, which helps with attributing authorship. Some sort of more generic meta-tagging scheme might be good (superseded_by could easily be interpreted as referring to the actual physical objects, not the OSM objects), so maybe something like osm:new_id=xxx, osm:merge_into=xxx etc. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
