This post is about living up to the User-friendly part, for the last week or so I have been helping a user place a 400 meter buffer around some points and road networks and generate a PDF.
How hard can that be?
- The point data was found in a Microsoft access database...
Final solution was to export from Access to CSV and use gdal to convert that to a shapefile and load the shapefile into uDig.
- The projection is kind of lost to the mists of time...
This is actually a very common occurrence - those who collected the data knew what they were measuring, but for us that come later it results in no end of fun.
Final solution was to guess based on some shapefiles and adjust the CRS settings until it lined up.
- Placing a buffer around the points was done by using the Reshape operation to generate a new set of features. While figuring out the buffer( the_geom, 400 ) syntax was not too bad it took a little bit of work (and checking the CRS) to see that the data was measured in meters.
- Exporting to a PDF can be done...
But the functionality is hidden as part of the Export Image wizard (PDF is one of the options just like PNG)
- CSV happens; I should stop treating it as a toy example for developers and build it into the application
- Showing a the raw WKT definition of a CoordinateReferenceSystem is actually useful; and allowing users to edit it even more so.
- Stay visual: The reshape operation just generated a new scratch layer and adds it to the catalog. Not so good - and hard to tell if anything was actually done ... so When the user is working on the Map, they expect the results on the Map,
- PDF really needs its own wizard.
So how (with all of that) can uDig be considered friendly? Well the documentation was updated as we went through the problem; and the developers were on the #udig IRC channel to answer questions.
Documentation harmed in the making of this post:
- Processing the Geometry in a Shapefile (now with a buffer example)
- Map to Image Wizard