<div dir="ltr"><div><br>First off, I don't intend this to come across as overly critical!  I think this is a very good discussion to have.<br></div><div>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. :)<br></div><div><br>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.<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><p>First we define our coordinate transformation functions:
axes_to_base(self, *q)
base_to_axes(self, x, y)</p>
<p>The term <code>base</code> could get replaced with <code>screen</code> 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.</p></blockquote><div><br></div><div>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.  <br><br></div><div>Or am I misunderstanding, and this is just a refactoring of `_get_core_transform` and `_get_affine_transform` into one method? <br></div><br>---------------------<br></div><div><br>My other main concern centers on map projections. The MEP currently mentions:<br><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.  <br></div><div>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.  <br><br>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.<br><br>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.)<br><br>----------------<br><br></div><div>At any rate, I may very well have misunderstood the changes that are being proposed here!  My apologies if I have.<br></div><div>Cheers,<br></div><div>-Joe<br></div><div><br></div><div> <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 5, 2015 at 10:16 AM, OceanWolf <span dir="ltr"><<a href="mailto:juichenieder-nabb@yahoo.co.uk" target="_blank">juichenieder-nabb@yahoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear matplotlibers,<br>
Here I announce the creation of MEP29 to tidy up the Axes classes, and other classes that relate specifically to the Axes.<br>
<br>
See <a href="https://github.com/matplotlib/matplotlib/pull/5029" rel="noreferrer" target="_blank">https://github.com/matplotlib/matplotlib/pull/5029</a> which you can click through to <a href="https://github.com/OceanWolf/matplotlib/blob/MEP-Axes-API/doc/devel/MEP/MEP29.rst" rel="noreferrer" target="_blank">https://github.com/OceanWolf/matplotlib/blob/MEP-Axes-API/doc/devel/MEP/MEP29.rst</a> to see the text itself.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Best,<br>
OceanWolf<br>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div><br></div>