Horothesia Blog

My boss, Tom Elliot, is an expert epigrapher as well as a fine programmer and geo hacker, and has a new blog on these subjects: Horothesia. Or, as we say around here: τὰ ὁροθέσια. In a way, epigraphs are the push-pins and popup description bubbles of ancient geography.

GeoJSON 1.0a1

After talking with Chris and seeing Camptocamp's plans for using JSON between the client and server sides of Cartoweb 4, I am going to get with the GeoJSON draft again. To help out, I have updated GeoJSON, tagged it as 1.0a1, and uploaded it to the Python Package Index: http://pypi.python.org/pypi/GeoJSON. It complements Shapely like this:

>>> from shapely.geometry import Point
>>> point = Point(0.0, 0.0)
>>> import geojson
>>> geojson.dumps(point)
'{"type": "Point", "coordinates": [0.0, 0.0]}'


Re: GeoJSON 1.0a1

Author: Christopher Schmidt

http://trac.gispython.org/projects/PCL/wiki/GeoJSON , linked from the pypi page, is a 404. http://trac.gispython.org/projects/PCL/wiki/GeoJson exists. (I like the former better.)

Re: GeoJSON 1.0a1

Author: Sean

Fixed. [wiki:GeoJSON] it is.


My favorite hobby horse was apparently given an inside track by the conference session committee: Charlie, Chris, and I got to speak in succession and tag team on REST. I started by trying to remind people how important the Web is, and how practical it would be to follow its best practices when designing geospatial services (instead of going with WS-*). Chris then used FeatureServer to demonstrate how easy it is to work using nothing but good old HTTP. Charlie introduced the Atom Publishing Protocol, a standard for manipulating collections of resources that is better suited than WFS-T for the Web. I don't know if anybody sat through all three of these talks (and kept their sanity), but we did get some good momentum going. And without any of the "REST for the mass market" nonsense that sometimes crops up in some quarters.

I missed Harris Kutagic's talk, but heard that he'd demonstrated parcel data editing in an OpenLayers/MapGuide application using just HTTP PUT instead of WFS-T. I've foreseen exactly this type of application for REST. A city's parcel information system is more like the ancient places of my Pleiades project than almost anything else in the GIS business and the usefulness of URLs for every parcel is obvious. Ownership (at least) of parcels changes independently of other parcels, and this also lends itself to use of PUT.

Several other presentations mentioned REST in passing and, like I said before, even the hardcore OGC service implementers are showing a lot of interest in and knowledge about REST. GeoRSS is already a very big deal in the geospatial business. Once people really catch up with how GData and Atompub standardize creation and modification of entries within feeds, the nature of new services is going to start changing quickly.

At the end of his talk, Charlie invited people to join our Geo-Web-REST discussion group. We're approaching 100 members, and have representatives from many of the most important open source projects, neogeography startups, vendors, search engines, and standards committees. Together, we're starting to sound out the best practices for GIS and REST.



Author: Christopher Schmidt

For the record, I sat through all three, and I was very happy with them. "Why can't we all just (web) along?", "Here's how it works", "Here's how it works with Atom + GeoRSS, the way the web is supposed to work." I think that it was a great set of sessions -- my only complaint is that so many people left immediately after the FeatureServer presentation and didn't stay for Charlie to tell them why Atom >> GML.


Author: Rob McCulley

I sat through all three, and thought they were really good. I work for a municipality, and we are slowly working towards web delivery of maps and parcel information. Very slowly. Like Sean says though, REST fits very well with parcel information.


Author: Vincent Picavet

I attended the whole REST session, and it was really interesting. Charlie's talk on atom was particularly good ! Thanks for that.

Wednesday FOSS4G Update

I'm very glad I attended Bastian Schaeffer's presentation about the 52N WPS. They are doing almost everything exactly right: a DSL for defining processes (BPEL in their case), user-defined and uploaded processes (what they call transactional WPS), and they seem to get what would be the RESTful way to do this stuff (I need to resume the discussion we were having about asychronous processing and callbacks). But it's still WPS, and not really for the web.

I got a glow-in-the-dark Ultrastar (Discraft's ultimate disc) with a TOPP hot-stamp from Chris Holmes. Reminds me how much I miss ultimate tournaments.

Alexander Quinn demonstrated a Library of Congress mapping application based on OpenLayers, MapServer, and Django (there's more Python here than in previous years) with smartly designed popups and labeling hacks.

Jan Hartmann is teaching ~~Belgian~~ Dutch villagers how to georeference historical maps and help tell the story of the invasions and occupations of his hometown since the 17th century.

Aimee Stewart is doing ecological niche modeling on the web with Python (yet again) and RESTful web services instead of SOAP.

Camptocamp is switching from PHP and mapscript to a javascript framework based on OpenLayers and Dojo for CartoWeb 4. Pierre Giraud's demo used services implemented with Pylons (yet more Python). I must find out how well CartoWeb 4 fits into Zope page templates. Shapely has had a bunch of contributions from his colleague Frédéric Junod.

The conference wifi melted down this morning, but the event is otherwise running well.


Re: Wednesday FOSS4G Update

Author: Frank

Hi Sean, You've left one one special presentation, namely your own :) There were a lot of great presentations, and yours was definitely one of them. Perhaps I'm a bit prejudiced, because I'm interested in history. (More the Jan Hartmann stuff than ancient Roman/Greek history, but that doesn't matter. B.t.w., Jan's village is in the Netherlands. Confusing those borders, right? In the case of Southern Limburg, it's absolutely forgivable ;)) Anyways, the stuff you showed from Pleiades was great, and absolutely worth a closer check!

Re: Wednesday FOSS4G Update

Author: Sean

I'm no Larry Lessig, but had fun ripping off his style of presentation, and I am glad that you enjoyed it. I met Jan in 2003 at the first MapServer Users Meeting and always thought he was a Nederlander. I guess I got confused in his talk and stumbled accidentally across the border.

Finding me at FOSS4G

I've put myself on the hook to explain a few different things outside of my scheduled presentation (3pm Tuesday, Saanich Room, after the GeoDjango talk): how to sanely manage map service auth and customization, how to do data processing using HTTP/1.1 only (no WPS). Maybe you want you ask me to pitch your product on my blog (I won't), or ask me to pour you some REST kool-aid (I will), or throw rotten vegetables (which I will nimbly dodge). It's the biggest open source (and special proprietary guests) GIS conference ever (take a bow, Paul Ramsey). I have no booth and my physical appearance is modal (sedentary white male). How then are you going to find me? Shouldn't be too hard; i'm a Free Software Zealot, and you can borrow the special glasses from almost any OSGeo member that will reveal my true form.

Libya and Western Civilization

Speaking of Cyrene, on page 3 of the Times International section is an article about Saif al-Islam el-Qaddafi, a Ph.D. student at the London School of Economics, and the son of Libya's president. A photograph of Mr. Qaddafi speaking from the Greek ruins of Cyrene accompanies the story. He's speaking about tourism, but there is clearly a wider, symbolic, appeal being made to the West.


Re: Libya and Western Civilization

Author: Andy Gee

Hi. The announcment made at the Cyrene declaration was to announce the formation of the green mountain development corporation which is as you say responsible for eco tourism; however it is also about creating a 5,000 sq km low-carbon sustainable region that includes renewable energy (www.pzero.co.uk/customers-gmcda.htm) irrigation, reforestation, microbanking and other an array of other projects aimed at protecting their environment from climate change and creating a sustianbale infrastructure for there people.

Toddler Travel Tip

I'm in Seattle for the pre-FOSS4G weekend, hanging out with family and doing big city stuff: going to the zoo, art museum, and Tom Douglas's dining empire. The flight went really well, and I'd be remiss if I didn't share the secret to traveling happily with a toddler. Always carry at least one big book of stickers for every 2 hours of time on board. Even if you don't have a toddler of your own; you might be able to pass the book to the harried parent in the next row and buy yourself a couple hours of peace. I recommend pirate stickers -- it's never to early for a child to learn how to wield a cutlass and say "Arr!"


Re: Toddler Travel Tip

Author: Debbie

Great job with the flight. We love sticker books and colorforms too. Now that you're here in Seattle, I thought you might like some other tips for toddler friendly activities. Seattle Travel With Toddlers Debbie (Mom of E 2 1/2 yrs old & D 1yr old)

Rethinking JSON for Geospatial

My issues with the specification coming together at http://geojson.org are orthogonal to Matt Giger's. Lists are the closest thing in JSON to tuples, and are the right way to represent points within lines and rings. The semantics of GeoJSON's:

[ [x1, y1, z1], ..., [xn, yn, zn] ]

are pretty obvious and the structure doesn't have to be unpacked like Matt's:

[ x1, y1, z1, ..., xn, yn, zn ]

Should you represent geometries as lists of lists in your analysis or visualization software? Probably not, for the reasons that Matt mentions: memory overhead and speed of access. But we're just talking about the wire format here, and representational clarity trumps computational efficiency on the Web. Limitations or quirks of our implementations shouldn't be engraved into our standards.

Which brings me to my issues with GeoJSON: the proposed mandatory "type" member for all objects. The argument for "type" is that it helps clients distinguish between geometries, features, and collections when parsing data structures. I think this is an entirely optional and avoidable implementation quirk that should not be a mandatory part of the specification.

Best practices for geospatial use of JSON make the need for "type" vanish. Querying a collection resource (all features from "cities" within a bounding box, for example) should return nothing but GeoJSON feature collections. This JSON structure in turn contains nothing but features. A request for the GeoJSON representation of a single feature resource should return nothing but a GeoJSON feature. It's as simple as that: return nothing but the proper JSON data structure.

Same story for data posted or put to resources. Collection resources should expect nothing but GeoJSON feature collections in a POST body. Single feature resources should expect nothing but GeoJSON features in a PUT body. The "type" member is completely needless, and in fact might conflict with the information that is ultimately most important: the class of web resource you're manipulating (collection or member) and the HTTP method you're using to manipulate it.

We in the geospatial business really do suffer from "standard euphoria", and need to remember there's only one first chance to get a standard right.

Update: more from Matt.


Re: Rethinking JSON for Geospatial

Author: Chris Holmes

Do we have a BOF at Foss4g? We should pick a time/place and just hash out all the final issues on GeoJSON once and for all and announce the 1.0 release of the spec at the end of the conference. I'd be happy to sprint a bit on my GeoJSON output of GeoServer to adjust to whatever we finalize on.

Re: Rethinking JSON for Geospatial

Author: Christopher Schmidt

Despite your problems with the mandatory type attribute, you didn't comment on the proposal to remove the mandatory type attribute from the spec. I'm obviously not understanding something here.

Re: Rethinking JSON for Geospatial

Author: Sean

I missed that proposal, did it go anywhere?

Re: Rethinking JSON for Geospatial

Author: Martin Davis

Seems to me this points up a fundamental issue with JSON. It intertwines the in-memory representation with the serialized representation. I agree with a comment of yours, Sean - the serialized representation should carry as much metadata and structure as possible to faithfully represent the structure of the contained information. Mushing stuff together just to avoid having to any work other than the standard Javascript parsing is not a good long-term strategy, IMO.

Ahoy! PP to Starboard


Now, thar be first-class privateerin'. Cap'n Perry dug up the secret of doublin' ye firepower. Matey, if ye not be comin' to Victoria, send me the address of ye home port, and I be rowin' o'er to the Mothership tonight to fetch ye booty.


Re: Ahoy! PP to Starboard

Author: Rob McCulley

Thanks Sean and Matt!! I had never heard of pp before this, and even after Sean mentioned it the other day, I didn't really think much of it, but after Matt posted his example, I jumped on the bandwagon. Here are my results: http://www.vermilion-river.ab.ca/rural-routes/?p=7

Re: Ahoy! PP to Starboard

Author: Sean

Good stuff, Rob! I'll look for you next week in Victoria.

Catching up With Python

I think I'm going to offer a bounty for the first open source GIS software that does something cool using pp [more about Parallel Python]. New Belgium swag, maybe? Drinks on me in Victoria?

Building and installing the GDAL/OGR Python bindings can be a bit of a pain in the neck. It's complex software with a lot of associated data. At the Lab, we're using zc.buildout (see pcl.buildout for a specific example) to create replicable, version-controlled Python environments that include GDAL/OGR (as well as MapServer and PostgreSQL + PostGIS).

Another new option for deploying intricate environments is Ian Bicking's virtualenv. From the readme:

virtualenv is a tool to create isolated Python environments.

The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.4/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.

Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.

Also, what if you can't install packages into the global site-packages directory? For instance, on a shared host.

In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't use the globally installed libraries either).

Virtualenv covers the same ground as the GDAL project's FWTools, but is more programmable and customizable. It integrates with setuptools, and so getting a fresh Python GIS environment from the package index could be just as easy as:

$ sudo easy_install gdal-env

Of course, someone would have to actually create and upload that gdal-env package. Bicking advises us to switch from workingenv to virtualenv.

I've written to the geo-web-rest group about CouchDB, a distributed, non-relational database, and now Sam Ruby has a Python prototype. Basura uses some elements that I like to blog about: namely JSON and WSGI.