From: Hezekiah M. C. <hez...@us...> - 2010-04-12 06:04:47
Attachments:
test2.png
|
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 |
From: David M. <da...@as...> - 2010-04-12 16:04:35
|
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® 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Hezekiah M. C. <hez...@us...> - 2010-04-12 16:33:55
|
On Mon, Apr 12, 2010 at 12:04 PM, David MacMahon <da...@as...> 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 |
From: Alan W. I. <ir...@be...> - 2010-04-12 19:16:48
|
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 __________________________ |
From: David M. <da...@as...> - 2010-04-12 20:38:49
|
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 |
From: Hezekiah M. C. <hez...@us...> - 2010-04-13 02:31:43
|
On Mon, Apr 12, 2010 at 4:38 PM, David MacMahon <da...@as...> 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 |
From: David M. <da...@as...> - 2010-04-12 20:52:02
|
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 |
From: Alan W. I. <ir...@be...> - 2010-04-13 03:50:51
|
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 __________________________ |
From: Hazen B. <hba...@ma...> - 2010-04-15 03:43:29
|
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 |
From: Hezekiah M. C. <hez...@us...> - 2010-04-17 02:15:00
|
On Wed, Apr 14, 2010 at 11:43 PM, Hazen Babcock <hba...@ma...> 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 |