tyrasd
commented
4 years ago this is indeed a nice idea, but there is one problem if we want to make these incremental counters: if a request does only request a part of an element's history, then the code can't know which minor version number to start counting from. example: say you have an element with the following minor versions:
t₁ – version 1.1 – creation
t₂ – version 2.1 – tag change
t₃ – version 2.2 – geometry change
t₄ – version 2.3 – geometry change
t₅ – version 2.4 – geometry change
t₆ – version 2.5 – geometry change
t₇ – version 3.1 – deletionif then a user requests only the time interval from t₄ to t₆ for example, then should the output be 2.3 → 2.4 → 2.5, but the API could reasonably only return 2.1 → 2.2 → 2.3 which would be quite confusing if one would compare this result with a second query which starts at a different time (say t₁).
One way to solve this is problem is to just not use an incremental minor version counter, but use the timestamps as minor-version differentiators. Like this:
t₁ – version 1.t₁ – creation
t₂ – version 2.t₂ – tag change
t₃ – version 2.t₃ – geometry change
t₄ – version 2.t₄ – geometry change
t₅ – version 2.t₅ – geometry change
t₆ – version 2.t₆ – geometry change
t₇ – version 3.t₇ – deletionNow the API can safely return the correct and stable sequence of minor versions for every request: 2.t₄ → 2.t₅ → 2.t₆.
Interestingly, we don't need to change anything in the ohsome API to achieve this kind of minor-version numbering, because we already have it implemented exactly like this. :sunglasses:
There is a special case within the OSM data, where the geometry of e.g. a building changes, but the version does not, as only one or more nodes changed their coordinates. This case is reflected within the OSHDB and is therefore used within the ohsome API too. It could lead to some confusion though, if two objects in the result have different geometries, but the same version. This is an example of an approach on how to apply it, e.g. on a building: