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
