In this edition of his ongoing column on Building the GeoWeb, Ron Lake talks about living in a period of constant, and accelerating, change. Ron proposes the use of “model-based thinking” as a tool . . . → Read More: Building the GeoWeb: Grappling with Change]]> GeoWorld   Issue Date: October – 2009, Posted On: 11/24/2009

In this edition of his ongoing column on Building the GeoWeb, Ron Lake talks about living in a period of constant, and accelerating, change. Ron proposes the use of “model-based thinking” as a tool for Grappling with Change and a way to better plan and forecast the needs of our urban environments.

Read Ron Lake’s column in V1 Magazine – Digital Cities, SDI and the GeoWeb discussing the implications of moving towards Digital Cities.  Ron explores what a Digital City might be, the role of SDIs and the GeoWeb, and the impact of information . . . → Read More: V1 Magazine: Digital Cities, SDI and the GeoWeb]]> Monday, 09 November 2009

Read Ron Lake’s column in V1 Magazine – Digital Cities, SDI and the GeoWeb discussing the implications of moving towards Digital Cities.  Ron explores what a Digital City might be, the role of SDIs and the GeoWeb, and the impact of information technology on urban planning and environments.

Read Ron Lake’s article discussing the interconnectedness of global resources, and whether and how geography might impact the economic and political success of nation states.

The full article is available in GeoWorld’s Building the GeoWeb column for April 2009.

Ron Lake's column in V1 Magazine discusses Google Ocean and the visualization framework that it provides. At the same time, Mr. Lake points out the need to take the next step for building . . . → Read More: V1 Magazine: GeoWeb – Shaping Geographic Awareness]]> Wednesday, 04 February 2009

Ron Lake's column in V1 Magazine discusses Google Ocean and the visualization framework that it provides. At the same time, Mr. Lake points out the need to take the next step for building out the GeoWeb for oceans and providing a middle tier data integration infrastructure.

Read the full column from V1 Magazine at http://www.vector1media.com/article/column/geoweb-%11-shaping-geographic-awareness/.

According to Ron Lake, many people believe we now stand on the edge of an economic precipice, a state unknown in the lives of most of us—and perhaps in . . . → Read More: GeoWorld: Can the GeoWeb Rescue the Economy?]]> Issue Date: January – 2009, Posted On: 2/1/2009

According to Ron Lake, many people believe we now stand on the edge of an economic precipice, a state unknown in the lives of most of us—and perhaps in the history of the modern world. What's most telling is the inability of anyone to say what happens next.

Read the full article in GeoWorld's Building the GeoWeb column for January 2009.

February 19, 2009

An article in the February 2009 edition of Directions Magazine reported on the Map World Forum, held in Hyderabad, India. Ron Lake, . . . → Read More: A View from Over There – India and NSDI]]> By Joe Francica , Editor-in-Chief and Vice Publisher, Directions Magazine

February 19, 2009

An article in the February 2009 edition of Directions Magazine reported on the Map World Forum, held in Hyderabad, India. Ron Lake, president of Galdos Systems, was one of the speakers at the event, and is quoted in the article.

The full article is available on the Directions Magazine website at http://www.directionsmag.com/article.php?article_id=3042&trv=1.

The cover story of the November/December 2008 issue of Backbone magazine featured an article by Ian Harvey: "The Geoweb is remaking mapping, the Web and perhaps your own corporate Web site" based on an . . . → Read More: Backbone Magazine: Map your world – the GeoWeb]]> 17 November 2008

The cover story of the November/December 2008 issue of Backbone magazine featured an article by Ian Harvey: "The Geoweb is remaking mapping, the Web and perhaps your own corporate Web site" based on an interview with Ron Lake.

The full article is available on Backbone's website.

If one looks at most SDIs today, notes Ron Lake, they heavily emphasize a "librarian view" of the software-infrastructure element (i.e., the primary points of focus are metadata collection . . . → Read More: GeoWorld: What’s an SDI? Can It Support Emergency Management?]]> Issue Date: October – 2008, Posted On: 11/1/2008

If one looks at most SDIs today, notes Ron Lake, they heavily emphasize a "librarian view" of the software-infrastructure element (i.e., the primary points of focus are metadata collection and discovery). As a result, they’re inappropriate to support many of the use cases for which such an infrastructure might be deployed.

Read the full article in GeoWorld's Building the GeoWeb column for October 2008.

Building the GeoWeb by Ron Lake

This is Part II in a series of “Building the GeoWeb” columns comparing the schema constructs found in Keyhole Markup Language (KML) and . . . → Read More: GeoWorld: Exploring Schema Constructs in KML]]> Issue Date: August — 2008, Posted On: 9/1/2008

Building the GeoWeb by Ron Lake

This is Part II in a series of “Building the GeoWeb” columns comparing the schema constructs found in Keyhole Markup Language (KML) and Geography Markup Language (GML). In the first column (see “Exploring Schema Constructs in KML,” GeoWorld, May 2008, page 20), I introduced a reference example of an aircraft FlightLine and discussed its possible realization in KML. In this final installment, I’ll look at the same FlightLine, but in GML.

It should be noted that GML doesn’t contain a schema-defining mechanism within GML itself, but rather uses another schema language. At the present time (and for the foreseeable future), this is the W3C XML schema, but DTD and RDF schema were used for this purpose in GML 1.0. In the future, GML might be seen in Relax or some other schema language not yet defined.

Schemas play a much deeper role in GML than in KML. The following is a possible GML Application Schema for the FlightLine object introduced in the previous column:

Such a schema definition could be referenced in KML (via ExtendedData) or otherwise support GML instances that would look like the following:

Note that in the GML definition:
• Everything is defined in a separate namespace
• FlightLine is an independent object (feature)
• LineString lives in a specific coordinate system
• The role (flightPath) of the LineString in relation to the FlightLine is specified in the schema
• An enumerated type is used to describe the FlightLine “classification”

Adding Complexity

This is, of course, a simple example, but what if it becomes more complex? Suppose you have a list of city airports, and you wish to replace the arrivesAt and departsFrom property values by the airports rather than the cities, and then describe these airports by their geodetic location.

In GML, the first step would be to define a new schema for Airports and related objects. Because this vocabulary might be controlled by another organization, another namespace is used. The GML schema might look like the following:

The FlightLine schema now is changed to use reference pointers to the Airports, and a new “city” property is added. The departsFrom and arrivesAt property schemas now become:

An instance now looks like the following:

How would this be done in KML? A user would need to create Placemarks for the Airports as well as a new schema definition for Airport:

Note, however, that I removed the properties departsFrom and arrivesAt from the schema, because there’s no support in SimpleField for URLs. Furthermore, the link in NetworkLink is a URL, and one can expect that any KML consumer must dereference (fetch) the URL when seen—whether this makes sense or not.

It can’t be known from the schema for this ExtendedData, in this Placemark instance, that there’s a property arrivesAt nor departsFrom—these aren’t part of the Placemark’s definition. It should be clear that a user can’t talk about a FlightLine or Airport Placemark at all—although they may associate ExtendedData information with particular Placemark instances.

Representation and Presentation

In KML, users can’t create geographic objects as they can in GML, but they can use the schema construct to add user-defined attributes to objects for visualization in an Earth browser such as Google Earth.

Also note that in GML, one can define a library of data types that can be further extended using extension or composition, whereas KML only allows the user-defined data embedded in a KML document as a whole.

KML elements aren’t intended to be used in the content of user-defined elements. Most KML elements are required to appear in certain context; they’re not allowed to be used anywhere else.

Although KML types can’t be used to describe a user’s elements, they can have their own vocabularies (described by something other than KML) embedded in KML. Such embedded XML is usually ignored by the KML processor, with the exception of templates used mainly for documentation in balloons.

This discussion isn’t criticism of either language, but it reflects the different objectives of the two languages: GML is intended primarily for geographic data representation, and KML is intended for geographic data presentation.

Read the article on their website: GeoWorld.

Download the PDF file:  GeoWorld – Exploring Schema Constructs in KML August 2008.pdf

Building the GeoWeb by Ron Lake

Many languages, including Keyhole Markup Language (KML) and Geography Markup Language (GML), use schema constructs to express a data model. "Building the GeoWeb" will explore . . . → Read More: GeoWorld: Exploring Schema Constructs in KML]]> Issue Date: May – 2008

Building the GeoWeb by Ron Lake

Many languages, including Keyhole Markup Language (KML) and Geography Markup Language (GML), use schema constructs to express a data model. "Building the GeoWeb" will explore the nature of these constructs as well as their role in each language to help researchers and application developers deploy these standards to their best advantage.

This first column will deal with KML, and a future column will tackle GML. To motivate and unify the discussion, I’ll employ a FlightLine object example that represents information about and associated with the path of a commercial aircraft. 

KML 2.2

Schemas in KML 2.2 are defined by the <Schema> element, which has the following syntax:

Therefore, I could define a FlightLine <Schema> that assumes all of the properties are of simple type (e.g., classification (commercial scheduled/commercial charter/private), airline, and departure and arrival cities) and write the following:

This is consistent with KML’s objective to support the visualization of geographic data. But note two restrictions in this current schema construct:

1. No complex types.

2. No enumerated types defined by the schema builder (see "classification" in the example).

Placemarks

Now look at how this is used in a KML instance. The <Schema> element is the child of <Document>.

In many cases, this same Document would contain a related Placemark, but because I want to keep the definitions separate to explore the idea of a KML vocabulary, I’ll place the schema in a Document containing no Placemarks, as follows:

This file (document) then can be located on the Web, for example, at www.aviation.org/aviation.kml, referencing the contained <Schema> using www.aviation.org/aviation.kml#FlightLine. This can be done from any KML file that references the <Schema> using the <ExtendedData>|<SchemaData> construct.

For this, I can write something like the following:

The schema-defined information (ExtendedData) now is contained in a Placemark. But the following should be noted:

1. There’s no namespace assigned to the definitions—just a location for the schema. Moving the schema somewhere else could mean something different, or not—you can’t tell.

2. The role or meaning of the LineString in the FlightLine isn’t described. You don’t know whether it describes the path of the aircraft or a bounding limit on the flight zone. This could be improved by adding descriptive ID values (e.g., id = "flightPath", id = "flightLimitRight", id = "flightLimitLeft", etc.), but such items can’t be defined by the schema.

3. There’s no way to say that LineString belongs in the FlightLine definition, but Point or Polygon don’t belong. These aren’t part of the schema definition.

4. The coordinate reference system can’t be changed—there’s only the default coordinate reference system urn:x-ogp:def:geodetic-crs:EPSG:4326 with the latitude and longitude reversed relative to EPSG4326 (i.e., (long, lat) rather than (lat, long)).

5. There’s no way to add new geometries to KML to accommodate special curves such as Loxodromes or Geodesics.

External Schemas

The KML <ExtendedData> element also allows users to add content that isn’t part of KML. For example, the following KML file includes the above properties as child elements of <ExtendedData>: 

 
But the content of <ExtendedData> isn’t KML nor defined by KML; it’s anything written in the namespace with prefix abc. KML doesn’t say anything about what’s to appear in the ExtendedData element, except that it’s XML and in a different namespace than KML.

"Place-Centric"

It should be apparent that KML provides flexible mechanisms for transporting data instances and rather limited ones for defining data models. This isn’t a criticism of KML, and it fits nicely into its role as the visualization language for Internet geography.

KML allows users to refer to external schema definitions (e.g., GML application schemas) and provides a restricted schema notion to describe the data associated with a visualization. KML is "place-centric" and allows users to associate data elements with a place. It would be wrong to think of KML as a data description language or talk of KML vocabularies.

Read the article on their website: GeoWorld.

Download the PDF file: GeoWorld – Exploring Schema Constructs in KML May 2008.pdf