That's what Raj Singh seems to be saying here:

For example, most of the REST material I've read treats images as indivisible, binary resources. This won't work in the geo field, where images are in the gigabyte and terabyte range and you've got to design services that provide access to portions of those images. However, aside from imagery I don't see much of a problem with using a resource-oriented approach to information access. In fact, in the sensor web arena I think a REST approach makes a ton of sense.

Raj, you're reading the wrong material. No REST architect accepts that the image "file" is the only possible resource. If I had a global sea-surface temperature coverage resource at /sst/current/, I could easily treat individual pixels as resources of their own: /sst/current/{pixel},{line} is just one possible URL form. I could even interpolate to fractional positions within the coverage, or do lat/long: /sst/current/{latitude},{longitude}. Modes of an empirical orthogonal function decomposition (hot topic when I was in school) could be modeled as resources: /sst/current/eof/{n}. Simple temperature slices are another possible set of algorithmic resources: /sst/current/?tmin=28 would be the warm waters that spawn tropical storms. All of the above are RESTful and no client needs to know whether I have a single file or multiple databases backing the resources. Furthermore, a resource-oriented approach scales better than an endpoint-based protocol like WCS. As the number of resources grows, you simply spread them over more servers like Google has done with its Earth and Maps tiles.

There may be geospatial problems that REST can't tackle, but access to arbitrary regions of a coverage is not one of them.

I'm also a bit disappointed to read this:

After all this [research], I think I know what's going on, but I don't think there's any one clear explanation (despite some nice pieces of the puzzle here [1] and here [2]) available, and there has certainly been little effort to analyze the REST architecture in relation to geographic information systems theory, so that's what I'll try to do now.

Of all the great posts and email threads which break GIS web services down in RESTful terms, he picks that muddled Directions article and another that only quotes one of my emails? This trivializes the geospatial community's conversation about REST, one that has been enlightening and amusing us for about a year now. The fact that there will be three REST related presentations at FOSS4G hints at the maturity of the topic.

My hackles rise every time I read that GeoDRM is one of the OGC's advanced technologies. I simply do not find it easy to look past it to the other more sensible working groups and standards. It's as though I'm in a strange city, getting directions from a helpful man. He's sharply dressed, Wall Street Journal tucked under his arm, speaking authoritatively about the neighborhood ... and then I notice that he's surreptitiously carrying a smoldering crack-pipe. When I ask, he's "just holding it for some other guy". Right.

Or maybe I'm just the cook (near the end) in this classic ;)

Let's you and him fight. Nevertheless, I always enjoy Sebastian's writing.

MapServer 5.0 has some nice new features. Christopher Schmidt has been blogging the hell out of one. Dynamically allocated arrays (culmination of my work on a container API -- msInsertLayer and friends) is a big one that doesn't get a lot of notice. I think my favorite is this: now you can pretty much stop using mapscript.

Steve Lime did the work. I did the nagging, testing, and the final mapscript touch. Here's a Python usage excerpt from the tests:

>>> import mapscript
>>> mo = mapscript.fromstring("""MAP NAME "test" END""")
>>> mo # doctest: +ELLIPSIS
<mapscript.mapObj; proxy of C mapObj instance at ...>
>>> mo.name
'test'

I've explained the motivation previously. You can now transform the problem of writing intricate, error-prone mapscript code into a more tractable template interpolation problem.

Since my employer isn't a member of the OGC, I'm stuck with blogging my ideas about KML in the hopes that they strike a chord with some insider and thereby tunnel through into the smoke-filled rooms where our industry standards are made.

Andrew Turner wrote the other day about KML modules and listed five: core, styling, 3d, metadata, and services. I'd like to see the core divided one more time. All the KML elements that overlap with Atom need to be factored into a module of their own. This means name, description, atom:author, and atom:link. An Atom module would help developers implement Atompub clients and services by marking a clear boundary between media and metadata elements.

Doctest/JS.

It is spreading. And spreading.

Kai Lautaportti just released OWSLib 0.2.1 [Cheeseshop]. It now works with no external dependencies on Python 2.5. Get it from the Cheeseshop:

$ easy_install OWSLib

or our Subversion repository:

$ svn co http://svn.gispython.org/svn/gispy/OWSLib/tags/rel-0.2.1 OWSLib

Update (2009-05-20): Hammock has been retired, replaced since December 2007 by Knowhere.

I have repurposed my Hammock application into a demonstration of the Atompub, KML, and Google Earth integration. Now, from an Atom perspective there is a service document and one collection at:

http://sgillies.net/hammock/index.atom

http://sgillies.net/hammock/places/

Subscribe to that second URL, it's an Atom feed. Any newsreader should be able to use it to monitor changes to the collection. Next, start Google Earth and in your temporary places container create a new network link to this URL:

http://sgillies.net/hammock/places.kml

The same (very simplistic) data model supports both the Atom feed and the KML document.

Ready to publish data to the Web, Atompub-style? All you need is a terminal, curl or another moderately sophisticated HTTP client, and a little make-believe. Imagine that Google Earth or another future geo-browser is doing all the POST and PUT dirty work for you.

In the temporary places container, create a new point placemark anywhere. Give it a name and a plain text description. Save it to your filesystem as hammock.kml. To create a new, publicly-shared place within the collection based on your new placemark you send the contents of that file in the body of a request to the collection URI. I showed that URI above, but the sure place to find it is in the atom:link element of the KML file. View the source on that file and verify that there's a link to http://sgillies.net/hammock/places/. Now send a request like:

POST /hammock/places/ HTTP/1.1
Host: sgillies.net
Content-type: application/vnd.google-earth.kml+xml

<kml>
...
</kml>

You can use curl to do it like this:

$ cat hammock.kml | curl -d @- --header
Content-type:application/vnd.google-earth.kml+xml
http://sgillies.net/hammock/places/

It's very important to specify the proper content type. If you've typed carefully, you will get response with a Location header containing the URL of the newly created resource. If you refresh the Atom feed and network link, you'll see the new resource reflected in each. You've seen this before in other apps like FeatureServer. What's new is that the KML document itself carries a link to the collection URI, the factory for new placemark resources. That's Atompub in action.

Furthermore, any placemark resource represented in http://sgillies.net/hammock/places.kml can be edited via its "edit" or "edit-media" (they are equivalent in this demo) atom:links using the HTTP PUT method. View the source to find the edit link for your newly created resource, and copy it (remember, one day Google Earth should do all this for you). Now, move the placemark in Google Earth or create a new one, and save it to the filesystem. Finally, PUT the saved placemark to the edit URI you copied using curl like:

$ cat edit.kml | curl -X PUT -d @- --header
Content-type:application/vnd.google-earth.kml+xml
http://sgillies.net/hammock/places/3

In this case, I've edited the third place. Note the use of the PUT method. If you typed carefully, the changes you made will be reflected in your newsreader and in the Google Earth network link.

It almost seems too simple to work: serve KML to users that provides the very links by which users can add to, or modify, the web resources represented in the document. I'd be surprised if there is a tidier solution. I hope this simple demo can convince a few people to take a closer look at using Atompub for geospatial services.

Following the example at byCycle.org I've figured out how to use Shapely geometries with SQLAlchemy and PostGIS. Here's the custom type:

from sqlalchemy import types
from shapely.wkb import loads

class Geometry(types.TypeEngine):

    def __init__(self, srid, geom_type, dims=2):
        super(Geometry, self).__init__()
        self.srid = srid
        self.geom_type = geom_type
        self.dims = dims

    def get_col_spec(self):
        return 'GEOMETRY()'

    def convert_bind_param(self, value, engine):
        if value is None:
            return None
        else:
            return "SRID=%s;%s" \
            % (self.srid, value.wkb.encode('hex'))

    def convert_result_value(self, value, engine):
        if value is None:
            return None
        else:
            return loads(value.decode('hex'))

Example:

>>> db = create_engine("postgres://localhost/the_db")
>>> metadata = MetaData(db)
>>> places = Table("places", metadata,
...     Column("the_geom", Geometry(4326, "POINT"))
...     )
>>> result = places.select().execute()
>>> row = result.fetchone()
>>> row
(<shapely.geometry.point.Point object at 0xb771490c>,)
>>> row.keys()
['the_geom']
>>> row.the_geom
<shapely.geometry.point.Point object at 0xb771482c>
>>> row.the_geom.wkt
'POINT (-106.0000000000000000 40.0000000000000000)'
>>> row.the_geom.x
-106.0
>>> row.the_geom.y
40.0