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
[EMAIL PROTECTED]
617-395-8254
www.traversetechnologies.com
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
