On Sat, Sep 5, 2015 at 3:10 PM, OceanWolf <juichenieder-nabb at yahoo.co.uk> wrote:
Not too sure what you meant by ````.
On 05/09/15 19:25, Joe Kington wrote:
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.
No worries, I experience the same, and yes I wanted to open this up for
just this kind of interrogation, especially as we have a lot of axes
related code, and I have only touched a fraction of it to date.
To explain where I come from, I should say that I like to work bottom-up.
I find designing good code starts with asking probing questions about what
you want to model, in this case we have an ``_AxesBase`` class and so by
definition it should model an abstract Axes, because of this in the
"Detailed Description" of this MEP I begin by asking the question probing
the definition of an Axes. I believe that if we model the world
intutitively as we see it, everything else will fall into place. I find
the most direct route in code usually contains lots of inflexibility, like
building a road through the mountain, you might go the direct route, but it
becomes very difficult to maintain and expand upon. Hence the focus lies
in the journey.
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.
If I understand you correctly you don't like the idea of forcing Artists
to use the transform. I don't see this as a problem (at the moment). As
far as I see it, all coordinates supplied to an Artist will come in the
form of Axes coordinates, i.e. Axes space, and thus we need to transform
those coordinates to screen coordinates... at least at some point, probably
when it comes to drawing... I especially think of drawing a triangle onto a
spherical geometry, see Spherical geometry - Wikipedia.
We create a Polygon patch and supply the three vertices that define our
Triangle... however on a spherical geometry, these "straight" lines do not
conform to the Euclid definition of straight, we need to draw them curved.
Because of this the transform will need to come very late in the drawing
process.
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?
As far as I know, I want to keep the transform system. I think I do just
mean refactoring that into one method. I say think as I still don't feel
fully understand how it all works, the Transform system, brilliant, but
very mind-boggling. I had to delve into it to find a bug reported by a
user on github, and went through around 50 (perhaps more) Transform
operations before I got to the problem. If you need to debug part of it,
like i had to, it becomes a tangled mess, luckily for most people they
don't have to, and the usage works quite simply. When I tracked down the
bug I also spent quite some time trying to figure out the Transform
classes, prior to the bug I only knew of Rotation, Shear and Reflection
Transforms. Anyway my point here comes that while great, it can become
quite the head-ache for the average user developer, especially for those
who know even less then I do about transforms, and so I want to blackbox
the transforms in the Axes with simple names such as
axes_to_***_coords(self, *q), and ***_to_axes_coords(self, x, y).
So I want to make it easy for people to write their own axes with their
own transform methods without having to worry about how the rest of the
Artist code and plot methods work (unless it works really bizarrely); and I
want people to work on Artist code, and creating their own tools and user
interaction stuff without having to worry about learning about transforms
(they just need to know that these two methods will do the conversion for
them from data coordinates, which they understand, to the location on the
screen or whatever, which they will also understand, start talking about
AffineTransforms and I think we will scare people off).
---------------------
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.)
Hmm, when I have used Basemap, the data files I work with I always get in
lat/lon format. One of my biggest annoyances with Basemap comes from
having to work projection coordinates. I move the mouse over the map and
statusbar shows me useless projection coordinate information; I want to
rotate the globe (in 'ortho' projection), but I can't, it becomes very
difficult to use from a user interface point of view.
I think the solution here comes from using a dual approach. With the
functions above I used the term base, as in the ``axes_to_base`` and
``base_to_axes`` functions. Here ``base`` defines the projected
coordinates. We can then leave it up to the user to decide whether to plot
in axes coordinates or base coordinates. We can start of leaving the axes
side unimplemented, and perhaps we will never implement the axes side for
some Axes classes... what do you think?
Best,
OceanWolf