On 2017-09-28 21:31+0100 Phil Rosenberg wrote:
Hi Mark and anyone else who is listening
I have just fixed the map plots. Apologies that this has taken
sooooooo long. The changes have just been pushed to the development
version and have been checked on my windows machine. Note that you
were correct also about there being an issue with using plmapfill. It
turned out that the type specified in the shapefile was overriding the
render type specified by the user.
While I was there I realised there was a problem with rendering
polygons that wrap round the whole globe such as Antarctica so that
should now be fixed too.
@Mark:
Thanks for spotting these issues that Phil just fixed.
For your information, the git master branch version (what Phil just
pushed) includes an earlier change by me where all the deprecated
plmap cruft was removed.
@Phil:
After fixing up some minor style and trailing space issues (commit
e60fba8 which I just pushed), I tested your changes in the build tree
and for the shared libraries case on Linux using the -DBUILD_TEST=ON
option. My build of the test_noninteractive target (which build
PLplot libraries, bindings, devices, and examples and which executes
each of our file devices for each of our C examples as well as
comparing -dev psc results for all our supported languages) continues
to work well. That is, there are no obvious configure, build, or
run-time issue, and no regressions on the remaining (OCaml) PostScript
differences with C example results. I also ran
examples/c/x19c -dev xcairo
, and there are no obvious rendering issues in those results (and
presumably also for all other devices/languages). I also
built the "validate" target (which tests your DocBook documentation
changes for any validation errors) without issues.
In sum, your current set of changes looks fine to me, and thanks for
this effort!
For those who may now how plfill works a bit better than me, something
that is supported by shapefiles, but currently not by plmap, is holes.
A polygon in a shapefile consists of multiple parts and clockwise
parts are filled whereas anticlockwise parts are holes. Is this
something we can do relatively easily with plfill or is it not really
doable?
I don't think that such a major change to plfill would be a good idea.
For example, calls to plsurf3d (example 8) and plshades (example 16)
end up at the lowest level as many different calls to plfill where
presumably some end up as anti-clockwise fills and some end up
as clockwise fills in difficult-to-predict ways.
Therefore, would it be possible for you to honor this shapefile
convention by simply not calling plfill from inside the plmap*
routines whenever they run into an anticlockwise part and by
changing our DocBook documentation of those routines appropriately?
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
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
