Optional column metadata field to store bounding box information

[jorisvandenbossche]

Closes #8

[jorisvandenbossche]

I added this "formatted according to RFC 7946, section 5" (i.e. GeoJSON), copying how this "bbox" was specified in the STAC Item schema: https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md#item-fields

However, I am not 100% sure we actually want to fully follow that:

• It mentions how to interpret it in case of antimeridian crossing -> this seems good to follow.
• It mentions how to interpret the connecting lines (the edges of the box). Do we want to relate this to Store information about planar vs spherical coordinates (eg geodesic=true/false) #9?
• It mentions how to deal with the poles, by using some placeholder values like minlat. However, it's not clear to me what this is (is this a string in JSON? But it's not formatted as a string). I am also not aware of an implementation actually doing this (for example, GDAL does not support this AFAIK)

[cholmes]

Do we want to relate this to #9?

I'm not sure exactly how we relate it, but I do think we should explicitly mention the interaction between that geodesic=true/false and the bounding box - if that field changes the interpretation of anything here.

It mentions how to deal with the poles, by using some placeholder values like minlat.

Wow, I've read that spec a number of times and never even noticed this. I feel ok with just referencing the spec and not trying to clarify this particular issue. If someone actually has a problem with it then we could redo it. But I think it's nice to be able to point at something else that has lots of parsers written for it, instead of making people carefully read ours and try to do something slightly different.

[kylebarron]

Wow, I've read that spec a number of times and never even noticed this

👍 , just saw this for the first time!

• It mentions how to deal with the poles, by using some placeholder values like minlat. However, it's not clear to me what this is (is this a string in JSON? But it's not formatted as a string). I am also not aware of an implementation actually doing this (for example, GDAL does not support this AFAIK)

My read of this is: in each of those examples, minlat, maxlat, eastlon, westlon aren't string literals intending to be saved to JSON but rather variables that you would replace with numbers for your own bbox. For example

A bounding box that contains the North Pole extends from a southwest
corner of "minlat" degrees N, 180 degrees W to a northeast corner of
90 degrees N, 180 degrees E. Viewed on a globe, this bounding box
approximates a spherical cap bounded by the "minlat" circle of
latitude.

"bbox": [-180.0, minlat, 180.0, 90.0]

My read of that is that if you had a bounding box to cover the globe above 70 degress latitude, your bounding box would be

[-180.0, 70, 180.0, 90.0]

[jorisvandenbossche]

My read of this is: in each of those examples, minlat, maxlat, eastlon, westlon aren't string literals intending to be saved to JSON but rather variables that you would replace with numbers for your own bbox.

Indeed! By chatting with @paleolimbot about this, he mentioned the same. I completely missed this from an initial reading, but that makes sense now.

So to follow up on my own questions:

It mentions how to interpret it in case of antimeridian crossing -> this seems good to follow.

That is consistent with how PROJ or S2 specify bounding boxes / areas (see also the comment at #8 (comment)).
I think it is fine to follow this, but implementors need to be aware that this makes interpreting the bbox more complex (you need to check for the east (ymax ) value being smaller than the west (ymin) value, and handle this case properly for crossing the antimeridian). For example, in the current GeoPandas implementation of this, we just make a rectangular polygon of those 4 values, and this gives the wrong polygon (not crossing the antimeridian, but rather the complementary bbox).

It mentions how to interpret the connecting lines (the edges of the box). Do we want to relate this to #9?

This is actually fine, and isn't influenced by the edges="planar"|"spherical" flag. Because of the way how a bbox is defined (take the min/max range of coordinates in each dimension), it can in practice always be considered as planar.

It mentions how to deal with the poles, by using some placeholder values like minlat.

This is clarified above.

---

In summary, I am now convinced it is good to specify this field follows the GeoJSON specification.