On 2012-09-28 14:25-0700 phil rosenberg wrote: > Looking again at the wikipedia shapefile page, the format seems pretty easy > to read. The three files that it says are required are the .shp, shx and > .dbf. The .shp is just a file header, then multiple records, each with a > header specifying the record length. This is pretty similar to the format I > suggested and for the point, polygon and polyline types is not much more > difficult to read than the format I suggested. > > Although it is claimed .shx and .dbf files are required, the .shp file could > be parse without them. The .shx file is just an index which would allow > seeking to specified records without reading the whole file to that point > (not really needed if we want to plot whole files as we do now) and the .dbf > provides attributes of the different shapes, but I'm not sure exactly what > attributes or if this file is entirely flexible to the users' needs. > > It wouldn't be too difficult to write a parser for .shp files supporting > point, polygon and polyline types only and include this in the core library. > As Andrew says Plplot isn't GIS software so maybe there is no need for full > support of all shapefile features. Another advantage of using shapefiles is > that only one type of shape should be included per file so representing the > UK we could have the following files: > ukcoastline.shp - polygon > ukborders.shp - polyline > ukcities.shp - points > uklakes - polygon > > And when loading data from each file the current line, fill and point > settings could be used. Maybe this could be for the future though. > > > Any thoughts? I'm busy with family at the mo after the arrival of a new baby > in the household, but a parser should only be a few hundred lines of code so > I might look into this - along with all the other promises I've made to > Plplot :-)
Hi Phil: If/when somebody implements the more general approach Andrew and I have discussed that makes essentially all vector and bitmap map formats accessible via the OGR and GDAL libraries, there will still be some users without access to those libraries that will be grateful for a fallback to the pure shapefile approach. Therefore, I think starting with the shapefile approach is a good idea. That is useful in its own right even in the long term and will give us some valuable experience as a group with some high-resolution map files. But do you really want to re-implement a shapefile parser? The MIT or LGPL dual-licensed shapelib library (see http://shapelib.maptools.org/) does that already and provides an API to read shapefile data from shapefile files. Just out of curiosity about the build system and the platforms that shapelib could be built on, I downloaded that library from http://download.osgeo.org/shapelib/shapelib-1.3.0.tar.gz (released in April this year so it appears shapelib is still under active development). The README in the top-level directory basically says that the build is done with make on Linux and nmake on Windows with very few files involved in the build. So that already looks like you will be able to build it on your Windows platform, but as a matter of convenience (and also something valuable you could donate back to the shapelib project) it would probably be worth your while to update that build system to CMake so that the code can be built out of the box for virtually every Windows platform and Unix platform. The debian packages for the shapelib package (containing shapelib applications) and libshp1 package (containing the shapelib library) shows no external dependencies other than the C library. So that should make for an extremely simple build (as already implied by the above README) which should be easy to generalize with CMake. 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 __________________________ ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
