http://creativecommons.org/licenses/by/3.0/
Megan Katsumi
While most existing work attempts to describe the network based on its physical constructs, we model the network flow and the physical infrastructure separately. The motivation for this is that the constraints on transportation flow are something that is applied to the physical infrastructure. These constraints are distinct from the physical characteristics and so should be defined separately. Although some constraints may be related, such as flow constraints imposed by the size of the lane that an arc accesses, this is a specific relationship that should be captured rather than conflating the concepts. For example, there is nothing to stop a vehicle from going the wrong way on a road, except for the flow of traffic that is imposed on the system (and these constraints may change with time). This results in the identification of two key concepts: the Transportation Network (a directed graph), and the Transportation Infrastructure (a physical feature where transportation occurs).
We relate the Network and the Infrastructure by relating an Arc to a Transportation Complex (or other Road Segment) with the "accesses" property. In this way, we may define an Arc accessing various Transportation Complexes at different Levels of Detail (LOD).
In this representation Nodes do not access the Transportation Infrastructure nor are they part of it in any way. Both Nodes and Arcs may have implicit locations based on the infrastructure they access, however unlike the infrastructure classes, Nodes and Arcs are not Spatial Things. A Node may have a control (e.g. a signal) with a physical presence somewhere else (traffic lights apply to one side of the intersection, but are actually located on the other side of the intersection); by separating the physical infrastructure and the network flow we are able to accurately represent this.
Currently, there is no need to capture an aggregate Arc; in other words, we do not require a subArc relation. It is possible this may change as the requirements evolve.
October 2017
Transportation System Ontology
icity-transportation
Developed as part of the overall iCity ontology effort, the iCity-TransportationSystem ontology is designed to capture concepts related to the transportation system.
Changes from previous version:
-Added Link and LinkPD classes to serve as “containers” for multiple arcs (e.g. vehicle lanes, bicycle lanes, walkways); introduced some additional properties and changed the mode of an Arc from an invariant to variant property.
-Associated location coordinates with the Node class.
-Extended to capture sensors such as loop detectors via SSN ontology
Copyright @ 2016 Megan Katsumi, iCity Research Group
http://ontology.eil.utoronto.ca/icity/TransportationSystem/1.1/
1.2
Under development. Please see report on iCity Ontology v1.2
Added for organizational purposes, to identify all properties defined in the Transportation System ontology.
Volume delay functions (VDFs) are defined by a combination of link functional class and adjacent land uses (which can influence roadway performance). The vdf attribute, therefore does double-duty as both the VDF index for link travel time calculations and as an indicator of link functional class.
Parts of the transportation network such as nodes and arcs, but also various physical entities, may be associated with (by location or ownership) a Planning District.
Parts of the transportation network such as nodes and arcs, but also various physical entities, may be associated with (by location or ownership) a Planning District.
Future extensions should capture this semantics in greater detail.
AccessRestriction may apply to certain Vehicle types (bus, cab, eco-friendly), Vehicle properties (number of passengers), or attributes of the traveler themselves (e.g. no bicycles on transit between certain times).
1
1
1
1
1
1
1
1
1
1
1
1
Capacity of traffic throughput for a lane (e.g. vehicles per time unit)
1
1
1
1
1
1
1
1
1
Nominal link capacity (per arc or lane) of traffic throughput.
1
1
1
An urban administrative division with jurisdiction over some area. We observe that the properties inMunicipality and inPlanningDistrict will likely apply to other areas of the domain (e.g. land use, building ontologies). It is likely that they will be better defined at a lower (more foundational) level within the ontology, however it is currently not clear where and how this should be done. For now, we define these properties within the Transportation Network System ontology and leave the final organization for a future iteration when the use and related concepts is more clear.
1
1
2
1
1
1
1
We observe that the properties inMunicipality and inPlanningDistrict will likely apply to other areas of the domain (e.g. land use, building ontologies). It is likely that they will be better defined at a lower (more foundational) level within the ontology, however it is currently not clear where and how this should be done. For now, we define these properties within the Transportation Network System ontology and leave the final organization for a future iteration when the use and related concepts is more clear.
1
1
1
1
Travel Time Index: a ratio of the inverse speed (travel time) to the inverse of some calculated, threshold speed (travel time).
The Travel Time Index (TTI) calculated against the Maximum throughput speed (average speed at capacity).
The Travel Time Index calculated against the minimum throughput speed.
Added for organizational purposes, to identify all classes defined in the Transportation System ontology.