On 2010-12-22 11:00+0100 José Luis García Pallero wrote: > Hello, > I think that PLPlot is a great tool. Thanks to the developers for > their hard work. I'm using PLPlot in order to draw worldmaps with > coastlines. I'm using plfill, plline and plmap functions and I find > they very useful. Nevertheless I have some minor problems (I'm using > PLPlot 5.9.7 compiled by me on a Debian GNU/Linux Sid). > > Using plfill I obtain a the message > > *** PLPLOT WARNING *** > plfill: too many points in polygon > > using polygons with 1000 vertices. Can I change the maximum number of > vertices at runtime or must I recompile the library? > > I'm using the coastlines from > http://rimmer.ngdc.noaa.gov/mgg/coast/getcoast.html that are > downloaded in ascii files with NaN indicators between each piece of > land. I can see that plfill and plline needs that the x and y arrays > contains data without "holes" (separators) > > I think it would be useful that plfill and plline could work with > arrays containing some "labels", for example NaN values (0.0/0.0 in > C), in order to manage several independent polygons or lines as, for > example, coastlines downloaded from > http://rimmer.ngdc.noaa.gov/mgg/coast/getcoast.html > Maybe it would be interesting that plmap or other similar new function > could load a coastline file, not only the internal of PLPlot. This > files could fe in the ascii format as from > http://rimmer.ngdc.noaa.gov/mgg/coast/getcoast.html >
Hi José: You have brought up a number of interesting points. Arjen has already answered you in general terms on the PL_MAXPOLY question (currently set at a hard limit of 256 in include/plplotP.h). If you grep through our code for that symbol, you will notice a number of fixed arrays that are dimensioned with that value. I would welcome a patch to replace all of those with malloced (and freed) memory so we could do away with the PL_MAXPOLY limit completely. Currently, PLplot has rather limited NaN awareness associated with the plgriddata functionality (which in turn relies on the csiro libraries in lib/nn and lib/csa). I would welcome a patch to extend NaN awareness to plline and plfill (and plgradient). With regard to map data, I would like to repeat what I said last April to the plplot-devel list. <quote> 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. </quote> One thing I failed to mention explicitly back then is we should use a free and open-source library to access map data using one API rather than trying to figure out for ourselves the large number of different map file formats. No action has been taken yet on any of those ideas, but obviously there is scope for a very large improvement of mapping support for PLplot so discussion, ideas, and patches would be most welcome. 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 __________________________ ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Plplot-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-general
