-
Notifications
You must be signed in to change notification settings - Fork 43
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
Should geospatial sources open with a default projection? #1106
Comments
Although having a default project would make sense in some contexts, I think this would be surprising in others. From a tile serving endpoint, this makes sense. From an algorithm endpoint, this doesn't (at least, I think many algorithms want to work on a pixel-wise basis and not a projected space basis). Maybe the tile serving endpoints that don't specify a project could default to none for non-geospatial and EPSG:3857 for geospatial, but the pythonic interfaces would stay with none as the default. |
This makes sense. I need to look into if Perhaps for geospatial sources (at the class-level), |
I think we currently open different projections as different sources (unlike with styles), so there isn't a |
Hm, then this might be too much effort to handle at this time |
Based on some discussion, one approach would be to have a default projection of some keyword like |
I think this makes the most sense. After all, I think it is rare for the rasterio (and even GDAL) sources to be used without a projection. |
The current default projection is
None
for geospatial sources -- this has a specific meaning (to use image coordinates).I'm wondering if geospatial sources should be opened with
EPSG:3857
by default, as this is intuitive and what most users probably do anyways.Changing this default will likely have ramifications in downstream packages (I know it will affect RGD and
django-large-image
at least).Similarly to #1105, this will improve useability of #1065 but is less critical
The text was updated successfully, but these errors were encountered: