geoLibro.org

So last time it was on and on about how we’re trying to live-edit a GeoNetwork checkout by essentially creating a parallel copy of it right next to the original code. I used the word “alternatize,” which isn’t a word really, to describe how, for any file we add to or edit in GeoNetwork, we add a pseudo extension like “_pugo” to mark that it’s been touched by grubby hands. This works well, but you have to be sure that all files that point to your new file know that its name has been changed (and this is upwardly-cascading, of course), so that if you edit a file to point to your new “_pugo” version of something, you then have to edit that file by adding “_pugo,” which means you must make sure all files that point to or include that file are altered and so on and so on. It makes much more sense when you have files in front of you and I don’t want to beat this horse any more than I have already. Do it differently or better or not at all if you want. We don’t have any real genius to be telling you how to keep your shit together.

Anyway, it was all a big bore and there are only a few people reading this series anyway. But those that do AND are interested in GeoNetwork might like this one better — it’s brush-clearing day in the GN user interface. The first problem I ever had with GeoNetwork was its cluttered, complicated, 1.0-esque UI. It’s surprising, too, because it has some cool shit going on (geoRSS, ajax pulls of metadata results, dynamic mapping of data attached to found records). You can see slightly customized versions at fao.org or unocha.org. Both are good examples of how GeoNetwork is quite powerful out of the box, really, but also how it appears to not be in tune with how usability and web design has gone in recent years (no offense, I hope). And if you’re thinking “aw, don’t be a prick — it’s FOSS4G,” I dare you to click the “Advanced Search” form option. In fact I’ll give you 20m to try and fill out that form.

Lest you still think I’m being hard on this project, remember what my own profession thought was acceptable for the last fifteen years (and in many places still to this day). Exhibits A and B. And for obvious reasons that constitute a pretty good excuse — when those 20 minutes of form-filling are up you’ve constructed a very powerful and accurate search. But there are better ways to do it and that’s one of the primary objectives of this project — to present a sleek, minimalist interface to all these datasets without sacrificing the real power of the system (just hiding it).

So the first thing on my list was to severely cut back the intitial impression of the site, and the first thing to go was the table-based front page layout. It wasn’t that hard, really, I just went in and cut out almost all inputs, form widgets, and intermap stuff. Then in what was left all table elements were replaced with divs or spans and styled with a custom css. This mostly just took trial and error, and it’s still not done. Why? Well it needs to be cleaned up for good, for one thing (some stuff didn’t get axed because I couldn’t tell what it was doing). But also because that fucking Internet Explorer is doing funky things with div clears and widths. I hate it so much.

Anyway, I know this is sort of a step-through series of how we’re actually doing this stuff, but this main page customization takes virtually no skill — I just kept chopping and styling, chopping and styling until I was left with this (draft):

…which is better than the way it was, in my opinion:

VerySpatial draws attention to something that would make any yuppie-nerd iPhoner with an interest in open source and public participation GIS get hot under the sweater vest: OSMTrack, the iPhone app for OSM contribution.

…Which I may need to look up in the beginning of 2009, as I just heard from an intern who wants to sign onto my mobile community inventory project (and — get this — to volunteer in advance of next semester).

Hm, turns out I do have something in common with Britney Spears. I code like she dances. Quite a while ago I decided to put kaMap in between the user and Mapserver on a bunch of different projects. Why? I like what kaMap purports to do and of all the options (OpenLayers, [shudder] ArcIMS, etc.) it made the most sense to me. But the problem is that I’m a librarian, so coding is not really my forté.

…Which I suppose is like saying parenting or singing or career management is not the forté of Spears. If Spears:child->Me:code, then we share the same disinterest in our children. I guess it would follow, too, that if I were a smoker I would smoke in the face of my code as she did her hers.

But with great help from my two grad assistants, the thing is coming along enough that we’re building dynamic layers from data in at least two separate postgres servers located in completely different places. Does that count as geoinformatics? Let’s say yes. Anyway, I have a decent-looking interface, but more importantly we’ve been able to work around strange problems with MapScript in kaMap to alter pretty much anything we want on the fly. Querying has been more of a problem, but we have workarounds for that, too. Rough ones (involving a near-invisible index layer used to then re-query PostGIS to get the values from the real feature classes), but we are able to query on PostGIS layers, present results, and launch little overlay layers (xmlOverlay) that identify, by click, individual geometries pulled by the query. I’m clinically stupid when it comes to coding and development, but even I recognize how important having access to the source code for this stuff really is, and even I was able to get in and fix some stuff.

So thanks, people who developed kaMap, we’re going to stick with it.

I ran across a 2005 post to gdal-dev today that blew my mind a little:GDAL, the big-name raster translator library, is supposed to be pronounced “goodle,” according to its developer, Frank Warmerdam. So you “jeedles” and us “jeedolls” need to straighten up and fly right.

Nowhere else is there an indication of support for PostgreSQL as the real back end of ArcSDE (except for the perpetual conversations taking place in ESRI forums), but…doesn’t this suggest that it might be in the works? Am I stupid for thinking such things?

This is going to work out fine, yes. I’ve been toying with the notion that the open source ka-Map might just be smooth enough (built on top of MapServer‘s robust enough) to handle some of the web mapping projects we have coming up. ka-Map is a javascript and php-built front end that takes MapServer’s output and tiles it, precaches it, then renders it within any number of web environments, a number of which come pre-built with the source. Think Google Maps to MapServer’s ArcIMS. So after a couple of false starts, one of which was due to a mysterious incompatibility somewhere within the string of libraries required to run it on OS X (it set up with no problem on Ubuntu and one of the grad assistants got it set up on Windows with a little text editing), everything fell into place this past weekend. Now in just a couple of days I have map attributes (shapefile) query and search running, have those queries then throwing out to some other database.

…And back! What’s the point? Well, Google recently attached map searches to their Book Search results. MetaCarta has been leading the pack on the same thing. What we have going here is something a little like that, but without the great power of the former and the awesome natural language processing of the latter. Specifically, we’re supposed to have an old soil survey of Tippecanoe County, IN scanned, its map scanned and rectified and, in fact, digitized, and ka-Map is going to allow us to run searches back and forth between the text of the survey and the data layers extracted from the map. In our minds it will be a great combination of library work and GIS and ka-Map is getting us closer every couple of weeks.

Roughly two weeks ago, I mentioned a workshop on GIS for librarians. Well, I went after all, with the slightly hidden agenda of seeing who in the state was interested in GIS for a library, why they were interested, and possibly hearing about ongoing or planned projects. First of all, it wasn’t taught by an architect after all. The instructor had almost 30 years of GIS under his belt and who happened to work for a firm whose several services include architecture.

Anyway, what was most useful was hearing the questions existing librarians had about why GIS should even be in a library, what would it cost, etc. Also interesting was witnessing confusion about that murky place between these datasets everybody talks about and the map products themselves. In other words, for most attendees it was easy to see conceptually how geographic information can be useful and how it might even belong in a library, but very difficult for them to imagine how that information gets put onto a computer screen in any useful, intuitive format.

Our instructor didn’t help out much in that respect, as his was pretty clearly a general “What-is-GIS?” presentation he just happened to be showing to a roomful of librarians. In other words, very little was said about how librarians might play a part in metadata creation, storage, or development and very little was said about how a library might go about employing and applying GIS for themselves or for patrons. And almost nothing was done to illustrate the real, physical connection between something called “data” and that rich, graphical, colorful visualized version thereof.

And one more thing. If you were talking up GIS to a bunch of nonprofit types and they almost literally gasped at the price of the ESRI products, wouldn’t you also mention that there are several easy to use, free (open source, most likely) software titles that might do what they  need? Not everybody would.

From Bull’s rambles: More NASA World Wind based GIS software…

I haven’t tried Dapple yet (would have to drag the old Toshiba out of whatever box it got put into), but I wanted to register the news. I’m especially excited to see that WorldWind isn’t being forgotten about. I always did like it better than Google Earth in most respects, but I fear that it’s just not developing fast enough.

Anyway, James Fee has posted a quick review of it which might help evaluate it (except he seems to think people will be “scared off from the non-Windows appearance that it gives off,” which is either testament to how well the NASA guys designed the WorldWind GUI [is that a magnified dock hanging from the title bar?] or how self-restrictive Windows adherents are).

And speaking of GIS on a Mac: Quantum GIS (qGIS) 0.8 Preview 1 is out. I haven’t done much with it yet. It crashed when I loaded a local shapefile, but it worked fine loading GRASS vector data (from Spearfish, loaded from within a GRASS session). It’s pre-1.0 and a preview at that, but go get it and beat it up a little. It’s the only way to make it better, and it’s still probably the best candidate for point/click GIS on a Mac system (uh, one that’s not running Windows, I mean).