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. Andrew On Sat, Oct 13, 2012 at 03:20:03PM -0700, phil rosenberg wrote: > Hi All again > version 2 now attached. I think I have taken account of all Andrew's > comments. I've also generated the shapefile equivalents of the current maps - > also attached. These need to go in the data folder. I guess the Install > project will need modifying too to copy these accross. As I'm not very good > with CMake could anyone else volunteer to make these mods? > ? > As far as depreciation is concerned I think I've got any more to say on the > subject of in-house formats, but to depreciate the current maps is a simple > case of going through the #ifdefs and removing the apropriate sections. > ? > Any further comments welcome > ? > 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: Friday, 12 October 2012, 7:20 > Subject: Re: [Plplot-devel] map resolution > > On 2012-10-11 22:59+0100 Andrew Ross wrote: > > [Phil said] > >> My fallback strategy will be to create a globe.shp, etc based on the > >> contents of globe.map I was just waiting for the code to be tested before > >> I did it. I think this is the "method of least surprise." If a user > >> selects to use shapefiles then they should use shapefiles easch time. > > > > I don't feel too strongly about this (perhaps others do?) > > I haven't had a chance to look at or try Phil's patch so I am not > quite sure what it does at this moment in regard to the the current > map files in the old format.? But from what he said, replacements for > the old formatted files in shapefile format are in the works. So I > think that leaves us three obvious choices with regard to how we deal > with the old map files and the software for reading that old format. > > (1) Preserve the ability to read the present map files in their > present old format indefinitely. > > (2) Same as (1) except just for the time being. This choice would give > us the chance to officially deprecate those old formats now (in the > release announcement for the forthcoming release) and wait to > eliminate those old formats (both data and code to read it) one > release cycle further down the road when shapelib would become an > official prerequisite for anyone wanting to decorate or transform maps > with PLplot. > > (3) Drop the official deprecation period and simply announce in the > release announcement for the forthcoming release that shapelib is an > immediate prerequisite for anyone wanting to decorate or transform > maps with PLplot. That choice means the old format maps and old format > reading code could be eliminated now rather than later. > > My only strong feeling is I don't like (1) at all, but I don't have > strong feelings one way or the other about which of the other two > choices we take.? However, I lean toward (3) because my impression is > the old format is so dated and obscure that it is just not taken > seriously by anyone who wants to decorate or transform maps with > PLplot. > > In sum, the basic point I would like to make is we should be clear > about our choice between the 3 possibilities above so that Phil knows > whether to plan to (1) never drop the old formatted files and the > associated software for reading them, (2) drop those old files and old > software soon, or (3) drop those old files and old software immediately. > > 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 ------------------------------------------------------------------------------ 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
