Hi Phil: On 2012-10-02 14:51-0700 phil rosenberg wrote:
> Hi All > I just downloaded shapelib and it builds with no difficulties at all on Windows. It seems to be written in "pure" C so it is just a case of compiling and linking the files - no build system is necessary as such. In less than an hour I had built the library and written a 10 line chunk of code to read in in file. In this sense then it would be easy to make use of. Excellent news. > However I still have some Windows pejudices. It's not at all clear to me how CMake could find out if I have shapelib or not automatically or even what the library is called (I just created shapelibsd.lib and shapelibs.lib s for static, d for debug). Creating a Find module to help find any library is pretty trivial under CMake. So it should not be a problem for me to add this capability to our build system (just like we have done for our core library for its _optional_ dependencies and also many other libraries that our specialized but optional devices need). > > It's always worth remembering that not everyone is an expert and for a long > time after starting using C++. I found compiling PLplot for the first time > (some years ago) a challenge and the more complexity we add the more we might > put off potential users (especially on Windows) > > There have been quite a few options thrown into the mix, so I thought I might > sumarise things a bit to focus the thoughts. Here are as many options as I > could come up with based on the discussions so far and my own random > thoughts. Maybe it would be useful to discard any of these that people feel > are terrible or add any others that people can think of. > I will express my opinion with No or Yes on each of your options. BTW, you had two options labelled (3) so I have renumbered those and changed your references to what I think you meant in your text below. > 1) We forget about this and leave users to deal with maps however they want. > Probably not the best option otherwise we wouldn't be having this > discussion No, because I think this discussion is going to lead to something useful. :-) > > 2) We leave the PLplot map file format alone but provide some extra maps at > different resolutions. > Better than now, with little work needed, but the integer format used > in the files limits resolution. Yes to continuing with the old PLplot map file format for now, but it should be strongly deprecated in favour of a better approach, meaning (in part) add no further extra maps and plan to completely delete a few release cycles down the road. > > 3) Do either 1) or 2) but also provide an interface for loading a standard > file format (presumably shapefiles via shapelib?). > Also Better than now and useful for those who wish to use GIS data, > but adds an extra dependancy. One possible hazard is that shapefiles can be > up to 2 GB and I think the whole file must be read even if we want to plot > over a limited lat/lon. Yes, please! It would probably be a good idea to include in the API the ability to limit the input map file to a user-supplied latitude and longitude range, but that is all I would do for now. So for large files there might be some noticable read time with this approach, but the result that is handled in PLplot after that will be reasonably small. In any case, I don't think you should be too concerned with large map efficiency issues. After all, presumbably there are plenty of small map files to deal with low resolution needs, and for high resolution needs the user has the choice to use some external tool to convert a large high-resolution map file into something smaller with more limited range or else use the internal PLplot range selection (see above). > > 4) We update the PLplot file format (adding a full description to the docs) > perhaps including some extra maps, but giving users the ability to generate > their own maps if neeeded. > This could be this simplest upgrade option. It will give us high > resolution with limited work. We can taylor the format to our needs e.g. so > that data is in blocks and only blocks in the xmin-xmax, ymin-ymax are read > for increased speed. No to updating the PLplot map file format. I think we really should go with shapelib for now and add the hdal/ogr libraries later rather than doing anything with our own map file format. > > 5) Do 4), but also add an interface for a standard file format. > I guess this is the ultimate solution. But most time intensive. No, see my objection to (4) above. > > 6) Do 4), but also add a utility to covert from a standard file format to the > PLplot format. > Similar to 5, but ensures that any performance advantages > from 4 are enforced, but at the expense of an extra pre PLplot step. > No, see my objection to (4) above. > 7) We replace the PLplot format files currently used with a standardised file > format. > Lots of flexibility from the user side, but makes shapelib a > requirement for PLplot. Also the hazard of 3 applies. Yes, eventually. But for now see my answer to (2) and (3). 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 __________________________ ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
