A recent Perspectives column in V1 Magazine noted the potential for using intelligent 3D city models for airports. At Galdos, we believe this is definitely true, and not only for airports, but for many other types of transportation infrastructure including rail stations, and seaport facilities. Furthermore, suitable city models can be used to provide effective functional semantics that could support various types of simulations for traffic management, noise abatement and other applications.
While a lot of the attention garnered by 3D models has emphasized visualization, we believe that this is only the tip of the iceberg of their utility in a host of applications. Intelligent models are intended not only to support visualization but various kinds of planning and operations related to structural upgrades (e.g. civil engineering) and its impact on thermodynamics, acoustics and business function. How do intelligent city models help?
I would define an intelligent city model as one that is based on a semantic model of a city, with objects in that semantic model for common components of the city representing the built infrastructure such as buildings, parks, transportation surfaces, and utilities (water, sewage, etc). An intelligent city model enables not only the description of the physical properties of these components in terms of a consistent 3D geometry and topology, but also the relationships between these components. Furthermore, such an intelligent city model must enable dynamic simulations to assess the impact of both planned and unexpected events.
Since there is no way that any a priori semantic model can be complete in and of itself, any such model must evolve over time, which requires the models to be extensible with well defined mechanisms for creating new types of model components and relationships between them.
Today there are two key candidate standards for the description of such intelligent city models, namely CityGML (OGC), and IFC (Building Smart). The former is a GML (Geography Markup Language) application schema developed for the overall spatio-semantic modeling of cities, while the latter, IFC (Industry Foundation Classes) is targeted more at the design and construction process for buildings. While we believe that both have roles to play, this article will focus on CityGML and its potential for the modeling of transportation infrastructures, and more specifically that of airports.
The complexity of airports can be explained in a detailed intelligent city model.
The Details of CityGML
CityGML provides a multi level of detail (LOD) model, with five levels of detail from 0 through 4. The levels progress from a very coarse regional/landscape representation at Level 0, to a block model of a city at Level 1, through to most detailed Level 4 (LOD4) that provides walkable interior room details including the placement of furniture. Any city object can exist in all LOD’s simultaineously, and these different representations may be related to one another simply by a “generalizesTo” property, meaning they need not have any common geometry or non-spatial properties.
CityGML scales from a landscape representation all the way to building interiors.
CityGML provides a set of core themes including buildings, transportation surfaces, water bodies, city furniture, and vegetation. These objects have standard geometric descriptions, as well as other object specific properties. In addition to these core themes, CityGML has two extension mechanisms, namely GenericObjects, and the more formal Application Domain Extension (ADE), the latter being effectively a GML application schema that is rooted in the CityGML type hierarchy. This extensibility aspect of CityGML is key to its application to urban transportation infrastructures.
If we consider CityGML for the modeling of an airport, it is clear that we need to create extensions in order to represent specific objects of interest in the airport domain including control tower (building), parking lots (transportation surface), runways (transportation surface), taxiways (transportation surface), terminal (building), microwave radars (city furniture), building mounted radar (building installation), rental car facilities (building, transportation surface), fences (city furniture), aircraft (new object type), service vehicles (new object type), passenger-related vehicles (new object type), and jetways (building parts). Some of these entities might be captured, not by creating completely new objects, but simply by providing appropriate values for CityGML codelist entries such as for BuildingClassType (e.g. habitation, recreation, business), BuildingFunctionType (e.g. hangar, traffic control tower, customs), BuildingFurnitureFunctionType (e.g. lighting, screen, passport reader), RoomFunctionType (e.g. ticketing, security check, lounge). Which approach is taken will depend on the nature of the applications to be supported. If we need only the function, form and dimensions of a room (e.g. security check area), the codelist approach is likely sufficient. On the other hand, if we need to model details of the airport taxiways, then more object specific properties will be required, and an ADE would likely be more suitable.
Airport Complexity
An interesting aspect of an airport, is that there are a great diversity of vehicle types, some of which are restricted to quite specific traffic areas, while others admit a multiplicity of vehicle types at all times, and some admitting more than one vehicle type only in very specific circumstances. For example, a passenger bus within the air terminal area, is typically restricted to quite specific traffic areas which are specifically designated for that vehicle type. This is equally true for runways and taxiways, although the latter will also admit various types of service vehicles to assist in moving the aircraft, while the former would admit such vehicles only in emergency circumstances such as a crash landing or a fire.
CityGML can describe roads and access pathways inside and outside an airport.
Information specific to air traffic management and airport operations are best described using another GML language, namely AIXM (Aeronautical Information Exchange Model). This language is a key part of the US NextGen and European SESAR programs, and is used to communicate information about several aspects of the air traffic domain including flight paths, airports, taxiways, etc. A particularly important application of AIXM is to the encoding of NOTAMS (notices to airmen) in order to provide both human and machine to machine connectivity. AIXM provides a rich set of objects for describing airports, events and air navigation from an operational standpoint. Objects like runways, taxiways, aprons, terminal arrival areas, and vertical structures (and many more) are defined in AIXM. But AIXM is about much more than airport geography. It is concerned with the state of these objects (and many others) from the point of view of flight planning and airport operations. For this reason, AIXM makes heavy use of GML dynamic features, which allow an object to be scheduled for different uses at different times or have a history of time varying properties. Thus we can have a RunwayDirection which is different in the morning than it is in the afternoon, or a RunwayVisualRange that changes from one hour to the next.
A useful, intelligent model of an airport requires that various views of the airport be integrated. CityGML can be deployed (with some extensions) to describe the physical facilities, and serve as a foundation for design and simulation tools for a range of applications including interior and exterior traffic management, security planning, as well as the visual aesthetics of the airport in the surrounding community. AIXM on the other hand describes the mechanics of operating the airport as an airport. Some objects such as a Road or Runway might appear in both representations, and visualization and simulation tools might be configured to make use of both of them in different contexts.
This brief examination of CityGML and AIXM in the context of modeling an airport reveals an interesting area of cross over and extension between these two grammars, one that might be applied in many other domains. For example, we might look at using CityGML in concert with ITSGML (Intelligent Transportation Systems), or a “VTSGML” (The point is that we get the most out of our City Model, if we are able to integrate the physical objects of the city (port, airport etc), with information exchanges that relate to the use of that “city” or facility. I believe this is a fruitful direction for future standardization efforts.
