This page last changed on Mar 14, 2008 by cholmes.

This project is to make a new module in GeoServer to allow users to upload a csv file through the web that contains California zip codes, and then have them automatically joined with the zip code geometries and be available for thematic styling and then 'published' on to Google Maps.

Tasks:

Creation of new, custom module in GeoServer. This will be specifically geared towards this use case, many things can be hardcoded, and potentially made more general later, if there's additional time in this round, or additional funding in the future.

The module can be coded against PostGIS directly. It can include a sql dump file that users must install, and the module can assume that the structure of the data is exactly as in the dump. The file/table should contain the geometries of the zip codes for the state of california.

The main function of the module is to enable the upload of a CSV file that gets turned in to a map, joining to geometries on the zip code. We can dictate to users exactly how this csv file should be structured, though having flexibility on what we can handle and good error reporting would be good. A REST end point should be provided to enable the upload of a csv file that will be automatically turned in to a featureType in GeoServer that can be styled, with the proper bounds set (initially can hard code the bounds for california, if there is time can compute bounds based on the zip codes that got joined). Should work how the shapefile upload works, but can be to a special module end point.

After upload the file should be transformed in to a PostGIS table. The end goal is a table or view that contains the zip code geometries joined with the zip code in the csv file, plus all the other columns and rows in the csv file. And we may want some default fields to be in each featureType as well. I believe registering a view that's a join of a newly uploaded csv file with the shapes should be fine. Each csv file can be its own table. We don't need to cover an editing use case, so it should be fine from that requirement. I believe it'd also be fine to replicate the geometry information, but that would be less efficient storage.

I believe we want the featureType to be published right away, at least from the geoserver perspective. At that point the UI will take the user to the map and let them do thematic mapping, like uDig does. The ominiverde guys have made decent progress on this, at http://www.ominiverdi.org/openlayers/OWSManager/examples/ows_manager_stile.html# So the other geoserver piece will be reviewing the code Kappu wrote and getting it in better shape. It can still live in a community module, but it'd be good to have it a lot more solid. I believe through that module they can edit the SLD directly, with REST calls. From the user perspective, once a user gets things looking as they want they should be able to hit some sort of 'publish' thing and get like a javascript window they can put somewhere. When they hit 'publish' we should stick their layer behind GeoWebcache, and we might consider giving some mechanism for them to start it seeding on 'publish'. But I feel like it also might be fast enough rendering that pre-seedings not required.

So that's the requirements. Things that would be nice to have / think about:

  • Have zip codes for the entire US, and then on upload only the zips that are actually in the csv file get registered in the view. The key will be to have the map bounds of the featureType set for just the present geoms
  • Make generic for not just zip codes, but for any geometry - would just supply a config param for the name of the geometry column to join against.
  • Further down the road: work against other backends, do joins purely in geotools, ect.

Data

We have zip codes and zip plus fours for the US, I think tiger 2006 as postgis dumps: http://geo.openplans.org/tiger/ Supposedly this month the latest tiger will come out as shapefiles. Can also just start with downloading an older shapefile for california. Just turn whatever in to a postgis dump file.

Front end:

The main task of the front end is to port the ominiverde stuff to Ext.js, and to add some better workflow, to allow the user to select the csv file to upload and to take them from there straight to the map that they can edit. I have a suspicion they'll also want to be able to make multiple maps from the same data set, which would just involve saving an SLD for each 'map'. I think we should deliver the basic functionality of upload csv and style as a map and 'publish', and then perhaps solicit feedback.

Document generated by Confluence on May 14, 2014 23:00