CityGML Comes of Age

By Adena Schutzberg

Over a bit of Halloween candy on the last day of October, a small but technical group gathered at Harvard to learn about CityGML from its principle author Thomas Kolbe, professor at the Technical University of Berlin. The presentation's title warrants exploration: "A Shared Vocabulary for Representing Cites in Three Dimensions." [Ed. Note: Directions Magazine published an article on the topic by Dr. Kolbe in 2005 which provides background.]

First, let's talk about the word "vocabulary." That's not a word we use much in geospatial, but it's an important one because without a defined set of words that represent objects in our databases, there can be no data sharing. Next, consider "representing." Many of the 3D representations we see today are simply visuals (bird’s eye views in Virtual Earth, blocky and not-so-blocky buildings in Google Earth and other 3D worlds). The representations Kolbe speaks about are far "smarter" - like the "smarter" objects we use in GIS. We take some pride in knowing our "points, lines and polygons" or "hydrants, rivers and building footprints" have spatial and non-spatial knowledge. Finally, think about "cities." CityGML is an interesting animal since it sits between the world of large scale building information models (BIM) and small scale GIS and LIS coverage.

With those terms as a starting point, let me share some of the big ideas I took away from Kolbe's talk.

The motivation for CityGML is interoperability. The motivation for interoperability, per Kolbe, is that spatial information is expensive! Thus, sharing is a necessity. "We don't," as Paul Cote of Harvard noted in his introduction, "want to make models of places that have been modeled before." But, to get to sharing, argued Kolbe, we need several types of interoperability:
  • Syntactical interoperability - defined protocols and formats
  • Semantic interoperability - ensuring we all share the same "image" for a defined object (i.e. is your image of a building the same as mine?)
  • Schema interoperability - a common data model (this follows from semantic interoperability)
More than Visualization
Kolbe acknowledged that much of the use of 3D models today is for visualization and inspection. What do things look like now, and what might they look like if we put in a road? But, 3D models can be used for far more; he offered applications including disaster management, cell phone transmission/propagation research, driving simulations (putting a policeman in a real car inside a simulator to practice real world chases) and 3D in-car navigation.

He described such models not as "virtual reality" but as "parallel to reality." And, these models, instead of having just one quality of those in the real world (what the object looks like), have both that look (geometry) plus many other properties (attributes). Thus, in the world of 3D modeling we need to move from the GIS paradigm of "point, line, poly" representing "hydrant, river, building footprint" to one of true objects. So, from a colloquial standpoint, instead of saying, "This line is a river," in a model, we'd say, "This river [object] has this [linear] geometry."

The 3D Model
So what, then, is the new sort of 3D model? It has several properties:
  • Completeness (covers entire geography)
  • As observed (this is, not what might be, but what is)
  • Includes both built and natural features (buildings and roads, as well as trees and ponds)
  • Includes 3D geometric, topographic, semantic and appearance information
What can you do with it?

(1) Query it! You can ask much more detailed questions than are possible with a GIS:
  • From which windows of which buildings can I see this feature?
  • Which floors got wet in a flood of eight feet?
  • Which halls in town seat 500, have a 3D projection system and are with a half-mile of public transportation?
(2) Enable semantic-supported navigation

Instead of making an individual who is less than comfortable with a 3D joystick or mouse "drive" in 3D, it's possible for him to "request" a tour. He might request that the system, using the model, create a tour of the city focusing on buildings with fewer than 10 stories while traveling down the sidewalk.

(3) Navigation for Robots

Not only do we humans need to navigate the city, but in time, so will our robot helpers. Kolbe is confident that robots will be doing much of the surveying in the future. So, we'll need to route them safely. (Yes, a Roomba-like device may be out mapping your neighborhood!)

(4) Urban Data Mining

Take the idea of marketers finding people who buy their product (say a Lexus), determining their demographics, then finding others of that demographic to buy more of those vehicles. That uses data mining. What if we could do that in cities? How about finding buildings with similar characteristics? They could be physical properties that could be used to predict and prevent future failures: "This building had water damage, a fire and a new heating system put in, and then it fell down. Can we find others that might fit that same profile?" Or they could be other properties - like cost or insurance similarities.

(5) 3D Cartography

We need to find better ways to show off the models. Today's visuals, be they "ugly" block models or photorealistic renders, may not "answer the question" posted. To answer the question "What businesses are along my route?" we would need intelligent 3D label placement. Kolbe showed some videos where label information was taken from the model and placed "over" the storefront, making it very clear what was where. He also showed a "sketched" version of a 3D model, like you might draw on a napkin. This, instead of showing reality, was a rendering that highlighted specific things - the number of stories a building had, along with its potential "inaccuracies." It basically filtered out the information that was not of interest for that use - such as the actual look of the buildings!

Users of 3D Urban Models
Both those who create data and those who produce applications need an agreed-upon model to allow them to invest in the technology. They, and their customers, come from a variety of areas. It's those players, from a variety of areas, who are behind CityGML. Kolbe's illustration showed the 3D model in the center and a variety of disciplines around the outside. They may use the models for their own purposes or they may share information via the model with a second discipline. The sample disciplines included: cadastre, tourism, environmental protection, architecture/urban planning, real estate management, urban facility management and training simulation.

Now, those players and others work at a variety of scales and use models that reflect the needs of those scales.

At one end, the largest scale, there's the construction engineer putting in a heating system - it's in one sort of model framework. Those designing the building might use Industry Foundation Classes (IFCs), models for AEC. Those in real estate may want broader information, at an even smaller scale in a 3D model in CityGML. IFCs go up to about the "site" level and CityGML goes from there to smaller scales. There is some overlap, to be sure.

CityGML holds the 3D model. It is:
  • a vocabulary for buildings, vegetation, roads, water features, terrain, traffic, etc.
  • an exchange format and a model
  • currently an OGC Best Practices Paper (expected to be a standard as of July 2008)
  • a subset of GML 3 geometry (there are no curved lines or surfaces)
  • an application schema of GML (that's a unique implementation with a specific vocabulary for a specific industry)
CityGML has five Levels of Detail (LoDs), each aimed at a different purpose. Each object may include information for each level of detail. Looking at some models, it seems sort of silly to see that one property of a road or a sidewalk is that "it's where traffic travels." Kolbe made it clear why that needs to be in the model: "It's obvious to you, but it's not obvious to the computer." It’s that sort of information in the model that enables us to ask the complex queries suggested above. How can a system route a robot if it does not know where the traffic runs? (The goal would be to keep the robot out of traffic.)
The five consecutive levels of detail LOD 0-4 of CityGML. Ascending LODs mean both an increase in geometric precision and thematic granularity. This image appeared in Kolbe's 2005 article. (Click for larger image)

It's worth putting CityGML in perspective. CityGML occupies the middle of a food chain of languages that beget languages. Extensible Markup Language (XML) is a meta-language - a language designed for the creation of languages. It spawned, among others, Geography Markup Language (GML), also a meta-language. That, in turn, spawned CityGML.

Now, CityGML can also spawn specific languages for specific uses - say for disaster management, or architecture, or real estate. CityGML is extensible in several ways. You can:
  • add new attributes to existing objects
  • add new feature types and relationship types (how multipart objects are put together, for example)
  • use the model inside other models
CityGML is in wide use in Germany, with about a dozen cities implementing such models. All have, or will soon be creating, a complete model. Here in the U.S. the focus seems, at this time, to be on BIMs, but the sense is that the interest in full city models will grow. My sense from the discussion after the presentation was that in Europe such interest came from small scale issues (planning, GIS, land management) and that in the U.S. the move will be from large scale (BIM) to city models. Those interested now include the Coast Guard and perhaps the Air Force, which manage campus-like areas.

During the Q and A several questions came up related to managing time with CityGML models. That is, "How are buildings that have been torn down managed?" For now, buildings have dates associated with them, but there is discussion of versions, or tagging them with "existing" versus "planned."

My question was practical: how are these CityGML models built? The answer is both from CAD and GIS software (ArcGIS in particular). (See the list of software supporting CityGML.) One answer was most interesting: one solution involves airborne LiDAR and Safe Software's FME.

When I first heard of CityGML some years ago, I didn't "get it." Today, with much more experience viewing and even playing with models in tools like SketchUp, I believe more of the world, myself included, is ready to embrace this higher level model for our cities.

Published Wednesday, November 7th, 2007

Written by Adena Schutzberg

© 2016 Directions Media. All Rights Reserved.