holoviz / geoviews

Simple, concise geographical visualization in Python
http://geoviews.org
BSD 3-Clause "New" or "Revised" License
578 stars 75 forks source link

Assume data in lon,lat by default? #39

Closed jbednar closed 6 years ago

jbednar commented 7 years ago

Currently, GeoViews assumes no coordinate transformation for its elements, making most (all?) of them act like the corresponding HoloViews element. I.e., if the output is in the Web Mercator projection, then the input data is also assumed to be in Web Mercator units.

This convention makes sense, but it doesn't seem to me to be the most useful default, and it doesn't seem to fit with the idea of GeoViews as a separate package from HoloViews. The major reason to use a GeoViews Path or Points object instead of the corresponding HoloViews object is precisely so that coordinates will be transformed, so shouldn't we decouple the input and output coordinate systems by default? Right now, unless one specifies the crs for every element, there's no way to change the output transformation, so those two are tightly coupled by default.

To avoid that problem, users currently have to specify crs=crs.PlateCarree() everywhere, for what is surely the typical case of having data specified in longitude, latitude coordinates.

I propose that we add a parameter declaring a default coordinate system for all GeoViews objects, and that this parameter be crs.PlateCarree() by default. This would be a breaking change, but only for behavior that doesn't seem very useful now anyway, i.e. default values that are tied to the output projection.

jbednar commented 7 years ago

I suppose this parameter could be set to None to restore the current behavior.

philippjfr commented 7 years ago

This is something that just came up in a discussion on Gitter. Determining when a plot is geographic or not is a difficult problem. You could for example use an gv.Image to display a cross-section of latitude and time, in which case you do not want to apply a projection. If we set the crs to default to PlateCarree then you'd have to manually set it to None for these kinds of plots. I think that's okay, particularly because you always have the option of dropping back to HoloViews element types for non-geographic plots. So overall I think I agree, crs should just default to PlateCarree and if the user wants something else they should specify it.

jbednar commented 7 years ago

Good point. If they use gv operations to construct such a time slice, hopefully it would already work, but I can definitely see cases where it wouldn't Still, those seem much less common, so I still favor making this change.

jbednar commented 7 years ago

I keep bumping up against this issue. Having to import crs and specify crs=crs.PlateCarree() really makes things ugly and is error prone. How hard would it be to make this change? Seems like we should really do it now, before this library gets as popular as I expect it will be. :-)

philippjfr commented 6 years ago

The PR above made this switch and it's part of the last release. Closing.