March 23, 2007
Another day, another version... yes, version 0.4 of the visual browser is up and running (http://localhost/visbrow/v1/map_explorer4.php). In this version when you press the button, you will be presented with a link to download the data for all the returning shapefiles into a single KML file. Then, the first shape file title is presented, below it is a link to download just that shape file's data in a KML file (named with the name of the shape file), and then the name of each of the data points is listed with a centroid (new feature in of itself). We then continue on to the next shape file and so on.
The next step is to implement the web data dictionary so we can integrate it as well and then, when we get it, integrate GeoServer (which works on the slow machine).
March 22, 2007
Getting stuff into Google Earth
I spent this morning working on a little script that will take a bounding box and list of shape files and then plop all the data into a file called Visbrow.kml ready for download. Each shape file has its own folder within the KML and all the shapefile data is put into the description field for each individual item.
The handy little script is here: localhost/visbrow/v1/2kml.php
An example URL would be this: localhost/visbrow/v1/2kml.php?shapes=historic_point,parcels&bounds=-83.057637,42.333508,-83.044763,42.3420922 which would get you a kml file with all the parcel and historic_point shape file data (each in their own folder) for that bounding box. But, once again, you have to be logged in as Jen and run the XAMPP webserver to use it. When is our live machine going to be available??
Current plan of attack:
- Integrate the 2kml into the visbrowser so users can download stuff with a button click
- build web version of the data dictionary
- integrate web data dictionary with visual browser so users can select desired fields for download into their kml file. Come to think of it, I could even let them name the kml file.
March 19, 2007
How do we identify a draft? Should we not be keeping psd, ai, and other files? How do we know if these are drafts? How do we define finished products? How do we know when a psd document is an image that exists elsewhere or just a half-baked project?
Let's all take a big, deep breath as we remind ourselves of our appraisal criteria.
We want things that can go into the visual browser. This means images, charette presentations or publications, and technical notes.
Which brings us to my:
Questionable Content List
documents leading to research materials
camera manuals (wtf)
.apr (ArcView Project File) files
I'm going to go think about these. I'll be back at five.
ETA: It's five and I'm still not sure about these. My instinct (and this is very un-archival.. no-no) is to convert all psd documents into jpgs, trash the psds and be done with it. But is there content in the layer data that would be useful? Even if there is, how could that possibly utilized in the visual browser?
For documentation's sake, here's the plan:
I will create a *very* truncated finding aid that will list, on the folder level (with some description where necessary) what we have.
Whatever is discarded will be moved to a "discard" folder within the parent folder before being tossed.
March 15, 2007
First, a few links. A blog entry about archiving GIS databases, which is not what we're doing but worth thinking about as we move forward. I know nothing about the authority of this blog, other than that this is an interesting entry.
Here are some resources about GIS and Geospatial Data Preservation, from the same blog.
Strictly speaking (and okay, I haven't had a chance to look at the data yet) we're not dealing with GIS databases so most of this information is less useful for our current task. We're taking the scribblings and half-baked documents from a few design workshops and trying to figure out what will be salvageable to put into our visual browser.
There may be so little data that we can feel free to hand-appraise this, but I'm not sure. We're talking about years of workshops, and I have absolutely no trust in the creators' record-keeping systems. Their conventions may not be useful and may not be followed thuroughly. We also need to think about how useful some of this will be. Do we want photos if they aren't geo-tagged? What do we do with previous design ideas and how do we categorize them?
::Timewarp:: It's now 4:16 and I'm looking at the Charette data. Jen and I have made a list of what we do and don't want, as we go through and appraise this data.
We DO want:
Site photos (even if not geotagged)
Anything produced by the charette (CAD, drawings, presentations, final productions [charette books], et al.)*
Administrative documents (Doug Kelbaugh or Eric Duweuke or past coordinators)
We DON'T want:
Census data, unless modified
Drafts of documents
This list is subject to change!
*a side note -- geotagging presentations would probably come in version 2.0, and would be represented by a polygon encompassing the scope of the presentation.
More to come this weekend as I flesh out the appraisal plan and start junking material.
March 08, 2007
We can now successfully query a database and return the data to the map viewer page without refreshing the page! The current prototype, found here, requires you to be logged on as Jen so you can run the XAMPP webserver and query the database. If you click the “Submit Query” button the form will submit a request to a php script called shapelister.php which will then process the bounding box, query the database, and then return the resulting database rows. The prototype is currently checking against a copy of the historic_point shape file. So, click the button, and all the historic points that exist within the bounds of the viewer will be returned with their name and longitude, latitude coordinates.
The next step is to load the data from our shape files into a new table listing all of our geometries and their respective shape file. Once GeoServer is running we could also return the data as layers to display in the viewer and provide links to download the datasets as KMLs.