Mappa Mercia/UTC

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)