Issue link: https://read.dmtmag.com/i/75042
Moving Toward a Global Geographic Content Standard BUILDINGTHEGEOWEB I n the last "Building the GeoWeb" column, I looked at how Geography Markup Language (GML) is increasingly coming of age (see "Is GML Coming of Age?" GeoWorld, April 2012, page 30). Faster computers, combined with new parsing and compression techniques, allow GML to be used where previously only binary encoding schemes were practical. Now the openness, expressiveness BY RON LAKE and flexibility of GML can be made avail- able everywhere, erasing the boundaries between CAD and GIS. Together with GMLJP2, it can provide a unified frame- work for imagery and vector data alike. Some countries, such as The Netherlands, already are well down the path of using GML as a national mapping standard and have defined several national content standards (GML Application Schemas: Top10NL, 3DNL and IMGeo), which are leading to a unified geographic encoding standard spanning GIS and CAD, offering a range of detail levels from individual rooms to coarser representations for buildings, cities and the entire country. It's not inappropriate to think in terms of a transnational encoding standard, based on GML, for all geographic objects across the globe. CityGML Leading the Way As many of the Dutch experiments have shown, CityGML may be a good starting point for developing a trans- national standard. It offers multilevel detail support, rather than using the notion of scale. In most applica- tions, there's a rough working dynamic range: the ratio between the largest and smallest objects of interest. For an entire province 200 kilometers across, for Ron Lake is president, Galdos Systems Inc.; e-mail: rlake@ galdosinc.com, blog: www. galdosinc.com/ archives/category/ media-center/blog. 30 example, there are few problems where users need to know the dimensions of objects only centimeters across at the same time. Using multiple levels of detail enables one to match the level of detail to the nature of the application and, at the same time, retain consistency of the overall model (e.g., an object can have multiple related representations). Moreover, CityGML is an intelligent or semantic model. Objects in CityGML correspond to "real-world" entities such as windows, buildings or traffic areas, which should be thought of as commonly understood GEO W ORLD / JU L Y 2O12 concepts rather than English words. CityGML then uses "code lists" (e.g., Building Type) to further refine these objects. This makes it easy to localize CityGML for specific natural languages to handle buildings, traffic areas, etc., that may be specific to particular parts of the world. CityGML also is extensible. Although it contains a reasonable complement of object types (i.e., structural, administrative concepts), one doesn't have to look far to see objects that aren't available (e.g., windmills, telescopes, cranes, wharves, etc). These could be described as "buildings" or CityGML Generic Objects. CityGML, however, offers a more robust solution in the form of Application Domain Extensions (ADEs), enabling these new object types to have their own properties and specific structure. Because most of these objects are globally understood, it's easy to see a global library of such ADEs being made avail- able in the near future. Another reason for promoting CityGML is its topo- logical integrity. Whether dealing with 1-D networks, 2-D traffic surfaces or complex buildings, this is an essential requirement for a wide variety of applications involving routing, cut-and-fill construction operations, building renovation and demolition, and many others. A Single Model Adopting CityGML (with appropriate ADEs) as a global mapping standard would readily support many requirements for information sharing to deal with complex cross-border issues such as traffic manage- ment; pollution and environmental degradation; and management of rivers for navigation, power genera- tion, irrigation and provision of potable water. Suppose all of Europe was to adopt this approach; a single European model could be created almost overnight. Registries could be deployed with core CityGML Schemas (GML Application Schemas) and ADEs, supporting the requisite code lists in all European languages. Furthermore, such registries could provide globally unique IDs for all CityGML core and ADE object types, enabling complete transparency of object types across all European languages—just as for code lists. With such an infrastructure in place, it would be easy to embed CityGML instance data inside JPEG 2000 images (using GMLJP2), and such data (image and embedded vectors) would be instantly usable anywhere in Europe, regardless of location. In collaborative activities across national and linguistic borders, each party would see the world in their own language, with complete consistency. Of course, if it can work in Europe, it can work across the globe. What's holding us back?