geoLibro.org

Getting back to this GeoNetwork business. We’re moving along at a decent clip given who we are and the fact that my GA is .5, student worker is .25 time, and I’m 1.89 time with 1.8 going to other projects. So this entry starts with work we did near the end of the summer and will be limited to the method we’re using to inject pretty severe edits into a checked-out GeoNetwork source in a way that will make at as easy as possible to maintain our live edits along with the checked-out GeoNetwork. The next entry will get into the edit of the default home page itself — later will come the search results, the addition of elements like OpenLayers or the styling of full metadata pulled in by ajax, etc. — but this one will explain away some strange things you would see if you checked out our version today.

Starting out I knew that if we made any progress at all there would come a time when the real GeoNetwork is updated and we would want to fold our changes right into the improved version. In an attempt to ease this process, one decision made right away was to alternatize the stuff we changed. And since that really isn’t a word, I’ll explain:

Most of the changes to the home page happen in file “main-page.xsl,” which gets called by the main.home service (defined in config.xml). I’ll get into the changes to this file below, but let’s jump ahead to us having a (severely) altered “main-page.xsl.” In order to not have to keep original copies around and start changing filenames in order to safely roll back to native GeoNetwork, I saved a copy of main-page.xsl with a pseudo extension that could be used to mark all of the files we change (or add). So “main-page.xsl” becomes “main-page_pugo.xsl,” and in fact this pseudoextension will be the norm for changes the rest of the way out. So we do two things; add “pugo” pseudoextension to the file to make an obvious copy and simultaneously mark edits inside of the files with “pugo” comments. For those files in GN whose file name could not be changed, it was obviously especially important for us to mark our edits with “pugo” comments. Worse comes to worse we can do searches for “pugo” to locate all of our edits, elisions, and additions.

So to begin live-editing and testing main-page.xsl we make a copy and name it “main-page_pugo.xsl.” Then to make GN actually use this file we need to configure the main.home service to load ours instead of the native. In config.xml, then, we change that service’s block from

to

This results in two distinct benefits. 1) we avoid having to diff twenty files (or more) every time the main GeoNetwork is updated, and 2) we can easily swap out our altered GeoNetwork with the native, allowing us to test how things are supposed to work and how they are (or more likely are not) working in ours. What it also means, however, is that any time we change a file to add a “_pugo” pseudoextension to a file, we need to be damned sure that all of the files that call the original now call our new copy. This is tedious one time for each file, but will save us a lot of heartache in the future. Get a text editor with file search or use Spotlight or something similar if you want it to be easy to find all files that call a given file. If you always make copies of files you edit (when possible) and point all files that use that file to your new copy, you end up with a cascading effect which is perfect — to turn on “our” GeoNetwork with all of the _pugo versions of files working together, we use config.xml as described above. To remove practically every change we make and run GeoNetwork natively, we remove the pseudoextension “_pugo” from the config.xml block quoted above, and everything is instantly back to normal.

…Not a thrilling entry, but so far this method is serving us very well. In the next entry we start really slicing up that home page, so don’t give up.

As we pound on GeoNetwork in order to make it a little more usable and presentable, we’ve had a couple of opportunities to see how well data viewers can inegrate with metadata search results. Primarily this means we’re including an OpenLayers instance that will automatically render either the data or the spatial footprint of a given search hit. Not a huge deal, this. A bigger deal is that we started toying with the idea of including an alternative globe render of search results. Google Earth was automatically disqualified because the embedded version is Windows-only (who does that in 2008?). So then we look at WorldWind Java and think…”why not?” Well, one reason “why not” is that I don’t know doink about java, so it became a special project for a grad asst.

And as we wait for a 0.6.0 release of WWj that purportedly has native CSW support (so it can be a stand-alone client for the catalog), my GA has gotten pretty far so far, able to get external page controls to act on an embedded WWj globe. I’ll post about this again when we’re further along (it will be part of my GeoNetwork series), but for now here are two rendered wms layers in an embedded WWj:

So GeoNetwork (GN here) is an open source java project. The open source part is great, of course, but the java? Well that’s…a problem. For me, anyway, given that java sits atop a huge, rich list of programming languages I know nothing about. This is nothing to be ashamed of if you’re a librarian, but it can be a problem if you’re the kind of librarian that complains, complains, complains about how most GIS web apps are practically cro-magnon (that’s right — they’re cro-magnon web apps). Why? Because ArcIMS made it easy to get something up. And once something was up, everybody quit trying, having fulfilled their county assessor’s office’s commitment to information transparency or whatever. The point is that these apps were clearly built by GIS people and whoever wanted them to be easy to use or (gasp!) attractive could go ahead and screw.

Then Google Maps proved that map interfaces didn’t have to be slow, cumbersome, lumbering gear-turners. Asynchronous calls to server side mechanisms meant you didn’t have to wait ten seconds every time you moved around, support for more common formats meant it was easier to get stuff on the map. Etcetera, right? You don’t need me to document the goodness of Google Maps.

capture from fao.org’s implementation

Tragically, GeoNetwork’s great back end is almost entirely obscured by the 1.0-looking front end. Which is suprising, because the front end is built with some modular, ajaxy pieces that are usually praised when put into practice. To wit, here’s a simplified outline of a pretty standard request-response procedure using out-of-the-box GeoNetwork:

It’s in this results file where we have spent most of our time chopping here, trimming there, wildly flailing sharp things everywhere else. And it’s in there that the next post (first of several that will document the changes we’re playing with) will start.

So there is a remarkable dearth of documentation for geospatial datasets on my campus. A number of different researchers, labs, and other agencies are consuming and producing geospatial data from within their own insulated pockets of campus. Not very many are then doing anything clever or coordinated that would make those data discoverable and therefore usable by other groups on campus or, better still, the world.

The reason, naturally, is that it’s hard. PIs of these projects build machinery to help themselves first and foremost, secondarily fit the parameters of the project, provide ample fodder for publication and further research, and then somewhere down the line might think about how their stuff can be made more easily available to the world. Typically they mount some web-facing app and that’s that. Find it if you can.

So we started a project over the summer to build a utility that can be one portal to geodata for and from campus labs and researchers. It will be a catalog, of sorts, but has potential built into it to be a much more agile and robust machine than a lot of libraries put up. It’s built on the open source GeoNetwork platform, but almost all of our work so far has been devoted to making GN more usable, more accessible in the ways web apps need to be these days.

Let this post stand as an intro to a series of posts that will describe and document what we’ve done and what we’re doing with GN. None of us (it’s me, on of my GAs, and one student worker) are java developers. None of us are developers at all, in fact, but the students are game and we’ve been able to wrestle GN into submission on a number of aspects that might be of interest to others. Minimally, this series can be rolled into the articles we write following a hopefully-successful deployment.

So the next post will discuss some basics about GN and its architecture (not all of which I understand). There are some aspects of how it’s built that are especially attractive to a dumb, clumsy librarian and I intend to start with those. The posts that follow will be devoted to the incisions and clubbings we dealt that platform in an effort to get it to where we wanted it.