mmd-osm left a comment (openstreetmap/openstreetmap-website#5973)
> > Changefiles today are usually sorted by (OSM type, OSM id, version). This
> > ensures that most(*) dependent changes are already available, when reading
> > an object. Consumers may rely on that order.
> I think we can keep the sorting of objects (per action) as is, regardless of
> the output format (ie. for the changeset download case).
Ok, I guess my comment was a bit premature. This happens when commenting on a
mobile without checking the actual implementation...
Sorting today is based on timestamp, object version, type (node/way/rel), and
object id
([souce](https://github.com/zerebubuth/openstreetmap-cgimap/blob/v2.0.1/src/osmchange_responder.cpp#L32-L62)).
The action itself doesn't matter. It will be determined for each single
element
([source](https://github.com/zerebubuth/openstreetmap-cgimap/blob/v2.0.1/src/osmchange_responder.cpp#L188-L207)).
As can be seen in the following examples, the current sorting wouldn't work
anymore and re-grouping by action would be mandatory for the proposed JSON
format in this PR. API clients would definitely see a fairly different sorting
in this case.
* https://www.openstreetmap.org/api/0.6/changeset/52067542/download
* https://www.openstreetmap.org/api/0.6/changeset/52067546/download
* https://www.openstreetmap.org/api/0.6/changeset/52067549/download
I think, my original proposal in
https://github.com/zerebubuth/openstreetmap-cgimap/pull/407 would avoid this
issue. Iit uses the exact same sorting as today without a need to regroup the
data.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/5973#issuecomment-2847964730
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/pull/5973/c2847964...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev