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.
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:
User loads default interface, probably at http://host:port/geonetwork/srv/main.home.
Shit starts to go down fast. The main.home service calls a bunch of xml and xsl files that together constitute the default page. Each element on this front page is a contribution from a different template out of xsl (the banner is created by banner.xsl, the header by header.xsl, etc.), so already it’s sort of easy to start busting up or removing pieces that offend your delicate sensibilities. You write a little or kill a little xsl and suddenly you’re “developing” GeoNetwork (of course not really, but a little gui tweaking goes a long way for some of us)
User draws a bounding box on the map for their area, fires off a search
Well there’s trouble already. The input map is a comically small Intermap embed, meaning it’s a little old school. But beware, if you choose “Advanced Search” as a means to present yourself with a little bit more space to make your choices, you’re going to be flooded with options and widgets and buttons and other garbage (flooded with a nifty ajax page element replacement, but flooded nonetheless). It’s almost as if it was built by the same genius that designed your basic Voyager-powered library opac (
here’s an example of a classic look,
here’s another — quite an orgy if you’re into filling out forms and reading about query syntax for ten minutes before you actually do any searching)
GN uses Lucene to index its contents and in fact throws bbox and keyword queries right up against its Lucene index. I don’t know enough about Lucene to understand how it’s doing this minor spatial query, but have charged one of my student workers to find out for me (I’m a mean boss).
GN supports several metadata schema
…Including fgdc, iso 19115, 19139, and dublin core. Search results from a query into metadata in these different schema are then normalized with schema-specific stylesheets so it can all be returned to a search-results_xhtml.xsl in a denominated format for rendering to the browser.
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.
November 5th, 2008 at 8:27 pm
I’m curious where things stand now with GeoNetwork.
I’m a student and Java developer working on a metadata catalog project that is looking at using GeoNetwork as a possible alternative to ESRI’s GeoPortal, and if we choose to use it I intend make some major overhauls in terms of atleast usability, form validation, and the map viewer (I agree, Google Maps is the way to go).
November 5th, 2008 at 10:50 pm
Matt, you’ve shamed me into not putting off the next entry any longer (I’ve been holding onto it because it’s a little boring). Part 3 is going up right after I finish this reply. Note that despite my praise for how Google Maps has changed things, we’re barreling forward with OpenLayers and so far we’re really happy with it. More on OpenLayers integration will come in maybe Part 4 or 5.
I (and I’m sure the entire GeoNetwork community) would really love to hear about any progress you make, so please let me know how it goes.