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.

From: Alan W. Irwin <irwin@beluga.phys.uvic.ca>
To: Andrew Ross <andrewross@users.sourceforge.net>
Cc: Hezekiah M. Carty <hezekiahcarty@users.sourceforge.net>; "plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net>; phil rosenberg <philip_rosenberg@yahoo.com>
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 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