On Wed, Oct 03, 2012 at 02:48:11AM -0700, Alan Irwin wrote: > 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, Certainly my take on this was that I was envisaging only using this support for behind the scenes improvements to plmap, not reproducing a general interface to shapelib / ogr / gdal etc. There is no point reproducing the wheel, particularly where things like shapelib have a pretty simple API anyway. I agree with Hez that all of this could be achieved already by the end user with the existing API (helped by a new plpolygons function). However, given we have plmap already and it adds some functionality in terms coordinate transformations I think we should limit ourselves to better supporting different map formats for plmap, at least for now. Being able to simple draw some stock map as a background for the real figure is useful (see Phil's examples) for scientific plotting. This is quite different though to producing high quality maps which is a job for a GIS and not plplot. I think this is what you were suggsting anyway isn't it? The idea of using raster maps as a background for a plot is interesting. I don't see why we couldn't implement an example of this using the current plimagefr function anyway. This could be a very pretty example of the kind of thing one can achieve with plplot. Just needs a copyright free raster map as the backdrop. Andrew ------------------------------------------------------------------------------ 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
