-
Notifications
You must be signed in to change notification settings - Fork 57
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
Comments
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. |
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 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? |
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? |
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) |
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?
The text was updated successfully, but these errors were encountered: