search

CubeBrowser / cube-explorer

browser based exploration of iris cubes
BSD 3-Clause "New" or "Revised" License
8 stars 12 forks source link

Naming this project #41

Closed jbednar closed 8 years ago

jbednar commented 8 years ago

Right now this project has three associated names: Cube Explorer, Cube Browser, and HoloCube. Usually, when something has lots of names, that's an indication that no one is particularly happy with any of them, or at least that not everyone is happy with any one of them. While the project has been completely in flux, settling on a name hasn't been urgent. But now as the project nears its first release and I'm working on the documentation, I think we need to take a step back and see what the shape of it is and thus (as a byproduct) what a good name would be.

I think the existing names have different connotations:

Cube Browser: to me, implies that we have some datastore of cube objects that we want to index and survey, visualizing specific cubes at will, but perhaps not diving too deeply into any one cube. Also seems to imply some sort of graphical app or GUI interface, not a library.

Cube Explorer: similar to Cube Browser, but perhaps indicates more that we will be diving into individual cubes to understand them, not simply surveying a set of them. As for Cube Browser, sounds like an app or GUI, not a library.

HoloCube: To someone who knows what HoloViews does and that Iris has cubes, this name suggests an interface between Iris cubes and HoloViews. To anyone else, probably means nothing at all. Sounds vaguely futuristic, at best. :-)

There are actually at least 5 different things that need a name:

  1. The overall project being done by Continuum with input from the Met. Currently, informally, the "Cube Browser" project, or (within Continuum) the "Met Office" project. This project includes work done as contributions to several different existing projects (HoloViews, Iris, Cartopy), plus work stored in a new GitHub repository created specifically for this project.
  2. The GitHub organization hosting packages created specifically for this project. Currently CubeBrowser.
  3. The Gitub project name holding Python package(s) created specifically for this project, plus examples and documentation specifically for this project. Currently cube-explorer.
  4. Any newly created conda and pip package(s) that users will install, once we release 0.1.0. Mainly contains Python packages.
  5. Any new Python package(s) that users will import. Currently holocube.

Very often, items 3, 4, and 5 will have the same name, which makes it much easier on the users: what they install with pip or conda provides a Python package of the same name, and corresponds to a GitHub project of the same name. The names for 1 and 2 are often the same as each other too, and for simplicity let's just assume those remain CubeBrowser for now. So we mainly need a name for item 5 that makes sense in the context of item 1 (because item 3 contains item 5 plus documentation of item 1).

Considering the overall project (item 1), what we did in this project is:

At a user level, a summary is that the main functionality provided by the holocube package is that they can now use Iris cube data whenever they create a HoloViews Element, plus they now have a set of specific projection-aware geographic Elements (GeoElements) they can use. The full power of HoloViews is then available for cube data and for geographic data, i.e. flexible combination and selection of instantly visualized data to create complex multi-figure layouts and animations with ease.

So, in terms of naming item 5, there are a few things we could focus on:

a. Connecting Iris, Cartopy, and HoloViews b. Plotting Iris data cubes flexibly (e.g. cube-browser, cube-explorer) c. Adding cube data support to HoloViews (e.g. holocube) d. Adding geographic projection support to HoloViews (e.g. geoviews, cartoviews) e. In general, plotting geographic data easily and flexibly (geoviews actually works here too)

Any opinions?

jlstevens commented 8 years ago

There is a lot to discuss here! The breakdown of what the project contains looks accurate to me.

Just to get the naming discussion started, I'll say that I agree that Cube Browser sounds more like a GUI tool and that I don't find the Cube Browser vs Cube Explorer distinction particularly helpful.

This could be fixed if a CubeExplorer organization was registered and this repository were transferred to it (getting rid of the name Cube Browser). Alternatively, we could simply rename this repository to cube-browser in order to ditch the Cube Explorer name.

In terms of naming, I think the former option would be nicer but it would also be more work. We would need a lot more input before going ahead with such a change and maybe we'll just stick to these two names simply to avoid the disruption.

philippjfr commented 8 years ago

I agree that CubeBrowser and CubeExplorer aren't very descriptive names for this project. Your summary of what this project actually contains is a good one and should guide the discussion on naming and where to move different components. To me there are two major aspects to the work we've done here:

1) Providing an interface to use cartopy projections and various geographical features in HoloViews. This includes various GeoElements including GeoFeature, GeoTiles, WMTS, Points and Text and their corresponding plotting classes.

2) Providing an interface to work with Iris Cube data in HoloViews, which basically consists of the CubeInterface, HoloCube and conversion interface. It also includes the plotting classes for the custom Image and Contours classes as those are currently only well defined when these Elements wrap actual cube data.

The question then becomes whether these two aspects fit into one project or whether they can move into other projects. The first comment I'd like to make in that regard is that I'd like to see an object like the HoloCube exist in HoloViews itself. Currrently we have the Table class, which implements a conversion interface. This made sense when the interfaces only supported tabular data but now that we have support for labelled nd-arrays in HoloViews I'd like to have a different class, which will allow you to wrap and convert data either in a gridded or in a tabular format. This would eliminate the need for a HoloCube class and conversion interface in this project.

That would leave just the Element types and the CubeInterface, which I think fit together into a nice project. The only thing to do to make this library completely general would be to implement the Image and Contour plotting classes in such a way that they can work with or without cube data. At that point the support for cube data will be a secondary detail and simply an easy way of supplying the data but the project could be used completely independently. If that were the case I think a general name like cartoviews or geoviews would be best.

The only question then would be under which organization this project would be managed.

jbednar commented 8 years ago

If you think the future of this Python package is to end up with cube data support being a secondary detail, then I think we should name it accordingly, i.e. not have "cube" in the name. So I'd vote for either cartoviews (if we want to make an explicit link to cartopy, which is helpful for explanations but means that if the library moves beyond cartopy someday then it will start to be confusing), or geoviews (if this package is where we expect to put any HoloViews support that's specific to geography, whether based on cartopy or other libraries). Philipp, what does your gut say? Will we (should we) ever have non-cartopy stuff in this package, other than the Iris support (which we hope to fade into the background)?

philippjfr commented 8 years ago

I have no particular preference between cartoviews and geoviews, both convey in some sense that they are extension for plotting cartographic/geographic data using HoloViews. Cartography is a meaningful term independent of cartopy so I don't think it locks us in in any way.

Will we (should we) ever have non-cartopy stuff in this package, other than the Iris support (which we hope to fade into the background)?

I don't know, it depends a little bit on what the MetOffice guys think. Once I'm done with my PhD I'd be very happy to continue developing a holoviews geographic package and possible extend it with geographic plotting support for bokeh for example and would therefore not necessarily tie it to just cartopy/matplotlib. However it may be that the MetOffice guys would rather have a separate package that deals exclusively with cartopy/iris interfaces, which may be easier to maintain for them.

marqh commented 8 years ago

http://semver.org/

jbednar commented 8 years ago

Moved discussion of versioning to issue #49.

jbednar commented 8 years ago

It seems to me that using the name cartoviews and limiting this package to containing HoloViews-based code specific to Iris and Cartopy would be the clearest option, so that the ownership of this package rests definitively with the Met. That way, if we did want to provide Bokeh-based geographic support, we would be free to develop it separately (perhaps as a geoviews project, or even just as part of Bokeh), or else we could contact the Met if we really thought it belonged in this package, but it would always be clear who has responsibility for making decisions about this package. I wouldn't want this package to become an orphan, owned by no one!

@marqh, how does that sound? I.e., call it cartoviews, specific to Iris and Cartopy interfaces to HoloViews, with the Met having the last word on any and all items included in the package (including setting all defaults, choosing all names, etc.)?

marqh commented 8 years ago

I can't help the feeling that the cartography aspects and the Met metadata are independent. cartoviews doesn't give me a sense of working with the metadata which is key to us

I am still quite taken with the initial place I started, which is cubebrowser

If we choose in the future to separate the interfaces out, so there is a map specific aspect that isn't related to Iris and cubes, perhaps that could be cartoviews but for now I like having the term cube in the name. The fact that cubes are often related to geography is useful, but not key.

So, to details:

The overall project being done by Continuum with input from the Met. Currently, informally, the "Cube Browser" project, or (within Continuum) the "Met Office" project. This project includes work done as contributions to several different existing projects (HoloViews, Iris, Cartopy), plus work stored in a new GitHub repository created specifically for this project.

I'm not too worried about this naming, I have always called this Cube Browser within my stakeholder communications.

The GitHub organization hosting packages created specifically for this project. Currently CubeBrowser.

This github organisation may well not last much longer. The repository may well move into http://github.com/SciTools as part of the adoption of code by our community.

The Gitub project name holding Python package(s) created specifically for this project, plus examples and documentation specifically for this project. Currently cube-explorer.

Any newly created conda and pip package(s) that users will install, once we release 0.1.0. Mainly contains Python packages.

I'm not sure about these.

Any new Python package(s) that users will import. Currently holocube.

This is the most crucial name for me. This is what we expect the Python coders to import, this should convey the nature of the library.

I like holocube here, it clearly describes the link between holoviews and Iris.cube

I can see how cubebrowser could be a reasonable alternative name, but perhaps that is better suited to the set of pre-prepared notebooks that are ready to roll, rather than the API which powers them.

philippjfr commented 8 years ago

If we choose in the future to separate the interfaces out, so there is a map specific aspect that isn't related to Iris and cubes, perhaps that could be cartoviews but for now I like having the term cube in the name.

I think this is the key point. I don't see this happening any time but once I personally have some more time I will probably devote some time to developing a package based on holoviews and cartopy that is centered around working with GIS data but independent of iris. Once that is done holocube can become a simple extension of that package adding support for iris.Cubes as a data source. Similarly we will likely develop a very similar interface for xarray datasets. Until that point it makes sense to keep the projects together under the header of holocube.

Moving it to the SciTools organization also makes sense to me, although I'd hold off on that until at least after the sprint.

jlstevens commented 8 years ago

Sounds like a plan to me!

Here is my summary of what I think is being proposed:

The only thing to add is that if holocube only adds Iris Cube support to HoloViews via a data interface, I can see it becoming part of HoloViews itself. In that case, there is only the Iris independent holoviews/cartopy component Philipp suggested. Maybe that would be the thing called cartoviews?

In this scenario, the cubebrowser notebooks will rely on holocube for the time being and may eventually rely only on cartoviews if Iris support is folded into HoloViews itself.

marqh commented 8 years ago

Exeter group consensus has settled on geoviews as the python package name

marqh commented 8 years ago

we now have a question of github organisation ownership for this project candidates:

marqh commented 8 years ago

pypi, conda and github repo are to be called

geoviews

marqh commented 8 years ago

67 for element naming

marqh commented 8 years ago

we now have https://github.com/ioam/holoviews (including Dataset) https://github.com/ioam/geoviews and https://github.com/scitools/cube_browser

marqh commented 8 years ago

this completes the naming issues

cube-explorer (this one) remains open as a focal point for the project issues