[OSGeo-Discuss] Should OSGeo get involved in the Information Architecture realm and nurture the development of definitive spatial ontologies?

[Miles Fidelman]

Bruce Bannerman wrote:
> We need robust debate on these types of issues if we are to progress
> them.
>
>   
Ok.. let's try this :-)
> I see that there are two main ways of utilising spatial information:
>
> - producing a pretty picture that helps people understand an issue. We
> have a number of types of products that fall in this realm, including
> Google Maps, Google Earth, Virtual Earth, Slippy Maps etc.
>
> - as an input into structured analysis that is used as an aid to
> answering a particular question and also as an aid to exploring
> inter-relationships between spatial, business, scientific data etc. The
> output from this analysis could be a 'map', but of equal relevance it
> could be in tabular, graphical or textual form. This is the realm of
> traditional spatial analysis, image analysis or a range of spatial
> products that I like to term 'Spatial Intelligence Frameworks' e.g.
> Cohga's Weave, NGIS' GeoSamba, ESRI Australia's Eview. 
>   
I don't think this dichotomy holds up under close scrutiny.  I don't see 
that much difference in the cognitive processes or computing tools 
involved in "producing a pretty picture that helps people understand an 
issue" and "structured analysis as an aid to answering a particular 
question" or "exploring inter-relationships between ... data."  Is not 
"structured analysis" part of producing any form of useful 
presentation?  In general, it's HARDER to organize and present issues to 
an audience that is not already familiar with the intricacies of an issue.

This implies that one needs more powerful tools, and more flexible data 
representations, to produce pretty pictures than to simply perform a 
specialized analysis.  A specialized analysis is amenable to a 
specialized tool.  The broader the range of analyses one wants to 
perform, and the broader the range of presentations that one might want 
to use to illustrate an issue, the MORE powerful and flexible the tools 
one needs - even more so if one wants to provide interactive 
capabilities to the audience of the "pretty picture."

Tools that support breadth, depth, and flexibility, coupled with 
ease-of-use and a touch of elegance, are far harder to build than those 
that support more narrowly scoped problems.  As a simple example: yes 
you can produce pretty pie charts using a drawing program, and you can 
perform incredibly powerful statistical analyses using SPSS or 
Mathematica, but you can address a far larger set of problems using a 
spreadsheet with graphics capabilities, particularly if the spreadsheet 
can tap into SQL databases, and you have a library of specialized macros 
available.

> Throw into this the big picture issues that we are facing, e.g. Climate
> Change, Water Shortage (in Australia) etc that require analysis at a
> continental or global scale and we have a big problem.
>
> How can we as an industry help this work to progress quickly with
> minimal impact on the analysis, minimal double handling of data and in
> many cases the use of dynamic data from multiple sources?
>   
<snip>
> In the end, I suspect that we will need community driven involvement to
> get it right. Communities of practice (like the geoscience community)
> will need to work together to develop *their* profiles describing
> *their* data. 
>
> Is it an OSGeo responsibility? Probably not. I take the point of your
> earlier email that OSGeo is predominantly about OS software.
>   
<snip>
> When you consider the analysis requirement for spatial data, I suspect
> that we as an industry may be heading in the wrong direction. 
>
> Some of the issues that are are attracting a lot of effort are about
> simplifying spatial data (GeoRSS, GeoJSON, BXFS etc). These appear to be
> about catering to the 'pretty picture' use of spatial information.
>   
I'm sort of driven to the opposite conclusion.  The more that data 
profiles are developed by specialized communities, the less likely that 
different data sets will be amenable to combination and correlation to 
support complex, cross-discipline issues such as climate change.

In one direction lies the need for anyone, working on a complicated 
problem, to understand in great detail all the overlapping disciplines 
that might be involved.  In the other direction lies framing higher 
levels of abstraction that allow examination of different types of 
ordering and interactions.

The example that comes to mind is systems engineering (my own 
discipline, as it turns out).  Yes, a systems engineer has to understand 
quite a bit about all the disciplines involved in building a system (or 
these days, a system-of-systems).  If you're building an aircraft, you'd 
better understand a lot about aeronautics, avionics (including hardware, 
real-time software environments, specific algorithms), and so forth.  
But the discipline involves understanding interactions and tradeoffs, at 
a higher level.  It's been a long time since I've written a large 
program, or designed hardware - and I haven't kept up with the 
intricacies of today's development tools - but making hardware/software 
tradeoffs doesn't require that very detailed knowledge - it has more to 
do with a different set of questions (example: do you throw more 
hardware at a problem or do you refine your software tends to involve 
questions of how many times an algorithm is executed per second, and how 
many instructions it involves - that tells you whether you're reaching 
limits of hardware performance or not). 

The trick is getting to the commonalities and finding a common language 
across disciplines, and geospatial data organization (whether presented 
as maps or as databases) seems to be a very powerful metaphor that links 
many disciplines together.  It strikes me that finding an easy-to-grasp, 
easy-to-use, core set of representations and functionality is a better 
starting point for cross-discipline collaboration than is a "complete" 
but highly complicated and opaque one.  Now if one can be elegant, and 
make that core set of capabilities readily extensible, it becomes 
possible to add capabilities as needed, down the road.




-- 
Miles R. Fidelman, Director of Government Programs
Traverse Technologies 
145 Tremont Street, 3rd Floor
Boston, MA  02111
mfidelman at traversetechnologies.com
617-395-8254
www.traversetechnologies.com