From: Andrew R. <and...@us...> - 2012-10-24 19:09:50
|
On Wed, Oct 24, 2012 at 10:26:48AM -0700, Alan Irwin wrote: > Hi Andrew and Phil: > > On 2012-10-24 09:36+0100 Andrew Ross wrote: > > > On Tue, Oct 23, 2012 at 06:11:51AM -0700, phil rosenberg wrote: > > >> 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? > > The SourceForge websites (including plplot.sf.net) are now back up so > I was able to answer that question. See > http://plplot.sourceforge.net/examples-data/demo19/x19.01.png which > does show the correct Antarctica boundary (right lower part near the > edge of the map) for the code for the last release. So _apparently_ > some change you did does compromise how the old maps without shapelibs > are rendered when HAVE_SHAPELIB is not #defined. On the other hand, > my impression has been the old code has always had difficulty > rendering the old maps in a consistent way. If you have been > following the Wine thread, I had a case where that old code (before > your changes were incorporated) rendered one of the pages of example > 19 completely badly with what looks like bits and pieces of other maps > rendered on half of the map and the rest of it blank. I just now > double checked the Wine run again for that case. (This time done with > the new code, but with HAVE_SHAPELIB not #defined at the C level > because I haven't built shapelib for Wine yet.) That previous bad page > is now rendered fine although the Antarctica boundary problem still > occurs on the first page just like it does on Linux with HAVE_SHAPELIB > not #defined. So from this result it looks like the new code is at > least not making huge errors in rendering like happened for the old > code from time to time. And I think the chances are that we will be > removing support for the old map formats in any case (see below). So I > am not too concerned about the Antartica boundary problem for the old > map format case. > > >> ? > >> As for your questions Alan. > >> ? > >> I don't have a preference about depreciation period. > >> ? > > > > This really boils down to whether we want to force a shapelib > > dependency. If we do, then I think we could deprecate the old maps now > > and maybe remove in the next but one release, so users of releases > > have at least some warning. Otherwise we seem to be committed to > > supporting the old version indeterminately to avoid the dependency, > > which is probably not wise. > > I believe the shapelib dependency for plmap (alone!) is not a big issue since the vast > majority of PLplot users don't use plmap in any case. Furthermore, > the minority that do attempt to use that functionality in a serious > way are probably already fairly familiar with mapping software. So the > chances are they already know about shapelib and have it installed on > their system. Or at least they won't feel that is an onerous > requirement especially if installing shapelib gives them access to a > blowaway example. > > As to the blowaway shapefile example, it appears like both of you have > a couple of possibilities in mind. So please go for it! > > If everybody is satisfied that forcing shapelib dependency for plmap > is only a matter of time, then what remains is the decision about > when/how to force that dependency. In this case, I think we should > deprecate now in a realistic way. That is plmap becomes a no-op if > HAVE_SHAPELIB not #defined unless the user specifically opts in (with > a specific CMake option) to using the code that accesses and uses the > old format files. We can decide later when to remove that option and > pull the plug on the old data formats and the code that supports that > old format depending on user feedback to the opt-in CMake option. For > example, if we get no reaction at all (which I think is fairly likely) > to this deprecation period which requires opt-in for the old formats, > then I think we can safely pull the plug on those old formats for the > release after this one. Alan, That sounds like a fine plan. Want me to put the code in place to do this? We should also update README.release to include this change. Andrew |