Re: [Plplot-devel] shapelib find module

[Alan W. I. <ir...@be...>]

On 2014-05-27 18:46+0100 Phil Rosenberg wrote:

> Hi Alan and anyone else
>
> No, you must call multiple times. This is mostly however a limit of shapefiles. An overview of shapefiles is as follows. A shapefile is actually multiple files with the same filename and different extensions. Lets call these a shapefile set. The files include the map data, an index to the data file and a metadata file. Some other optional files can be included too. Each shapefile set can be either line data, point data, fill data, etc. Mixed shapefile sets are not permitted. So to define a full map you would generally have multiple shapefiles defining various different aspects of the map. So to plot different types you would have to plot data from different files anyway. Because a file contains only one data type it is not necessary to define the type, but it may be useful to be able to override the type. For example I often see coastlines plotted as dots, or line data may wish to be filled or vica versa.
>
> So, I will change the implementation to use one function. This will have parameters for all the types and a type parameter. Which may be auto, point line, fill or gradient.
>
> I don't have access to the api right now, but it might make sense to have a plsmaptype function. Users could call this to override the default type of the file and this would remove one parameter from plmap. This is at the expense of a further function to propagate. I wwill go through and check if there are any further draw types that may be useful.
>
> Let me know if you have any further thoughts. I'm away this week so it will be the weekend at least before I do anything about this.

Thanks, Phil, for that additional information about shape files.  From
what you have said, though, it should still be possible to implement a
plmap API that with the integer type parameter having independent bits
corresponding to each of fill, line, etc.  Then inside that function
you could iterate through each of fill, line, text, etc.,
possibilities and for each case (if the relevant bit is set in the type
parameter) read in the appropriate shapefile and plot it.  In other
words, the loop through the possibilities is inside the function
rather than the user's responsibility.  So the advantage of this
approach is the user only has to choose which bits to set in the map
type, and plmap does the rest.

I do forsee one small drawback of this approach. I assume that the
object index is completely different between types so that the number
of fills might be quite different than say the number of text items.
So, this means a drawback of this "loop inside function" approach is
you would have to use a two-dimensional array to define how each type
of object is sampled.  However, I view this as a small drawback since
my guess is most users will want to use all map objects rather than
sampling them, i.e., this array will be NULL for most use.

Note, I am just throwing out ideas for discussion here, and I will be
happy to go along with whatever you and Andrew ultimately decide is
the best API.

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
__________________________