Looking again at the wikipedia shapefile page, the format seems pretty easy to read. The three files that it says are required are the .shp, shx and .dbf. The .shp is just a file header, then multiple records, each with a header specifying the record length. This is pretty similar to the format I suggested and for the point, polygon and polyline types is not much more difficult to read than the format I suggested.
 
Although it is claimed .shx and .dbf files are required, the .shp file could be parse without them. The .shx file is just an index which would allow seeking to specified records without reading the whole file to that point (not really needed if we want to plot whole files as we do now) and the .dbf provides attributes of the different shapes, but I'm not sure exactly what attributes or if this file is entirely flexible to the users' needs.
 
It wouldn't be too difficult to write a parser for .shp files supporting point, polygon and polyline types only and include this in the core library. As Andrew says Plplot isn't GIS software so maybe there is no need for full support of all shapefile features. Another advantage of using shapefiles is that only one type of shape should be included per file so representing the UK we could have the following files:
ukcoastline.shp - polygon
ukborders.shp - polyline
ukcities.shp - points
uklakes - polygon
 
And when loading data from each file the current line, fill and point settings could be used. Maybe this could be for the future though.
 
 
Any thoughts? I'm busy with family at the mo after the arrival of a new baby in the household, but a parser should only be a few hundred lines of code so I might look into this - along with all the other promises I've made to Plplot :-)
 
Phil
From: "plplot-devel-request@lists.sourceforge.net" <plplot-devel-request@lists.sourceforge.net>
To: plplot-devel@lists.sourceforge.net
Sent: Thursday, 27 September 2012, 17:37
Subject: Plplot-devel Digest, Vol 76, Issue 6

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. Release schedule? (Andrew Ross)
  2. Re: map resolution (Andrew Ross)
  3. Re: map resolution (Arjen Markus)
  4. Re: map resolution (Andrew Ross)
  5. Re: map resolution (Arjen Markus)
  6. Re: map resolution (Alan W. Irwin)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Sep 2012 13:47:57 +0100
From: Andrew Ross <andrewross@users.sourceforge.net>
Subject: [Plplot-devel] Release schedule?
To: Plplot-devel mailing list <plplot-devel@lists.sourceforge.net>
Message-ID: <20120926124757.GG4106@gandalf.rivendell>
Content-Type: text/plain; charset=us-ascii


It is coming up to a year since the last official release of plplot
(5.9.9). Although it has been a relatively quiet time in terms of
developments, there are some important bug fixes for newer software
versions in there. We should think about a timetable for the next
release and whether there are any outstanding issues that need fixing
/ new features to include for such a release to happen. Does anyone
have any thoughts on this?

Before a release we also need to find a new release manager to
coordinate the process and do the actual release, announcements etc.

Regards

Andrew




------------------------------

Message: 2
Date: Wed, 26 Sep 2012 15:52:58 +0100
From: Andrew Ross <andrewross@users.sourceforge.net>
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: <20120926145258.GA17224@gandalf.rivendell>
Content-Type: text/plain; charset=us-ascii

On Fri, Sep 21, 2012 at 05:14:30AM -0700, phil rosenberg wrote:
> In many respects I agree. Plplot isn't a mapping tool and I could just get some outline data and plot it as a series of lines. As you say, when zoomed in the map projections make little difference.
>
> The stuff I'm doing at the moment is zoomed right in on Southern UK so projections aren't an issue, but if I were looking at northern Europe for example then I think I'd want something more detailed than the current maps and the projections would probably be useful then. I imagine that also there would be many lines needed to simply plot the outlines as a line chart.
>
> If we wanted to adopt an existing file format then shapefiles seem quite common and have essentially an open specification. The format is relatively straightforward, having a file header followed by a number of records each with a header followed by data. See http://en.wikipedia.org/wiki/Shapefile. There is a C library for reading/writing them at http://shapelib.maptools.org/ - this does add an extra dependency though with the extra complexity in the build stage or some relatively straightforward code could be added to Plplot to read basic shapefiles.
>
> Or if this is overkill for the needs of plplot a map file could begin with a header something like
>
> {
> ??? char newversionflag; //always zero to identify new versions vs current version
> ??? char versionnumber; //for future proofing
> ??? char datatypeflag; //flag whether the data is big/little endian integers or ieee floats
> ??? char nbytesperpoint; //number of bytes for each lat/lon value
> }
> followed by a series of records each beginning with a number which specifies the number of lat/lon values in the record like the current version.
>
> This would give most users the flexibility to generate the maps or any additional surface features they want in a pretty straightforward way or a number of different maps at different resolutions could be provided with plplot.
>
>
> Like Andrew says - just my random thoughts

Phil,

I took a look at the shapefile format. My personal take is that this
might be a little over the top. Strictly it requires 3 files including
information like projections etc. Seems more than we need.

I think a simple binary format such as you suggest may suffice and
could easily be made backwards compatible with the current file
format. Not sure I'd bother with supporting both big and little endian
formats.

Would you be willing to try this out and produce a patch +
documentation? If so, I think it could be a useful addition,
particularly if we can also generate some better data files as
examples.

Regards

Andrew



------------------------------

Message: 3
Date: Thu, 27 Sep 2012 13:12:40 +0200
From: Arjen Markus <arjen.markus@deltares.nl>
Subject: Re: [Plplot-devel] map resolution
To: "plplot-devel@lists.sourceforge.net"
    <plplot-devel@lists.sourceforge.net>
Message-ID: <506434A8.2040403@deltares.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Andrew, Phil,

On 2012-09-26 16:52, Andrew Ross wrote:

>
> I took a look at the shapefile format. My personal take is that this
> might be a little over the top. Strictly it requires 3 files including
> information like projections etc. Seems more than we need.
>

On the other hand, the shape file format is a very commonly used format
and there are plenty tools around to handle them. Isn't there a
thrid-party library that we can use? Not to mimick a GIS system but
to make it easier for people to use geographical information without
having to convert the files.

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.







------------------------------

Message: 4
Date: Thu, 27 Sep 2012 12:35:05 +0100
From: Andrew Ross <andrewross@users.sourceforge.net>
Subject: Re: [Plplot-devel] map resolution
To: Arjen Markus <arjen.markus@deltares.nl>
Cc: "plplot-devel@lists.sourceforge.net"
    <plplot-devel@lists.sourceforge.net>
Message-ID: <20120927113505.GA12903@gandalf.rivendell>
Content-Type: text/plain; charset=us-ascii


There are such libraries (Phil mentioned one). We could use these, it
just introduces another dependency on the core of plplot for what is
a relatively minor feature. Currently the plplot core and some basic
drivers can be compiled with almost no dependencies. For testing,
porting to new systems and potentially embedded systems this is a very
useful thing and worth preserving.

Of course we could keep the current code as well and only enable
shapefile support if the library is present. Shapefile support would
be convenient for users.

Andrew

On Thu, Sep 27, 2012 at 01:12:40PM +0200, Arjen Markus wrote:
> Hi Andrew, Phil,
>
> On 2012-09-26 16:52, Andrew Ross wrote:
>
> >
> > I took a look at the shapefile format. My personal take is that this
> > might be a little over the top. Strictly it requires 3 files including
> > information like projections etc. Seems more than we need.
> >
>
> On the other hand, the shape file format is a very commonly used format
> and there are plenty tools around to handle them. Isn't there a
> thrid-party library that we can use? Not to mimick a GIS system but
> to make it easier for people to use geographical information without
> having to convert the files.
>
> 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.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>



------------------------------

Message: 5
Date: Thu, 27 Sep 2012 13:36:52 +0200
From: Arjen Markus <arjen.markus@deltares.nl>
Subject: Re: [Plplot-devel] map resolution
To: "plplot-devel@lists.sourceforge.net"
    <plplot-devel@lists.sourceforge.net>
Message-ID: <50643A54.1050702@deltares.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

HI andrew,

On 2012-09-27 13:35, Andrew Ross wrote:
> There are such libraries (Phil mentioned one). We could use these, it
> just introduces another dependency on the core of plplot for what is
> a relatively minor feature. Currently the plplot core and some basic
> drivers can be compiled with almost no dependencies. For testing,
> porting to new systems and potentially embedded systems this is a very
> useful thing and worth preserving.
>
> Of course we could keep the current code as well and only enable
> shapefile support if the library is present. Shapefile support would
> be convenient for users.
>

Actually, that is what I had in mind.

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.







------------------------------

Message: 6
Date: Thu, 27 Sep 2012 09:37:34 -0700 (PDT)
From: "Alan W. Irwin" <irwin@beluga.phys.uvic.ca>
Subject: Re: [Plplot-devel] map resolution
To: Andrew Ross <andrewross@users.sourceforge.net>,     Arjen Markus
    <arjen.markus@deltares.nl>
Cc: "plplot-devel@lists.sourceforge.net"
    <plplot-devel@lists.sourceforge.net>
Message-ID: <alpine.DEB.2.00.1209270758110.7726@ybpnyubfg.ybpnyqbznva>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On 2012-09-27 13:36+0200 Arjen Markus wrote:

> On 2012-09-27 13:35, Andrew Ross wrote:
>>
>> Of course we could keep the current code as well and only enable
>> shapefile support if the library is present. Shapefile support would
>> be convenient for users.
>>
>
> Actually, that is what I had in mind.

I think that this (only enable support if the dependent library is
present) is a good general approach.
So we could start with using shapelib (if present) to interpret
shapefile data.  But in the long term I don't think we should stop there.

I have mentioned the MIT-licensed OGR and GDAL possibilities before,
but let me do it again since they are so relevant to this discussion
and they are both more comprehensive now (more formats supported)
than when I mentioned them before.

The OGR library (http://www.gdal.org/ogr/index.html) translates
between many vector formats for maps (see
http://www.gdal.org/ogr/ogr_formats.html for the full list) including
ESRI Shapefile format.

The GDAL library (http://www.gdal.org/) similarly translates between
many raster formats for maps (see
http://www.gdal.org/formats_list.html for the full list).

I think our long-term goal should be to interface our core library to
both the OGR and GDAL libraries (again, only if those libraries are
present).  This would give PLplot users the powerful capability of
being able to translate most available map formats into either a
standard internal vector form (probably shapefile according to this
current thread) or standard internal raster form (probably PNM
following what we do with the "Lena" image) and modify that internal
form with extra decorations and transformations as in example 19.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________



------------------------------

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html

------------------------------

_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


End of Plplot-devel Digest, Vol 76, Issue 6
*******************************************