[OSM-talk] Id stability

[Frederik Ramm]

Hi,

On 08/02/11 15:21, Gregor Horvath wrote:
> It is a logically inaccurate to delete an ID in such cases.
> What you actually logically do is replacing an ID, or creating an alias.
> The problem is there is no semantic in OSM data to express such a move
> operation. Deleting is the wrong one. Deleting means a destroyed house
> or physically removed street and in this case it is logically correct
> that the ID is gone.

No. You are entirely mistaken in applying that kind of semantic to OSM. 
When a mapper maps a street, or a building, or anything, the ID is just 
a throwaway by-product of that process which allows us to refer to the 
object internally. The mapper does not willingly say: "I hereby assign 
the following ID to you, house, to remain with you until you are destroyed!"

Therefore, IDs in OSM can be torn down, changed, even renumbered at will 
without there being *any* semantic reflecting on the actual physical 
object. What we have in OSM are models of physical objects, and these 
models may change, merge, vanish, be duplicated, modified, extended, or 
reduced without anyone saying "oh, this must mean that the physical 
house now has got an extra feature!".

Deleting an object in OSM only becomes "logically inaccurate" if one 
makes the semantic connection that you are making ("deleted object -> 
demolished house"), but in fact it is that connection that is logically 
baseless. (For example, we would also delete an object if we find out 
that it was wrongly imported or taken from an unsuitable source, just to 
mention the most obvious examples.)

> So my proposal is to describe move operations in OSM data.
> For example: Instead of deleting, all tags of the object or removed and
> a "alias_for" "joined_with" "splitted_to" tag(s) which points
> to the new correct node(s) ID is inserted to the old node .

This is an interesting idea that would often make it easier to find out 
what someone has done in an editing session - has he shortened one way 
and created another new way, or has he simply split one?

But it should not be confused with ID persistence.

Bye
Frederik