14 Mar 2006 - SDI Concepts
SDI = Spatial Data Infrastructure. Every national government seems to have one. We even talk of a GSDI (Global) - but there have been few if iany realizations. What do we mean by SDI? How close are we to creating an SDI with commercial software technology? What functinality should an SDI provide?
Let's put things in some concrete context. You are a highway or subdivision planner. To do your job you need access to lots of information. Location of existing street and highway networks, the water network, the electrical system, telecommunication systems etc etc. All information that is likely held by multiple organizations in a multitude of formats and with many disparate and possibily inconsistent data models. You will use that information in a variety of planning, design and project management tools to create proposed highway designs, subdivision designs etc. which you will need to share with your colleagues in the transportation authorities, land development organization, building approval, land reclamation etc etc. Furthermore you will need to be able to share this information in a secure manner and such that some people can see some things and others can see other things. The things you share will be both actual existing structures and proposed and planned ones. The things you want from others will be much the same. So information must flow in a controlled and secure manner between multiple parties - in as near to real time a manner as possible. To achieve this, however, neither you, nor your colleagues want to give up the planning, design and project management software you have grown to love and to hate. Better the devil you know then one you do not. So this SDI thing must do a lot. It is clear that:
An SDI is much more than a portal:
A portal is a set of presentation services - user interfaces - that provide access to things for people. From a portal I could look at maps in my web browser - but only if there are a set of back end services. Moreover, since I want to contnue to use my existing planning, design and project management tools - unless these are all integrated into the portal I am not going to be very happy. A portal is then just part of the story.
Note that I really do need much more than just the presentation of maps. This is very nice for planning and for discussion - but I need the actual dimensions and other properties of structures and natural objects - how else can I plan the ones I will introduce into the world? So an SDI must provide:
Universal Data Discovery:
I need a way to find all those needed information sources. I need a way to determine my access rights. I need a way to specify the access rights of those with who I am willing to share my data - my plans, designs and proposals for the future.
I need a way to register what I am interested in and find out what is available and how to get it. Ideally I can access all of the needed information online - but we all know this is off somewhere in the future - but I do need to access what I can access and access it now in real time. And please don't tell me I need to worry about format conversion - or changes of coordinates and such. Surely the SDI and help me with ..
Universal Data Access:
Of course, I don't expect that all data will be free or freely accessible. After all I know much of the information I have is confidential (the new highway route is significant economically and premature release of this information could be disastrous). In some cases I know I will need to pay for data, in some cases not. The SDI should enable these kinds of access - meaning access based on who you are and access based on whether or not you have paid your accounts. So Universality yes, but circumscribed by appropriate access control. So the SDI needs to support Universal Access with Universal Access Control and Authentication - meaing across the SDI, hence across the community of interest.
Of course Universal Data Access is not all that helpful unless I can access the models of the information being supplied. What is a road in one community is something else in another. SO there must be a means for the SDI to provide access to the
Community Vocabulary:
By this I mean the various objects shared by the community - their names and properties - does a road have a width? a surface type? a classification? How are these expressed? I am not sure I need (or could use as yet) a full ontology - but at least a dictionary of the shared (common to the community) objects is needed and in both human and machine readable terms.
Given this information - I can advertise my own data to suit or provide the appropriate translation between my view of the world and that which I share with the community. So I expect the SDI to provide me access to these common vocabularies and perhaps some tools to help me with translation.
While I think of it - I am not sure I really want to think about the SDI itself all that much. Even going to a portal seems outside my normal experience. In fact., I think a requirement for an SID should be transparency or even invisibility.
Transparency:
If I work in planning, I already have a set of tools that I work with - ones I am used to and ones which have developed over time in my own field - hence provide user features that enhance my productivity. I am not going to give these up for an SDI. Of course, one should not have to. The SDI should take care of that for you. The SDI should enlarge in a transparent as possible manner your applications access to data and services beyond your application domain - but in such a way that your existing application can use them. This is in effect the key problem for SDI.
Even transparency is not enough, however. Why should an SDI be restricted to spatial information? How could restrict it to spatial information anyways? Would I need to be able to distinguish between spatial and non-spatial information? I am not sure I would even know how to do that. So maybe the spatial in SDI has as much to the spatial distribution of the actors involved as it does to the partly spatial character of the information being manipulated. Or perhaps it is the spatial (geographic) nature of the information that demands integration because of the inherently integrated nature of the world.
There are indeed many points to ponder - there is much more to SDI than we might first suppose.
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



