Make gv an alias for hv in general?

[jbednar]

GeoViews provides specialized versions of many of the components available in HoloViews, and in many cases a given HoloViews object "hv.X" can be used in a projection-aware way as "gv.X". However, many items in HoloViews can be used as-is with GeoViews, and thus there is not in general a full set of "gv." versions of the various bits of HoloViews. In practice, it can be difficult for a GeoViews user to remember whether some component has been implemented in GeoViews or in HoloViews, and the resulting code is also often confusing (why does it sometimes say "hv." here, and ".gv" over here?).

I propose that we consider the alternative approach of mirroring all the main items in '.hv" so that they appear in ".gv" if they make sense there, which will make the user not have to worry about where that component was defined, and will make it simpler for us to add GV-specific versions of HV components later.

The first component that comes to mind is hv.extension(), which needs to be in any GV notebook, thus forcing a direct import of HoloViews. If that function were imported into the geoviews namespace, then users could just call gv.extension(), and someday if we wanted to add some GV-specific extension arguments we could easily do so.

[PeterDSteinberg]

+1 on any changes that make it easier for new users to remember which of these two packages provides a given functionality.

[kcpevey]

+1 This would make my life much easier!

[jbednar]

@philippjfr, what do you think?

@PeterDSteinberg, I think this change would make it harder for users to remember which one provides specific functionality, intentionally -- it would hide the distinction between hv and gv entirely, and allow gv users to simply think of gv as a version of hv with geo stuff in it, rather than thinking about which package has which bit. But yes, should make users life easier.

[philippjfr]

I think hv.extension should absolutely be exposed at the geoviews level and hv.help too, but I can't think of anything else.

[jbednar]

Are there Elements that don't need to be any different for gv, but still work fine when overlaid or laid out with gv Elements? If so, those should probably mirror into gv.

What about operations? Those need to be imported explicitly already, so maybe not.

In general, I'd think that anything from the hv namespace that people use regularly should be in gv too, whether changed for gv or not.

[philippjfr]

Are there Elements that don't need to be any different for gv, but still work fine when overlaid or laid out with gv Elements? If so, those should probably mirror into gv.

No, any elements you want to overlay on a gv plot should also allow specifying a crs.

In general, I'd think that anything from the hv namespace that people use regularly should be in gv too, whether changed for gv or not.

I don't disagree, but I don't know what there is beyond extension, help and maybe Store, renderer and Cycle.

[philippjfr]

Okay I've now added certain things. Do we want to go further and also expose the container objects in geoviews, i.e. HoloMap, DynamicMap, GridSpace, Layout, NdLayout, Overlay and NdOverlay?

[jlstevens]

I have mixed feelings about exposing holoviews elements through geoviews - as you say, crs should be supported for all elements in geoviews. However, I don't see any reason why container types would need to be customized in geoviews so exposing those classes does seem reasonable.

[jbednar]

I think the container types should be exposed in gv, both for practical reasons for geoviews users and as a declaration that these containers already have full support for all GeoViews functionality.

[philippjfr]

Now done. Here's the full API that's exposed:

from holoviews import (extension, help, opts, output, renderer, Store, # noqa (API import)
                       Cycle, Palette, Overlay, Layout, NdOverlay, NdLayout,
                       HoloMap, DynamicMap, GridSpace, Dimension)