OpenSearch Geo and Time extensions

At WhereCamp we finally sat down and hashed out a Geo-extension to OpenSearch.

If you're not familiar with OpenSearch, the general concept is a simple format for specifying how to query a web resource, and additional metadata in the results to support syndicating these results. What does that mean to you, the developer/user?

If you didn't realize it, the Firefox search bar is powered by OpenSearch. Watch for the area to glow on sites that include an OpenSearch definition. Once it's added you can then quickly search the service directly from Firefox.

Take for example, a popular search engine - let's call it yoogel. yoogel has a simple URL for a query: This will search all of yoogel for 'flumbits'. OpenSearch provides a way to define where that search term goes. Essentially it would look like:{searchTerms}, where {searchTerms} would be replaced by any general string.

Aggregators and applications now have a way to simply define a search service and let a user just type in their terms, but then search N search engines. Of course, there are problem millions of hits for 'flumbits'. So how would I know how to paginate and aggregate these results? OpenSearch lets me do{searchTerms}&page={startPage?}

Ok, so now you know how to request a page. And the question mark, ?, lets me know this is an optional parameter. yoogel won't yell at me if I don't include it. I can know if I need to go to more pages (or how many pages to show my user) by using the nice OpenSearch response elements. These would actually go into the HTML page (or RSS, or other formats) response:


Now I know there were in fact more than 4 million 'flumbits' responses and each page gives me 10 results.

OpenSearch has a lot more functionality and is especially useful when requesting syndication formats such as Atom or RSS.

Now onto the Geo

So that was a little introduction to OpenSearch - just so you could get the gist of the Geo-extensions. You've seen how you can search for 'flumbits', but what if I only want 'flumbits' in my neck of the woods.

OpenSearch Geo extensions let me add that type of search definition. Here is how to specify an optional bounding box search:{searchTerms}&page={startPage?}&bbox={opensearchgeo:box?}

which would actually look like:,42.943,-119.856,43.039

If you're paying attention, you'll notice the bounding box format is: west, south, east, north. That may not seem special (in fact, it's different than what GeoRSS uses - shucks). But what's really cool about that is it's the order already used by a bunch of services you may have heard of such as Flickr, KML Network links (as used by Google Earth).

The OpenSearch Geo extension also includes definitions by: point/distance, polygon, location string (up to each service to do it's own geocoding).

If you want to see them in action, check out the Mapufacture OpenSearch description.

When deciding the format of OpenSearch Geo, the guiding principle was to keep it inline with other emerging, open, geospatial standards such as GeoRSS and GeoJSON. That way, developers and users can learn the concepts and formats in parallel, and then easily switch between them as necessary (they're all mostly just syntaxes and have appropriate uses in the appropriate places).

Your choice of flavors

To illustrate the point of interoperability and formats playing together, let me show you how an OpenSearch description would work for an example site that provided results in a multitude of formats.

Search for geographic items in Mapufacture
geo georss location kml aggregation geosearch

That is almost too easy - in one definition I've specified I can return results in 4 different formats. Internally, it would be easy to write out my results in these formats because again, they're mostly just syntax. (note: of course my text/html would include Microformat geo, though it has a long way to come in handling anything more than point locations)

By the way - it's tempting to think that this could be reduced to a single definition (I had that thought writing out the definition myself) that included a term for "format". However, there isn't a standard way to refer to formats, so that would almost require a dictionary linking MIME-type to format string, and specifying MIME-type in the URL is ugly and prone to errors. Perhaps something for the future.

But it's just 'neogeographers' reinventing the wheel

Yeah, I know - those in the geo-world are asking, "Isn't this like WFS Simple?" (or any number of other geo-search formats).

Yes, it is like them. But different too. For one, OpenSearch already has good market share and implementation (you probably don't realize you're using it often), so it makes sense to add Geospatial capability to it. Also, like GeoRSS-Simple is to GML, it's more readily understandable by non-geospatial experts. This means more use and implementation. And hopefully OpenSearch Geo is kept parallel enough that as developers want more complex capabilities, they'll 'graduate' to more complex formats like WFS.

But I don't have the time

We have your time right here. It's not part of Geo (yeah, yeah, I know about Spacetime and the fact that movement through time and space are indistinguishable), so it is it's own extension, OpenSearch Time extension.

With OpenSearch Time you can specify time start, finish, and slices for searching data. This would be useful, for oh, Upcoming, Calendar applications, or Blogs.

For posterity, here is the original geowanking mailing list - call for feedback. This is still just a draft specification, so if you have thoughts, ideas, suggestions, now is the time to chime in before the web becomes rampant with OpenSearch geo.

About this article

written on
posted in NeogeographyOpenSearch Back to Top

About the Author

Andrew Turner is an advocate of open standards and open data. He is actively involved in many organizations developing and supporting open standards, including OpenStreetMap, Open Geospatial Consortium, Open Web Foundation, OSGeo, and the World Wide Web Consortium. He co-founded CrisisCommons, a community of volunteers that, in coordination with government agencies and disaster response groups, build technology tools to help people in need during and after a crisis such as an earthquake, tsunami, tornado, hurricane, flood, or wildfire.