MetaCarta Labs is a small team of enthusiastic, fast paced developers working directly under the CTO to develop prototypes and new products and facilitate developer outreach. MetaCarta Labs is taking a key role in geo-enabling the Web — helping existing content owners to add geographic information to their content — and has a long history of working with external developer communities through open source projects and conferences.

I’ve been working at MetaCarta for two years, and I’ve really had a great time there. Some of the smartest people I know are my coworkers, and I’ve learned more working with them than I have anywhere else. I’ve travelled to conferences in other countries, met people from around the world, worked on several open source projects, and directly participated in a number of interesting revenue-building things within the company.

Interest in geo a must: experience in geo optional. We’re looking for a web hacker, primarily: interest and experience in HTML and JS is pretty much a prerequisite for what we’re looking for at the moment.

It’s a cool gig: if you know anyone who might be interested, feel free to send them our way: Contact information is available in the link above.

The GeoJSON Authors are proud to announce the finalization of the GeoJSON 1.0 Specification.

Representing more than a year’s worth of community discussion and development, the GeoJSON specification describes an easy to use, extensible format for transferring geographic data over the web. With support in more than 20 different applications, GeoJSON is already quickly becoming a de facto standard for transferring geographic data in a JSON format. The finalization of the spec represents the final step in formalizing the GeoJSON format for encoding this data.

More information on GeoJSON can be found at http://geojson.org/ , or from the GeoJSON mailing list at http://lists.geojson.org/listinfo.cgi/geojson-geojson.org .

FeatureServer and OpenLayers, two pieces of software originally created with MetaCarta Labs, are both heavy supporters of GeoJSON, and have been following the spec for more than a year now. It’s great to finally have this done and published as a ‘final’ 1.0 release.

However, there are some limitations placed on BigTable datastources that make doing geographic queries more difficult than it might otherwise be. Understanding of querying/indexing two-dimensional/geographical data is something that is typically a database extension — in Postgres, this is the PostGIS extension to the database, for example. BigTable has no inherent understanding of this type of data, so we have to drop to a more naive implementation. A first pass approximation at bounding box queries might be to create a four-tuple of columns in your datasource: left, bottom, right, top, and store the extent in that datasource. In a typical relational database, this would work reasonably well, though your database wouldn’t truly be indexing both dimensions at once: instead, you’d be using a single dimensional index, and then filtering the result as a second pass.

App Engine doesn’t allow this type of query, however: an application can’t perform inequality queries on more than one field at once. The naive implementation, of x < right and x > left, then, will fail: left and right are different fields, and you can’t do queries of that type.

So, the key is clearly to encode the bounding box of features in a way that embeds the data into a single string, which represents the bounding box accurately, but is also ‘ordered’ — such that a point represented by ‘123′ is near a point represented by ‘1234′.

The default response to this — for points — is to use Geohash (Wikipedia). Geohash embeds location information for a point into a single, ordered string, for which you can drop precision by simply dropping bits off the end of the string. For points, this actually works relatively well: a given point will be between two geohash values for the corners of a bounding box. So, if you have -71,42, and a Geohash of ‘drmwbmg7sp6yf’, and you do a query for -72,41 -> -70, 43, you have limits of ‘drkc1xg4q3uy8′ and ‘drwhx5gt1ubzk’. Clearly, the former is between the latter two: You can simply do a database query of (hash < 'drwhx5gt1ubzk' AND hash > ‘drkc1xg4q3uy8′), which App Engine has no problem with.

However, this doesn’t scale equally to non-point features. You can find the ‘union’ of two Geohashes by taking the bits that are the same from each and putting them together: in the case above, the bounding box of -72,41,-70,43 is the bitstring ‘01100101111′: however, because bboxes are not infinitely precise (/infinitely small) as points are, there is no way to assign precision to the string. This means that the ‘cutoff’ results in queries that don’t match up:

>>> a = str(geohash.Geostring((-72.01,40.99)))
>>> b = str(geohash.Geostring((-69.99,43.01)))
>>> c = str(geohash.Geostring((-72,41)) + geohash.Geostring((-70,43)))
>>> c >= a
False
>>> c <= b
True

Clearly, these should both return true: the bounding box of C is contained within the points, but because of the ‘infinite accuracy’ of points, this doesn’t actually work.

Instead, we need to add an additional mode to each of our bits: instead of just storing 0 or 1, we need to store an ‘inbetween’ bit to indicate that there is ‘no known data’. (This fixes the problem that the null string is less than 0.) In order to do sorting properly, we need this to be between ‘0′ and ‘1′, so we instead move to ‘0′, ‘2′, and ‘1′ for inbetween. We call this class the Geoindex class. For our ‘c’ above, this turns 01100101111 into:

0220020222211111111111111111111111111111111111111111111111111111

Now, we do the same test as before, with the new Geoindex class:

>>> a = str(geohash.Geoindex((-72.01,40.99)))
>>> b = str(geohash.Geoindex((-69.99,43.01)))
>>> c = str(geohash.Geoindex((-72,41)) + geohash.Geoindex((-70,43)))
>>> c >= a
True
>>> c <= b
True

Hooray! It worked as we expect.

Geohash here is a public-domain Python module created by Schuyler Erle, available from Mapping hacks Code: Geohash. Schuyler was the brainchild behind all the Geohash work: I just told him what did and didn’t work

In this way, I was able to put together a geographic bounding box query, on top of Google App Engine, using a Geohash-like algorithm as a storage format, and use that query to power a FeatureServer Demo App Engine application, doing geographic queries of non-point features on top of App Engine/BigTable. Simply create a Geoindex object of the bounding box of your feature, and then use lower-left/upper-right points as bounds for your Geohash when querying.

(A later post will detail how to set up your own copy of this App Engine app: I’m still working out a number of kinks with it.)

App Engine provides a number of interesting capabilities; for geographic applications, bounding box queries are very important, and using this solution, you can do queries against this type of data with some success.

• Atom
• GeoRSS
• FeatureServer
• OpenLayers

A: The world’s first Open Source Browser-Based Atom Pub GIS Client.

Last night, I sat down with the intention of using this in some way. I was able to hack together half of what I wanted in about an hour, and I hacked together the other half this morning in another hour.

Announcing…

FlickrBrowse: Browsing the World’s Interesting Flickr Images via OpenLayers

Using Flickr’s ‘interestingness’ sort, I’ve put together a map of the recent flickr geo photos, ordered by interestingness. You can limit photos by username/user id, and clicking the photos gives you little infobubbles with a link to the original photo.

The code is quite simple (view source to see it), and it provides a relatively cool service.

I think this is the kind of thing that OpenLayers and FeatureServer are all about: making it easier to integrate disparate datasets into a single interface. In this case, doing the transformation on the client would be difficult, so we do it on the server, and the client sees it as ‘just another WFS’.

Hindsight

Topix: Creating local news pages by tagging documents on the web. “We don’t do NLP” — describing the different ways to disambiguate, from city mayor names, to names that residents attibute to themselves (Bay Stater, Nutmegger). Creating 32000 zip-code based news pages.

Google:  Google Street Map View, Google Mappletts, now indexing and providing search access to GeoRSS feeds (as of this morning).

MetaCarta + OpenLayers: Cool Map Tools

Of course, this video will also be available from the MetaCarta Labs on a Stick

Check it out!

To that end, I spent today rethinking how I wanted to do it, and I think I’ve come up with something I like better. You can check out the new labs-on-a-stick is available from the Labs on a Stick homepage, as a .tar.gz and a .zip file. This distribution is much bigger — ~9MB — because it includes video demonstrations of OpenLayers and MetaCarta’s geographic search engine. In addition, the homepage (instead of being a FeatureServer demo) is a list of all the things available, including four demos, software downloads, and video presentations.

Although this is probably not ideal for downloads by users on dialup, that’s not the target of the distribution, so for now I’m happy with that.

Now I can go back to concentrating on picking out what URLs I want to demo for my OpenLayers presentation. Hopefully (assuming I get it done in time), I’ll have that made into a video too, adding more material onto this nifty USB distribution.