21 Dec 2007 - What are the key issues for geographic information technology?
If one looks at the field of GIS today, what really are the critical issues confronting users? Theoreticians? Developers?
Where are the dominant problems?
What do we as the broader community require? Better user interfaces? Better data structures? Better tools for data analysis? Easy data sharing and aggregation? Better measurement and data acquisition?
As you might anticipate, I am going to argue that the dominant issue facing all of these groups today is easy data sharing and aggregation. To say that this is so, let’s have a look at some of the alternatives. I won’t claim that there is nothing to do in these other areas however I will claim that in all of them we have adequate solutions today. Within all of these groups, with the exception of easy data sharing and aggregation, the playing field is substantially different today than it was 20 years ago.
Data Structures:
While there is a concerted move into unifying object-oriented structure models (e.g. BIM, IFC) with more conventional geographic abstractions (e.g. GIS), this is really a solved problem from the data structure point of view. However the real problem of data sharing and aggregation is under a different guise. Information created to make building drawings is hard to share with people that are concerned with building operation and maintenance. The data structures to view both as different views of the same design over time already exist. While the infrastructure to enable the easy transformation and distribution of this information does not.
More conventional GIS data structures (i.e. conventional to GIS practioners) has changed very little in the past 20 years, and are of course based on geometry constructs from 200 to 2000 or more years ago depending on your point of departure.
It is curious that in spite of the efforts of the OGC and ISO to abstractly define coverages and features in such a way as to blur the raster-vector distinction, real progress in people’s thinking is much less than one might think. OGC WCS supports only raster structures. OGC WFS by and large only supports vector structures. People still use these words even when they don’t mean what they say!
Even wavelet representations which offer a potential unifying approach to the infamous divide of “rasters and vectors” have been with us for some time and are now widely implemented in imaging and computer graphics. Furthermore the ultimate gain of such representations over current approaches based somewhat on brute force is still unclear.
User Interfaces:
This is an area that always consumes enormous energy and never fails to generate interest and excitement. “Google Earth is so easy to use!!” While ease of use is clearly important, I would argue that the success of Google Earth has far less to do with its ease of use and far more to do with “I can see my house”. The navigation paradigm is smooth and clever for sure, however not enormously more so than previous generations of GIS or CAD tools. The real trick is that Google has provided a window on a huge aggregated base of data – the key ingredient in being able to “see my house”.
The past several years have also seen important user interface developments from hyperbolic tree structures (e.g. Macintosh user interface) to hyperbolic lenses (e.g. Idelix) and context sensitive viewing. Many of these are indeed significant advances, although they really reflect the availability of increased compute power rather than truly new ideas. They are of little use it they cannot be applied to current accurate information.
Tools for Data Analysis:
One of the early and signal characteristics of GIS was the ability to perform geospatial analysis such as overlays, buffer computation and routing to name just a few and have long been well developed. In the end, this is nothing more than mathematics applied to the geometric characteristics of geographic objects. Though while we can develop faster and more efficient algorithms, and make these easier to use, there is nothing really fundamental on the horizon that will dramatically impact geographic information utilization. I think we will see more analytical tools in the hands of end users (routing is the obvious example), but that just reflects the restructuring of geographic information technology than any significant developments in data analysis itself.
Easy Data Aggregation and Sharing:
It’s the data that matters! Nothing could make this point more obvious than the rise of Google Earth and Google Maps. The availability of relatively accurate high resolution imagery and maps on a global basis has supplanted what we used to think as the task of national mapping agencies. It has even left some such agencies wondering “what is their mission in life?”.
That being said, Google Earth (and MS Virtual Earth) also reveal what they cannot do – and that is provide current and accurate data from the source. As a result, we see the “meltdown in the maze”, and big trucks being routed through small towns, and a host of other consequences of missing information. This is not to say that this is the responsibility of Google or Microsoft – simply that there is no infrastructure for them to leverage to ensure the currency, richness and accuracy of their data. They do a yeoman’s job under the circumstances.
The local level is no different. Every day, somewhere in the world, a pipe or cable tray is broken and services are disrupted because someone did not have access to accurate and current information. The costs are not easily estimated, but I would guess they run into many billions of dollars each year. Additionally there are construction delays, permitting delays, confrontations and a host of other consequences of misinformation, all associated with the development of just about everything from a new mine in a wilderness area to a new building in the center of a large city. These costs are even more difficult to estimate, but would run into the tens of billions or more.
All of the fancy visualization and analysis tools are of use and this applies also to the slowly proliferating list of location-aware services. However, only if they can access or be based on current and accurate information, and this can only be accomplished if we can make data aggregation and sharing as easy as possible.
Some people had hoped that this can be solved by the so called Web 2.0 approach, meaning data is generated “out in the wild”. While there is no question that this is an important part of the solution, such observations cannot replace the fact that
1) these are largely observations which must be “validated”; and
2) lots of information derives from the business processes by which societies govern themselves (and this is more than just government).
You cannot change the boundaries of your property by sketching them on Virtual Earth. There is a legal process by which this happens, and when it happens it is known in a particular institution first. This is also true of new building plans, engineering in-progress construction and so on. So more than Web 2.0 is required!
The drive for easy data aggregation and sharing is an old one – so old that many people blanch at the very mention of the term SDI — including myself. We have all talked for decades about this need. We all understand the importance of it. It is no more important than having an accounting system for the whole company, rather than one for each department with no way of doing an overall consolidation. The purpose of an accounting system is to make visible what is going on in a company so that those in the company can take appropriate action. The purpose of GeoWeb/SDI is to help provide this visibility for our society. Clearly this is the most important issue for geographic information technology!
No Comments | Leave a comment»
Comments
No comments yet.
Leave a comment
Blog Entries:
08 May 2008 - Looking ahead to GeoWeb 200921 Apr 2008 - Spatial Infrastructures, IFC & Collaborative Engineering
14 Apr 2008 - KML released as an OGC Specification
02 Apr 2008 - BIM/CAD/GIS Integration
13 Mar 2008 - Structuralism and Data Exchange
05 Mar 2008 - Building the GeoWeb in your own backyard
03 Mar 2008 - Davos of Geo in Vancouver
28 Feb 2008 - What are coordinates?
19 Feb 2008 - Does the invisible hand always get it right?
31 Jan 2008 - “Design for Test” in the GeoWeb
23 Jan 2008 - GeoWeb Local - GML in Local Government
15 Jan 2008 - GML Core and Extensions
04 Jan 2008 - GeoWeb 3D
21 Dec 2007 - What are the key issues for geographic information technology?
26 Nov 2007 - GML in the Back Office
19 Nov 2007 - CAD- BIM-GIS-Games Integration
07 Nov 2007 - What’s in a name? Searching for the right words
23 Aug 2007 - KML Placemarks as Observations
29 Jun 2007 - Where GML was right .. and wrong
17 May 2007 - From GML 1.0 onwards - a brief history
17 May 2007 - GML and Database Interoperability
10 May 2007 - GeoWeb Manifesto
09 May 2007 - Meltdown and the Maze - Toward a Real Time Geography
08 May 2007 - GML, KML, Sensor Data, Imagery
20 Apr 2007 - Transporting GML in KML
21 Mar 2007 - The Architecture of the GeoWeb
14 Feb 2007 - From Interoperability to Infrastructure
14 Feb 2007 - GML without Geometry
18 Dec 2006 - ebRIM gets the nod at the OGC
06 Oct 2006 - In praise of complexity
05 Oct 2006 - Infrastructure - the next step past interoperability
12 Jun 2006 - GML and ebRIM
21 May 2006 - Features, Observations and Authorization
21 Apr 2006 - Transfer and Transaction Models
12 Apr 2006 - Feature Catalogues/Dictionaries, GML and RDF/S
10 Apr 2006 - Genus Loci
04 Apr 2006 - GeoWeb and Survival Part II - Towards Environmental Security
04 Apr 2006 - GeoWeb and Survival
17 Mar 2006 - Schemas, Interoperability and RDBMS
14 Mar 2006 - SDI Concepts
05 Mar 2006 - GML Complexity Re-visited
05 Mar 2006 - Observations are for more than sensor data
05 Mar 2006 - Application Schemas Drive Profiles
25 Feb 2006 - The problem with XML
15 Feb 2006 - The importance of profiles
08 Feb 2006 - One person’s metadata is another person’s …
07 Feb 2006 - From Soup to Nuts
02 Feb 2006 - GeoRSS - GML in news feeds
31 Jan 2006 - Performance and the GeoWeb
27 Jan 2006 - Remote API’S, Web Services and the GeoWeb
19 Jan 2006 - GeoWeb 2006 - GeoWeb Grows Up
09 Jan 2006 - Dealing with time in GML
23 Dec 2005 - Dynamic
14 Dec 2005 - GML in the cockpit
01 Dec 2005 - SDI - What is it really?
25 Nov 2005 - GML is the same for all applications
25 Nov 2005 - Schemas and Profiles - whats the difference?
22 Nov 2005 - Schemas - why the big deal?
15 Nov 2005 - GML for Geographic Imagery
13 Nov 2005 - GML, and KML - Why the fuss?
10 Nov 2005 - Is GML a format?
09 Nov 2005 - Embedding GML in “foreign” grammars
03 Nov 2005 - Authentication and Access Control
03 Nov 2005 - OnStar in the era of the GeoWeb
03 Nov 2005 - Do we need to encode location in news feeds?
03 Nov 2005 - gMedia - Towards Geographically Aware Media
03 Nov 2005 - Where are we going?
02 Nov 2005 - Sample XSLT Style Sheet
02 Nov 2005 - Sample KML Output
02 Nov 2005 - Sample GML Data File
02 Nov 2005 - Styling GML to KML - XSLT
02 Nov 2005 - Simple Geometry Schema
01 Nov 2005 - Simple GML Geometry
18 Oct 2005 - Simple GML Geometries
18 Oct 2005 - Styling GML to KML for Visualization
18 Oct 2005 - Some Simple GML Profiles
17 Oct 2005 - Embedding GML in non-GML grammars
17 Oct 2005 - Geotags - the answer to everything?
20 Sep 2005 - GeoWeb 2006
20 Sep 2005 - GML Observations and Features
14 Sep 2005 - What is KML?
07 Sep 2005 - Time in GML
07 Sep 2005 - GML Observations
07 Sep 2005 - GML and KML Syntax
07 Sep 2005 - GeoWeb - Part II - GML and KML
07 Sep 2005 - GI Markup - Part I - Feeding the web with Geographic Information
06 Sep 2005 - GML Complexity
06 Sep 2005 - GML “Sucks”
24 Aug 2005 - Web Feeds and Geographic Information
23 Aug 2005 - What is the Geo-Web?
23 Aug 2005 - IS WGS84 Enough
04 Aug 2005 - Coordinates in GML
03 Aug 2005 - GML Profiles
03 Aug 2005 - GML and Coordinate Systems
03 Aug 2005 - Information Sources
03 Aug 2005 - Features and Geometry Properties
03 Aug 2005 - GML Geometries
03 Aug 2005 - GML FAQ for RSS Geeks and others



