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

BBOX and footprints concerns (CRS, redundancy) #7

Open
cholmes opened this issue Jun 15, 2017 · 1 comment
Open

BBOX and footprints concerns (CRS, redundancy) #7

cholmes opened this issue Jun 15, 2017 · 1 comment

Comments

@cholmes
Copy link
Contributor

cholmes commented Jun 15, 2017

Right now we say that the BBOX is in CRS units, and we don't specify the units of the footprint.

At the very least we should specify the units of the footprint.

The example json is in 4326, but it is common for imagery to be provided in a specific UTM zone. If the bbox and coordinates are not in 4326 then it'll be pretty annoying for crawlers to properly catalog stuff, as they'll need to understand projections.

At Planet we have gotten a request from a provider to make the footprints available in the native projection. But it seems like most providers make the footprint available as 4326.

We could consider making 'projection' an optional field, and just rely on the image format to provide its proper projection? And then just make the BBOX and footprint in 4326.

Also do we really need bbox and footprint? Perhaps we just have footprint.

@matthewhanson
Copy link
Collaborator

@cholmes

An argument can be made to make all coordinates in 4326, it's easier to search by users and as you say doesn't require any understanding of projections. However I personally think that the footprint should be given in the projection that the data is made available in. Footprints in a data native projection will be rectangular (no doubt there are exceptions), while a 4326 footprint may be a more complicated polygon which may not necessarily describe the footprint as accurately as one in a data native projection. However, this is certainly going to vary by data source and provider. I think your idea of making projection an optional field is perhaps the best, it's not so good to require a footprint only in 4326 if it's not appropriate for some non-standard projections (see MODIS).

BBOX is a useful parameter - it's short and a quick way to use a spatial filter to narrow down a search region, as well as provide a quick reference for location. As such it works best in 4326, regardless of the footprint, and in fact is even more important if the footprint is not in 4326 as it provides easily recognizable coordinates.

In summary - BBOX is a short useful parameter when in 4326. Footprint should be allowed to be given in any arbitrary CRS but default to 4326 if a CRS is not given.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants