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: "plplot-devel-request@lists.sourceforge.net" <plplot-devel-request@lists.sourceforge.net>
To: plplot-devel@lists.sourceforge.net
Sent: Tuesday, 2 October 2012, 20:23
Subject: Plplot-devel Digest, Vol 77, Issue 2

Send Plplot-devel mailing list submissions to
    plplot-devel@lists.sourceforge.net

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
    plplot-devel-request@lists.sourceforge.net

You can reach the person managing the list at
    plplot-devel-owner@lists.sourceforge.net

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 <andrewross@users.sourceforge.net>
Subject: Re: [Plplot-devel] Fw:  wxWidgets driver and line breaks
    (fwd)
To: phil rosenberg <philip_rosenberg@yahoo.com>,
    "plplot-devel@lists.sourceforge.net"
    <plplot-devel@lists.sourceforge.net>
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" <irwin@beluga.phys.uvic.ca>
Subject: Re: [Plplot-devel] map resolution
To: phil rosenberg <philip_rosenberg@yahoo.com>
Cc: "plplot-devel@lists.sourceforge.net"
    <plplot-devel@lists.sourceforge.net>
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" <irwin@beluga.phys.uvic.ca>
Subject: Re: [Plplot-devel] map resolution
To: Andrew Ross <andrewross@users.sourceforge.net>
Cc: plplot-devel@lists.sourceforge.net
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 <arjen.markus@deltares.nl>
Subject: Re: [Plplot-devel] Building examples on Windows
To: "plplot-devel@lists.sourceforge.net"
    <plplot-devel@lists.sourceforge.net>
Message-ID: <506A91CB.805@deltares.nl>
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" <irwin@beluga.phys.uvic.ca> 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
> Plplot-devel@lists.sourceforge.net
> 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 <dcesari@arpa.emr.it>
Subject: Re: [Plplot-devel] map resolution
To: "Alan W. Irwin" <irwin@beluga.phys.uvic.ca>
Cc: PLplot development list <plplot-devel@lists.sourceforge.net>
Message-ID: <506A9B66.1060605@arpa.emr.it>
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" <irwin@beluga.phys.uvic.ca>
Subject: [Plplot-devel] Using gcj-4.7-jdk on Debian wheezy fails with
    PLplot
To: Andrew Ross <andrewross@users.sourceforge.net>,     PLplot
    development list <Plplot-devel@lists.sourceforge.net>
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


End of Plplot-devel Digest, Vol 77, Issue 2
*******************************************