[Matplotlib-devel] MEP 29 Axes Refactor

[Joe Kington]

First off, I don't intend this to come across as overly critical!  I think
this is a very good discussion to have.
Also, I tend to have a bad "knee-jerk" reaction to change and tend to come
around over time, so keep that in mind too. :)

However, while I agree that `Axes` is quite a beast, I'm not sure this
proposal simplifies things.  From my perspective, it adds complexity. If
I'm understanding correctly, this would effectively tie the Transform stack
to the Axes, instead of having the Axes generate a Transform object that
may or may not be used by the artists in the Axes.

First we define our coordinate transformation functions: axes_to_base(self,
> *q) base_to_axes(self, x, y)
>
> The term base could get replaced with screen but for now we will keep it
> simple to reflect another transformation from base coords to screen coords,
> e.g. perhaps to differentiate between window and screen coords.
>

This is my main concern.  We have a (i.m.o.) very flexible and actually
quite clean Transform system to handle this.  Why shift away from it?
`ax.transData` may be non-PEP8 naming, but it's a good way to do this.  The
concept of having Transform objects that handle this but are separate from
the Axes gives a lot of flexibility.  In my opinion, the core concept of
having this transformation handled by a Transform object that's separate
from the Axes is one of the best things about matplotlib's design.

Or am I misunderstanding, and this is just a refactoring of
`_get_core_transform` and `_get_affine_transform` into one method?

---------------------

My other main concern centers on map projections. The MEP currently
mentions:

an anticipated structure of a base mapping class with a coordinate system
> in lat/lon coordinates, but with different mapping projections available
> for the conversion between the Axes coordinate system and the screen.
>

However, this is a bad approach for cartographic data. Geographic is not
the base for a projected coordinate system. There are several reasons for
that.

1. Map data is usually _in the projected coordinate system_.  Lat, long
data is actually not terribly common unless you're working with global
datasets.
2. Raster data (i.e. anything displayed with imshow) is typically going to
be gridded on a regular grid in the projected coordinate system.  Forcing a
transformation back to a non-uniform grid in lat, long space then back onto
a different uniform grid than the original in display space is
unnecessarily expensive.

One of the great things about Cartopy is that it leaves the fundamental
Cartesian projected space unchanged, and let's you specify the transform if
you want to use geographic coordinates.  Basemap handles it a bit
differently but has the same core concept.  Latitudes and longitudes aren't
the data coordinate system.  The projected coordinate system is.

There's a reason for that approach.  Forcing people to convert their data
into a geographic coordinate system before plotting it is a bad idea. It's
good to have plotting methods that allow geographic coordinates, but bad to
require that transformation.  (I'll skip the very important datum part for
the moment.  Just be aware that a lat, long only gets you to within ~1km of
a location without more information.)

----------------

At any rate, I may very well have misunderstood the changes that are being
proposed here!  My apologies if I have.
Cheers,
-Joe



On Sat, Sep 5, 2015 at 10:16 AM, OceanWolf <juichenieder-nabb at yahoo.co.uk>
wrote:

> Dear matplotlibers,
> Here I announce the creation of MEP29 to tidy up the Axes classes, and
> other classes that relate specifically to the Axes.
>
> See https://github.com/matplotlib/matplotlib/pull/5029 which you can
> click through to
> https://github.com/OceanWolf/matplotlib/blob/MEP-Axes-API/doc/devel/MEP/MEP29.rst
> to see the text itself.
>
> This MEP outlines how I see the Axes class progressing and tbh I feel very
> excited about what I have written, allowing people to write all sorts of
> exotic Axes such as those that employ non-Euclidian geometry; and also
> allowing for us to add multiple x,y,z axes to a 3d plot to name but a few
> of the features this MEP will add.
>
> Check out the MEP for more details, and please feel free to give comment.
> I should also point out that while I know about the existence of
> non-Euclidian geometry, my background comes from ocean-physics, not
> mathematics, so I have no knowledge beyond that considered popular
> mathematics.
>
> Also due to the complexity of the Axes classes at the moment, and how it
> spreads out into many files and beyond the core-matplotlib, I think this
> will take quite some time to implement, at the moment I just want to
> collate the most salient points into this MEP, I don't know how many
> features unknown to me exist, so help welcome, and then sort through,
> decide on a stratagy of how to split this up into more bitesized PRs and
> get going.
>
> Best,
> OceanWolf
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150905/6aea3fff/attachment.html>