On 2012-10-02 22:24-0400 Hezekiah M. Carty wrote: > I've used PLplot to plot a lot of data on maps, including mixing data > from shapefiles and other sources. Based on my experience I think we > may be going off in the wrong direction here.
Hi Hez: In order to be sure we understand the rest of your comments, could you explain in more detail how you made map data accessible to PLplot so you could decorate existing maps like you described above? I assume your applications used the API of libraries like shapelib, MDAH, and OGR to import the map data you desired and then you called on the libplplot routines to manipulate those data further, but that assumption needs confirmation. If you do confirm that was the approach you took, my vision is quite similar except my idea was it would be an added convenience for many map/PLplot users to provide a PLplot API that imports map data so their applications can manipulate those data with further PLplot commands. Of course, if some users didn't like that PLplot map importing API, they would be free to import map data into their applications in any other way they like, but our job would be to make that PLplot map importing API reasonably attractive and useful for a large majority of users' map importing needs without making that API too complicated. If you respond you cannot simplify the shapelib, MDAH, and OGR API's any more than they are now for PLplot's _limited_ needs, then obviously it makes little sense for PLplot to provide duplicates of those map importing API's when the user can just call those libraries directly from his application. However, private map importing functionality _is_ needed behind the scenes for plmap (as used in example 19), and I think we should support that "hidden" approach (where the map data is simply plotted and not exposed to the calling routine) as well as the "exposed" approach (which does expose the map data to the calling routine) as outlined above. As we all know, the map importing that plmap does behind the scene currently uses an obscure map file format with very few maps associated with it, but I think we should expand that map importation capability along the lines I described above for the "exposed" approach. Would a good compromise be to work exclusively on improving the map import capability behind plmap for now? If it turns out we like how we simplify the shapelib, MDAH, and OGR API's in that private case for plmap's limited map import needs, then we can turn that into a general public API suitable for the "exposed" case described above. But if the improved map importing functionality we develop for plmap is not going to be added value for users (say, because it just duplicates shapelib, MDAH, and OGR API's) then we should keep it private for the exclusive use of plmap. I certainly agree with you that we need examples of the "exposed" case (whether implemented with direct calls to shapelib, MDAH, or OGR or via some PLplot map import API if that turns out we develop that). I haven't thought too much about your call for improvements in PLplot's functions to deal with additional general plotting needs that would be useful for the "exposed" map case, but I assume those ideas are well taken as well. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
