<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Damn, forgot to delete the top part before I sent, I started writing
at the top, before cutting and pasting to below and forgot to delete
the rest.<br>
<br>
Anyway thank you again for your positive constructive criticism. As
I say, exactly what I wanted, food for thought, use cases that I
didn't know about that I can now research and feed into the
"Detailed Description" section. I now see some more inconsistencies
that we need to solve.<br>
<br>
I feel I came to quick in my last email to bring about solutions,
possibly they will become the solution, perhaps not, but first I
need to flesh out the description section... hopefully over the next
week I will add information about the inconsistencies your email
reply brought to light (I know I speak in riddles, but I have to
first clarify it for myself with examples). The rest of the MEP
will take time to develop, probably with some simple diagrams too.<br>
<br>
And when I say "I" feel free to interpret it as "we", if you have
ideas please feel free to post them here, or make PRs, for example
against my PR and we can flesh the Description section out even more
:).<br>
<br>
Best<br>
OceanWolf<br>
<br>
<div class="moz-cite-prefix">On 05/09/15 22:10, OceanWolf wrote:<br>
</div>
<blockquote cite="mid:55EB4C4B.6090902@yahoo.co.uk" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<br>
<br>
<br>
Not too sure what you meant by ````. <br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 05/09/15 19:25, Joe Kington wrote:<br>
</div>
<blockquote
cite="mid:CACe1pJdxmbSckwbzTDXgn0jLnRE_GNGR+VgUv557wPRNR9g_oA@mail.gmail.com"
type="cite">
<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>
</blockquote>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CACe1pJdxmbSckwbzTDXgn0jLnRE_GNGR+VgUv557wPRNR9g_oA@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</div>
</div>
</blockquote>
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 <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://en.wikipedia.org/wiki/Spherical_geometry">https://en.wikipedia.org/wiki/Spherical_geometry</a>.
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.<br>
<blockquote
cite="mid:CACe1pJdxmbSckwbzTDXgn0jLnRE_GNGR+VgUv557wPRNR9g_oA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<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>
</div>
</div>
</blockquote>
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).<br>
<br>
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).<br>
<blockquote
cite="mid:CACe1pJdxmbSckwbzTDXgn0jLnRE_GNGR+VgUv557wPRNR9g_oA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>---------------------<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>
</div>
</div>
</blockquote>
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.<br>
<br>
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?<br>
<br>
Best,<br>
OceanWolf<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Matplotlib-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Matplotlib-devel@python.org">Matplotlib-devel@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/matplotlib-devel">https://mail.python.org/mailman/listinfo/matplotlib-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>