Sorry for the duplicate message - I didn't use the proper From address for the mailing list in my previous send.
On Tue, Oct 2, 2012 at 7:41 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> w= rote: > Hi Phil: > > On 2012-10-02 14:51-0700 phil rosenberg wrote: > >> Hi All >> >> 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. > I've used PLplot to plot a lot of data on maps, including mixing data from shapefiles and other sources. Based on my experience I think we may be going off in the wrong direction here. >> 1) We forget about this and leave users to deal with maps however they w= ant. >> Probably not the best option otherwise we wouldn't be having thi= s discussion > > No, because I think this discussion is going to lead to something > useful. :-) > I actually like this idea! With some embellishment, but I think it is closest to the right approach. PLplot is not a GIS platform and it probably should not strive to be. It would be nice, though, to have an easy and documented way to take advantage of PLplot for mapping/GIS purposes. With a few support functions I think we could provide a convenient interface for users without restricting PLplot to particular libraries or file formats. plline and plfill give us polygons. plstring gives us points. plstransform gives us global, consistent coordinate transformation support. So PLplot has the rendering components needed for basic mapping. A plpolygon function could be added to PLplot for convenience. plpolygon would render multiple closed, filled or unfilled polygons. This is useful for filled continents/oceans/lakes, geographic outlines and similar tasks which require multiple polygons to be rendered in the same way. Given those functions and an (external, untethered!) library such as shapelib to ingest data you have what you need to easily render a map. We could provide examples of how to do this with shapelib for geographic outlines, GDAL for some raster data plotted with plshades or plimage, and perhaps a few other libraries. I'm not convinced that going further than that provides a benefit. >> >> 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. > Along the lines of my extensions to (1) above, why not provide the existing map data in a more friendly and verbose format such as CSV? An example or core PLplot function could be added to load this simple data format along with the shapelib and other examples. This allows us to continue to have very simple geographic outlines working "out of the box". Some "good enough" low resolution data available without external dependencies is better than none. >> >> 3) Do either 1) or 2) but also provide an interface for loading a standa= rd file format (presumably shapefiles via shapelib?). >> Also Better than now and useful for those who wish to use GIS da= ta, but adds an extra dependancy. One possible hazard is that shapefiles ca= n 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). > I think this is getting out of scope for PLplot. Providing examples illustrating how to mix various support libraries with PLplot is a better way to start. If the steps required to get from [insert external common data source here] to a format usable by PLplot are onerous then some convenience loading/conversion functions could be written, but the result may end up being as complex as using the upstream library directly. Hez ------------------------------------------------------------------------------ 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
