Thanks Alan
I hadn't noticed the missing Antarctica boundary section, I'm not sure why it
should be missing, in one but not the other, but if I'm honest I'm not going to
lose too much sleep if you intend to depreciate the old files anyway. Was it
missing pre patch?
Andrew, re the bug, I can't remember if I encountered the bug using a different
test shapefile. I think the old logic was if
abs((int)longitude_change)>abs((int)latitude) (where _change is from one point
to the next)then initiate wraparound fixing. Some comments indicated the intent
was that near the poles points were more likely to span large longitude
differences. Near the equator however the system broke down such that
relatively small longitude changes were still bigger than the current latitude.
By (int)ing the values longitude changes less than 1 were rounded to zero
avoiding problems for the current files within 1 degree of the equator (by
design?). In the test shapefile I used, the straight African boundaries must
have had point-to-point differences larger than 1 degree so it all broke down.
The current system is as general as I could make it. It might fall over if
someone tries to draw a line >180 degrees, point-to-point, but I don't think
there is an obvious fix there.
As for your questions Alan.
I don't have a preference about depreciation period.
I guess the four maps were used to show the different maps that came with
PLplot, can't think of another reason.
As for a blowaway example - the biggest advantage of using shapefiles is the
access to a huge array of datasets in this format, many of which are much
higher res than the old maps. So I think the 'hook' is either an example where
the user can specify their own shapefile, or an example where we use a much
higher res shapefile that we provide. For the latter case we could deliberately
contrast the old coarse maps with a new higher res one - in which case the
subject would need to be a coasline otherwise it wouldn't be on the old maps at
all. For any Hitchhikers Guide fans out there Norway has a prize winning coast
if memory serves correct.
Phil
________________________________
From: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
To: Andrew Ross <andrewr...@users.sourceforge.net>
Cc: phil rosenberg <philip_rosenb...@yahoo.com>;
"plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net>
Sent: Monday, 22 October 2012, 22:13
Subject: Re: [Plplot-devel] map resolution
On 2012-10-22 20:37+0100 Andrew Ross wrote:
>
> Phil,
>
> This all seems to work fine to me. I can't reproduce your bug with the old
> code, but I suspect I'm not using the right lat / lon and / or map file.
> The examples all work fine with your new code though.
>
> I've committed the changes to allow wider testing. The new data files are
> larger (~5 times) but are higher quality. Still not excessive to
> distribute.
It all works fine here (Debian wheezy
platform) both with
-DHAVE_SHAPELIB=OFF and (the
default) -DHAVE_SHAPELIB=ON. Thanks,
Phil for getting this idea to work so well in C code, and thanks
Andrew for implementing the CMake support for this idea.
When visually comparing the two cases it appears the code run with
-DHAVE_SHAPELIB=ON (and presumably the shapelib form of the map files)
produces slightly better looking results. For example, some of the
Antarctica boundary is missing from the first page of example 19 when
-DHAVE_SHAPELIB=OFF. But other than some minor improvements like that
for the -DHAVE_SHAPELIB=ON case, the results are indistinguishable.
Assuming others here also report good results I have
three further questions:
* Should we drop the non-shapefile map files and associated code
during this current release cycle? I lean toward that solution since
I suspect the non-shapefile map files and associated code were never
used for anything
serious. I would be perfectly willing to go along
with the alternative of having an official deprecation period until
at least the next release cycle before we remove the non-shapefile
maps and associated code, but such an official deprecation period
may be overkill.
* Why do we need four shapefile map files for the current example 19?
Couldn't we just adopt the (world) shapefile map file that is used
for the first page of example 19 and range-limit and transform it as
appropriate for the remaining pages of the example? Or am I missing
something important? (This question has been motivated by my
experience viewing a BC shapefile map that could be zoomed to show a
lot of fine detail for the Victoria BC area where I live).
* The current example 19 demonstrates only a minor advantage (improved
Antarctica boundary and a few
other slight rendering improvements)
for the shapelib approach. Can we add a fifth page (only for the
case when HAVE_SHAPELIB=ON) to example 19 that demonstrates a really
beautiful shapelib map that knocks the socks off of users? In fact,
I would suggest it was time to change all pages of example 19 to
knock the socks off of users for the HAVE_SHAPELIB=ON case.
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
__________________________
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
