February 22, 2007
EPSG and WGS and SRIDs, Oh My!
After some pain, sweat, and tears I have learned a lot about projections. For future reference, WGS84 is the projection commonly used for latitude & longitude, which is the same as EPSG:4326. The SRID of which is the same number, whereas the Historic points shape file uses SRID 2253 and NOT 26990 (long story). Fortunately we can use the ArcGIS Toolbox to reproject the data to WGS84 which will save us the headache of identifying each shapefile's SRID. We can now get out shape files to map to the proper projection, and then query across the data points using a bounding box (provided by the map explorer).
It appears that I am going to do some Perl script writting, however, to get all the data into the same place (actually three, but anyway...). As it is, our importer spits out way too much data. To compensate I need to write a Perl script (my kingdom for BASH) to extract the weat from the chaff. Because some of our shapefiles have point data (historic points), others line data (roads), and still others polygons (parcels) we need to store the data in three database tables and query them seperately. I can then take all the results and compile them together. I can make the import data script detect which one it is and select the appropriate table from there.
While you can currently see a version of the map explorer that shows the WKT polygon geometry to query the database against, the live machine has no database to query against. As concequence I set up a Dreamweaver site that uses the XAMPP tool to run a temporary webserver on the Novell machine. This way the php script has access to the database that stores our data for me to run tests against. - The small problem with this is that you need to be logged in as Jen to make it work.
All in all, progress is being made. My next task is working with the temp webserver to see if I can get the php script to effectively query the database.
February 12, 2007
VisBrow - the beginning
At last, it has begun. Most of my time was spent reading docs to start getting my mind wrapped around the problem and the resources available.
I was thinking that a simple process for the app could be:
- Display default map view
- User pan/zoom to site of interest
- click "Get Datasets"
- query database: get all layers that contain points in this geometry
- display list of applicable layers (shp files) to user
- User selects layers & styles
- Presses "Display data"
- Add layers to existing map & display (OpenLayers pulls layers from Geoserver)
- Provide link to download map as ShapeFile, KMZ, pdf, etc.
So far I can:
- load a default map
- Allow user to pan and zoom
- Click â€śGet Datasetsâ€?
- Display the NE and SW (lat, lon) of the mapâ€™s current window. (see http://www.lib.umich.edu/nsds/visbrow/v1/map_explorer2.php)
- Get a running copy of PostgreSQL with PostGIS
- Play with querying the dataset for applicable shape files
February 07, 2007
What to do about TypeCode.xls and UseCode.xls?
In the data dictionary, under Building Permits, we have a data dictionary file called TypeCode.xls that serves as a key to the TYPEBP attribute in the BP