the wiki about changeset download [1] says:
“The elements in the OsmChange are sorted by timestamp and version number.”
Let’s assume that an object is changed multiple times in one changeset, say it is first updated and later removed or first created and later modified. Is there any chance that I see the second change before the first when parsing a cs?
I guess no and such a cs would be invalid. Is that correct?
The way that I’ve always read it is that if the timestamps are the same (which is possible - a very quick add and delete within the same second) then the version number would ensure that they occurred in the right order in the changeset.
Yes, that was my assumption as well. I just wondered what would happen when someone changes the clock on the server (back) while the changeset is uploaded.
We’ve had front ends go out of sync irl, so I wouldn’t rely on that. As the multiple ops on the same element is most likely to occur in the multiple uploads to the the same changeset scenario, and you are not guaranteed to get the same front end on every upload, so the only think I would rely on is the version.
This API call is in fact handled by CGImap, and it seems to differ across read-only and write backend. In the former case, there’s an explicit ORDER BY object id and version, in the latter case, it’s absent and results would then be undefined.
Edit: However, it will later be sorted by timestamp, version and type.
Just to make that clear: I do not know about any cs which might be wrong. I stumbled over this because of a refactoring of the cs reader code in JOSM. I have no detailed information about the database structure or the processes that handle the changeset data.
I got curious because I found no reason to sort the entries by timestamp. You say they are sorted by object id and version when I retrieve changeset data, that’s what I expected.
The other question is how the objects are ordered before the version is set. If you think that there might be a problem please open a ticket.
My understanding so far is that each single change is processed against the database and that the version is increased by actually storing it in the DB or by rejecting it in case of conflicts, so again I see no need for sorting the data by timestamp.
I think we’re talking about two different scenarios here: in one case, you’re uploading changes, in the other you were referring to in your initial post, you’re downloading changesets via the API.
During upload, version numbers are initially set to 1 for a new object, or need to increase one by one, otherwise the changeset will be rejected with a conflict error.
OK, let’s focus on the download API. The Wiki still says that the elements are ordered by timestamp and version number.
When the mentioned ORDER BY clause is part of the API I think the Wiki should be corrected.
Please forget about what I wrote about cgimap, I missed a sort operation in the final response stage, which is based on the timestamp string (excluding milliseconds), the version, and the object type. This all happens way after the DB Select, the ORDER used in the database statement won’t impact the final result. In conclusion, the Wiki is correct here. Sorry for the confusion.