extent <> bbox

[iwpnd]

Hey,

I just ran into that foot gun of Photons search response properties.extent not following the bounding box order of coordinates in the GeoJSON spec. As far as I could find out this is deliberate choice and not a bug in Photon.
From a small search on the issues I can see that I'm not the only one that ran into that wall, so I was wondering if it makes sense to ship search response GeoJSON Features with an additional feature.bbox attribute as the GeoJSON spec allows to avoid that confusion.

Kind regards

[lonvia]

That would be possible. Is Strava willing to sponsor such a feature?

[iwpnd]

That would be possible. Is Strava willing to sponsor such a feature?

Not sure what you mean by feature, but I'm happy to add a bounding attribute to the response feature that conforms to the GeoJSON spec if that helps prevents confusion that I, and others ran into. 👍

[iwpnd]

Do you want me to create a separate issue outlining the steps before creating a PR? Or do you prefer to keep the discussion here?

[iwpnd]

I went ahead and sketched out the change locally. It's a small addition to the serializer: adding a spec-conformant bbox member to the Feature alongside the existing extent in properties, no breaking change.

Something like (pseudo):

west, south, east, north = [
    min(extent[0], extent[2]),
    min(extent[1], extent[3]),
    max(extent[0], extent[2]),
    max(extent[1], extent[3]),
]

Happy to open a PR if you'd like to review it, or if you'd prefer I file an issue first, that works too.