Vancouver, Canada July 24 – July 28, 2006

The past several years has seen the emergence of two key components that are the foundation for a revolution in the world of geographic information. The first is the realization of the importance of geographic information in the world of commerce. While long understood by the professional GIS community, it has taken the search engine community with its focus on advertising and broad information access to really bring this into the consciousness of the everyday citizen. The second is the arrival and broad acceptance of markup languages (XML) and web services, and their common adoption in the world of the professional GIS and the new world of mass commercial utilization of location information. Together these two components provide the fuel and the technology base to build a new location-enabled economy.

The GeoWeb conference aims to bring together two worlds which up to now have been largely separate: the world of professional GIS – the world focused on the standards of the OpenGeospatial Consortium (OGC) and ISO TC/211, and the broader world of the web – the world focused on the standards of W3C and allied technologies. It is the belief of the conference organizers that important synergies will come from this interaction in terms of business opportunities, business and policy models, technology development and specifications.

On the technical front, the conference will continue the themes of the successful GML and GI Web Services (formerly GML Days) conferences from which this conference has evolved – but will expand to include not only GML and OGC web services (WFS, WMS, WRS etc.), but also LandXML, geoRSS, KML, J-PIP and several others. It is our belief that the in-person interaction enabled by this conference will serve to unify the standards world for both developers and the business people and enable the rapid emergence of a GeoWeb – a spatial infrastructure – providing accurate, real-time geographic and geographically related information across the spectrum of government, corporations and the private citizen.

On the business front, the conference will provide opportunities to explore and develop new business models, recognizing that it is business itself that must provide the engine to make the GeoWeb a reality. Issues of government policy, needed legislation (or removal of legislation), security, identity, privacy, monetization and access control are all key issues with respect to geographic and geographically related information – and their discussion and resolution will be a key conference theme.

The GML and GI Web Services conference (http://www.gmldays.org) has shown an international reach since its inception in 2002, and we anticipate that this will both broaden and deepen in the context of GeoWeb 2006. Google Earth, MS Virtual Earth and Yahoo Maps have shown the worldwide excitement generated by the world itself – fusing a local and global focus – this is the key to the GeoWeb.

GeoWeb 2006 will be held in Vancouver, Canada.

In a previous note we introduced the concept of GML Observations.  Observations can be used to record everything from tourist photographs to scientific measurements. An Observation might also be used to capture the acquisition of an aerial photograph or satellite image.  (We will deal with this case in a future posting!).  Today, I would like to talk about the use of GML Observations to records observations about geographic features, either ones that already exist, or ones which are newly created or discovered.  This is a particularly interesting application of GML observation and one that is growing in popularity.

Here is the basic idea.  Features represent objects (things) of interest in your application domain. Features can include things like airports, countries, dams, bridges, buoys, sea lanes etc.  Features are described in GML using application schemas defined by the user or by a user community.  One can capture features and then insert or update them in a WFS by direct transactions.  That is one way.  There is, however, another.  We can have observations about features.  If I go "into the field", I can observe/record that a certain road segment has a particular geometry, or is a gravel road, or now has 3 lanes where previously it only had 2.  I could record in my GML observation that the road no longer exists (e.g. a decomissioned forest access road).

Observations in GML ARE features and hence can be inserted,updated,deleted etc using WFS transactions.  These transactions then record the observing ABOUT the features in the real world, and can be used to record observing about GML features in a database (WFS) that reflects the state of these real world features.  The GML Observation has a <subject> or <target> property that can pint to the feature to which an observation refers.  The value of this <target> property can be written using the GML remote property as:

    <gml:target xlnik:href = http://www.myfeatures.org/featureset.xml#r21 />

The balance of my observation then can describe the values of properties of that feature target.  Of this requires that we construct an application schema for observations that restricts the values of the <resultsOf> property to the desired feature properties.

How then do these observations actually impact the features to which they refer?  This of course requires an application that can examine the incoming feature (say post comit in the WFS) and decide if the feature in question should be updated or not to conform to the observation.  Perhaps the observation is flawed in some way?  Perhaps the existing values of the features properties must be taken in to account?  This cannot be decided by the GML alone - and requires that an external "policy" or rule be used.

It is clear that KML is a success in the sense of attracting the eyeballs of the world to Google Earth. As I have said here, and elsewhere, Google Earth is an impressive achievement. It redefines how consumers think about location information. Google Earth provides a complete application with a supporting environment incorporating both maps and images on a global basis. It is this aspect that is more impressive than any other!  In fact, the genius of Google Earth is that it is a communication mechanism between people.

In terms of KML - Google's language for referencing places on the earth "LookAt" at this place - and to symboloize that "PlaceMark".  "Here I went on holidays" - "Look at me on the beach".

This is clear. It is equally clear that maps on Google Earth are not yet available in KML nor is it likely that the data underlying these maps is based on KML.  What then are the functions of KML.

It seems to perform several functions, including:

• Encoding of geographic features.
• Expressing styling rules for the graphic (map) visualization of geographic features.
• Expressing the actual graphical appearance of the visualized geographci features.

Encoding Geographic Features

• <LookAt> - where to Look at on the earth.
• <Point> - presumably the Point on the earth where the Place is located?
• <visibility> - the visibility of the symbol for the PlaceMark on a Google Earth map.  Enables the PlaceMark to be visible or invisible.
• styleURl - refers to a style that may exist remotely.   The Google documentation (http://www.keyhole.com/kml/kml_doc.html#Placemark) does not make it clear where the <Style> element appears in <PlaceMark> but it the <Style> definition says it can be used within a <PlaceMark>.

One could easily create a GML representation for <PlaceMark>, treating it as a GML feature.  So far so good.  What about using KML to represent other geographic features?  It seems unsatisfactory to say that all geographic features need to be represerted using <PlaceMark>.  How would we encode say a building with a polygonal extent, a number of floors, a height, a position, a type (e.g. Church, Police Station etc), and the date when the building was erected.  This is less clear, based on the existing documentation. One could use the <Schema> construct something as follows:

It is not clear from the documentation just how one uses the created <Road> element, nor how one might express restrictions on the geometry properties of the object, nor how to express relationships.  At least as far as the provided documentation goes, KML seems a pretty limited basis for representing geographic objects.  KML does not appear to clearly differentiate between an object and the visual appearance of that object in Google Earth.

Styling rules for the graphic (map) visualization

KML is not only a language for representing geographic objects, but also one for the expression of styling rules for the graphical representation of those objects.  This is handled in KML using the <Style> element. The <Style> element provides limited abilities to specify the visual properties of text, point, line and polygon geometric elements. A Polygon can be filled with a single solid colour for example, and it can it have a boundary or not.  There does not appear to be a way to determine the colour or weight of the boundary curves.  There appears to be no means to fill a polygon with hash or other patterns nor to fill it with symbols.

There does not appear to be any ability to express styling rules that depend on the characteristics of a geographic feature - for example a <Road> with three lanes should be a thick red line, while a <Road> with two lanes should be a thin yellow line.

Since KML does not clearly distinguish feature representation from graphic visualization, it is hard to say that KML really provides a Style Language such as in GML default style, or OGC SLD (Styled Layer Descriptor).

Graphical Encoding

KML is focused on visualization within the Google Earth application.  As noted above, the <Style> elements above can be interpreted as style rules (weakly) or as simply specifying the graphical output in Google Earth.  In this sense, KML is similar to SVG, but with 1) a binding to Google Earth and 2) description of geometries in WGS84.

Geography is not only concerned with space and neither is GML. The temporal.xsd schema (see http://schemas.opengis.net/gml/3.1.1/base/temporal.xsd ) contains a set of useful definitions for time related objects and properties.  The simplest of these is TimeInstant.

A TimeInstant is what it says - an instant in time. It has a single child (property) called timePosition.  A TimeInstant is thus written:

Of course not all times are instants - some are TimePeriods.  For these we can write:

Of course GML can provide a number of ways of expressing time durations and time lengths as well and can deal with non-ISO times and dates (need a Geological Calendar?) but that is beyond our scope for now.

Ever wanted to take a photograph and then record it along with the location and time at which it was taken?  Ever wanted to post those on the web?

GML Observation was in part created for this purpose.  What does it provide?

A GML Observation models the act or the doing of the observing.  It is a GML feature.

It has the following properties:

• location (point, line, area) of the observing
• time of the observing
• resultOf the observing (this can be a link)
• using - how the observing was done (what was used in doing it) (can be link)
• subject or target of the observing (can also be a link)

If you can deal with a feature, you can deal with an Observation. You can use the concrete GML observation "out of the box" or create your own custom ones.  There is even a concrete DirectedObservation which adds a direction of looking to the above properties.

Look at the notes on styling (see further down in this BLOG) to see how to put your observations on a map.

I have noticed of late a number of requests on the Google Community site for 1) an XML Schema for KML and 2) Some attempt at converging KML with GML. To help this process along I thought would post some observations on the GML/KML overlap.

Purpose:

GML is intended to describe geographic objects. It uses application schemas written in XML Schema for this purpose.  It is NOT intended for graphical display. It leaves this to other grammars like SVG.

KML is one tool fits all. It defines geographic objects and their styling and their graphical representation. It uses schemas as part of the object description component, but uses its own schema language.

Syntax:

Since KML and GML serve different purposes they can only really be compared on their ability to describe geographic objects. 

KML provides a basic geometric objects including Point, LineString, Polygon.  Its geometry model is identical to GML v1.0 and 2.0.  Note that GML 3.0 is an extended version of the GML 2. geometry model.  Here is a comparison for a Polygon in KML and GML.

KML Polygon: (from the KML Reference http://www.keyhole.com/kml/kml_doc.html)

<Polygon>
   <outerBoundaryIs>
      <LinearRing>
         <coordinates>.....<coordinates>
      </LinearRing>
   <outerBoundaryIs>
<Polygon>

In GML this would look like:

<gml:Polygon>
   <gml:outerBoundaryIs>
      <gml:LinearRing>
         <gml:coordinates>.....<gml:coordinates>
      </gml:LinearRing>
   <gml:outerBoundaryIs>
<gml:Polygon>

Note that these are identical.  I could have surpressed the gml: in these examples as everything is in the same namespace. So far KML seems to be ignorant of namespaces.

If you look at all of KML, you will see that a fair number of tags are "borrowed" from GML.  The table of contents for the KML list of elements looks like this:

o                    KML Elements

§                            <address>

§                            <altitudeMode>

§                            <begin>

§                            <color>                                      

§                            <coordinates>                             (GML)

§                            <description>                              (GML)

§                            <Document>

§                            <drawOrder>                             

§                            <east>

§                            <end>

§                            <extrude>

§                            <fill>                                          

§                            <Folder>

§                            <geomColor>                             

§                            <GeometryCollection>                 (GML)

§                            <geomScale>

§                            <GroundOverlay>

§                            <h>

§                            <heading>

§                            <href>

§                            <Icon>                                       

§                            <IconStyle>

§                            <innerBoundaryIs>                       (GML)

§                            <labelColor>

§                            <latitude>

§                            <LatLonBox>

§                            <LinearRing>                               (GML)

§                            <LineString>                                (GML)

§                            <longitude>

§                            <LookAt>

§                            <name>

§                            <NetworkLink>

§                            <north>

§                            <ObjArrayField>

§                            <ObjField>

§                            <open>

§                            <outerBoundaryIs>                      (GML)

§                            <outline>

§                            <overlayXY>

§                            <Pair>

§                            <parent>

§                            <Placemark>

§                            <Point>                                       (GML)

§                            <Polygon>                                  (GML)

§                            <PolyStyle>

§                            <range>

§                            <refreshInterval>

§                            <refreshVisibility>

§                            <rotation>

§                            <Schema>

§                            <scale>

§                            <ScreenOverlay>

§                            <screenXY>

§                            <SimpleArrayField>

§                            <SimpleField>

§                            <size>

§                            <south>

§                            <snippet>

§                            <Style>

§                            <StyleMap>

§                            <styleUrl>

§                            <tessellate>

§                            <tilt>

§                            <TimePeriod>                             (GML)

§                            <TimeInstant>                             (GML)

§                            <timePosition>                            (GML)

§                            <type>

§                            <href>

§                            <Url>

§                            <viewRefreshMode>

§                            <viewRefreshTime>

§                            <visibility>

§                            <w>

§                            <west>

§                            <x>

§                            <y>

I have annotated the elements which are copied from GML using (GML).  Styling from GML should thus be pretty easy.

So what is the difference between GML and KML (Google)?  I think one the big differences is that there is a big well known styling engine for KML called Google Earth.  If I create some GML data - what then?  Well I have to have a style engine and a rednering engine to make a map. Is that difficult? Nope - but it is not no work either.  To get a style engine is NOT so hard - just any sort of XSLT engine will do the trick. And for rendering the output of the styling process (typically SVG) you need something like the Adobe plugin for SVG or the Batik libraries to turn it into an image (PNG, TIF, JPEG).  Note that SVG allows image underlays - so that part is easy too.  Google Earth provides you a ready to hand set of images (of their choosing) with Global coverage.  So am I saying I can make my own Google Earth. Yes - I guess that is what I am saying.  Here is the basic recipe. Let's leave the Google Earth images out of it for the moment.

• You get SAXON or some other XSLT engine.  Install SAXON as a servlet.
• You write a style sheet for your GML data to SVG.
• You install the Adobe SVG plugin in your browser (or other SVG renderer)
• You create your GML data file - just like you do for Google - only following GML instead of KML.
• You create a web page that sends the style sheet reference (URL) and the data reference (URL) to GML to the servlet.
• You get back SVG which appears in your SVG viewer.
• This could be extended to include an image referenced in the request as well since SVG viewers support image underlays.

There you have your own Mini-Google.

Around the year 1999, I was talking with a potential investor about the marvels of markup and the implications for the world of GIS and the World Wide Web.  I scribbled on the paper something like:

The investor looked at me with dubious smile.  Later that day I tried my wife, who told me I should focus on something useful.  In spite of these early negative experiences we persevered and finally (in 2000) there was GML.  Neither the investor, nor my wife were any more impressed.  Nonetheless GML development continued.  Fast forward to 2005. My wife calls to tell me to look at Google Earth - it was apparently "revolutionary".  Later that day I encounter that same investor with the same "look at Google Earth" mantra. I was intrigued to say the least.  So I did. Impressed, I looked below the surface and read the KML tutorial (and later the KML reference guide at http://www.keyhole.com/kml/kml_doc.html),  What did I find?

Revolutionary indeed!!

As a looked further I realized that the entire geometry model of KML - this revolution of 2005, was an idetic copy of the geometry model of GML v1.0.  Other parts of Google KML are snippets (identical) to parts of GML 3. (e.g. TimePosition etc.).  Still further I noted that KML had introduced application schemas, not by using XML Schema as in GML, but by introducing a new schema language (as was tried an abandoned in GML v1.0).  So is this a revolution or not?  If so what is the revolutionary part of it?  Is it all just timing?

After some thought I have decided that this is indeed a revolution and for many of the same reasons that drove my thinking in 2000.  But before we get to that - why the success of Google Earth thus far?  It surely is not just because of markup?

I think the success of Google hinges on a few things - most of which are not really connected with markup.

• It provides global coverage of the earth using both maps and satellite inages. I think this is the biggest single factor.
• It provides a slick user interface.
• It enables you to place your information (Placemarks) on the map (here markup IS USED).
• It allows your information (your placemarks) to be fetched from a remote site.
• It provides a single engine that takes your information, styles it and presents it on their site. It is in effect a single, geographic application.

So where is the revolution?  I think there are several parts to the answer.

1. Google Earth is revolutionary because it brought an awareness of the accessibility and utility of geographic information to a wide commercial audience.
2. By providing an integrated publishing site - in our terms a style engine and a backround map server with global coverage - it allowed people to create simple markup that DID something - i.e. they could see it visualized in a meaningful context on their screen.

Google Earth illustrates the power of dynamic geographic data publication. This is for me the real revolution - the one we dreamed about back in 1999. Here we have the first signs of life.  From here the way forward seems more well defined.

1. The specification is thick (Over 600 pages).
2. The specification describes many objects (over 1000 tags identified).
3. GML uses application schemas.
4. GML deals with complex topics (geometry, topology, coverages).
5. GML separates presentation from content.
6. GML has an object-property rule
7. GML is written in XML Schema

The specification is thick

True.  The specification is indeed long.  It is, however, not longer than other important specifications such as XML Schema, SQL (over 1200 pages).  One might compare the "complexity" of GML in terms of the size of the spec to the complexity of a telephone book. The latter is also very thick. Any large city (where "books" are still in use) will be some thousand or more pages of very fine print. In all cases, however, the model underlying the telephone book will be more or less the same and quite simple - namely person's name, address, and telephone number.  Much the same could be said of GML.  The specification is long - but in all of the objects described there is a the same model and it is quite simple - namely and object (Curve, Point, Feature) and the object's properties.  More over this model has not changed to any appreciable degree since GML Version 1.0.  So how to read the GML "phone book" is the same now as it always was.  A simple model and a thick specification.  This is because GML is essentially a content specification - it uses a simple model to describe a large number of kinds of objects.

The specification describes many objects

This is true.  There are over 1000 tags in GML and hence a few hundred object types are described.  How should I read the GML specification?  To start with read the parts that interest you or are important for your area of application.  I you are not concerned with topology you do not need to read that section. Ditto for coverages, observations etc.  For many users, a general understanding of features and geometries is enough.  For others only coordinate systems are important.  It is just a function of the concepts you need in your application domain.

GML uses application schemas

Unlike many other XML Schema grammars, GML does not rely on a single closed schema to define GML application objects.  If you want to have a road, river or church steeple you will need to create an application schema.  Some people find this requirement complex.  It has a number of well known precedents, however, including:

• Relational schemas - to create a table in a relational DBMS you need to decide on the table structure or schema.  In the same way to create an object in GML you need to create a GML application schema using XML Schema.
• Objects - to create an instance of an object in object oriented languages like C++, Java etc. you need to create a class - the class defines a "schema" for the object.

Early in GML we considered creating a schema language in GML itself.  Thus in one of the profiles of GML 1.0 you will see something like:

<gml:Feature typeName = "Road> .. </gml:Feature>

This was an attempt to make GML only a single schema.  The difficulty with this approach is that:

• We are creating our own schema language in GML for which no tools exist or are likely to exist.
• While it might start very simple - it would likely grow into something complex like XML Schema as we added support for enumerations, ranges etc.

One might note that other geographic languages also use schemas, in particular KML (Google).  It has gone the GML v1.1 route and defined a new schema language.  At the moment this seems to support only simple types - but people will surely want more .. then what do we do.

GML deals with complex topics

This is certainly true.  The topics that underly Geography are not necessarily simple.  Since GML exposes these objects directly it provides exposure to the complexity of the objects themselves.  What is a Polygon?  Can it have holes? What is a geometry complex? and so on.  GML is the raw nuts and bolts of geography.  In terms of using GML you need only understand the objects you need to deal with ...

GML separates presentation from content

This is a common place of XML.  Lots of XML is commonly styled to XHTML or HTML for presentation.  Nonetheless this does introduce an additional level of complexity - as is always the case when a general problem (in this case map generation) into multiple constituent parts.  The parts need to be composed together to do the task - something that was not necessary when it was all one thing. Of course this decomposition provides other benefits  - the components are simpler and one can use different styling mechanisms for the same data - or apply a single styling mechanism to multiple kinds of data.  Hence this is a tradeoff.  Note that KML (Google) currently is a graphic presentation language (like SVG), a style description language (like SLD/XSLT), a geographic representation language like GML ..

GML has an object-property rule

GML provides a thin layer of semantics, namely the object property rule.  This means that if you look at GML and you find an object, the children of that object (in the XML sense) are the properties of that object - no more and no less.  The children are not sub types nor are they objects contained in the parent object.  GML properties express attributes and associations (relationship) of the parent object.  When you create an application object (e.g. Road) you are expected to follow this same rule. Properties of a Road are encoded in XML (GML) as child elements - hence:

<abc:Road gml:id ="hj1">

   <abc:numLanes>3</numLanes>

   <abc:surfaceType>gravel</abc:surfaceType>

   ...

</abc:Road>

So numLanes is always the numLanes(Road) or Road.numLanes.  GML core schemas follow this same model.  This means that a point in GML is not the minimal:

<Point>100 200</Point>

but rather the somewhat longer:

<Point>

   <pos>100 200</pos>

<Point>

where pos is the coordinates of the Point.   GML stays true as possible to the object-property model.  Note that the object-property rule, like many things in GML is borrowed from RDF.

GML is written in XML Schema

As we noted above, an early design decision in GML was that it must be inherently extensible, and that such extensibility should come from an external schema language and NOT from GML itself. In GML v1.0, both DTD and RDFS were provided as the schema languages. From GML 2.0 on we have chosen XML Schema.  This rests on a few basic principles:

• We did not want to create a new schema language just for GML.
• We wanted something that was widely used.
• We wanted something for which there were many fast parsers.

From these requirements, XML Schema as selected.  This is NOT to say that GML can only be expressed in XML Schema.  In fact there is consideration of also providing GML in OWL or RDFS (once again).  Someone may construct a RelaxNG version of GML. This would be perfectly valid. Of course this implies interoperability issues between one representation and another.

Much of the processing complexity of GML (and the visual complexity) derives from XML Schema. Some people will argue that another schema language will make things much simpler. I think this is not likely the case - at least of the schema language offers comparable functionality.  Noneless the implementation of the GML model in XML Schema does entail that GML application schema processors be able to do certain operations that are not completely trivial - such as handle inheritance tracing or deal with substitution groups.  For this reason, various vendors offer GML SDK's that hide these XML Schema details from software developers.

So while I would not call GML "simple" - it is what one might call appropriately complex!!

While perusing some other blogs I came across the following:

geek post--GML sucks

Posted on 2004.10.11 at 20:36