Geo-Web

Before we look at the Simple Geometry profile of GML, a short discussion of geometry is required.  In GML, objects have characteristics some of which may be geometric.  We can talk about the extent of a Lake, the position of a vehicle, the edge or centerline of a road etc.  These geometric characteristics are described by a property of the object, which is a relationship between the object and some geometric object.

In the Simple Geometry profile of GML there are only three kinds of geometry objects, namely:

• Point
• LineString
• Polygon

Point

This one is pretty self explanatory.  A point has "coordinates" that determine its location relative to some coordinate system (e.g. (latitude, longitude).

LineString:

Think of a LineString as a curve, line or edge.  If you look really close you see that it is made up of a bunch of line segments strung together - so is a string of lines or LineString.  See the image.

Polygon:

A polygon is just a bit more complex.  A Polygon is a region or area.

Think of the state of California (all of it) as having a Polygon extent.  The boundary of the State of California is the black line around the outside.

SO Polygons have a boundary as shown in the figure.

Now Simple Geometry ONLY allows the boundary of the Polygon to made of a single piece called a LinearRing. This is a LineString that is closed on itself like the ring on your finger.

In full GML, the boundary of a polygon may be composed of separate LineStrings much as the boundary of the State of California is composed of parts of the border of Arizona, Oregon, Nevada and the Pacific Ocean.

That is it for now.

One of things that makes programmers keep programming is "feedback" and especially VISUAL feedback.  Show me it works - means show me it doing something I can see. While one of the most common things to do with geographic data is to visualized it in as create a map.  While we have talked about styling GML to SVG, we can also readily style GML to KML and use Google Earth as our drawing canvas.

Our styling will be accomplished in a straightforward manner using XSLT - keeping in the XML world.  So over the next couple of weeks we will discuss how to create style sheets that can use KML as a mapping space for your GML data.  Once we can do that - we will look at how to automate the process and dynamically style GML data from a Web Feature Service (WFS) (aka GML Data Server) to KML.

This will include:

• Styling GML features with Simple Geometry (see) to KML.
• Styling GML web publishing (observations) to KML

Official GML profiles are now being widely discussed and it is more or less a certainty that some of these will be official OGC specifications in the coming months.  Remember that GML was intended to be profiled and that a subset tool has been included in the specification since GML v3.0.  This tool enables one to readily create profiles on which particular types of application schemas can be built.  Use of profiles enables particular application domains and types of applications to only use the GML components that they need and disregard the rest. Don't need CRS schemas - well then don't use them.  Don't need topology?  Don't need coverages?  Then profiles can be quickly tailored for these requirements.  The point of profiles from a specification viewpoint is simply to provide a named reference to the profle and some simple documentation that appeals to a particular group of users.  I can say then "we support the Point profile" or we support the "GMLJP2 profile" or we support the "simple geometry profile" and so on.

To make this discussion more concrete I will describe a few simpe profiles including:

• Point only
• Simple geometry
• Web publishing

These profiles have no OGC status and are NOT OGC specifications. They are, however, perfectly valid profiles of GML and any general GML software (e.g. Galdos GML SDK) will be able to process them or data instances that conform to application schemas constructed on any of these profiles.

Just to give you a heads up, these profiles will contain the following elements:

Point Only

This will contain ONLY gml:Point

Simple Geometry

This will contain only gml:Point, gml:LineString, gml:LinearRing, gml:Point.

Web Publishing:

This will contain the Simple Geometry as above,  some time elements (see this blog), and gml:Observation. This allows to record things like "I took this picture here" or "I recorded this sound here and at this time". 

There are lots of people who want to use GML for locations, extents etc. - but don't want to subscribe to the more formal grammar of GML (object-property-value) throughout their own grammar.  Some examples might include the embedding of GML in RSS, Atom, CAP and otrher XML grammars that have a limited requirement for geographic information - but which wish to define a "property" that has some geometric extent.

For example - I might wish to associate a news story with a location.  I might write (this is not RSS per se)

 

<NewsStory>

     <author>John Lamb</author>

     <dated>10-Jan-2006</dated>

     <where>

            <gml:Point id="p21"><gml:pos>45.2 -89.7</gml:pos></gml:Point>

     </where>

</NewsStory>

In this case only the bits with the "gml" prefix are in the GML namespace (http://www.opengis.net/gml).  and the rest need NOT be a formal GML application schema.  The rest are in my web-feed grammar.

In a similar way I might use GML to disseminate information about a public alert (syntax below is NOT CAP) -  I might want to describe an alert with an impact area for the alert.

 

<Alert id="a100">

    <dateReleased>10-Jan-2007</dateReleased>

    <type>ice storm</type>

    <impactArea>

        <gml:Polygon>

              <gml:exterior>

                    <gml:LinearRing>....</gml:LinearRing>

              </gml:exterior>

       </gml:Polygon>

   </impactArea>

</Alert>

 

again - ONLY the stuff with the gml prefix is in the GML namespace and the rest need NOT be a formal GML application schema.

Why then would I want this to appear in a GML application schema?  Well to begin with it means I can use GML aware software - and not create new software to process an exploding set of XML grammars.  Additionally I know that I can use certain features of GML that are useful like remote property references.  The web feed example if it was in GML (not just the geometry part) could also be written:

subscribe to the more formal grammar of GML (object-property-value) throughout their own grammar.  Some examples might include the embedding of GML in RSS, Atom, CAP and otrher XML grammars that have a limited requirement for geographic information - but which wish to define a "property" that has some geometric extent.

For example - I might wish to associate a news story with a location.  I might write (this is not RSS per se)

<NewsStory>

     <author>John Lamb</author>

     <dated>10-Jan-2006</dated>

     <where xlink:href = "... "/>  this points to the GML geometry Point

</NewsStory>

Similarily the Alert example could become:

<Alert id="a100">

    <dateReleased>10-Jan-2007</dateReleased>

    <type>ice storm</type>

    <impactArea xlink:href = "... "/>  Points to the impact area geometry in GML

</Alert>

   

Much has been written about the utility of geotagging - meaning the attribution of location or extent to a web page.  This essential bit of metadata was part of the original Dublin Core proposals along with author, title and so forth.  Like many other pieces of metadata it has so far not gained a great deal of currency.  With the advent of "local search" and the geo-enabling of the various search engines - this may change in the next couple of years.

To geo-tag a web pag is simple enough.  One can simply add a new metadata tag that contains a location.  This can be specified by a GML point, or other geometry, or by referencing a feature (e.g. Eiffel tower).  Without being concerned with the syntax at this point, how much does this really do for us?

For some types of web pages this makes perfect sense.  The original "coverage" attribute in DC had this in mind. If I write a web page which is the history of France then it is clear that a geotag indicating "France" is meaningful.  But anything more complex and things are not so clear.

If my web page concerns multiple places  - does it help to attach geo-tags for all of the places that I reference?

If my web page is concerned with ordering physical goods, I might want to know the location of the store, warehouse or pickup depot.  These can be referenced within the web page for sure - and some means of indicating their location is clearly useful.  But this is then no longer related to the web page and is just geographic information "in the page"

So while geo-tagging in the sense of web page metadata has rather limited uses - the use of geographic information - encoded within a web page, can have significant benefits.

A web page describing a flood, earthquake or other natual disaster could contain geographic data or data references that could then be visualized as SVG or other graphics within the web page.  This could include animation or even user interaction with the information.

A web page selling physical goods could contain location information that could be combined with the readers current location (e.g. via GPS, cell zone) to providing routing instructions to the store, depot or warehouse.

Note that the information could be in-line within the web page - or can be supplied by means of references to geographic information located in an online web service such as an OGC-compliant Web Feature Service.

We will explore the syntax of this using GML in the next article.