Geo-Web

This is the last note of the holiday season. I wish all of our readers the best for this holiday and for the months to come in 2006. I think it will prove to be a good year for GML and for the GeoWeb - perhaps a watershed year.

One thing that GML (and its partner specifications like WFS and FPS/WMS) enable, is the ability to create truly dynamic "maps". By dynamic maps, I mean maps that are updated in real time from sensors, aerial surveys, satellite imagery and so forth. Maps that update as the world changes. This is of course one of the long sought promises of the Internet and GIS - one that until recently we did not have the technology and standards to achieve.

With GML we can now express - in a single encoding - vector geographic features, sensor data (data packets, sensor observations) and imagery. Specific child specifications such as GMLJP2 combine the power of GML with the power of other specifications such as JPEG 2000. This can be expected to develop even further in 2006 with the emergence of WFS/JPIP. Transactional (i.e. update) of imagery and associated features is in the works - this will greatly accelerate data integration and vastly improve existing work flows for the creation and maintenance of geographic information.

For some this is a shock. They think of geographic data as more or less static vector features and little else - but this is so wrong! Is the speed of a vehicle on a highway less "geographic" than the highway itself? Are characteristics of that vehicle or its relation to the environment not also "geography"? Is the weather not so as well. In GML we see the ability emerging, in combination with other specifications, to truly integrate these apparently disparate kinds of information. All of this stems from seeing that GML is NOT a format - it liberates us all from the binding of information models to file structures - this is a key fact. And one that will drive the development of the GeoWeb in 2006.

Have a great holiday!!

With all of the discussion of GML and KML one might lose sight of some of the many applications of GML that are outside the commercial and consumer domain - applications which nonetheless have a big impact on our daily lives. One of these is air travel. While the dust is far from settled, there is the distinct possibility of GML and WFS being used to update aeronautical databases. What are those? They are databases that contain current information on the state of the airspace through which airplanes including commercial, private and military must fly (or must not fly). Airspaces are defined by terrain - by commercial, private and defense facilities - by obstacles (cranes, tall buildings etc.) and so on. More than airspaces are involved as well - since we need also to describe the facilities themselves (e.g. an airport) from which aircraft takeoff, land, taxi etc. All of these things involve geographic information and relatively complex geographic information - furthermore it is a case where accuracy matters and where we cannot ignore the curvature of the earth. Most importantly, it is case where we must synchronize a large number of databases (those on the ground and those in aircraft) so that they all have a common picture of the world. It would not be good if pilots, avionics and ground systems had different views of the world. GML and WFS (Web Feature Service) can be used to maintain this virtual common picture of the world.

Maybe next time you board a plane - have a look for GML in the cockpit.

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.