Following extensive work on the OpenStreetMap NextGen migration, I’m excited to share my proposed data model for API 0.7. This incremental update focuses on streamlining and standardizing mostly existing features. Please share your thoughts and suggestions in this thread!
This document may be updated as the discussion progresses.
Unfortunately, area type in API 0.7 doesn’t seem feasible. OpenStreetMap-NG is already a huge step forward, and let’s focus on making that leap a success! I’m committed to delivering a fantastic API experience as we build toward the future. I look forward to exploring a more robust data model for API 1.0 (when the time comes).
Short answer
On second thought, this doesn’t seem useful. I’ll remove it for now. Thanks for pointing that out!
Long answer
I initially intended this feature for applications using database cursor functionality, where requests aren’t limited to a fixed count but can continue fetching related query elements. The superseded_at property would indicate if elements became outdated during subsequent requests.
However, I realize such implementation is flawed. While it would guarantee freshness for later queries, it wouldn’t do the same for previously read data. A better solution would be a separate endpoint (when needed) that checks for elements modified since the initial query. This would ensure true freshness and simplify responses by removing the superseded_at property. I’ll remove it for now, keeping in mind that no is temporary, but yes is forever (what does it mean).
This document may be updated as the discussion progresses.
Just one question, what’s the rationale behind adding a