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

Clarify projection of bounding box columns #203

Closed
kylebarron opened this issue Apr 16, 2024 · 4 comments · Fixed by #226
Closed

Clarify projection of bounding box columns #203

kylebarron opened this issue Apr 16, 2024 · 4 comments · Fixed by #226
Assignees
Milestone

Comments

@kylebarron
Copy link
Collaborator

kylebarron commented Apr 16, 2024

I think the spec could be a bit clearer about this. Do the bbox columns HAVE to be in the same projection as the data?

Thinking about this in the context of stac-geoparquet... the STAC spec defines bbox to always be WGS84, even when the projection of the geometry is not WGS84 (edit: oops STAC defines geometry to be WGS84, so this specific use case is irrelevant, but the general question still stands). There are certainly some use cases where having the bbox always in WGS84 simplifies things (thinking of the browser myself).

Is this something that should be allowed in the spec? Should bbox columns be allowed to have their own projection?

@rouault
Copy link
Contributor

rouault commented Apr 16, 2024

Do the bbox columns HAVE to be in the same projection as the data?

There should be a strong use case for allowing bbox columns not to be in the same projection as the data, as that would be a source of complexity. I can't think of any other existing geospatial format that has a a spatial index in a SRS that is not the one of the geometries being indexed.

@cholmes
Copy link
Member

cholmes commented May 6, 2024

I agree there should be a strong use case for bbox columns in a different projection.

It does seem like this could be an area where there's experimentation for awhile before we bring it into the spec. Like there's nothing stopping adding an extra consistent-bbox column in WGS84, or even only using that (since the core bbox one is optional). If there's compelling cases for it we could add it.

Not sure if we need to be more explicit in the spec that for now we require the bounding box geometry to be the same as the specified crs?

@cholmes cholmes added this to the 1.1 milestone May 29, 2024
@cholmes
Copy link
Member

cholmes commented May 29, 2024

So do we want to say something in the spec, just to be clear that current practice is for bbox columns to be in the same projection as the primary geometry column?

@jorisvandenbossche
Copy link
Collaborator

Yes, I think it would be good to add a sentence to explicitly state that the values in the bbox column should be interpreted in the projection of the corresponding geometry column.

(note this is not necessarily the primary geometry column, as the covering bbox info is in the column metadata, so in theory you can have multiple geometry columns in a file each with a different CRS and have a bbox column for each of those)

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

Successfully merging a pull request may close this issue.

4 participants