From: Phil R. <phi...@ya...> - 2014-05-28 16:18:37
|
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" <ir...@be...> Sent: 27/05/2014 21:47 To: "Phil Rosenberg" <phi...@ya...> Cc: "Andrew Ross" <and...@us...>; "PLplot development list" <Plp...@li...> 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 __________________________ |