Friday, August 07, 2009

Bottoms Up?

In his take on last month's GeoWeb conference, Sean Gorman expresses his love for the "bottom up" style of geo-webification:
Top down being standards developed by committees (W*S, GML, CWS etc.), data sharing initiatives in the form of Spatial Data Infrastructures (SDI), and implementations built around protocols like SOAP. On the other end we have bottom-up approaches where de facto standards are created around iterated implementations (KML, GeoRSS, SpatiaLite etc.). Data sharing takes the form of indexed geodata that is directly Web accessible (e.g. Jason Birch’s work with Nanaimo). Protocols for implementation in the bottom-up category typically follow a RESTful philosophy.
But, how do I find all this wonderful "bottom up" data? Here's a hint, it starts with "G"... Basically the "bottom up" folks have looked at the SDI publish-find-bind triangle and decided that "find" and "bind" are too much trouble. Someone else will have to deal with that. And fortunately (?), someone (starts with "G") has.

The rejoinder to my complaint is that the bottom up approach demonstrably works, while the SDI approach demonstrably doesn't. But that doesn't stop me from worrying about handing over a big part of the geo-webification program to a big, privately controlled, black box. One of Jason Birch's concerns about his elegant SEO-oriented approach to civic data publication was that the big black box was returning his data the "wrong way" (funneling certain address searches into the wrong place). We are back to hacking against a private black box API; it's Win32 all over again folks.

My geo-webby self loves that this stuff (mostly) "just works". My open-sourcey self worries that we are merrily affixing the golden handcuffs to ourselves. I, for one, am ambivalent about our new Googley masters.
 

5 comments:

sean said...

Good points - the Googly approach is the most ubiquitous but not the only game in town. I believe there is room for a bottom up approach for finding data as well. We've been leveraging OpenSearch, Atom and GeoRRS to enable data federation and discovery. The bottom-up initiatives can interconnect themselves and allow discovery in a more robust way. Allow bounding box searches, leverage metadata, provide file format translation etc. While Google does many things well in search and geo - I'm not convinced filetype:kml is the answer.

sean.gillies@mac.com said...

Paul, important as Google is, it's a mistake to equate its search with the web. Search wasn't specified in the web architecture doc; it emerged from webarch's simple principles and constraints. The web makes lots of room for such innovation. Unexpectedly good things can arise. In the thoroughly-specified SDI architecture, not so much. It's not that "publish (to a registry), find (in a registry), bind (classes to services)" is too hard, it's that there's too little freedom or opportunity.

Agreed, though: lock-in is lock-in.

sean said...

Although the only way to avoid lock-in is to provide alternatives; otherwise we'd all be using MS SQL instead of PostGIS :-)

Regina Obe said...

I think the lesson here is that we should be flip flopping between bing, googly, Oracle, SQL Server etc. and keep the big corporations confused as to which one the world prefers.

That way google would be too afraid to become evil. Nothing against Microsoft or Google or any of us. I think the point is that as the dinosaur gets bigger the tempation to step on mice becomes more enticing unless there are other dinosaurs around to fight with.

The Sunburned Surveyor said...

Paul,

This was an excellent post, and I enjoyed the comments from other readers.

I'm about as far as you can get from a web developer, but I think there is tremendous opportunity to improve the search for geospatial information on the web. Microformats our one example of this opportunity. Imagine being able to vacuum up contacts or book reviews in a search engine using microformats. Might not the same thing be possible with geospatial content?

I don't think we need fancy APIs to accomplish this. We need a simple text format for describing geospatial data. Something any webcrawling program can suck-up from the web in plain old html. Maybe this has already been invented and we need to just promote its use?

I think the development of (non-google) tools that search for content on the web using more structured HTML mark-up is very promising, and could be applied to the geospatial arena.

Landon

About Me

My Photo
Victoria, British Columbia, Canada

Followers

Blog Archive

Labels

bc (32) it (26) postgis (17) icm (11) enterprise IT (9) sprint (9) open source (8) osgeo (8) video (8) management (6) cio (5) enterprise (5) foippa (5) gis (5) spatial it (5) foi (4) mapserver (4) outsourcing (4) bcesis (3) foss4g (3) oracle (3) politics (3) COTS (2) architecture (2) boundless (2) esri (2) idm (2) natural resources (2) ogc (2) open data (2) opengeo (2) openstudent (2) postgresql (2) rant (2) technology (2) vendor (2) web (2) 1.4.0 (1) HR (1) access to information (1) accounting (1) agile (1) aspen (1) benchmark (1) buffer (1) build vs buy (1) business (1) business process (1) cathedral (1) cloud (1) code (1) common sense (1) consulting (1) contracting (1) core review (1) crm (1) custom (1) data warehouse (1) deloitte (1) design (1) digital (1) email (1) essentials (1) evil (1) exadata (1) fcuk (1) fgdb (1) fme (1) foocamp (1) foss4g2007 (1) ftp (1) gds (1) geocortex (1) geometry (1) geoserver (1) google (1) google earth (1) government (1) grass (1) hp (1) iaas (1) icio (1) industry (1) innovation (1) integrated case management (1) introversion (1) iso (1) isss (1) isvalid (1) javascript (1) jts (1) lawyers (1) mapping (1) mcfd (1) microsoft (1) mysql (1) new it (1) nosql (1) opengis (1) openlayers (1) oss (1) paas (1) pirates (1) policy (1) portal (1) proprietary software (1) qgis (1) rdbms (1) recursion (1) regression (1) rfc (1) right to information (1) saas (1) salesforce (1) sardonic (1) seibel (1) sermon (1) siebel (1) snark (1) spatial (1) standards (1) svr (1) tempest (1) texas (1) tired (1) transit (1) twitter (1) udig (1) uk (1) uk gds (1) verbal culture (1) victoria (1) waterfall (1) wfs (1) where (1) with recursive (1) wkb (1)