# OAI-ORE, Aggregate Resources, and Atom

I left a comment on Jeroen Ticheler's blog, recommending Atom over RSS 2.0, which seems to have been eaten. Coincidentally, Dan Cohen reminded me today about the new ORE specification and its Atom serialization. I think there are some good lessons in ORE for the geospatial respository people. Atom as a format is one.

We have some graph-y plans for the resources of Pleiades and related projects that fit perfectly with ORE.

# Fun With Shapely

Very cool. Is this neogeogenomics? I hope the JTS/GEOS architects are equally pleased. You could do this with the OGR Python bindings of course, but since there are no projections involved, and no GIS data to read – only the comparably baroque genetic software formats – there's little point in doing so. I designed Shapely to provide simple spatial functions and otherwise get out from under the feet of your imagination.

### Re: Fun With Shapely

Author: brentp

but with ogr, it'd be more code to translate to/from numpy arrays for plotting -- unless ogr bindings provide the array interface and i just missed that. any chance for 1D spatial operators in geos, like: >>> LineString1D(astart, astop).overlaps(LineString1D(bstart, bstop)) for that kind of thing i use: >>> LineString([[astart, 0], [astop, 0]]).overlaps(...) maybe then "neogeogenomics" would catch on.

### Re: Fun With Shapely

Author: Sean

I'm not sure that I understand you. The 1D calculations would be trivial, yes? Is the distance between their center points less than or equal to half the sum of their lengths?

### Re: Fun With Shapely

Author: brentp

yes, they are trivial--and your method is simpler than i'd been using. But then for a Multi1D, you do that n times. and Multi1D to Multi1D, n*n times... maybe i'm too lazy.

# Rethinking GSDI Architecture

Ed Parsons and Chris Holmes were at the GSDI-10 conference and have each written posts about "GeoWebs" and "Global Spatial Data Infrastructures" that touch one of my favorite topics: architecture. Ed says that it is time for grand data sharing designs to yield to an evolutionary approach:

So we need to move away from the "Grand Design" approach and build SDI's organically and simply, perhaps making use of the new Global infrastructures that companies like Google and Microsoft have made available to bootstrap the technology, and deliver faster benefits and to make the case for more in depth infrastructures at a later date.

It's great that the GSDI community is hearing this. Yes, Ed is pitching Google's services as he pitches the Web, but I think it's still an honest argument for the Web. The Web works: not only for Google, but for thousands of other business, governmental, and non-profit enterprises, and for billions of users.

I only need to make one little correction or addendum to these paragraphs in Ed's post:

The Grand Design approach does introduce an additional issue which is technology related, many of the current SDI projects are planned to deliver over decades, with technological developments continuing to move rapidly, it is difficult to plan to implement using a technology which will be obsolete years before the infrastructure goes live.., as it is today the best available standards as drafted by OGC are moving from basic http interfaces to the more web services friendly SOAP based interfaces, while the leading edge is looking to REST based interfaces.

Mostly right. When we say "REST", we mean protocols based on the HTTP application protocol, and the architecture that makes the Web a success. REST is not a radical prescription at all. When you consider that REST won the distributed systems architecture war, to take the losing approach forward seems much more radical.

Chris Holmes's presentation is focused on social change, top-down yielding to bottom-up, but when he writes (on slide 19) that GSDI should

build on what's out there, on successful architectures of participation.

there are to me clear technical implications: The Web has an "architecture of participation", and its architectural style is named Representational State Transfer, or REST. I don't fault Chris at all for not directly pointing out that the OGC architecture is misaligned with the architecture of the Web: it's a distraction from his social message and possibly demoralizing to GIS data managers. But I don't think you can for very long dodge the issue that a "GeoWeb" really demands a RESTful Web-like architecture, and something like HTML. Hypertext, not GetCapabilities() and GetData().

### Re: Rethinking GSDI Architecture

Author: Ed Parsons

Sean, I think we are in agreement I did not mean to suggest that REST was radical, it is just some way away from where we are now with the earlier http based OGC interfaces. In terms of searching for Geospatial content a RESTful approach makes life much easier.. ed

### Re: Rethinking GSDI Architecture

Author: Sean

And I'm glad we're in agreement. It's just that I didn't think it was clear enough that the leading edge (REST) uses good old reliable HTTP and is arguably the more conservative approach to distributed systems.

### Re: Rethinking GSDI Architecture

Author: Allan Doyle

Conservative architecture is something that evolves from what people are familiar with, and that is not necessarily the same as something that is elegant, simple, and robust. Computing architectures "matured" in the days of IDLs (interface definition languages) and compiled stubs that when instantiated provided systems that were distributed but still tightly coupled. Sun RPC begat the Distributed Computing Environment which begat CORBA. Microsoft COM begat DCOM which begat OLE COM (or was it COM OLE, and which came first anyway? it's all a blur). Then while the radicals were looking at REST, the conservatives began to build WS-*. From a business and management control perspective, REST is radical. It removes all the ivory-tower layers that have been accreting for what must be close to two decades. So no matter how conservative it may seem to those who understand REST, it remains something mysterious to a large segment of the computing industry. Similarly, SDIs have grown up around the notion of control, this time in terms of metadata, framework data, data accuracy standards, and on and on. The radical thought here is that maybe you don't have to have all of that at once to start doing something useful. The good qualities of SDI will eventually remain, but largely hidden from the view of most of the beneficiaries of all the geospatial functionality that has been able to push its way into the forefront of late.

### Re: Rethinking GSDI Architecture

Author: Allan Doyle

Or, to be more succinct: REST is the radical thought is that you can have your apps be (part of) the web instead of just having them use the web. And therein lies the "architecture of participation".

### Re: Rethinking GSDI Architecture

Author: Sean

Allan, I appreciate the reminder that the Web still seems new and maybe a little immature to the old guard. I admit that I take it for granted.

# G(eo)nomes of Vancouver

Anybody else ever play Steve Jackson's Illuminati card game? The "Gnomes of Zurich" jumped instantly to mind when I read that the "GeoWeb" conference is the "Davos of Geo" on Ron Lake's (written by Roisin Clarke?) blog.

In emails I've seen mention of a possible REST agenda at the conference. That would be a good thing.

# Frugosapalooza in Fort Collins

I'm so glad Dave Bouwman made it out because the question of the night was: coming from an all-ESRI environment, how hard is it to learn and get up to speed on an entirely new software stack? It's hard, and I don't deny that, but Dave reminded people that you don't need to take on everything at once. I think it's easier to start using open source on the very front or back ends. Maybe just try OpenLayers as the map interface for a new project, or try gdal_translate or ogr2ogr for ploughing through data offline before it is loaded into your database.

Turnout was surprisingly good: 10 of us, which is even better, per capita, than the huge (25-ish) Denver meetup. The MapWrecker was sorely missed, but the up side of that is nothing was broken.

By coincidence, the local Hacking Society was also meeting at the Bean Cycle tonight. Conversation with Sean and Evelyn reminded me that I probably should have submitted a presentation on Shapely and other Python GIS software to the PyCon committee.

### Re: Frugosapalooza in Fort Collins

Author: Howard Butler

I submitted a generic GIS-in-Python overview talk giving the 50k view of libraries and utilities you can use in Python to PyCon, and it was rejected. There were some positive comments on my submission, but I think there just wasn't enough room in the conference or interest.

### Re: Frugosapalooza in Fort Collins

Author: Sean

Now I am feeling thankful for the time I didn't spend on a submission. Still, I should attend PyCon some day.

# More Open Source Geospatial and Archaeology

This is an fun coincidence: yesterday I blogged about PyWPS and applying open source GIS software to not-exactly-GIS problems in archaeology, and today one of the Ominiverdi (a company supporting PyWPS) developers blogs about an even more interesting application of that kind. Via Stefano Costa.

# Not-Quite-Web Processing Service

I had a longer post about the new WPS specification that I scrapped after I realized that it reduces to this: the OGC WPS working group gets the formats and parameters more or less right as usual (good), but still can't find any respect for HTTP as an application protocol (bad).

Web geo-processing came up at tonight's meetup in the form of this question: how do I compute zonal statistics on a raster over the web using open source? I said that GRASS would be part of the answer. It wasn't until the meeting broke up that I realized I'd neglected to mention PyWPS, which has a tantalizing kernel of Pythonic goodness.

Meanwhile, it looks like ESRI's ArcGIS Server might be the prime mover for RESTful geo-processing this year.

Update: or maybe it won't. This is not exactly an endorsement by Vish.

### Re: Not-Quite-Web Processing Service

Author: Stefano Costa

Sean, it's worth noting that PyWPS is heavily based on GRASS (or other programs like R and GDAL/OGR) for all its analytical functions. See http://pywps.ominiverdi.org/ for some live examples. That said, I'll wait for another post from you about RESTful geoweb services to learn something about it.

### Re: Not-Quite-Web Processing Service

Author: Sean

Yes, that was my point about PyWPS: that it has solved the problem of calling GRASS routines in the context of a web request, and is therefore worth looking at despite my concerns about the WPS protocol.

# InscriptOL Source

By popular demand (okay, 2 people asked), you can now browse or clone the inscriptOL repo. I need to get back to the GIS-y aspects of Pleiades and won't be actively developing inscriptOL for a while, but patches are very welcome. SVG.js needs to be extended so that the format supports points and polygons as well as polylines. OpenLayers.Format.GML was my starting point and the difference between the polyline methods in the files should be illustrative. Code to browse and select source imagery, with setting of bounds and dimensions to appropriate values should also not be much of a task. Sound support for editing traced features is the most complex of the first things that need to be done to turn this into a serious tool.

# Really, There is More to REST Than HTTP + POX

Umibot writes:

After some hard work/late nights and prodding from the geo-techno elite, we’ve humbly completed and are pleased to offer RESTful access to our neighborhood API.

In their "REST API", you can use either GET or POST (trampling the uniform interface) to invoke a remote method and get a JSON or XML response. It's better than SOAP, but I'm dismayed that this is hyped as REST.

# Python, MapServer, and WSGI

I was pleased to stumble onto Brent's blog a week ago: I spent my undergrad afternoons working in a molecular biology lab and still dabble in genomics. His genome browser inspired me to see OpenLayers as more than a web GIS tool.

### Re: Python, MapServer, and WSGI

I've found the MapScript OWSRequest capability invaluable for overlaying layers in Google Earth, so don't doubt that it's a valuable feature.

### Re: Python, MapServer, and WSGI

Author: brent

hi sean, good to hear i've inspired you somehow. i'm an avid reader (and user) of your code and blog. i'm really having fun with mapscript lately.