search

CubeBrowser / cube-explorer

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

Added handling for geographic axis extents and ticks #28

Closed philippjfr closed 8 years ago

philippjfr commented 8 years ago

This PR enables controlling ticks and correctly computing the extents of the plots based on the data. This is enabled by transforming extents and ranges with the source coordinate reference system and the plotted projection. When used in an Overlay the options have to be set on the bottom layer.

This adds support for automatically computing extents of plots across multiple frames and allows control over ticking. The current ticking support is somewhat hardcoded so we should decide on how best to provide completely custom control over it. When setting xticks or yticks to an integer it sets that number of ticks in the current data interval, additionally the tick positions can be also be set explicitly in degrees:

%%output size=400
%%opts GeoFeature [xticks=[-180, -90, 0, 90, 180] yticks=3]
feats = [cf.LAND, cf.OCEAN, cf.RIVERS, cf.LAKES, cf.BORDERS, cf.COASTLINE]
features = hv.Overlay([hc.GeoFeature(feature) for feature in feats])
features

image

The formatter is currently hardcoded but it would likely be better to predefine latitude and longitude dimensions with a value_formatter defined, which the user and the cube interface could use. The current obstacle to that is that the cartopy latitude and longitude formatters have to be associated with an axis and can therefore not be used to format values independently of a particular plot.

Depends on https://github.com/ioam/holoviews/pull/578 in HoloViews.

philippjfr commented 8 years ago

I've slightly revised the PR such that ticks are only formatted for cylindrical projections, which avoids various issues. I think we can think about the issue with tick formatters at a later point as some ticking support is better than none. I suspect we'll have to support setting tick formatters as a plot option as an explicit override for the Dimension value formatter since you want it to be dependent on the projection you use to display it, so hard coding it on the Dimension isn't flexible enough.

The support for computing extents also seems pretty robust from my testing but we should consider adding support for adding padding to the axis limits because snapping to the data extent obscures data at the edges.

philippjfr commented 8 years ago

This PR still has various issues with certain projection types and will require some work to get right.