Hi Alan
To plot multiple types would need plmap to be called on multiple files. I have
an example sorted and this has separate shapefile sets for contours, land use
polygons, roads, rivers and points for labels. This is typical because you
cannot have a shapefile containing more than one type of data. Therefore to
plot all these elements requires 5 plmap calls, one for each file. Also we
would of course want to set the colour and line width differently for contours
vs, roads, vs rivers and we might want every 10th contour to be thicker or
major roads to be a different colour to minor roads. I can't really see a
sensible way for one call to plmap to allow every element to be drawn.
A combined function would have a prototype something like
Void plmap ( char* filename, int *elementstodraw, int nelementstodraw, char
*string, PLFLT justification, PLFLT dx, PLFLT dy, PLFLY shearx, PLFLT sheary,
PLFLT angle )
Filename is obvious, elementstodraw would be an array indicating which elements
to draw (so we can draw different roads in different colours for example),
string, justification, dx, dy, shearx, sheary, would only be used for points.
Angle would be used for gradient fill or we could not use this and use dx and
dy instead. We could have a different parameter to override the type ( point,
line, etc), or a plsmaptype function to do this. Or we could just not permit
this at all.
All thoughts welcome
Phil
-----Original Message-----
From: "Alan W. Irwin" <[email protected]>
Sent: 27/05/2014 21:47
To: "Phil Rosenberg" <[email protected]>
Cc: "Andrew Ross" <[email protected]>; "PLplot development list"
<[email protected]>
Subject: RE: [Plplot-devel] shapelib find module
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
__________________________
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
