In summary, the most important concepts that the group think need to be addressed by the model are:
There are a number of existing architectures that should be used, such as the TCIP and ITS architectures.
Every transit operator tends to do things differently. A common data model for transit objects would help to bring some standardization, but must also support the different approaches that different operators take.
The object model must support multiple scales and support the ability to aggregate objects at one scale into objects at another scale.
The object model must support temporal data. Data must also be supported at different scales and the object model must support these different scales. For example, engineering and planning users tend to use different scales.
It must be possible to aggregate objects in more than one way. For example, data relating to stops could be aggregated to a long bus route or they could be aggregated at a transfer points or terminus.
TCIP objects should be reused to the extent possible.
In general existing transit models and applications should be reviewed. There are a number of existing AVL, a PC, and scheduling packages that incorporates data models. One important role of the data model will be to help users to integrate data used by these packages with other data.
It is vital for the data model to be able to deal with logical and physical (or spatial or geometric) objects separately, but to maintain and make you solve linkages between them.
The model must support 3-D overpasses and buried cables under railway lines (in other words, nonplanar feature relationships).
Modeling transit involves more temporal than spatial aspects. The model should support these well.
The model should support Section 15 reporting (which includes vehicle miles along various kinds of roads) and HOV lanes. It is not enough to be able to say that a carriageway has and HOV lane, or that a bus travels along carriageway. It must be possible to define topological relationships between these.
It must be possible to relate a logical bus network to underlying logical and geometric street networks separately.
There must be a vehicle object. This object should be extensible. (There was some discussion about whether separate objects are needed for people and vehicles).
The model must deal intelligently with different sides of the road (pedestrians will always wait only on one side off the road).
Network barriers need to be more flexible.
The model should facilitate compilation between different logical transportation networks and between logical and physical transportation networks.
It must be possible to model fares in a number off different ways. These include by routes, by time on the day, by origin and destination, by distance, and by fare zone.
The model should support the calculation of mileage for federal (Section 15) reports. This includes calculating HOV lane usage.
The model must support multiple owners off transportation network objects and underlying physical features. For example separate cities must be able to maintain their own lines (this raises border issues). Different work groups within one agency must also be able to maintain different properties of bus stops.
The model must support different implicit and explicit location descriptions for stops:
The model must support real-time travel time forecasting (e.g. displays at bus stops indicating when the next bus will arrive there).
The model must relate scheduled times to actual times.
The model should support "Smart Bus" technology. This means that the bus contains a database and network. It needs to know what it is meant to be doing (its block, which includes everything the vehicle does from when it pulls out of a garage to when it pulls in again) and relate this to actual data being recorded by various sensors.
Model must support a hierarchy of stops:
The model must support the ability to collapse and explode shapes. For example, a transit center can be exploded to show all of its stops or represented as a single point. The model should incorporate functions for such collections all of features:
The model should support path optimization
In addition to listing these points, examples, problems, and things to be addressed by the model, the group spent some time discussing the process of developing the model. The following points were made.
There are many more things that the model has to address than the 30-odd listed above.
Research should be done into models, object descriptions, and terminology that is already out there.
The multi-modal aspects of the model must incorporate participants from CVO and freight sectors, as well as water transportation.
Paula Okunieff and Ken Dueker should be invited to participate in the consortium.