< Mappa Mercia

Mappa Mercia/UTC

Current Primary Mapping Focus


UTC (Urban Traffic Control) Tagging Schema (UK specific)

Although this is UK-specific, it could probably be modified easily for other countries The rationale for developing this schema arose from a collaboration between Birmingham City Council and the local OSM community organised in mappamercia.

UTC in Birmingham is largely managed through a common data base which integrates a number of systems

  • SCOOT – this system detects vehicle flows and speeds and optimises traffic lights across a network(or regions). The system uses induction loops embedded in the road, of which there are approximately 1500 around Birmingham.
  • ANPR cameras - monitoring traffic flows and journey times(NB NOT spot speed (e.g speed cameras) or surveillance)
  • Above Ground Detection – monitoring traffic flows at individual sites. Provides vehicle classification, not just flows
  • MOVA – this system detects vehicle flows and speeds and optimises isolated sets of traffic lights (i.e. not in a network) * BCC don’t currently have this data, but it is a logical next step

Most of this tagging is not possible without access to Council UTC data, and even with access to the data, it is not understandable without the assistance of Council Highway Engineers. So we envisage most use scenarios will be collaborative between local OSM mappers and councils, as and when councils want to develop applications using OSM data. Mappers can assist by locating street cabinets for traffic signals identified with reference numbers, tagging traffic signals and crossings and adding lanes information to highways.

EntityKeyValueExampleNotes
SCOOT regiontraffic:scoot_region:refxxtraffic:scoot_region=c5A collection of SCOOT nodes
operatorxxxoperator=bcc
SCOOT region relationtypescoot_regionSee Note 8
traffic:scoot_region:refxxtraffic:scoot_region=c5
SCOOT nodetraffic:scoot_nodejunction OR crossingtraffic:scoot_node=junction
traffic:scoot_node:refxxxtraffic:scoot_node:ref=E0411
traffic:scoot_region:refxxtraffic:scoot_region=c5
operatorxxxoperator=bcc
SCOOT node relationtypescoot_nodeSee Note 8
traffic:scoot_node:refxxxtraffic:scoot_node:ref=E0411
SCOOT linktraffic:scoot_link:refxxtraffic:scoot_link=D1The way upstream of the SCOOT node. See note 6
traffic:scoot_region:refxxtraffic:scoot_region=c5
operatorxxxoperator=bcc
lanes:scoot_linkxx|xxM1for a two-way highway. Example shows 2 lanes. See note 10
Monitored traffic flowslanesxlanes=3See Note 7
sensor_node:lanesxx|xx|xxE0411|E0411|E0411To total no. of lanes. ALL lanes monitored
sensor_node:lanesxx|xx|noE0411|E0411|no2 lanes monitored
sensor_ref:lanesxx|xx|xxN53151D|N53151D|N5351DTo total no. of lanes. ALL lanes monitored
sensor_ref:lanesxx|xx|xxN53151D|N53151D|no2 lanes monitored
SCOOT detector(sensor)traffic:sensorxxxTraffic:sensor=loopSCOOT nomenclature is detector but bcc prefer the generic term sensor which is extensible as the "internet of things" progresses
traffic:scoot_node:refxxxtraffic:scoot_node:ref=E0411
traffic:scoot_region:refxxtraffic:scoot_region=c5
traffic:sensor:refxxxxtraffic:sensor:ref= N53151DThe last character is the same as the first character from the SCOOT link
operatorxxxoperator=bcc
Non-SCOOT sensortraffic:sensorxxxtraffic:sensor=cameraCameras
camera:imagexxxcamera:image=ANPRCameras can collect both image and data
camera:dataxxxxcamera:data=countCameras can collect both image and data
man_mademonitoring_stationSee notes 4 and 5
monitoringtraffic
enforcementno
surveillanceno
traffic:sensorcamera_targetNode on the way being monitored: required for network logic
traffic:sensor:refxxxtraffic:sensor:ref= JTMS38Refs are non-SCOOT construction
camera_viewlinexxxJTMS38Way connecting the camera node to the target node
Street Cabinetman_madestreet_cabinetNot necessary for network logic but visible for mappers, complete with ref nos
street_cabinettraffic_signals
traffic:scoot_node:refxxxtraffic:scoot_node:ref=E0411Ref no should be visible on cabinet. One cabinet could have several ref nos
traffic:scoot_region:refxxtraffic:scoot_region=c5Not visible
operatorbccNot visible - can be inferred from position inside bcc boundary


Notes

1.traffic: as a namespace has been used in order to locate and group the tags ( as was done with naptan data)

2.Only a pilot SCOOT region is being tagged together with Birmingham City Council, so that software developers can test the data model with a prototype, before a city-wide rollout.

3.Inductive loop sensors can often be seen in the surface of roads as a cut pattern: diamonds, chevrons, squares and rectangles. Although visible to mappers, without the expertise of a Highway Engineer, they can't be mapped and tagged.

4. Cameras for UTC purposes should not be tagged as man_made=surveillance but as man_made =monitoring_station. A mapper won't know which are which by observing them so should continue to tag with man_made=surveillance. As and when council transportation engineers want to add their UTC data, they can change the tags for the appropriate cameras.

5.Cameras for UTC purposes (like speed cameras) are not located on the way, unlike inductive loops.Sometimes they're on buildings and can sometimes be located on top of traffic signal poles which are physically located to the side of the OSM way (like bus stops). However the node for the traffic signals is on the way, which for UTC purposes is also the stopline and has a different semantic meaning. Hence the camera monitoring station is placed in OSM where the pole is , which will be to the side on the traffic signal node. However we need for the sake of network logic to place a node on the way at the point which is being monitored by the camera (this could be a specific lane in a multi-lane way). For the sake of clarity we have also used a way joining the camera node to the monitored node(traffic:sensor=camera_viewline)

6. As SCOOT links are always upstream of the SCOOT node there is an inherent logical relationship so there is no need to tag with SCOOT node ref.

7.The :lanes suffix needs to be used to indicate which lane is being monitored on ways where there is more than one lane (which will be the majority) and potentially where there are multiple sensors dedicated to different lanes. This will often be used in conjunction with bus:lanes and turn:lanes and lanes:forward and lanes:backward. Scenarios can be quite complex. Allocating tags to lanes proceeds from left to right in the direction of the way. For more information see the OSM wiki page on lanes

8. Even though all the relevant objects are tagged, relations have also been added to ease maintenance, mainly for periodic consistency checks to ensure that data has not been edited and to apply reversion. These are not relations recognised anywhere else, but specific for this purpose. Roles are stop, link, sensor. Where a non-signalled roundabout forms a SCOOT node o r forms a nodeless boundary between SCOOT regions, additional roles of entry and exit are used where ways enter and leave the roundabout.

9.Special case treatment for crossing=traffic_signals at locations where there are highway=traffic signals at junctions that are SCOOT nodes:

9.1 On an inbound way place a highway=traffic_signals node at the stop line you can see on bing imagery. Add a crossing=traffic_signals k/v tag on the same node. Remember at a two-lane single way crossroads ALL ways will be inbound

9.2 Between the stop line and the junction( where pedestrians actually cross in front of the traffic stationary on the stop line) place a highway=crossing node. DO NOT add a crossing=traffic signals k/vtag

9.3 On dedicated outbound ways (i.e dual carriageways) there will be no highway=traffic_signals node so this special treatment is not necessary. The standard coupling of highway=crossing and crossing=traffic_signals will apply.

9.4 Additionally a way tagged highway=footway is also present joining the crossing nodes. This should be split appropriately and tagged crossing=traffic_signals

9.5 This special treatment is necessary ONLY where UTC data is being added. It is DISCRETIONARY elsewhere.

10 Unlike one-way highways, a two-way highway could consist of TWO downstream links if there is a SCOOT node at either end of the way and thus the link ref has to be tagged via the lanes: suffix and NOT on the way. If the higway flares to multiple lanes before a SCOOT node then tag to the specific number of lanes in the flare. Backwards/Forwards taggs will also be needed in the flared section. Backwards/Forwards tags are not needed normally on two-lane two-way highways as the default in the UK is left forwards and right backwards. Rare exceptions can be found for designated contraflows such as bicycle and bus lanes.

CommentSignature
forwards and backards lanes tagging - is it lanes:backwards or backwards:lanes?

--Brianboru (talk) 18:08, 24 August 2015 (UTC)

This article is issued from Openstreetmap. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.