Mappa Mercia/UTC

From OpenStreetMap Wiki
Jump to: navigation, search

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.

Entity Key Value Example Notes
SCOOT region traffic:scoot_region:ref xx traffic:scoot_region=c5 A collection of SCOOT nodes
operator xxx operator=bcc
SCOOT region relation type scoot_region See Note 8
traffic:scoot_region:ref xx traffic:scoot_region=c5
SCOOT node traffic:scoot_node junction OR crossing traffic:scoot_node=junction
traffic:scoot_node:ref xxx traffic:scoot_node:ref=E0411
traffic:scoot_region:ref xx traffic:scoot_region=c5
operator xxx operator=bcc
SCOOT node relation type scoot_node See Note 8
traffic:scoot_node:ref xxx traffic:scoot_node:ref=E0411
SCOOT link traffic:scoot_link:ref xx traffic:scoot_link=D1 The way upstream of the SCOOT node. See note 6
traffic:scoot_region:ref xx traffic:scoot_region=c5
operator xxx operator=bcc
lanes:scoot_link xx|xx M1 for a two-way highway. Example shows 2 lanes. See note 10
Monitored traffic flows lanes x lanes=3 See Note 7
sensor_node:lanes xx|xx|xx E0411|E0411|E0411 To total no. of lanes. ALL lanes monitored
sensor_node:lanes xx|xx|no E0411|E0411|no 2 lanes monitored
sensor_ref:lanes xx|xx|xx N53151D|N53151D|N5351D To total no. of lanes. ALL lanes monitored
sensor_ref:lanes xx|xx|xx N53151D|N53151D|no 2 lanes monitored
SCOOT detector(sensor) traffic:sensor xxx Traffic:sensor=loop SCOOT nomenclature is detector but bcc prefer the generic term sensor which is extensible as the "internet of things" progresses
traffic:scoot_node:ref xxx traffic:scoot_node:ref=E0411
traffic:scoot_region:ref xx traffic:scoot_region=c5
traffic:sensor:ref xxxx traffic:sensor:ref= N53151D The last character is the same as the first character from the SCOOT link
operator xxx operator=bcc
Non-SCOOT sensor traffic:sensor xxx traffic:sensor=camera Cameras
camera:image xxx camera:image=ANPR Cameras can collect both image and data
camera:data xxxx camera:data=count Cameras can collect both image and data
man_made monitoring_station See notes 4 and 5
monitoring traffic
enforcement no
surveillance no
traffic:sensor camera_target Node on the way being monitored: required for network logic
traffic:sensor:ref xxx traffic:sensor:ref= JTMS38 Refs are non-SCOOT construction
camera_viewline xxx JTMS38 Way connecting the camera node to the target node
Street Cabinet man_made street_cabinet Not necessary for network logic but visible for mappers, complete with ref nos
street_cabinet traffic_signals
traffic:scoot_node:ref xxx traffic:scoot_node:ref=E0411 Ref no should be visible on cabinet. One cabinet could have several ref nos
traffic:scoot_region:ref xx traffic:scoot_region=c5 Not visible
operator bcc Not 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.

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

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