[OSM-talk] Proposal superseded_by tag for ID stabilisation

[Claus Stadler]

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 at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk