Pattaya gone


Yes, it was removed in that changeset:

Maybe send a message to the user to inform him/her of the error.

I can revert the change in a moment, but I need to do some other stuff first.


ID’s are never re-used, new ID’s will always be created for new nodes.

Though you didn’t ask, I still think this might be of interest to you:
You can’t rely on the ID always staying the same either, which is nice to know if you ever try to link external datasets to OSM objects. Wikipedia for ecample wanted to have the Chiang Mai province article pointed at the Chiang Mai province boundary id - this is not recommended.

At some point the OSM database might change form and all ID’s could renumbered, and only internal references would be automatically updated.

Another issue is if someone splits the boundary, then two new boundaries are created - some with the old ID and some with the new ID - later these boundaries could be re-joined and the old ID could disappear.

Anyway, this is an issue that people are still trying to solve and not really related to this problem.


For those curious in the Python code behind this:

from osmapi import OsmApi

# Login to OSM
MyApi = OsmApi(username = u"Johnny Carlsen", password = u"******")

# Create a new changeset
MyApi.ChangesetCreate({u"comment": u"Restored Pattaya"})

# Load version 8 of the Pattaya node - this was the lastest non-deleted version 
node = MyApi.NodeGet(278056967, 8)

# Update the version to 9, so we don't get conflict errors
node[u'version'] = 9

# Re-upload version 8 of the node as version 9

I believe there are several ways of undeleting nodes, some might even be built in to editors like JOSM.



I think quite a bit is being lost and it is difficult to track because there are many correct deletions as well.

Change monitoring tools such as Who Did It (Implementations here and here) and OWL (beta implementation here) can be useful for monitoring changes and deletions in an area. Actively going through them to check for unconstructive edits can still be quite a pain, though.