PLplot

Sounds (and looks!) interesting, Hez!

Is this global transform applied before, after, or instead of the  
"pltr" type transformations?

It looks like the global transform function has the same signature as  
the "pltr" transform functions so that the predefined pltr1, pltr2,  
etc. functions can be used as global transformation functions.  Do  
you envision this global transform capability supplanting the  
individual pltr parameter in the functions that currently support it?

Thanks,
Dave

On Apr 11, 2010, at 22:56 , Hezekiah M. Carty wrote:

> PLplot developers and interested users,
>
> With PLplot trunk rev. 10905, I have committed basic support for
> universal 2D coordinate transformations in PLplot using a new
> function, plstransform.  The commit includes an additional page in
> example 19 to illustrate how this function works.  A path
> approximation function plpath has also been included which can be used
> to draw an approximation of a straight line in transformed
> coordinates.  An update to the API docbook documentation for these two
> functions is included.
>
> "Universal," in this case, refers to the fact that _all_ PLplot
> plotting functions which act within the plot window should be affected
> by the defined transform.  If no transform function is defined then
> all PLplot functions should act as they did before this commit.  I
> have attached an example plot which takes advantage of this function
> both as an example of what this helps facilitate and to show that our
> modern output devices (pngcairo in this case) produce some very nice
> looking output!  The example shows plmap, plmeridians, plimagefr and
> plcont all working with the same transformed coordinate system.
>
> I have been using this patch for several months now without trouble or
> regressions that I have seen.  This patch does, however, touch a large
> number of core functions so I would like to request that other
> developers keep an eye out for possible regressions.
>
> The C and OCaml languages have been updated in this commit.
>
> Take care,
>
> Hez<test2.png>-------------------------------------------------------- 
> ----------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw- 
> dev_______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

On Mon, Apr 12, 2010 at 12:04 PM, David MacMahon
<davidm@...> wrote:
> Sounds (and looks!) interesting, Hez!
>
> Is this global transform applied before, after, or instead of the "pltr"
> type transformations?
>
> It looks like the global transform function has the same signature as the
> "pltr" transform functions so that the predefined pltr1, pltr2, etc.
> functions can be used as global transformation functions.  Do you envision
> this global transform capability supplanting the individual pltr parameter
> in the functions that currently support it?
>
> Thanks,
> Dave
>

Dave,

I'm glad others think that this is an interesting addition.  I certainly agree!

The global transform is applied after the "pltr"-type transforms,
While the signatures are the same, I'm not sure that pltr[0-2] could
be used with plstransform in a simple manner.  The intent of the
function is closer to that of the mapform parameter in plmap and
plmeridians where the transform is from unprojected world coordinates
-> projected world coordinates.  If I recall correctly, the pltr*
functions transform data-grid coordinates ((0, 0) to (nx -1, ny - 1))
to world coordinates so they may not work with plstransform exactly as
they are, at least not in all cases.  They do, however, still play an
important role.

Which leads to your question on supplanting per-function pltr
parameters.  I think these parameters could be replaced, but I see
some value to keeping them around, at least for some PLplot functions.
 For plmap and plmeridians, the mapform function parameter could be
completely replaced by plstransform as the mapform function performs a
(longitude, latitude) -> plplot world coordinate transformation.  The
replacement is not as simple for plshades, plcont, plimagefr and
similar functions.  In some cases, you may still want to map the data
grid values to specific coordinates and then project those coordinates
in a particular way.  A meteorological example might be mapping
satellite-based precipitation observations to (longitude, latitude)
with a pltr function and then transforming (longitude, latitude) to a
particular map projection.  These projections could be combined in to
one step, but splitting them up allows for a slightly more modular
design.  Replace (longitude, latitude) with (RA, Dec), "precipitation"
with "M51" and "map" with "sky" for a contrived astronomical example
:-)

Hez

On 2010-04-12 09:04-0700 David MacMahon wrote:

> Sounds (and looks!) interesting, Hez!

I have to agree.  I urge everyone here to look at Hez's attachment to
get a feel for the possibilities allowed by this powerful new feature.

This brings up an important question we should discuss. Is it time to
completely update both plmap functionality and example 19?

Currently plmap gives us access to just 4 map outlines which are stored in
data/cglobe.map data/globe.map data/usa.map data/usaglobe.map. From the
"file" command those files are stored in a binary format that appears to be
"Atari 68xxx CPX file (version 03e8)" format (whatever that is).  As far as
I know, no software project other than PLplot stores their map data that
way, and obviously users contemplating using PLplot for their mapping needs
require access to more than just four maps!

Fortunately, there appears to be substantial effort underway to provide
open-source GIS (geographical information system) software. See
http://opensourcegis.org/ for a list of 247 (!) projects.  These projects
obviously require map data to work with, and it appears there is a lot of it
that is free (see http://data.geocomm.com/).

I think it is time that we take advantage of that free map data rather than
limiting ourselves to just the four map data files that are currently
accessible from PLplot. Ideally the availability of free GIS data (along
with changes to plmap to allow access to those data) should allow us to
replace example 19 to provide examples of some really high-quality maps that
are built directly from free GIS data by PLplot.  For example, it would be
nice to provide topographic maps of my two favorite volcanos, Olympus Mons
and Valles Caldera.  (The first is the largest volcano in the solar system,
and the second is a personal favorite of mine because I toured it as a boy,
and it is near the locale of one of my favorite Westerns by Louis L'Amour).
But we don't have to stop with contour maps of volcanos. Please use your
imaginations to think of additional attractive maps that we could generate
as part of a replacement example 19 if/when we gain access to free GIS data.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On Apr 12, 2010, at 9:33 , Hezekiah M. Carty wrote:

> The global transform is applied after the "pltr"-type transforms,
> While the signatures are the same, I'm not sure that pltr[0-2] could
> be used with plstransform in a simple manner.  The intent of the
> function is closer to that of the mapform parameter in plmap and
> plmeridians where the transform is from unprojected world coordinates
> -> projected world coordinates.  If I recall correctly, the pltr*
> functions transform data-grid coordinates ((0, 0) to (nx -1, ny - 1))
> to world coordinates so they may not work with plstransform exactly as
> they are, at least not in all cases.  They do, however, still play an
> important role.

Thanks for that clarification.  This leads to my next question! :-)

Are the world coordinates given to plenv etc the projected (i.e.  
transformed) world coordinates?

If one has setup a transformation like the example you included in  
you original message, would a "plline" call to plot a line between  
points of equal latitude but different longitudes still draw a  
straight line while a "plpath" call to do the same would draw an arc  
according to the established transformation?

Maybe this will all be obvious once I actually read the docs and look  
at the example code!

Thanks again,
Dave

On Apr 12, 2010, at 12:16 , Alan W. Irwin wrote:

> I think it is time that we take advantage of that free map data  
> rather than
> limiting ourselves to just the four map data files that are currently
> accessible from PLplot. Ideally the availability of free GIS data  
> (along
> with changes to plmap to allow access to those data) should allow  
> us to
> replace example 19 to provide examples of some really high-quality  
> maps that
> are built directly from free GIS data by PLplot.

I think this is a great idea!  My only caution would be to watch out  
for including too much GIS-specific functionality within PLplot.   
IMHO, it would be preferable to use external (and externally  
maintained!) libraries if/when possible.

Dave

On Mon, Apr 12, 2010 at 4:38 PM, David MacMahon
<davidm@...> wrote:
>
> On Apr 12, 2010, at 9:33 , Hezekiah M. Carty wrote:
>
>> The global transform is applied after the "pltr"-type transforms,
>> While the signatures are the same, I'm not sure that pltr[0-2] could
>> be used with plstransform in a simple manner.  The intent of the
>> function is closer to that of the mapform parameter in plmap and
>> plmeridians where the transform is from unprojected world coordinates
>> -> projected world coordinates.  If I recall correctly, the pltr*
>> functions transform data-grid coordinates ((0, 0) to (nx -1, ny - 1))
>> to world coordinates so they may not work with plstransform exactly as
>> they are, at least not in all cases.  They do, however, still play an
>> important role.
>
> Thanks for that clarification.  This leads to my next question! :-)
>
> Are the world coordinates given to plenv etc the projected (i.e.
> transformed) world coordinates?
>

plenv etc. are not currently affected by the transformed coordinates,
so in its current state you must set the window extents in a manner
appropriate to the transform being used.  Axis tick marks and labels
are not handled in a special way either.

> If one has setup a transformation like the example you included in you
> original message, would a "plline" call to plot a line between points of
> equal latitude but different longitudes still draw a straight line while a
> "plpath" call to do the same would draw an arc according to the established
> transformation?
>

Yes, that is correct.  Internally, plpath calls pljoin if no transform
is defined.  If a transform is defined then it calls plline with n
segments approximating the transformed curve.

Hez

On 2010-04-12 13:51-0700 David MacMahon wrote:

>
> On Apr 12, 2010, at 12:16 , Alan W. Irwin wrote:
>
>> I think it is time that we take advantage of that free map data rather than
>> limiting ourselves to just the four map data files that are currently
>> accessible from PLplot. Ideally the availability of free GIS data (along
>> with changes to plmap to allow access to those data) should allow us to
>> replace example 19 to provide examples of some really high-quality maps 
>> that
>> are built directly from free GIS data by PLplot.
>
> I think this is a great idea!  My only caution would be to watch out for 
> including too much GIS-specific functionality within PLplot.  IMHO, it would 
> be preferable to use external (and externally maintained!) libraries if/when 
> possible.

Agreed.  If somebody here decides to take this on, they should think very
carefully about the goal here and also discuss that goal on list. To get
some discussion going about what that goal should be, my own feeling, is we
don't want to expand the PLplot API to the point where it is attempting to
compete with the comprehensive GIS open source projects such as GRASS.
Instead, I believe we just want some simple functionality that lets our
users input 2-dimensional (e.g., outline maps like we have now only a lot
more of them) or 3-dimensional (e.g., height versus position) GIS data and
then lets our users play with that data in any way they like (say with
plgrid) before plotting it with the remainder of the PLplot API.

Assuming we agree on that simple goal, then all we need is some library to
give us simple access to 2D and 3D GIS data. I just did a cursory search,
and it appears there are at least two open-source libraries called OGDI and
GDAL which allow access to GIS data. There may be more.

Anyhow, I hope I have given the rest of you some food for thought here about
mapping possibilities with PLplot and GIS data.  Furthermore, I hope we get
a good discussion going about exactly what people would like to see in
example 19 which might help focus further discussion of exactly what the
PLplot mapping API goals should be.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hezekiah M. Carty wrote:
> PLplot developers and interested users,
> 
> With PLplot trunk rev. 10905, I have committed basic support for
> universal 2D coordinate transformations in PLplot using a new
> function, plstransform.  The commit includes an additional page in
> example 19 to illustrate how this function works.  A path
> approximation function plpath has also been included which can be used
> to draw an approximation of a straight line in transformed
> coordinates.  An update to the API docbook documentation for these two
> functions is included.
> 
> "Universal," in this case, refers to the fact that _all_ PLplot
> plotting functions which act within the plot window should be affected
> by the defined transform.  If no transform function is defined then
> all PLplot functions should act as they did before this commit.  I
> have attached an example plot which takes advantage of this function
> both as an example of what this helps facilitate and to show that our
> modern output devices (pngcairo in this case) produce some very nice
> looking output!  The example shows plmap, plmeridians, plimagefr and
> plcont all working with the same transformed coordinate system.
> 
> I have been using this patch for several months now without trouble or
> regressions that I have seen.  This patch does, however, touch a large
> number of core functions so I would like to request that other
> developers keep an eye out for possible regressions.
> 
> The C and OCaml languages have been updated in this commit.

Don't forget to update README.release :).

-Hazen

On Wed, Apr 14, 2010 at 11:43 PM, Hazen Babcock <hbabcock@...> wrote:
> Hezekiah M. Carty wrote:
>>
>> PLplot developers and interested users,
>>
>> With PLplot trunk rev. 10905, I have committed basic support for
>> universal 2D coordinate transformations in PLplot using a new
>> function, plstransform.  The commit includes an additional page in
>> example 19 to illustrate how this function works.  A path
>> approximation function plpath has also been included which can be used
>> to draw an approximation of a straight line in transformed
>> coordinates.  An update to the API docbook documentation for these two
>> functions is included.
>>
>
> Don't forget to update README.release :).
>

Thanks for the reminder Hazen!  Done, with revision I-don't-remember-which.

Hez