From: Andrew R. <aro...@ya...> - 2012-09-13 11:22:48
|
At 03:53 AM 13/09/2012 -0700, you wrote: >Hi all >I was just wondering what the format of the plPlot map files is? The maps >included in plPlot are rather low resolution so wondered if it was >possible for me to download more detailed ones form somewhere? > >Phil It was the CIA World DataBank map format. Many years ago I did use higher res versions for something or other - they are out there if you look. http://www.evl.uic.edu/pape/data/WDB/ might be some from what I can see. -Andrew |
From: phil r. <phi...@ya...> - 2012-10-02 19:50:40
|
Hi Arjen Sorry, the phrase "static linkage" clearly has different meanings depending upon who uses it. When I refer to static linkage I don't mean creating .lib files rather than .dll files I mean linking against the static runtime libraries (/MT and /MTd compiler options or runtime library under project properties, C/C++, Code Generation. Sorry if I'm teaching my granny to suck eggs, but these options mean I can copy an exe file to any other windows PC and run it. Otherwise the PC needs the visual studio runtime installed. If I try to create a statically linked exe, but link to a dynamically linked library (using the definition above) then the linker generates loads of errors because it gets conflicts between the two runtime environments. In theory I should just need to add /MT or /MTd to the compiler flag as Alan mentioned earlier in the thread, but this didn't seem to work for some reason (it worked fine for setting unicode). Hence the patch. Phil Message: 4 Date: Tue, 02 Oct 2012 09:03:39 +0200 From: Arjen Markus <arj...@de...> Subject: Re: [Plplot-devel] Building examples on Windows To: "plp...@li..." <plp...@li...> Message-ID: <506...@de...> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Phil, Alan, just tested this on Windows, using MS VC/C++ 2008 and GCC (MinGW) with CMake 2.8.7: With the option BUILD_SHARED_LIBS=OFF, the build process results in static libraries (for PLplot, csirocsa and qsastime, the default libraries that are usually built on my system). The only dynamic libraries left are the runtime libraries that come from the compiler. So it is not necessary to apply Phil's patch anymore. (The problems may have been due to some bug/quirk in older CMake versions.) Regards, Arjen On 2012-10-01 09:50, Arjen Markus wrote: > Hi Alan, Phil, > > On Sat, 29 Sep 2012 16:53:17 -0700 (PDT) > "Alan W. Irwin" <ir...@be...> wrote: > >> I don't recall exactly what happened in this case, but >> probably I just >> silently left it to Arjen to deal with since he is in a >> good position >> to test your patch on the Windows platform. >> >> Arjen, if you haven't dealt with this already, would >> you be willing to take a look? >> > > I do not recall the follow-up either, but I should be able > to look into this. I will try to do that this week. > > Regards, > > Arjen > > > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. ------------------------------ Message: 5 Date: Tue, 02 Oct 2012 09:44:38 +0200 From: Davide Cesari <dc...@ar...> Subject: Re: [Plplot-devel] map resolution To: "Alan W. Irwin" <ir...@be...> Cc: PLplot development list <plp...@li...> Message-ID: <506...@ar...> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 01/10/2012 22:38, Alan W. Irwin wrote: >> On Mon, Oct 01, 2012 at 10:09:31AM +0200, Davide Cesari wrote: >>> [...]Hello to everybody, >>> please note that shapelib is part of the OSGEO4W installation, >>> >>> https://trac.osgeo.org/osgeo4w/ >>> >>> which is currently the official and supported way to install shapelib >>> (and to build it) on Windows; OSGEO4W comes with an interactive >>> installer which allows you to choose the desired packages, from lower >>> level libraries to full GIS applications, and the necessary dependencies >>> are automatically installed. And of course it includes also Gdal/Ogr, as >>> a more general approach to GIS formats. >>> FYI. another useful site with high resolution, free (with >>> limitations) >>> country boundaries data in shapefile format is this one: >>> http://www.gadm.org/ >>> >>> Best regards, Davide > > @ Davide: > > That combination of shapelib and GDAL/OGR of the OSGEO4W installation > might indeed be potentially useful to our Windows users. However, I > am a bit concerned about flexibility. For example, if PLplot Windows > users build PLplot with either MinGW or the proprietary Microsoft > compilers can they always link to the OSGEO4W versions of shapelib and > GDAL/OGR? Or are they forced to use just one type of Windows compiler? Just to share some experience, I am trying to port to Windows the Fortran interface to shapelib and gdal (fortrangis.berlios.de) and I succeeded with GNU compilers under mingw linking to the OSGEO4W install, despite the difficulties of sticking to an autoconf build system; I don't know how it would be with MS compilers. Anyway shapelib has no dependencies so I agree that an independent solution will be suitable as well. > > As I posted to this list previously shapelib is an extremely simple > build. So for that I would advocate using a CMake-based build system > to give maximum flexibility in compiler choices. The builds for > GDAL/OGR can be complex (see remarks at ... Davide ------------------------------ Message: 6 Date: Tue, 2 Oct 2012 12:23:46 -0700 (PDT) From: "Alan W. Irwin" <ir...@be...> Subject: [Plplot-devel] Using gcj-4.7-jdk on Debian wheezy fails with PLplot To: Andrew Ross <and...@us...>, PLplot development list <Plp...@li...> Message-ID: <alpine.DEB.2.02.1210021138510.2754@enira.zlyna.ubzr> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Debian wheezy has a huge number of different java choices so I thought I should briefly document the particular choices I made which lead to the error below. I installed the gcj-4.7-jdk package which seemed to suck in everything else that is needed via the large number of package dependencies for that package. However, CMake needs help finding the peculiar location of the headers and libraries that this package uses. So before running cmake in an initially empty build tree I had to set the following environment variables: export CMAKE_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/include export CMAKE_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gcj-4.7-13 After that, running cmake seemed to work fine to find all java components, and the java bindings were built without any obvious issues. However, when trying to compile the examples, I ran into the following peculiar error: software@raven> make x01j [ 0%] Built target plhershey-unicode-gen [ 0%] Built target plhershey-unicode.h_built [ 0%] Built target csirocsa [ 13%] Built target csironn [ 13%] Built target deltaT-gen [ 17%] Built target deltaT.h_built [ 17%] Built target tai-utc-gen [ 21%] Built target tai-utc.h_built [ 26%] Built target qsastime [ 78%] Built target plplotd [ 78%] Built target plplotjavac_wrap [ 95%] Built target plplot_core Scanning dependencies of target x01j [100%] Generating plplot/examples/x01.class gcj-4.7: error: utf8: No such file or directory and similarly for any of our other Java examples. @Andrew: I believe you have had success with Java on Debian unstable. What do you do that is different from what I did above? Can you also confirm the above issue on Debian unstable for the Java package selection (gcj-4.7-jdk) that I made? Is there something else I should install as well to get that to work? When I did a google search for the above error message there were only a few hits, but they appeared to be quite significant because they were associated with Debian package builds which also appear to be running into this same gcj error. Thanks in advance for any help you can give me with this error. 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 Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel End of Plplot-devel Digest, Vol 77, Issue 2 ******************************************* |
From: phil r. <phi...@ya...> - 2012-10-02 21:51:42
|
Hi All I just downloaded shapelib and it builds with no difficulties at all on Windows. It seems to be written in "pure" C so it is just a case of compiling and linking the files - no build system is necessary as such. In less than an hour I had built the library and written a 10 line chunk of code to read in in file. In this sense then it would be easy to make use of. However I still have some Windows pejudices. It's not at all clear to me how CMake could find out if I have shapelib or not automatically or even what the library is called (I just created shapelibsd.lib and shapelibs.lib s for static, d for debug). It's always worth remembering that not everyone is an expert and for a long time after starting using C++. I found compiling PLplot for the first time (some years ago) a challenge and the more complexity we add the more we might put off potential users (especially on Windows) There have been quite a few options thrown into the mix, so I thought I might sumarise things a bit to focus the thoughts. Here are as many options as I could come up with based on the discussions so far and my own random thoughts. Maybe it would be useful to discard any of these that people feel are terrible or add any others that people can think of. 1) We forget about this and leave users to deal with maps however they want. Probably not the best option otherwise we wouldn't be having this discussion 2) We leave the PLplot map file format alone but provide some extra maps at different resolutions. Better than now, with little work needed, but the integer format used in the files limits resolution. 3) Do either 1) or 2) but also provide an interface for loading a standard file format (presumably shapefiles via shapelib?). Also Better than now and useful for those who wish to use GIS data, but adds an extra dependancy. One possible hazard is that shapefiles can be up to 2 GB and I think the whole file must be read even if we want to plot over a limited lat/lon. 3) We update the PLplot file format (adding a full description to the docs) perhaps including some extra maps, but giving users the ability to generate their own maps if neeeded. This could be this simplest upgrade option. It will give us high resolution with limited work. We can taylor the format to our needs e.g. so that data is in blocks and only blocks in the xmin-xmax, ymin-ymax are read for increased speed. 4) Do 3), but also add an interface for a standard file format. I guess this is the ultimate solution. But most time intensive. 5) Do 3), but also add a utility to covert from a standard file format to the PLplot format. Similar to 4, but ensures that any performance advantages from 3 are enforced, but at the expense of an extra pre PLplot step. 6) We replace the PLplot format files currently used with a standardised file format. Lots of flexibility from the user side, but makes shapelib a requirement for PLplot. Also the hazard of 3 applies. What does anyone think? Phil ________________________________ From: "plp...@li..." <plp...@li...> To: plp...@li... Sent: Tuesday, 2 October 2012, 20:23 Subject: Plplot-devel Digest, Vol 77, Issue 2 Send Plplot-devel mailing list submissions to plp...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/plplot-devel or, via email, send a message with subject or body 'help' to plp...@li... You can reach the person managing the list at plp...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Plplot-devel digest..." Today's Topics: 1. Re: Fw: wxWidgets driver and line breaks (fwd) (Andrew Ross) 2. Re: map resolution (Alan W. Irwin) 3. Re: map resolution (Alan W. Irwin) 4. Re: Building examples on Windows (Arjen Markus) 5. Re: map resolution (Davide Cesari) 6. Using gcj-4.7-jdk on Debian wheezy fails with PLplot (Alan W. Irwin) ---------------------------------------------------------------------- Message: 1 Date: Mon, 1 Oct 2012 10:05:41 +0100 From: Andrew Ross <and...@us...> Subject: Re: [Plplot-devel] Fw: wxWidgets driver and line breaks (fwd) To: phil rosenberg <phi...@ya...>, "plp...@li..." <plp...@li...> Message-ID: <20121001090541.GC10587@gandalf.rivendell> Content-Type: text/plain; charset=us-ascii On Mon, Oct 01, 2012 at 09:51:38AM +0100, Andrew Ross wrote: > > Hi Phil, > > I don't have AGG currently so haven't tested that (I'll try later). > The basic backend (backend=0) is fine (see attached screenshot). The > problems are with the wxGraphicsContext backend (backend=1). Sorry backend=2 not backend=1. > > I'm using your v2 patch with the current svn. > > Regards > > Andrew > ------------------------------ Message: 2 Date: Mon, 1 Oct 2012 11:14:50 -0700 (PDT) From: "Alan W. Irwin" <ir...@be...> Subject: Re: [Plplot-devel] map resolution To: phil rosenberg <phi...@ya...> Cc: "plp...@li..." <plp...@li...> Message-ID: <alpine.DEB.2.02.1210010959210.2754@enira.zlyna.ubzr> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII On 2012-09-30 14:41-0700 phil rosenberg wrote: > Hi Alan > I was just considering that one negative brought up regarding supporting shapefiles was the addition of extra dependencies. I sometimes feel (probably wrongly) that if only a basic bit of functionality is needed then it's easier to have a basic bit of code that does exactly what I (we) need rather than add an extra dependency and API (and possibly build system) that goes overboard on features. Maybe this is a Windows hangup as a lot of open source code has build systems which are rather biased towards linux (even CMAKE setups can be guilty of this) so sometimes it can be a few days work to get a library built and more than once I've been totally unable to do it. This kind of thing is often quite daunting to people who haven't done it before. > > I'll have a look at shapelib anyway and see if compiles easily on Windows. Hi Phil: My impression is lots of Windows developers still think exactly like you do about dependencies because historically the handling of library dependences was done so poorly on that platform ("dependency hell" and all that). However, CMake is beginning to change those Windows developer attitudes because it makes software builds on Windows so simple with correct library dependencies implemented semi-automatically. The KitWare developers for CMake itself have a very large amount of build expertise on Windows, Mac OS X, and Linux platforms, and that expertise shines through in CMake itself. As a result huge numbers of developers have started using CMake for their software project's build system and a substantial fraction of those (perhaps even the majority from all the Windows-oriented traffic on the CMake mailing list) are Windows developers. So I don't think Windows (and Mac OS and Linux) developers could go wrong by implementing a CMake-based build system for any software they are interested in. Therefore, if you run into any trouble with that nmake-based build of shapelib, please contact me off list since I think I could help you straighten out any such build issues by implementing a proper CMake-based build system for shapelib. I estimate putting together such a build system for a simple software project like shapelib would only require a few hours of my time. Also, I have just now completed an upgrade from Debian squeeze (stable) to Debian wheezy (testing) so I have access to a shiny new Wine version of the Windows platform to check a CMake-based build system for shapelib on that platform. 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 __________________________ ------------------------------ Message: 3 Date: Mon, 1 Oct 2012 13:38:43 -0700 (PDT) From: "Alan W. Irwin" <ir...@be...> Subject: Re: [Plplot-devel] map resolution To: Andrew Ross <and...@us...> Cc: plp...@li... Message-ID: <alpine.DEB.2.02.1210011238470.2754@enira.zlyna.ubzr> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > On Mon, Oct 01, 2012 at 10:09:31AM +0200, Davide Cesari wrote: >> [...]Hello to everybody, >> please note that shapelib is part of the OSGEO4W installation, >> >> https://trac.osgeo.org/osgeo4w/ >> >> which is currently the official and supported way to install shapelib >> (and to build it) on Windows; OSGEO4W comes with an interactive >> installer which allows you to choose the desired packages, from lower >> level libraries to full GIS applications, and the necessary dependencies >> are automatically installed. And of course it includes also Gdal/Ogr, as >> a more general approach to GIS formats. >> FYI. another useful site with high resolution, free (with limitations) >> country boundaries data in shapefile format is this one: >> http://www.gadm.org/ >> >> Best regards, Davide @ Davide: That combination of shapelib and GDAL/OGR of the OSGEO4W installation might indeed be potentially useful to our Windows users. However, I am a bit concerned about flexibility. For example, if PLplot Windows users build PLplot with either MinGW or the proprietary Microsoft compilers can they always link to the OSGEO4W versions of shapelib and GDAL/OGR? Or are they forced to use just one type of Windows compiler? As I posted to this list previously shapelib is an extremely simple build. So for that I would advocate using a CMake-based build system to give maximum flexibility in compiler choices. The builds for GDAL/OGR can be complex (see remarks at http://trac.osgeo.org/gdal/wiki/BuildHints and links from that page). However, I imagine those build requirements are substantially simplified for our needs where we just want to read from (but not write to) a lot of differently formatted map files and translate those to some uniform internal format that PLplot can use to decorate the map and possibly transform its coordinates before outputting the combined result in the normal way with our bit-mapped (for the GDAL case) or vector (for the shapelib or OGR cases) devices. So it is possible CMake might be the best choice for our needs in the GDAL/OGR case as well. But we only should be concerned about that question much further down the road after the shapelib effort is completed since that project will give us all some much-needed experience with modernizing PLplot's interactions with maps. On 2012-10-01 09:41+0100 Andrew Ross wrote: > [...]On Linux both shapelib and gdal/ogr are > commonly packaged by the distributions. > [...]Does anyone know > about Mac OSX? @ Andrew: macports (see http://www.macports.org/ports.php) has packages for both shapelib and gdal. I assume the latter contains ogr just like it does on Linux. There is also a pointer to privately maintained gdal Mac OS X binaries at http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries. @ everyone here: In sum it appears to me that shapelib and GDAL/OGR binary libraries are available for all platforms. For the Windows case there may be "dependency hell" issues for those binary libraries that could be solved by the CMake approach. That should be a trivial effort for shapelib so I think that is worth doing. I probably will do that myself if Phil doesn't want to do that himself just for the CMake experience. On the other hand, more effort would be required in the GDAL/OGR case to implement a CMake-based build system so when that time comes (_after_ the shapelib effort is completed), we will have to weigh the advantages of the CMake approach (fewer "dependency hell" issues) compared to the effort required to implement a CMake-based build system for GDAL/OGR. 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 __________________________ ------------------------------ Message: 4 Date: Tue, 02 Oct 2012 09:03:39 +0200 From: Arjen Markus <arj...@de...> Subject: Re: [Plplot-devel] Building examples on Windows To: "plp...@li..." <plp...@li...> Message-ID: <506...@de...> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Phil, Alan, just tested this on Windows, using MS VC/C++ 2008 and GCC (MinGW) with CMake 2.8.7: With the option BUILD_SHARED_LIBS=OFF, the build process results in static libraries (for PLplot, csirocsa and qsastime, the default libraries that are usually built on my system). The only dynamic libraries left are the runtime libraries that come from the compiler. So it is not necessary to apply Phil's patch anymore. (The problems may have been due to some bug/quirk in older CMake versions.) Regards, Arjen On 2012-10-01 09:50, Arjen Markus wrote: > Hi Alan, Phil, > > On Sat, 29 Sep 2012 16:53:17 -0700 (PDT) > "Alan W. Irwin" <ir...@be...> wrote: > >> I don't recall exactly what happened in this case, but >> probably I just >> silently left it to Arjen to deal with since he is in a >> good position >> to test your patch on the Windows platform. >> >> Arjen, if you haven't dealt with this already, would >> you be willing to take a look? >> > > I do not recall the follow-up either, but I should be able > to look into this. I will try to do that this week. > > Regards, > > Arjen > > > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. ------------------------------ Message: 5 Date: Tue, 02 Oct 2012 09:44:38 +0200 From: Davide Cesari <dc...@ar...> Subject: Re: [Plplot-devel] map resolution To: "Alan W. Irwin" <ir...@be...> Cc: PLplot development list <plp...@li...> Message-ID: <506...@ar...> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 01/10/2012 22:38, Alan W. Irwin wrote: >> On Mon, Oct 01, 2012 at 10:09:31AM +0200, Davide Cesari wrote: >>> [...]Hello to everybody, >>> please note that shapelib is part of the OSGEO4W installation, >>> >>> https://trac.osgeo.org/osgeo4w/ >>> >>> which is currently the official and supported way to install shapelib >>> (and to build it) on Windows; OSGEO4W comes with an interactive >>> installer which allows you to choose the desired packages, from lower >>> level libraries to full GIS applications, and the necessary dependencies >>> are automatically installed. And of course it includes also Gdal/Ogr, as >>> a more general approach to GIS formats. >>> FYI. another useful site with high resolution, free (with >>> limitations) >>> country boundaries data in shapefile format is this one: >>> http://www.gadm.org/ >>> >>> Best regards, Davide > > @ Davide: > > That combination of shapelib and GDAL/OGR of the OSGEO4W installation > might indeed be potentially useful to our Windows users. However, I > am a bit concerned about flexibility. For example, if PLplot Windows > users build PLplot with either MinGW or the proprietary Microsoft > compilers can they always link to the OSGEO4W versions of shapelib and > GDAL/OGR? Or are they forced to use just one type of Windows compiler? Just to share some experience, I am trying to port to Windows the Fortran interface to shapelib and gdal (fortrangis.berlios.de) and I succeeded with GNU compilers under mingw linking to the OSGEO4W install, despite the difficulties of sticking to an autoconf build system; I don't know how it would be with MS compilers. Anyway shapelib has no dependencies so I agree that an independent solution will be suitable as well. > > As I posted to this list previously shapelib is an extremely simple > build. So for that I would advocate using a CMake-based build system > to give maximum flexibility in compiler choices. The builds for > GDAL/OGR can be complex (see remarks at ... Davide ------------------------------ Message: 6 Date: Tue, 2 Oct 2012 12:23:46 -0700 (PDT) From: "Alan W. Irwin" <ir...@be...> Subject: [Plplot-devel] Using gcj-4.7-jdk on Debian wheezy fails with PLplot To: Andrew Ross <and...@us...>, PLplot development list <Plp...@li...> Message-ID: <alpine.DEB.2.02.1210021138510.2754@enira.zlyna.ubzr> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Debian wheezy has a huge number of different java choices so I thought I should briefly document the particular choices I made which lead to the error below. I installed the gcj-4.7-jdk package which seemed to suck in everything else that is needed via the large number of package dependencies for that package. However, CMake needs help finding the peculiar location of the headers and libraries that this package uses. So before running cmake in an initially empty build tree I had to set the following environment variables: export CMAKE_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/include export CMAKE_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gcj-4.7-13 After that, running cmake seemed to work fine to find all java components, and the java bindings were built without any obvious issues. However, when trying to compile the examples, I ran into the following peculiar error: software@raven> make x01j [ 0%] Built target plhershey-unicode-gen [ 0%] Built target plhershey-unicode.h_built [ 0%] Built target csirocsa [ 13%] Built target csironn [ 13%] Built target deltaT-gen [ 17%] Built target deltaT.h_built [ 17%] Built target tai-utc-gen [ 21%] Built target tai-utc.h_built [ 26%] Built target qsastime [ 78%] Built target plplotd [ 78%] Built target plplotjavac_wrap [ 95%] Built target plplot_core Scanning dependencies of target x01j [100%] Generating plplot/examples/x01.class gcj-4.7: error: utf8: No such file or directory and similarly for any of our other Java examples. @Andrew: I believe you have had success with Java on Debian unstable. What do you do that is different from what I did above? Can you also confirm the above issue on Debian unstable for the Java package selection (gcj-4.7-jdk) that I made? Is there something else I should install as well to get that to work? When I did a google search for the above error message there were only a few hits, but they appeared to be quite significant because they were associated with Debian package builds which also appear to be running into this same gcj error. Thanks in advance for any help you can give me with this error. 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 Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel End of Plplot-devel Digest, Vol 77, Issue 2 ******************************************* |
From: Andrew R. <and...@us...> - 2012-10-03 13:19:25
|
On Tue, Oct 02, 2012 at 02:51:34PM -0700, phil rosenberg wrote: > Hi All > I just downloaded shapelib and it builds with no difficulties at all on Windows. It?seems to be?written in "pure" C so it is just a case of compiling and linking the files - no build system is necessary as such. In less than an hour I had built the library and written a 10 line chunk of code to read in in file. In this sense then it would be easy to make use of. > ? > However I still have some Windows pejudices. It's not at all clear to me how CMake could find out if I have shapelib or not automatically or even what the library is called (I just created shapelibsd.lib and shapelibs.lib s for static, d for debug). > ? > It's always worth remembering that not everyone is an expert and for a long time after starting using C++. I found compiling PLplot for the first time (some years ago)?a challenge and the more complexity we add the more we might put off?potential users (especially on Windows) > ? To demonstrate how easy it is I've added cmake support for shapelib to plplot. This is currently only tested on Linux, but should work on other platforms. You may need to set the SHAPELIB_INCLUDE_DIR and add to the library paths, but it should be relatively straightforward. At least this gives a template to work from. Debian installs the library as libshp.so so I would suggest sticking to a naming convention with shp as the the base library name. The cmake support will assume that, and will add on the appropriate prefixes / suffixes for each platform. Cheers Andrew |
From: Alan W. I. <ir...@be...> - 2012-10-02 23:41:51
|
Hi Phil: On 2012-10-02 14:51-0700 phil rosenberg wrote: > Hi All > I just downloaded shapelib and it builds with no difficulties at all on Windows. It seems to be written in "pure" C so it is just a case of compiling and linking the files - no build system is necessary as such. In less than an hour I had built the library and written a 10 line chunk of code to read in in file. In this sense then it would be easy to make use of. Excellent news. > However I still have some Windows pejudices. It's not at all clear to me how CMake could find out if I have shapelib or not automatically or even what the library is called (I just created shapelibsd.lib and shapelibs.lib s for static, d for debug). Creating a Find module to help find any library is pretty trivial under CMake. So it should not be a problem for me to add this capability to our build system (just like we have done for our core library for its _optional_ dependencies and also many other libraries that our specialized but optional devices need). > > It's always worth remembering that not everyone is an expert and for a long time after starting using C++. I found compiling PLplot for the first time (some years ago) a challenge and the more complexity we add the more we might put off potential users (especially on Windows) > > There have been quite a few options thrown into the mix, so I thought I might sumarise things a bit to focus the thoughts. Here are as many options as I could come up with based on the discussions so far and my own random thoughts. Maybe it would be useful to discard any of these that people feel are terrible or add any others that people can think of. > I will express my opinion with No or Yes on each of your options. BTW, you had two options labelled (3) so I have renumbered those and changed your references to what I think you meant in your text below. > 1) We forget about this and leave users to deal with maps however they want. > Probably not the best option otherwise we wouldn't be having this discussion No, because I think this discussion is going to lead to something useful. :-) > > 2) We leave the PLplot map file format alone but provide some extra maps at different resolutions. > Better than now, with little work needed, but the integer format used in the files limits resolution. Yes to continuing with the old PLplot map file format for now, but it should be strongly deprecated in favour of a better approach, meaning (in part) add no further extra maps and plan to completely delete a few release cycles down the road. > > 3) Do either 1) or 2) but also provide an interface for loading a standard file format (presumably shapefiles via shapelib?). > Also Better than now and useful for those who wish to use GIS data, but adds an extra dependancy. One possible hazard is that shapefiles can be up to 2 GB and I think the whole file must be read even if we want to plot over a limited lat/lon. Yes, please! It would probably be a good idea to include in the API the ability to limit the input map file to a user-supplied latitude and longitude range, but that is all I would do for now. So for large files there might be some noticable read time with this approach, but the result that is handled in PLplot after that will be reasonably small. In any case, I don't think you should be too concerned with large map efficiency issues. After all, presumbably there are plenty of small map files to deal with low resolution needs, and for high resolution needs the user has the choice to use some external tool to convert a large high-resolution map file into something smaller with more limited range or else use the internal PLplot range selection (see above). > > 4) We update the PLplot file format (adding a full description to the docs) perhaps including some extra maps, but giving users the ability to generate their own maps if neeeded. > This could be this simplest upgrade option. It will give us high resolution with limited work. We can taylor the format to our needs e.g. so that data is in blocks and only blocks in the xmin-xmax, ymin-ymax are read for increased speed. No to updating the PLplot map file format. I think we really should go with shapelib for now and add the hdal/ogr libraries later rather than doing anything with our own map file format. > > 5) Do 4), but also add an interface for a standard file format. > I guess this is the ultimate solution. But most time intensive. No, see my objection to (4) above. > > 6) Do 4), but also add a utility to covert from a standard file format to the PLplot format. > Similar to 5, but ensures that any performance advantages > from 4 are enforced, but at the expense of an extra pre PLplot step. > No, see my objection to (4) above. > 7) We replace the PLplot format files currently used with a standardised file format. > Lots of flexibility from the user side, but makes shapelib a requirement for PLplot. Also the hazard of 3 applies. Yes, eventually. But for now see my answer to (2) and (3). 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 __________________________ |
From: Maurice L. <mj...@br...> - 2012-10-03 01:39:10
|
On Tuesday, October 2, 2012 at 16:41:43 (-0700) Alan W. Irwin writes: > Hi Phil: > > On 2012-10-02 14:51-0700 phil rosenberg wrote: > [snip] > > 3) Do either 1) or 2) but also provide an interface for loading a standard file format (presumably shapefiles via shapelib?). > > Also Better than now and useful for those who wish to use GIS data, but adds an extra dependancy. One possible hazard is that shapefiles can be up to 2 GB and I think the whole file must be read even if we want to plot over a limited lat/lon. > > Yes, please! It would probably be a good idea to include in the API > the ability to limit the input map file to a user-supplied latitude > and longitude range, but that is all I would do for now. So for large > files there might be some noticable read time with this approach, but > the result that is handled in PLplot after that will be reasonably > small. > > In any case, I don't think you should be too concerned with large map > efficiency issues. After all, presumbably there are plenty of small > map files to deal with low resolution needs, and for high resolution > needs the user has the choice to use some external tool to convert a > large high-resolution map file into something smaller with more > limited range or else use the internal PLplot range selection (see > above). I agree with Alan's points. There may be other filters (I don't know) that could be used on the data as well. In addition, plan for the future -- ram is cheap. People wanting to manipulate a huge DB can have it all in ram if they really want. Earlier this year I bought 8G of DDR2 (4x2G) for only $100 from newegg. Wait a few years and 32G or even 64G will be attainable without paying "enterprise" prices. -- Maurice LeBrun |
From: Hezekiah M. C. <hez...@us...> - 2012-10-03 02:49:20
|
Sorry for the duplicate message - I didn't use the proper From address for the mailing list in my previous send. On Tue, Oct 2, 2012 at 7:41 PM, Alan W. Irwin <ir...@be...> w= rote: > Hi Phil: > > On 2012-10-02 14:51-0700 phil rosenberg wrote: > >> Hi All >> >> There have been quite a few options thrown into the mix, so I thought I = might sumarise things a bit to focus the thoughts. Here are as many options= as I could come up with based on the discussions so far and my own random = thoughts. Maybe it would be useful to discard any of these that people feel= are terrible or add any others that people can think of. >> > > I will express my opinion with No or Yes on each of your options. > BTW, you had two options labelled (3) so I have renumbered those > and changed your references to what I think you meant in your text > below. > I've used PLplot to plot a lot of data on maps, including mixing data from shapefiles and other sources. Based on my experience I think we may be going off in the wrong direction here. >> 1) We forget about this and leave users to deal with maps however they w= ant. >> Probably not the best option otherwise we wouldn't be having thi= s discussion > > No, because I think this discussion is going to lead to something > useful. :-) > I actually like this idea! With some embellishment, but I think it is closest to the right approach. PLplot is not a GIS platform and it probably should not strive to be. It would be nice, though, to have an easy and documented way to take advantage of PLplot for mapping/GIS purposes. With a few support functions I think we could provide a convenient interface for users without restricting PLplot to particular libraries or file formats. plline and plfill give us polygons. plstring gives us points. plstransform gives us global, consistent coordinate transformation support. So PLplot has the rendering components needed for basic mapping. A plpolygon function could be added to PLplot for convenience. plpolygon would render multiple closed, filled or unfilled polygons. This is useful for filled continents/oceans/lakes, geographic outlines and similar tasks which require multiple polygons to be rendered in the same way. Given those functions and an (external, untethered!) library such as shapelib to ingest data you have what you need to easily render a map. We could provide examples of how to do this with shapelib for geographic outlines, GDAL for some raster data plotted with plshades or plimage, and perhaps a few other libraries. I'm not convinced that going further than that provides a benefit. >> >> 2) We leave the PLplot map file format alone but provide some extra maps= at different resolutions. >> Better than now, with little work needed, but the integer format= used in the files limits resolution. > > Yes to continuing with the old PLplot map file format for now, but it > should be strongly deprecated in favour of a better approach, meaning (in= part) > add no further extra maps and plan to completely delete a few release > cycles down the road. > Along the lines of my extensions to (1) above, why not provide the existing map data in a more friendly and verbose format such as CSV? An example or core PLplot function could be added to load this simple data format along with the shapelib and other examples. This allows us to continue to have very simple geographic outlines working "out of the box". Some "good enough" low resolution data available without external dependencies is better than none. >> >> 3) Do either 1) or 2) but also provide an interface for loading a standa= rd file format (presumably shapefiles via shapelib?). >> Also Better than now and useful for those who wish to use GIS da= ta, but adds an extra dependancy. One possible hazard is that shapefiles ca= n be up to 2 GB and I think the whole file must be read even if we want to = plot over a limited lat/lon. > > Yes, please! It would probably be a good idea to include in the API > the ability to limit the input map file to a user-supplied latitude > and longitude range, but that is all I would do for now. So for large > files there might be some noticable read time with this approach, but > the result that is handled in PLplot after that will be reasonably > small. > > In any case, I don't think you should be too concerned with large map > efficiency issues. After all, presumbably there are plenty of small > map files to deal with low resolution needs, and for high resolution > needs the user has the choice to use some external tool to convert a > large high-resolution map file into something smaller with more > limited range or else use the internal PLplot range selection (see > above). > I think this is getting out of scope for PLplot. Providing examples illustrating how to mix various support libraries with PLplot is a better way to start. If the steps required to get from [insert external common data source here] to a format usable by PLplot are onerous then some convenience loading/conversion functions could be written, but the result may end up being as complex as using the upstream library directly. Hez |
From: Andrew R. <and...@us...> - 2012-10-10 20:39:09
|
Phil, Thanks for your patch. A great start. I've got a few comments. To get it to compile on Linux required a couple of changes: 1) Debian installs the include file shapefil.h in /usr/include not in a shapelib subdirectory. Changing the #include statement in plmap.c fixed this. Phil, where is yours installed? Is the subdirectory a standard thing, or something you created? Making use of the ${SHAPELIB_INCLUDE_DIR} variable should allow you to search in the correct place. 2) plplotd needs to be linked with the shp library. To achieve this I added the following code to src/CMakeLists.txt if(HAVE_SHAPELIB) set( libplplot${LIB_TAG}_LINK_LIBRARIES ${libplplot${LIB_TAG}_LINK_LIBRARIES} shp ) endif(HAVE_SHAPELIB) 3) The code generated the following gcc warning /home/andrew/software/plplot/plplot/src/plmap.c:48:1: warning: 'visibility' attribute ignored [-Wattributes] The problem here is the static attribute. This makes the scope of the variable local to this file, and hence visibility attributes don't make sense. I'm guessing this is not what you wanted. Looks like this bit of code was just copied from src/plctrl.c. The plplotLibDir variable there is only actually used by the tcl code to pass the tcl library directory. I would just remove all references to this here. Other comments: - Having made these changes the code compiled and example 19 ran. I tried this _before_ downloading any shapefiles. As it stands your patch doesn't fall back to using the old map code. I'd suggest a fallback would be sensible for compatibility. One might want to use shapefiles and old plplot maps (at least for now). At least it needs an error message if the file can't be found! - The function OpenShapeFile still contains mentions of plLibOpenPdfstr. - As a general coding principle I try to avoid using macros in the manner you have done with OpenMap and CloseMap. It's not wrong, it just leads to code that can be harder to read. It's generally better to include code in #ifdefs as then makes it explicit what functions are being called and under what circumstances. Macros can also confuse some debuggers. - As a further basic principle I'd try to ensure that the different code paths (shapelib and plplot format) are as similar as possible, and share code where appropriate. As an example, bufx and bufy are statically created for the old code path and allocated with malloc in the shapelib code path. Some of this code could be shared. - I've had a quick look at the transform code. Making multiple copies of the data seems like a slightly inefficient way of solving the problem. I wonder if there is a better algorithm for fixing the problem? I would suggest creating a simple example to illustrate the problem (maybe a new page for example 19). This way we would have a test case try out new algorithms. Once I downloaded the shapefiles following your pointer to www.naturalearthdata.com (great site by the way!) all worked fine so these comments are mostly stylistic in nature. Regards Andrew On Mon, Oct 08, 2012 at 03:27:25PM -0700, phil rosenberg wrote: > Well I've managed to find a little time between changing dirty nappies so please find attached my first cut at a patch for shapelib > support in plmap > I???ve made a few changes to plmap to do this: > ?? > First is the simple reading of the data from the shapefiles > rather than the original files. The .shp and .shx files are needed, none of the other shapefile files are used. ??The shapelib files can be placed and > referenced exactly like the old files, so either in a ???special place??? (data > folder, exe folder, etc) and referenced by filename or anywhere else referenced > by full path. Note that the extension can be omitted or included as per the > shapelib API. > ?? > Second is the transformation is now performed after the > wraparound fixing. This is because the transformation may be into metres or > some other such length unit if a map projection is used (I've just been working with data transformed onto a transverse mercator projection which does exactly this) making wraparound fixing impossible after the transformation has been applied. > ?? > Third is that wraparound fixing has been rewritten. This was > because the previous method broke near the equator, particularly in Africa > where there are a number of long straight political boundaries (so > point-to-point lon changes can be large and lat can be small). It may be of > interest that the new method means that if the user specifies lon on 0-360 > scale, but the map is -180-180 (or visa-versa) then the features still plot > correctly. > ?? > From the previous discussions I???m sure there will be a > number of avid testers. Example 19 uses plmap, but to run it??you will need to get a replacement > shapefile map for the globe and usaglobe original maps. For testing I grabbed > the 110 m resolution countries map from http://www.naturalearthdata.com/features/and made two copies of the .shp and .shx files, renaming them globe and > usaglobe. Putting these in the same location as the usual map files will give > you a functioning example 19. > ?? > If/when people are happy with the patch I'll generate shapefile equivalents of the current maps which will mean that existing code will produce identical output whether or not PLplot has been compiled with shapelib support. > ?? > The code currently plots polygons and ploylines only, and in both cases plots these as lines with no fill. I had wondered about adding the ability to plot polygons with a fill, but this requires a change or addition to the public API and I'm not sure how useful it would be - It would probably need some way to link different fill syles to different objects within a file and I think we already discussed that this is something it is best to let people code themselves rather than try to turn PLplot into GIS software. Although if people think that it would be useful to have a fill option it's relatively little effort to do - discus!!! > ?? > Let me know if the patch works for you. > ?? > Phil > > > > ________________________________ > From: Alan W. Irwin <ir...@be...> > To: phil rosenberg <phi...@ya...> > Cc: "plp...@li..." <plp...@li...>; Andrew Ross <and...@us...> > Sent: Friday, 5 October 2012, 21:38 > Subject: Re: [Plplot-devel] map resolution > > By the way, I looked for a shapefile viewer on Debian and found > thuban. I don't know whether that is the best shapefile viewer for > Linux, but it is based on libgda/ogr.?? When I tried thuban on overall > shapefile maps for British Columbian (obtained by following links at > http://downloads.cloudmade.com/) it appeared to work instantaneously > and well for the size (which totalled 200MB) of the 7 shapefile layers > making up the map of British Columbia that is provided by > http://downloads.cloudmade.com/.?? Furthermore, I was much impressed > with all the high-resolution local detail (e.g., coastlines, natural features, > political boundaries to name three of the most useful shapefile layers > available for the British Columbia map) that was available under the > thuban zoom mode.?? By the way, that zoom mode worked essentially > instantaneously as well. > > I assume shapelib will be as fast or faster than libgda/ogr so I think > we have a lot to look forward to concerning the speed with which > shapelib can deliver shapes behind the scenes to plmap for that > function to plot. > > And to anticipate a possible ( :-) ) further question from Phil, no I > don't think we should get into trying to let plmap deal with several > shapefile file layers at once. Instead it should be the users' > responsibility to specify, e.g., "british_columbia_coastline.shp" as a > filename to plmap if they want the B.C. coastlines on their plot, and > if a user wants another layer in their plot with natural features on > top of those coastlines, they can call plmap again with a different > filename for the same region, e.g., "british_columbia_natural.shp". > > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2012-10-24 17:27:11
|
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 __________________________ 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 __________________________ |
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 |
From: Arjen M. <arj...@de...> - 2012-10-03 07:59:29
|
Hi Phil, right, I misunderstood the problem. There are several ways to deal with these runtime libraries: - Put them along with the executables on the target machine. If they are in the same directory this usually works, but the manifest mechanism has made this slightly tricky. - Install the proper version of the runtime libraries - this is the recommended way for the MS Visual C/C++ compiler. It uses so-called side-by-side assemblies and the manifest mechanism. The main drawback: you have to make sure they are installed on all target machines. Not a big deal if you are allowed to install something, but I have had headaches trying to deal with systems where that was pertinently not allowed :(. - Incorporate the runtime libraries into the executables. This is the easiest solution in terms of deployment, but modern compilers are making this increasingly difficult and sometimes outright impossible to achieve. I know for instance that the static OpenMP library used by Intel is scheduled to be removed, leaving a dependency on the DLL. Similar things have happened long ago with the X11 libraries on Linux/UNIX. I will see if there compiler and linker options that help with the scenario you are after, but it may turn out to be impossible - /MT and /MTd may be the way towards that goal. (I just failed to produce a small program that depends on these runtime libraries so that is easy to investigate what options would help - sigh. Probably better then to try a PLplot example instead) Regards, Arjen On Tue, 2 Oct 2012 12:50:28 -0700 (PDT) phil rosenberg <phi...@ya...> wrote: > > > Hi Arjen > Sorry, the phrase "static linkage" clearly has different >meanings depending upon who uses it. > > When I refer to static linkage I don't mean creating >.lib files rather than .dll files I mean linking against >the static runtime libraries (/MT and /MTd compiler >options or runtime library under project properties, >C/C++, Code Generation. > > Sorry if I'm teaching my granny to suck eggs, but these >options mean I can copy an exe file to any other windows >PC and run it. Otherwise the PC needs the visual studio >runtime installed. If I try to create a statically linked >exe, but link to a dynamically linked library (using the >definition above) then the linker generates loads of >errors because it gets conflicts between the two runtime >environments. > > In theory I should just need to add /MT or /MTd to the >compiler flag as Alan mentioned earlier in the thread, >but this didn't seem to work for some reason (it worked >fine for setting unicode). Hence the patch. > > Phil > > Message: 4 > Date: Tue, 02 Oct 2012 09:03:39 +0200 >From: Arjen Markus <arj...@de...> > Subject: Re: [Plplot-devel] Building examples on Windows > To: "plp...@li..." > <plp...@li...> > Message-ID: <506...@de...> > Content-Type: text/plain; charset=ISO-8859-1; >format=flowed > > Hi Phil, Alan, > > just tested this on Windows, using MS VC/C++ 2008 and >GCC (MinGW) > with CMake 2.8.7: > > With the option BUILD_SHARED_LIBS=OFF, the build process >results > in static libraries (for PLplot, csirocsa and qsastime, >the default > libraries that are usually built on my system). > > The only dynamic libraries left are the runtime >libraries that > come from the compiler. > > So it is not necessary to apply Phil's patch anymore. >(The problems > may have been due to some bug/quirk in older CMake >versions.) > > Regards, > > Arjen > > On 2012-10-01 09:50, Arjen Markus wrote: >> Hi Alan, Phil, >> >> On Sat, 29 Sep 2012 16:53:17 -0700 (PDT) >> "Alan W. Irwin" <ir...@be...> wrote: >> >>> I don't recall exactly what happened in this case, but >>> probably I just >>> silently left it to Arjen to deal with since he is in a >>> good position >>> to test your patch on the Windows platform. >>> >>> Arjen, if you haven't dealt with this already, would >>> you be willing to take a look? >>> >> >> I do not recall the follow-up either, but I should be >>able >> to look into this. I will try to do that this week. >> >> Regards, >> >> Arjen >> >> >> >> DISCLAIMER: This message is intended exclusively for the >>addressee(s) and may contain confidential and privileged >>information. If you are not the intended recipient please >>notify the sender immediately and destroy this message. >>Unauthorized use, disclosure or copying of this message >>is strictly prohibited. >> The foundation 'Stichting Deltares', which has its seat >>at Delft, The Netherlands, Commercial Registration Number >>41146461, is not liable in any way whatsoever for >>consequences and/or damages resulting from the improper, >>incomplete and untimely dispatch, receipt and/or content >>of this e-mail. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Got visibility? >> Most devs has no idea what their production app looks >>like. >> Find out how fast your code is with AppDynamics Lite. >> http://ad.doubleclick.net/clk;262219671;13503038;y? >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> > > > > DISCLAIMER: This message is intended exclusively for the >addressee(s) and may contain confidential and privileged >information. If you are not the intended recipient please >notify the sender immediately and destroy this message. >Unauthorized use, disclosure or copying of this message >is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat >at Delft, The Netherlands, Commercial Registration Number >41146461, is not liable in any way whatsoever for >consequences and/or damages resulting from the improper, >incomplete and untimely dispatch, receipt and/or content >of this e-mail. > > > > > > > > ------------------------------ > > Message: 5 > Date: Tue, 02 Oct 2012 09:44:38 +0200 >From: Davide Cesari <dc...@ar...> > Subject: Re: [Plplot-devel] map resolution > To: "Alan W. Irwin" <ir...@be...> > Cc: PLplot development list ><plp...@li...> > Message-ID: <506...@ar...> > Content-Type: text/plain; charset=ISO-8859-1; >format=flowed > > On 01/10/2012 22:38, Alan W. Irwin wrote: >>> On Mon, Oct 01, 2012 at 10:09:31AM +0200, Davide Cesari >>>wrote: >>>> [...]Hello to everybody, >>>> please note that shapelib is part of the OSGEO4W >>>>installation, >>>> >>>> https://trac.osgeo.org/osgeo4w/ >>>> >>>> which is currently the official and supported way to >>>>install shapelib >>>> (and to build it) on Windows; OSGEO4W comes with an >>>>interactive >>>> installer which allows you to choose the desired >>>>packages, from lower >>>> level libraries to full GIS applications, and the >>>>necessary dependencies >>>> are automatically installed. And of course it includes >>>>also Gdal/Ogr, as >>>> a more general approach to GIS formats. >>>> FYI. another useful site with high resolution, free >>>>(with >>>> limitations) >>>> country boundaries data in shapefile format is this one: >>>> http://www.gadm.org/ >>>> >>>> Best regards, Davide >> >> @ Davide: >> >> That combination of shapelib and GDAL/OGR of the OSGEO4W >>installation >> might indeed be potentially useful to our Windows >>users. However, I >> am a bit concerned about flexibility. For example, if >>PLplot Windows >> users build PLplot with either MinGW or the proprietary >>Microsoft >> compilers can they always link to the OSGEO4W versions >>of shapelib and >> GDAL/OGR? Or are they forced to use just one type of >>Windows compiler? > > Just to share some experience, I am trying to port to >Windows the >Fortran interface to shapelib and gdal >(fortrangis.berlios.de) and I > succeeded with GNU compilers under mingw linking to the >OSGEO4W install, > despite the difficulties of sticking to an autoconf >build system; I > don't know how it would be with MS compilers. Anyway >shapelib has no > dependencies so I agree that an independent solution >will be suitable as > well. > >> >> As I posted to this list previously shapelib is an >>extremely simple >> build. So for that I would advocate using a CMake-based >>build system >> to give maximum flexibility in compiler choices. The >>builds for >> GDAL/OGR can be complex (see remarks at > ... > > Davide > > > > > > > > > > > > > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 2 Oct 2012 12:23:46 -0700 (PDT) >From: "Alan W. Irwin" <ir...@be...> > Subject: [Plplot-devel] Using gcj-4.7-jdk on Debian >wheezy fails with > PLplot > To: Andrew Ross <and...@us...>, >PLplot > development list ><Plp...@li...> > Message-ID: ><alpine.DEB.2.02.1210021138510.2754@enira.zlyna.ubzr> > Content-Type: TEXT/PLAIN; format=flowed; >charset=US-ASCII > > Debian wheezy has a huge number of different java >choices so I thought > I should briefly document the particular choices I made >which > lead to the error below. > > I installed the gcj-4.7-jdk package which seemed to suck >in everything > else that is needed via the large number of package >dependencies for > that package. However, CMake needs help finding the >peculiar location > of the headers and libraries that this package uses. So >before > running cmake in an initially empty build tree I had to >set the > following environment variables: > > export >CMAKE_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/include > export >CMAKE_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gcj-4.7-13 > > After that, running cmake seemed to work fine to find >all java > components, and the java bindings were built without any > obvious issues. However, when trying to compile the >examples, > I ran into the following peculiar error: > > software@raven> make x01j > [ 0%] Built target plhershey-unicode-gen > [ 0%] Built target plhershey-unicode.h_built > [ 0%] Built target csirocsa > [ 13%] Built target csironn > [ 13%] Built target deltaT-gen > [ 17%] Built target deltaT.h_built > [ 17%] Built target tai-utc-gen > [ 21%] Built target tai-utc.h_built > [ 26%] Built target qsastime > [ 78%] Built target plplotd > [ 78%] Built target plplotjavac_wrap > [ 95%] Built target plplot_core > Scanning dependencies of target x01j > [100%] Generating plplot/examples/x01.class > gcj-4.7: error: utf8: No such file or directory > > and similarly for any of our other Java examples. > > @Andrew: > > I believe you have had success with Java on Debian >unstable. What do > you do that is different from what I did above? Can you >also confirm > the above issue on Debian unstable for the Java package >selection > (gcj-4.7-jdk) that I made? Is there something else I >should install > as well to get that to work? When I did a google search >for the above > error message there were only a few hits, but they >appeared to be > quite significant because they were associated with >Debian package > builds which also appear to be running into this same >gcj error. > > Thanks in advance for any help you can give me with this >error. > > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > > > End of Plplot-devel Digest, Vol 77, Issue 2 > ******************************************* DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2012-10-03 08:30:19
|
Hi Phil, On Wed, 03 Oct 2012 09:59:09 +0200 "Arjen Markus" <arj...@de...> wrote: > I will see if there compiler and linker options that >help > with the scenario you are after, but it may turn out to > be impossible - /MT and /MTd may be the way towards that > goal. (I just failed to produce a small program that > depends on these runtime libraries so that is easy to > investigate what options would help - sigh. Probably > better then to try a PLplot example instead) > The GNU compilers are happy to use the static runtime libraries if I pass the option -static. So that is one solution. Now see about the MSVC compiler. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2012-10-03 14:04:39
|
Hi Phil, >> I will see if there compiler and linker options that >>help >> with the scenario you are after, but it may turn out to >> be impossible - /MT and /MTd may be the way towards that >> goal. (I just failed to produce a small program that >> depends on these runtime libraries so that is easy to >> investigate what options would help - sigh. Probably >> better then to try a PLplot example instead) >> > MSVC seems to be happy indeed by replacing /MD by /MT to use only static runtime libraries. I used override files to test it (as described in the CMake FAQs), but at the very least that option is working. Next step: your patches. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2012-10-03 09:48:22
|
On 2012-10-02 22:24-0400 Hezekiah M. Carty wrote: > I've used PLplot to plot a lot of data on maps, including mixing data > from shapefiles and other sources. Based on my experience I think we > may be going off in the wrong direction here. Hi Hez: In order to be sure we understand the rest of your comments, could you explain in more detail how you made map data accessible to PLplot so you could decorate existing maps like you described above? I assume your applications used the API of libraries like shapelib, MDAH, and OGR to import the map data you desired and then you called on the libplplot routines to manipulate those data further, but that assumption needs confirmation. If you do confirm that was the approach you took, my vision is quite similar except my idea was it would be an added convenience for many map/PLplot users to provide a PLplot API that imports map data so their applications can manipulate those data with further PLplot commands. Of course, if some users didn't like that PLplot map importing API, they would be free to import map data into their applications in any other way they like, but our job would be to make that PLplot map importing API reasonably attractive and useful for a large majority of users' map importing needs without making that API too complicated. If you respond you cannot simplify the shapelib, MDAH, and OGR API's any more than they are now for PLplot's _limited_ needs, then obviously it makes little sense for PLplot to provide duplicates of those map importing API's when the user can just call those libraries directly from his application. However, private map importing functionality _is_ needed behind the scenes for plmap (as used in example 19), and I think we should support that "hidden" approach (where the map data is simply plotted and not exposed to the calling routine) as well as the "exposed" approach (which does expose the map data to the calling routine) as outlined above. As we all know, the map importing that plmap does behind the scene currently uses an obscure map file format with very few maps associated with it, but I think we should expand that map importation capability along the lines I described above for the "exposed" approach. Would a good compromise be to work exclusively on improving the map import capability behind plmap for now? If it turns out we like how we simplify the shapelib, MDAH, and OGR API's in that private case for plmap's limited map import needs, then we can turn that into a general public API suitable for the "exposed" case described above. But if the improved map importing functionality we develop for plmap is not going to be added value for users (say, because it just duplicates shapelib, MDAH, and OGR API's) then we should keep it private for the exclusive use of plmap. I certainly agree with you that we need examples of the "exposed" case (whether implemented with direct calls to shapelib, MDAH, or OGR or via some PLplot map import API if that turns out we develop that). I haven't thought too much about your call for improvements in PLplot's functions to deal with additional general plotting needs that would be useful for the "exposed" map case, but I assume those ideas are well taken as well. 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 __________________________ |
From: Andrew R. <and...@us...> - 2012-10-03 11:40:25
|
On Wed, Oct 03, 2012 at 02:48:11AM -0700, Alan Irwin wrote: > On 2012-10-02 22:24-0400 Hezekiah M. Carty wrote: > > > I've used PLplot to plot a lot of data on maps, including mixing data > > from shapefiles and other sources. Based on my experience I think we > > may be going off in the wrong direction here. > > Hi Hez: > > In order to be sure we understand the rest of your comments, could you > explain in more detail how you made map data accessible to PLplot so > you could decorate existing maps like you described above? I assume > your applications used the API of libraries like shapelib, MDAH, and > OGR to import the map data you desired and then you called on the > libplplot routines to manipulate those data further, but that > assumption needs confirmation. > > If you do confirm that was the approach you took, my vision is quite > similar except my idea was it would be an added convenience for many > map/PLplot users to provide a PLplot API that imports map data so their > applications can manipulate those data with further PLplot commands. > Of course, if some users didn't like that PLplot map importing API, > they would be free to import map data into their applications in any > other way they like, but our job would be to make that PLplot map > importing API reasonably attractive and useful for a large majority of > users' map importing needs without making that API too complicated. > > If you respond you cannot simplify the shapelib, MDAH, and OGR API's > any more than they are now for PLplot's _limited_ needs, then > obviously it makes little sense for PLplot to provide duplicates of > those map importing API's when the user can just call those libraries > directly from his application. > > However, private map importing functionality _is_ needed behind the scenes for > plmap (as used in example 19), and I think we should support that "hidden" > approach (where the map data is simply plotted and not exposed to the > calling routine) as well as the "exposed" approach (which does > expose the map data to the calling routine) as outlined above. > > As we all know, the map importing that plmap does behind the scene > currently uses an obscure map file format with very few maps > associated with it, but I think we should expand that map importation > capability along the lines I described above for the "exposed" > approach. > > Would a good compromise be to work exclusively on improving the map > import capability behind plmap for now? If it turns out we like how > we simplify the shapelib, MDAH, and OGR API's in that private case for > plmap's limited map import needs, then we can turn that into a general > public API suitable for the "exposed" case described above. But if > the improved map importing functionality we develop for plmap is not > going to be added value for users (say, because it just duplicates > shapelib, MDAH, and OGR API's) then we should keep it private for the > exclusive use of plmap. > > I certainly agree with you that we need examples of the "exposed" case > (whether implemented with direct calls to shapelib, MDAH, or OGR or > via some PLplot map import API if that turns out we develop that). I > haven't thought too much about your call for improvements in PLplot's > functions to deal with additional general plotting needs that would be > useful for the "exposed" map case, but I assume those ideas are well > taken as well. Alan, Certainly my take on this was that I was envisaging only using this support for behind the scenes improvements to plmap, not reproducing a general interface to shapelib / ogr / gdal etc. There is no point reproducing the wheel, particularly where things like shapelib have a pretty simple API anyway. I agree with Hez that all of this could be achieved already by the end user with the existing API (helped by a new plpolygons function). However, given we have plmap already and it adds some functionality in terms coordinate transformations I think we should limit ourselves to better supporting different map formats for plmap, at least for now. Being able to simple draw some stock map as a background for the real figure is useful (see Phil's examples) for scientific plotting. This is quite different though to producing high quality maps which is a job for a GIS and not plplot. I think this is what you were suggsting anyway isn't it? The idea of using raster maps as a background for a plot is interesting. I don't see why we couldn't implement an example of this using the current plimagefr function anyway. This could be a very pretty example of the kind of thing one can achieve with plplot. Just needs a copyright free raster map as the backdrop. Andrew |
From: phil r. <phi...@ya...> - 2012-10-11 10:22:45
|
Hi Andrew Thanks for your comments, massively useful. I have added some further comments/questions below. Cheers Phil ________________________________ From: Andrew Ross <and...@us...> To: phil rosenberg <phi...@ya...> Cc: "plp...@li..." <plp...@li...> Sent: Wednesday, 10 October 2012, 21:38 Subject: Re: [Plplot-devel] map resolution Phil, Thanks for your patch. A great start. I've got a few comments. To get it to compile on Linux required a couple of changes: 1) Debian installs the include file shapefil.h in /usr/include not in a shapelib subdirectory. Changing the #include statement in plmap.c fixed this. Phil, where is yours installed? Is the subdirectory a standard thing, or something you created? Making use of the ${SHAPELIB_INCLUDE_DIR} variable should allow you to search in the correct place. The joy of windows - there is no standard directory, in the source tree the shapefil.h header is in the top level. I always create a librarytopleveldir/include/libraryname folder for headers and add the include MAKE at all so is there any chance you could create a #define SHAPELIB_INCLUDE_DIR based on the variable. 2) plplotd needs to be linked with the shp library. To achieve this I added the following code to src/CMakeLists.txt if(HAVE_SHAPELIB) set( libplplot${LIB_TAG}_LINK_LIBRARIES ${libplplot${LIB_TAG}_LINK_LIBRARIES} shp ) endif(HAVE_SHAPELIB) Does plplotd link with the other libraries used by plplot? Thisbehaviour doesn't occur on my Windows system and I have to link my final code against the other dependancies myself. Do you want to commit this change yourself or shall I include it in my patch? 3) The code generated the following gcc warning /home/andrew/software/plplot/plplot/src/plmap.c:48:1: warning: 'visibility' attribute ignored [-Wattributes] The problem here is the static attribute. This makes the scope of the variable local to this file, and hence visibility attributes don't make sense. I'm guessing this is not what you wanted. Looks like this bit of code was just copied from src/plctrl.c. The plplotLibDir variable there is only actually used by the tcl code to pass the tcl library directory. I would just remove all references to this here. Good spot, I didn't get the warning. I wasn't sure about the use of plplotLibDir so was just trying to preserve it. I will remove references to it. Other comments: - Having made these changes the code compiled and example 19 ran. I tried this _before_ downloading any shapefiles. As it stands your patch doesn't fall back to using the old map code. I'd suggest a fallback would be sensible for compatibility. One might want to use shapefiles and old plplot maps (at least for now). At least it needs an error message if the file can't be found! 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. - The function OpenShapeFile still contains mentions of plLibOpenPdfstr. I'll make sure this is removed - As a general coding principle I try to avoid using macros in the manner you have done with OpenMap and CloseMap. It's not wrong, it just leads to code that can be harder to read. It's generally better to include code in #ifdefs as then makes it explicit what functions are being called and under what circumstances. Macros can also confuse some debuggers. I'll change this then - As a further basic principle I'd try to ensure that the different code paths (shapelib and plplot format) are as similar as possible, and share code where appropriate. As an example, bufx and bufy are statically created for the old code path and allocated with malloc in the shapelib code path. Some of this code could be shared. Yeah, I was just trying to keep as much old code as possible, but I agree there can be more shared code this way, I'll change it - I've had a quick look at the transform code. Making multiple copies of the data seems like a slightly inefficient way of solving the problem. I wonder if there is a better algorithm for fixing the problem? I would suggest creating a simple example to illustrate the problem (maybe a new page for example 19). This way we would have a test case try out new algorithms. It might be inefficient, but I would guess (and it is a guess without profiling) that the time to make multiple copies is less than the time to read the data from the hard drive. I could instead reuse the same data, but would need to itterate over it 5 times, which I'm not sure would be much quicker. The method that was there before, plain didn't work, neither did the method that it had replaced that was commented out. This method should be as general as possible so should work with any shapefile (with units of degrees lat/ lon) which is important if users might try their own shapefiles. I can certainly implement another algorithm if you have any suggestions. Once I downloaded the shapefiles following your pointer to www.naturalearthdata.com (great site by the way!) all worked fine so these comments are mostly stylistic in nature. Regards Andrew On Mon, Oct 08, 2012 at 03:27:25PM -0700, phil rosenberg wrote: > Well I've managed to find a little time between changing dirty nappies so please find attached my first cut at a patch for shapelib > support in plmap > I???ve made a few changes to plmap to do this: > ?? > First is the simple reading of the data from the shapefiles > rather than the original files. The .shp and .shx files are needed, none of the other shapefile files are used. ??The shapelib files can be placed and > referenced exactly like the old files, so either in a ???special place??? (data > folder, exe folder, etc) and referenced by filename or anywhere else referenced > by full path. Note that the extension can be omitted or included as per the > shapelib API. > ?? > Second is the transformation is now performed after the > wraparound fixing. This is because the transformation may be into metres or > some other such length unit if a map projection is used (I've just been working with data transformed onto a transverse mercator projection which does exactly this) making wraparound fixing impossible after the transformation has been applied. > ?? > Third is that wraparound fixing has been rewritten. This was > because the previous method broke near the equator, particularly in Africa > where there are a number of long straight political boundaries (so > point-to-point lon changes can be large and lat can be small). It may be of > interest that the new method means that if the user specifies lon on 0-360 > scale, but the map is -180-180 (or visa-versa) then the features still plot > correctly. > ?? > From the previous discussions I???m sure there will be a > number of avid testers. Example 19 uses plmap, but to run it??you will need to get a replacement > shapefile map for the globe and usaglobe original maps. For testing I grabbed > the 110 m resolution countries map from http://www.naturalearthdata.com/features/and made two copies of the .shp and .shx files, renaming them globe and > usaglobe. Putting these in the same location as the usual map files will give > you a functioning example 19. > ?? > If/when people are happy with the patch I'll generate shapefile equivalents of the current maps which will mean that existing code will produce identical output whether or not PLplot has been compiled with shapelib support. > ?? > The code currently plots polygons and ploylines only, and in both cases plots these as lines with no fill. I had wondered about adding the ability to plot polygons with a fill, but this requires a change or addition to the public API and I'm not sure how useful it would be - It would probably need some way to link different fill syles to different objects within a file and I think we already discussed that this is something it is best to let people code themselves rather than try to turn PLplot into GIS software. Although if people think that it would be useful to have a fill option it's relatively little effort to do - discus!!! > ?? > Let me know if the patch works for you. > ?? > Phil > > > > ________________________________ > From: Alan W. Irwin <ir...@be...> > To: phil rosenberg <phi...@ya...> > Cc: "plp...@li..." <plp...@li...>; Andrew Ross <and...@us...> > Sent: Friday, 5 October 2012, 21:38 > Subject: Re: [Plplot-devel] map resolution > > By the way, I looked for a shapefile viewer on Debian and found > thuban. I don't know whether that is the best shapefile viewer for > Linux, but it is based on libgda/ogr.?? When I tried thuban on overall > shapefile maps for British Columbian (obtained by following links at > http://downloads.cloudmade.com/) it appeared to work instantaneously > and well for the size (which totalled 200MB) of the 7 shapefile layers > making up the map of British Columbia that is provided by > http://downloads.cloudmade.com/.?? Furthermore, I was much impressed > with all the high-resolution local detail (e.g., coastlines, natural features, > political boundaries to name three of the most useful shapefile layers > available for the British Columbia map) that was available under the > thuban zoom mode.?? By the way, that zoom mode worked essentially > instantaneously as well. > > I assume shapelib will be as fast or faster than libgda/ogr so I think > we have a lot to look forward to concerning the speed with which > shapelib can deliver shapes behind the scenes to plmap for that > function to plot. > > And to anticipate a possible ( :-) ) further question from Phil, no I > don't think we should get into trying to let plmap deal with several > shapefile file layers at once. Instead it should be the users' > responsibility to specify, e.g., "british_columbia_coastline.shp" as a > filename to plmap if they want the B.C. coastlines on their plot, and > if a user wants another layer in their plot with natural features on > top of those coastlines, they can call plmap again with a different > filename for the same region, e.g., "british_columbia_natural.shp". > > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Andrew R. <and...@us...> - 2012-10-11 21:59:53
|
No problem! Responses are inline below. Andrew On Thu, Oct 11, 2012 at 03:22:34AM -0700, phil rosenberg wrote: > Hi Andrew > ? > Thanks for your comments, massively useful. I have added some further comments/questions below. > ? > Cheers > ? > Phil > > > ________________________________ > From: Andrew Ross <and...@us...> > To: phil rosenberg <phi...@ya...> > Cc: "plp...@li..." <plp...@li...> > Sent: Wednesday, 10 October 2012, 21:38 > Subject: Re: [Plplot-devel] map resolution > > > > Phil, > > Thanks for your patch. A great start. I've got a few comments. > > To get it to compile on Linux required a couple of changes: > > 1) Debian installs the include file shapefil.h in /usr/include not in a > shapelib subdirectory. Changing the #include statement in plmap.c fixed > this. Phil, where is yours installed? Is the subdirectory a standard > thing, or something you created? Making use of the ${SHAPELIB_INCLUDE_DIR} > variable should allow you to search in the correct place. > > The joy of windows - there is no standard directory, in the source tree the shapefil.h header is in the top level. I always create a librarytopleveldir/include/libraryname folder for headers and add the include MAKE at all so is there any chance you could create a #define SHAPELIB_INCLUDE_DIR based on the variable. The way to do this is to use the cmake variable to set the include path on the command line. My latest commit to src/CMakeLists.txt does this, so you should now be able to set CMAKE_INCLUDE_DIR and then just have "#include <shapefil.h>" in src/plmap.c. > 2) plplotd needs to be linked with the shp library. To achieve this I > added the following code to src/CMakeLists.txt > > if(HAVE_SHAPELIB) > ? set( > ? ? libplplot${LIB_TAG}_LINK_LIBRARIES > ? ? ${libplplot${LIB_TAG}_LINK_LIBRARIES} > ? ? shp > ? ? ) > endif(HAVE_SHAPELIB) > > Does plplotd link with the other libraries used by plplot? Thisbehaviour doesn't occur on my Windows?system and I have to link my final code against the other dependancies myself. Do you want to commit this change yourself or shall I include it in my patch? My patch also ensures that plplotd is properly linked to libshp. It's a bit more comprehensive than the above. At least on Linux this means that you don't need to explicitly link to the shapelib library when using plplot. > > 3) The code generated the following gcc warning > /home/andrew/software/plplot/plplot/src/plmap.c:48:1: warning: 'visibility' attribute ignored [-Wattributes] > > The problem here is the static attribute. This makes the scope of the > variable local to this file, and hence visibility attributes don't make > sense. I'm guessing this is not what you wanted. Looks like this bit of > code was just copied from src/plctrl.c. The plplotLibDir variable there > is only actually used by the tcl code to pass the tcl library directory. > I would just remove all references to this here. > > Good spot, I didn't get the warning. I wasn't sure about the use of plplotLibDir so was just trying to preserve it. I will remove references to it. > > Other comments: > > - Having made these changes the code compiled and example 19 ran. I tried > this _before_ downloading any shapefiles. As it stands your patch doesn't > fall back to using the old map code. I'd suggest a fallback would be > sensible for compatibility. One might want to use shapefiles and > old plplot maps (at least for now). At least it needs an error message if > the file can't be found! > > 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 do think there should be a warning message if the file is not found though. > - The function OpenShapeFile still contains mentions of plLibOpenPdfstr. > > I'll make sure this is removed > > - As a general coding principle I try to avoid using macros in the > manner you have done with OpenMap and CloseMap. It's not wrong, it > just leads to code that can be harder to read. It's generally better to > include code in #ifdefs as then makes it explicit what functions are > being called and under what circumstances. Macros can also confuse some > debuggers. > > I'll change this then > > - As a further basic principle I'd try to ensure that the different code > paths (shapelib and plplot format) are as similar as possible, and share > code where appropriate. As an example, bufx and bufy are statically > created for the old code path and allocated with malloc in the shapelib > code path. Some of this code could be shared. > > Yeah, I was just trying to keep as much old code as possible, but I agree there can be more shared code this way, I'll change it > > - I've had a quick look at the transform code. Making multiple copies of > the data seems like a slightly inefficient way of solving the problem. I > wonder if there is a better algorithm for fixing the problem? I would > suggest creating a simple example to illustrate the problem (maybe a > new page for example 19). This way we would have a test case try out > new algorithms. > > It might be inefficient, but I would guess (and it is a guess without profiling) that the time to make multiple copies is less than the time to read the data from the hard drive. I could instead reuse the same data, but would need to itterate over it 5 times, which I'm not sure would be much quicker. > The method that was there before, plain didn't work, neither did the method that it had replaced that was commented out. This method should be as general as possible so should work with any shapefile (with units of degrees lat/ lon) which is important if users might try their own shapefiles. I can certainly implement another algorithm if you have any suggestions. Clearly this is a bug fix, and is somewhat separate from the shapelib support. Perhaps stick with your method for now. If it proves burdensome then we can look at alternative ways of solving the problem. |
From: Alan W. I. <ir...@be...> - 2012-10-24 21:38:54
|
On 2012-10-24 20:09+0100 Andrew Ross wrote: >> 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? Yes please. > We should also update README.release to include this change. Absolutely. 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 __________________________ |
From: Andrew R. <and...@us...> - 2012-10-24 21:52:57
|
On Wed, Oct 24, 2012 at 02:38:41PM -0700, Alan Irwin wrote: > On 2012-10-24 20:09+0100 Andrew Ross wrote: > > >> 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? > > Yes please. > > > We should also update README.release to include this change. > > Absolutely. Both now done. I notice there are no release notes so far for this release. I suspect we have done things that should be documented. The colorbar changes I will add once that has settled down. In the meantime a check of the svn changes since the last release might be prudent. Anyone who knows they have made changes, please document them in README.release. Andrew |
From: Alan W. I. <ir...@be...> - 2012-10-12 06:20:21
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2012-10-03 18:23:58
|
On 2012-10-03 12:40+0100 Andrew Ross wrote: > Alan, > > Certainly my take on this was that I was envisaging only using this > support for behind the scenes improvements to plmap, not reproducing > a general interface to shapelib / ogr / gdal etc. There is no point > reproducing the wheel, particularly where things like shapelib have a > pretty simple API anyway. > > I agree with Hez that all of this could be achieved already by the end > user with the existing API (helped by a new plpolygons function). However, > given we have plmap already and it adds some functionality in terms > coordinate transformations I think we should limit ourselves to better > supporting different map formats for plmap, at least for now. > > Being able to simple draw some stock map as a background for the real > figure is useful (see Phil's examples) for scientific plotting. This > is quite different though to producing high quality maps which is a > job for a GIS and not plplot. > > I think this is what you were suggsting anyway isn't it? Yes, I agree we should concentrate for now on better support for different map formats for plmap as well as Hez's suggestions for improved general polygon plotting functions. > The idea of using raster maps as a background for a plot is > interesting. I don't see why we couldn't implement an example of this > using the current plimagefr function anyway. This could be a very > pretty example of the kind of thing one can achieve with plplot. Just > needs a copyright free raster map as the backdrop. I agree this is a good idea. 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 __________________________ |
From: phil r. <phi...@ya...> - 2012-10-04 19:58:35
|
I also agree with Hez that there should be a split between the PLplot backend and how frontend users plot maps. PLplot needs its own backen maps and files so users who want basic functionality can get it (which I think should include more than one resolution). For "advanced use" functions which allow users to plot their own map data as easily as possible is a priority - they probably have their own favourite map format and routines to load them anyway so maybe just the ability to easily provide arrays of lats/lons is key. Maybe a version of plfill, plline and plstring which accepts a map transform? If this is the kind of model we go for then I just want to double check that shapefile really the correct format to use for the built in maps. The only concern I have is that it may be slow and memory hungry to read the files because the file only specifies min/max x/y for the entire file. If these files are not intended for the users to see or modify then they can be taylored to best suit the needs of PLplot rather than being "generically useful". The main reason why I have these concerns is because (if I'm not mistaken - but I might be, so correct me if I'm wrong) plreplot doesn't seem to be fully implemented so in my current setup I replot a whole plot from scratch whenever my wxWidget window is resized. I wouldn't want every resize and every subsequent call to plmap to load tens or hundreds of MB. Despite this it can't be a bad thing to ensure the map files load quickly and use as little ram as possibles. Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: Andrew Ross <and...@us...> Cc: Hezekiah M. Carty <hez...@us...>; "plp...@li..." <plp...@li...>; phil rosenberg <phi...@ya...> Sent: Wednesday, 3 October 2012, 19:23 Subject: Re: [Plplot-devel] map resolution On 2012-10-03 12:40+0100 Andrew Ross wrote: > Alan, > > Certainly my take on this was that I was envisaging only using this > support for behind the scenes improvements to plmap, not reproducing > a general interface to shapelib / ogr / gdal etc. There is no point > reproducing the wheel, particularly where things like shapelib have a > pretty simple API anyway. > > I agree with Hez that all of this could be achieved already by the end > user with the existing API (helped by a new plpolygons function). However, > given we have plmap already and it adds some functionality in terms > coordinate transformations I think we should limit ourselves to better > supporting different map formats for plmap, at least for now. > > Being able to simple draw some stock map as a background for the real > figure is useful (see Phil's examples) for scientific plotting. This > is quite different though to producing high quality maps which is a > job for a GIS and not plplot. > > I think this is what you were suggsting anyway isn't it? Yes, I agree we should concentrate for now on better support for different map formats for plmap as well as Hez's suggestions for improved general polygon plotting functions. > The idea of using raster maps as a background for a plot is > interesting. I don't see why we couldn't implement an example of this > using the current plimagefr function anyway. This could be a very > pretty example of the kind of thing one can achieve with plplot. Just > needs a copyright free raster map as the backdrop. I agree this is a good idea. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2012-10-04 23:14:52
|
On 2012-10-04 12:58-0700 phil rosenberg wrote: > I just want to double check that shapefile really the correct format to use for the built in maps. The only concern I have is that it may be slow and memory hungry to read the files because the file only specifies min/max x/y for the entire file. If these files are not intended for the users to see or modify then they can be taylored to best suit the needs of PLplot rather than being "generically useful". Hi Phil: I have had a quick look at http://shapelib.maptools.org/shp_api.html, and it appears essentially every shape (except null and single point) has a bounding box. So it should be straightforward to read in shapes and select only the ones which are relevant to the area of the map you want to plot with plmap. I would aim just for that simple area selection capability to start. Once you are happy with the plotted results for small shape files where efficiency is not a concern, you might want to implement an optimization that eliminates shapefile rereads for the same shapefile and same plotted area that has been specified before. I can think of several possibilities for such an optimization, and I am sure you can as well. However, I would strongly advise waiting to figure out the specifics of such optimization until later. After all, the usual programming advice is to optimize late in development rather than early, and I think that advice is completely relevant to this 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 __________________________ |
From: Andrew R. <and...@us...> - 2012-10-22 19:37:32
|
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...@be...> > To: Andrew Ross <and...@us...> > Cc: phil rosenberg <phi...@ya...>; "plp...@li..." <plp...@li...> > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2012-10-22 21:13:21
|
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 __________________________ |