Version information in new deleted object may differ depending on use case

[CloudNiner]

Currently we always just pass through whatever version we get from the osm change file. However, it looks like depending on the use case and the type of change file that is used, this may not be the best strategy.

Conversation on osmus slack

https://osmus.slack.com/archives/C1VE7JM9T/p1591676862101500

shouldn’t that mean a delete element in an OSC would never have version=1? i’m seeing deletes with version=1 in a geofabrik regional daily osc

mmd 24 hours ago
do you have an example id for such a v1 delete?

mmd 24 hours ago
ok, I have one: 291305802v1 was marked as deleted in one of geofabriks osc files. (edited)

mmd 24 hours ago
that's a bit odd, i would have expected in there, and leave v1 as is.

mmd 24 hours ago
Ah, see it's documented on the osmium page: https://docs.osmcode.org/osmium/latest/osmium-derive-changes.html (edited)

mmd 24 hours ago

Note that for objects that are in OSM-FILE1 but not OSM-FILE2 a “deleted” entry will be created in the output. But because we can not know when this deletion actually occurred, in which changeset, and by which user, it is unclear what attributes this deleted object should have. Also, if you are working with extracts, the object might not actually have been deleted in the OSM database, but just moved out of the extract you are looking at. So a real, new, “deleted” version was never created. Usually the “deleted” object will get the same version number and timestamp as the object in OSM-FILE1 had, all other information will be removed. But you can change this using the --increment-version, --keep-details, and --update-timestamp options. Depending on which software you are using the change files with, different settings might be necessary.