Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AugmentedDiffSource.sequenceToTimestamp is off by one minute #142

Open
CloudNiner opened this issue Sep 22, 2020 · 0 comments
Open

AugmentedDiffSource.sequenceToTimestamp is off by one minute #142

CloudNiner opened this issue Sep 22, 2020 · 0 comments

Comments

@CloudNiner
Copy link
Contributor

The official conversion at https://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs#Time_slices_and_numbering uses the epoch offset of 1347432960 and the sequence id refers to the timestamp at the end of the minute.

Vectorpipe defines its conversion as https://github.com/geotrellis/vectorpipe/blob/master/src/main/scala/vectorpipe/sources/AugmentedDiffSource.scala#L134 which uses the epoch offset 1347432900.

This means that if I call AugmentedDiffSource.sequenceToTimestamp(4216952) I get back 2020-09-18T17:27:00Z. If I query overpass for the same augmented diff ID, I get osm elements modified in the range 2020-09-18T17:27:00Z through 2020-09-18T17:28:00Z. According to https://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs#Time_slices_and_numbering, the timestamp should be the end time of the range, so we're off by one.

To fix, we should update the epoch offset in our methods to match the 1347432960 used by Overpass.

This would be a breaking change and may require special consideration by downstream clients in order to to adjust correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant