GeoWorld April 2012

Issue link:

Contents of this Issue


Page 29 of 31

Is GML Coming of Age? BUILDINGTHEGEOWEB A lthough encodings such as KML and, to a much lesser extent, GeoJSON have gathered a lot of press, there's mounting evidence that Geography Markup Language (GML) is coming of age. Ten years ago, the notion of GML Application Schemas (vocabularies writ- ten in GML for a particular application domain) wasn't much more than ideas on a PowerPoint presentation. But today there are dozens of these BY RON LAKE application schemas, and some of them (e.g., AIXM (aviation), DIGGS (geotechni- cal engineering), CityGML (urban model- ing), GeoSciML (geology) and WaterML (water supply)) are emerging or already are significant standards in their own right. In addi- tion, there are likely hundreds more that are used within specific organizations for internal information sharing or sharing information with customers. The extensibility and rich set of geometries in GML—and its ability to support time, dynamic (time-varying) features and coordinate reference systems—has long meant that GML is an effective solution to the BIM/GIS/CAD integration that so many have been dreaming about. Moreover, as GML is XML, it's (to a degree) human readable. But more importantly, it's machine readable, so it's compara- tively easy to integrate GML into new environments as well as create intelligent search, analysis and simulation functionality. Ron Lake is president, Galdos Systems Inc.; e-mail: rlake@, blog: www. archives/category/ media-center/blog. 30 Inherently Extensible In the context of information sharing and collabora- tion, there's increasing understanding that this is most important in the urban landscape, where CAD, BIM and GIS must integrate. Here, GML can be considered "the only game in town." Collaboration is impossible without a common vocabulary, and GML provides the ability to define and utilize that vocabulary regardless of the vendor technologies employed by different participants. Because GML is a language to create application vocabularies, any such vocabulary is inherently exten- sible, as illustrated by CityGML (urban modeling) and DIGGS (geotechnical engineering), to name just two. If GML has all these advantages, then why isn't it more widely used? Many have pointed to the GEO W ORLD / AP R I L 2O12 New parsing techniques enable fast processing and display of GML data, such as in this example of a house. specification's size, which runs to a few hundred pages. Others have referred to the complexity of XML as well as the number of elements and type defini- tions. I can't accept either of these reasons. The GML specification is smaller than specifica- tions such as SQL, and it's not much larger than that for KML. GML is simple (object/property/value), and the specification's length is because it offers a large number of object definitions, just as a phone book has a simple model (name, address, telephone number), but contains a large number of entries. I believe that the issue, until recently, has been that of performance—memory footprint and the time to process GML for typical tasks such as visualization. This is about to change in a major way. No Looking Back Ten years ago, the idea of storing hundreds of thousands or millions of GML features would have seemed fanciful. I used to hold up a 3.25-inch floppy disk and say it could hold a thousand features. Today, using the same metric, a smaller device would hold 10 million-plus features. With simple compres- sion schemes, that number can easily be increased by a factor of ten or more. Ten years ago, it was a challenge to process a few dozen features (e.g., drawing a map). Today, with modern parsing techniques and larger machines, quickly processing tens or hundreds of thousands of features is possible. As an example, the CityGML LOD4 house shown in the accompanying figure is fetched and rendered in as little as 800 milliseconds on my laptop—that includes all interior details of the rooms, including furniture. Handling 2-D data with hundreds of thousands of features in the client at once now is quite practical. Ten years ago, people said "GML is very flexible, but it's too verbose, too deeply nested." In XML, elements are nested inside one another, and the depth refers to how far down such nesting goes. One might note that in my example (the house), the worst-case depth was 13. The implications for GIS are significant. GML is flexible, extensible and easy to process. Now it can perform! Let the symphony begin. Mobility/GPS Special Issue

Articles in this issue

Links on this page

Archives of this issue

view archives of GeoWorld - GeoWorld April 2012