This is something that I’ve wanted to share for sometime now - how to use the Geography Mark-up Language (GML) for tracking things that move in the real world. GML can be a lot to get one’s head around so I hope that this real-world implementation will help you. We have been using GML for sometime now with our Titan Class Vision product.
I want to show you how GML can be used to describe flight data; the sort of data you’ll see presented in the arrival and departure halls of airports. I have a hope that the world can share a view on how airport flight information should be provided to many kinds of application.
GML provides a set of abstractions that are intended to be specialised by applications for their own purpose. Consequently we have defined a schema to describe journeys. This schema is represented by the class diagram above and is available in XSD form from our website.
Journeys describe a track between point A (departure port) and point B (arrival port). They have a scheduled departure and scheduled arrival time. A specific type of journey is a flight which has no other characteristic than its type for distinguishing itself.
A Journey is a specialisation of a GML DynamicFeature. Dynamic features are things that have a relationship to geography (as per a regular Feature) but can also change over time and record when they do so. Consequently snapshots of a dynamic feature can be expressed given the availability of a validTime element. Additionally, and importantly, dynamic features can also have a “track” element. Tracks define a set of objects that describe a feature’s status over a period of time. These objects are known as GML’s MovingObjectStatus and minimally describe the time that the status applies to (validTime) and the location of the dynamic feature. A location can also be “null” i.e. unknown; this is pertinent to us and I’ll come back to it. The other elements are also very useful when tracking the position of a dynamic feature. For example, given acceleration, speed, bearing (horizontal and vertical), elevation etc. one can reasonably predict where the feature will be next. For most flight information displays in airports though, these elements are less important (Titan Class Vision at the airport is attempting to change this situation!).
We have further specialised MovingObjectStatus as a JourneyStatus with the discriminating element being the Estimated Time of Arrival (ETA). Thus for a given validTime we can report what the ETA was.
Enough words! Let’s have an example based on our journey schema:
<j:FeatureCollection ...>
<name>Journeys</name>
<boundedBy>...</boundedBy>
<featureMembers>
<j:Flight>
<name>QF32</name>
<validTime>
<TimeInstant>
<timePosition>
2006-05-01T10:30:00Z
</timePosition>
</TimeInstant>
</validTime>
<track>
<j:JourneyStatus>
<validTime><TimeInstant>
<timePosition>
2006-05-01T10:30:00Z
</timePosition>
</TimeInstant></validTime>
<location><Null/></location>
<j:ETA>
2006-05-02T00:05:00Z
</j:ETA>
</j:JourneyStatus>
</track>
<j:departPort xlink:href="..."/>
<j:departTime>
2006-05-01T11:15:00Z
</j:departTime>
<j:arrivePort xlink:href="..."/>
<j:arriveTime>
2006-05-02T00:00:00Z
</j:arriveTime>
</j:Flight>
</featureMembers>
<validTime><TimeInstant><timePosition>
2006-05-01T10:30:00Z
</timePosition></TimeInstant></validTime>
</j:FeatureCollection>
Please note that the above is not valid XML i.e. I’ve removed the namespace declarations and the xlink:href contents so that I could fit everything on the page and just present what is relevant to this discussion. A valid version of the above can be found on our website.
The above document states, “here are the flights as at 1030 GMT. There is just one flight named QF32 which is scheduled to arrive at midnight GMT. However the current ETA is 0005 GMT.”. In the real world there would be a number of Flight elements for a given airport and a number of JourneyStatus elements if there have been a number of ETA revisions. The location is not important for most flight information displays at airports and hence we show that as having a null value.
ETA could have been included as a element of Journey. I chose to have it as an element of JourneyStatus (aka MovingObjectStatus) so that I could have a number of ETAs reported for historical reasons. Additionally the reporting of an ETA could be further analysed by location.
Plans are deemed other features (including other Journey features) that can further describe a given Journey feature. For example we have journeys that describe the frequently used flight paths between various destinations. These paths can include various way-points and record typical elevation and speed at those points.
Our schema can also be used to describe a schedule such as a flight schedule. The validTime element of a Journey feature has the potential to be used to distinguish different schedules depending on the day of the week. For example a scheduled flight might only occur on Mondays and Fridays.
I’m hoping that it is becoming apparent that more than just the ETA of a flight can be described. Firstly the structure of our schema permits the actual positions of flights at given time instances. We have embarked on consuming air radar data using our journey schema. This will enable us to render the real-time track of aircraft with our flight information display.
Secondly anything that has a journey should be able to be described. This includes trains, ships, cars and trucks - even people swiping their security cards.
In a future blog I shall describe various forms of accessing journey data using the Web Feature Service (WFS) and also how this data can be published and subscribed using an enterprise messaging bus such as IBM’s Websphere MQ and others that use the Java Messaging Service (JMS).
Meanwhile if you find that our journey schema is useful to you then please add a comment or do get in touch.
