OSB data in simple text format

I merged and tweaked a couple of example programs from the open source "shapelib" project for reading ESRI shape files, and Anthony ran the program over the OSB data to produce the text file in
http://www.cs.uoregon.edu/classes/08F/cis422/data/OSBShpExtract.txt

This is not in xml, but it's a very simple format that can be parsed with either a scripting language like Python, Perl, or Awk, or with Java's "tokenize" method --- each line can be identified by the first token on the line, and the important fields (x and y coordinates of points, in particular) are separated by blanks.

Of course no one is obligated to do anything with this data at such a late date, but there it is if you want to take a shot at it. Later (probably during holiday break) I'll see about making a version of the extractor program that produces XML in a form close enough to the campus map XML input files to "fool" the data readers you have produced.

Data, again

Many thanks to Daniel, who apparently knows the magical incantations necessary to transform ESRI shapefile data into XML files. If you look in
http://www.cs.uoregon.edu/classes/08F/cis422/data/OSBxml/
you will find the full collection as osb_gis_xml.tar.zip or you can look in the osb_gis_xml directory to get individual xml files.

It's very late, and I understand if you are not able to incorporate this into your project before the deadline. On the other hand, it would be great if at least some of you could do so, or at least give it a try and document what problems need to be solved to make it work.

Update: I've looked through the XML data and I'm not so sure we're making progress. As near as I can tell, what we have is "PolygonB" objects that are represented as byte arrays (and I don't know how to interpret those byte arrays). It seems that "PolygonN" objects have a field called "Rings", which are arrays of (x,y) coordinate pairs, and that's what we were expecting. I don't know how to turn "PolygonB" objects into "PolygonN" objects. Maybe someone does?

OSB data? Please have a look

I have an XML file from Amy. It's one big XML file, rather than a file per layer, but maybe that's not a problem (??). As I eyeball it, though, it seems to me like the shapes are defined in a different way than in the campus map XML files ... it looks like there is a sort of hex encoding of sequences of coordinates, instead of XML-ish encoding of each coordinate pair. So, my best guess is that this will not work with the "generalized" input modules that you have worked on. But please give it a try, and let me know what you discover. Is there some obvious way to transform this XML into something we can deal with?

I also have the raw ESRI shapefile data, if anyone knows the ArcGIS program well enough to manage the XML export from that. (I don't, but I am beginning to see that it's something I had better learn.)

The XML file is at: http://www.cs.uoregon.edu/classes/08F/cis422/data/OSBdata.xml

OSB data new ETA - next week

I got word from Amy that there were some problems getting the OSB data into the geographic database. The problems have been worked out, but the new projected time to get the data is next week. That's awfully late in the (first half) project, and I worry that you won't have time to deal with whatever surprises turn up when you're working with a new data set (and I can almost guarantee there will be some surprises, though I don't know what they will be).

On the positive side, this is a realistic experience ... dealing with some external dependence that was not resolved as planned happens all the time.

So how do we cope with it? Here are my thoughts:

• It's worth at least taking a shot at handling the OSB data when we get it ... but I won't be surprised if the result of that is identifying some problems rather than solving them. Identifying problems is progress.
  
• I've asked Amy if we can get some different GIS data, possibly from downtown Eugene, so that we can have some kind of test of the ways you are generalizing the input handling.
  
• If all we can do is test the generalized input processing on the existing input data ... it's not what I hoped for by the midterm, but it's better than nothing.
  

So we go forward as best we can.

Field trip?

Bob Disher, technology specialist at Oregon School for the Blind, asked if we would like to visit as a group. I think that could be an excellent thing to do, but I have a lot of questions about how and when to do so, and of course I will need to know how interested CIS 422/522 students are in such a field trip. And of course there are the practical issues of transportation and paying for it (e.g., if we rent one or more vans for a field trip).

Regarding scheduling, I can think of three plausible times to go:

• As soon as possible
• Mid-term, when we have initial prototypes to show off, so we can solicit feedback and ideas
• At or near the end of the term, when we have more to show off (but feedback and ideas are more for future developers)

My initial thought is that (a) trying to go right away is probably hopeless ... the earliest we could organize it is mid term and (b) a term is so short that we would probably get most out of it at the end, perhaps Monday or Wednesday of dead week. Those are just initial thoughts, though ... let's talk about it a bit in class Monday.

Notes from OSB visit, 3 Oct 2008

I accompanied Prof. Amy Lobben to Oregon School for the Blind (OSB) in Salem Friday, along with a geography student who is gathering raw data for the OSB map using a GPS unit. We met primarily with Bob Disher, Technology Specialist at OSB. Here are a few notes on that visit and what I learned.

The OSB campus is smaller than University of Oregon campus, and the map will be quite a bit simpler, with fewer layers (classes of object). Objects to be included in the map include at least the following:

• Buildings
• Some rooms within buildings
  
  • Auditorium, media center, main office, infirmary, dining hall
• Some main doors to outside
• Parking lot
• Sidewalks
• Campfire pit (a meeting place)
• Sensory garden (as a single object)
• Major features of the immediately surrounding area
  
  • Cross streets
  • Intersections

An interesting issue that came up, and one that has not been considered in our soundscape map work to date, is representing attributes like incline (slope) and the width of sidewalks. I'll make a separate post about that.

In discussions about longer term trajectory for the project, Bob asked about producing maps from data that is not in a geographic information system, e.g., from a plan of a building that is in terms of relative positions but not referenced to lattitude and longitude. This seems conceptually straightforward (it really shouldn't matter to us whether the coordinate system is degrees or feet, or where the origin is), but it does suggest that our earlier discussion about not tying our input data format too tightly to a fixed GIS data source is in fact relevant.

In a separate discussion with Amy, on the way to Salem, I asked whether we should be considering GIS systems other than those of ESRI (the company that makes ArcGIS). Amy said that, while GIS systems sometimes do provide some limited interoperability by reading other data formats, in practice ESRI dominates the field so strongly that supporting ESRI formats is enough for handing pretty much all GIS data we are likely to encounter.

The meeting was quite loosely structured, and in addition to needs for the current project, we discussed the way the project has evolved and the way it involves students. Bob Disher extended an invitation for us to visit OSB as a group. I'll write a separate post to discuss that possibility.