Proposal:Temporary

Temporary traffic restrictions during construction work

temporary
Proposal status:	Obsoleted (inactive)
Proposed by:	stanton
Tagging:	temporary:*=*
Applies to:	way, node, area
Definition:	A temporary change to certain features of a map item
Statistics:
Rendered as:	See description
Draft started:	2010-11-30

Summary

A temporary change to individual features of a map item. Examples are:

• Restrictions for the duration of construction work, e.g. special speed limits, road closures, one-way restrictions, temporary traffic signals
• Attractions at fairs (think Oktoberfest beer tents showing up only for the two weeks of the event)
• Road closures due to fairs, demonstrations, summits or other events
• Roads inaccessible due to natural disasters

In fact, this approach allows for a wide range of possible uses. Anything which sets a tag or substitutes the value of a tag with something else for a determined period of time, after which the old value will be valid again, can be tagged in this way - for any item, for any reason and modifying any tag.

Additionally temporary:date_on=*, temporary:time_on=*, temporary:date_off=* and temporary:time_off=* can be used to specify the duration of the temporary modifications. Allowed values are analogous to date_on=*, time_on=*, date_off=* and time_off=*.

Reasoning

In areas with active mapping communities it has become common to insert even temporary modifications, such as road closures due to construction work, into OSM. Until now, this has been done by simply changing the affected tags, e.g. setting maxspeed=* to reflect the temporary speed limit in effect during construction work.

However, this is unsatisfactory for various reasons:

• There is no information as to whether access tags, oneway restrictions and others are temporary or permanent.
• When the construction work finishes, the fair is over or the real situation returns to normal for any other reason, objects have to be tagged back to their old values again. Depending on how active the mapping community in a particular place is, the temporary tagging may remain in place for some time despite being out-of-date.
• The old (permanent) tag values are lost and have to be recovered either by looking at the object history or by revisiting the place - again a time-consuming and error-prone process.
• Downloaded OSM data becomes outdated quickly: Suppose the main road in a town is closed for a three-day fair and someone downloads data to use with their navigation system during this time. However, the user of the navigation system may go to that place only a week later, and although the main road will long have been reopened by that time, the navigation system will still avoid it, relying on its stale data. Printed maps will report the road as inaccessible forever - and worst, there is no way of knowing whether these restrictions are temporary or permanent.
• Some "temporary" modifications may remain in place for a significant amount of time (the photo is from the construction site for the metro line 5 in Milan, where work is expected to last for more than four years), hence a map not reflecting it will be inaccurate for a long period of time - on the other hand, it is nonetheless a temporary thing

Tags such as date_on, date_off exist but their scope is limited to the access tags; no such mechanism exists for other tags. Even for the access tag, the permanent and temporary value cannot be maintained at the same time.

The new tagging proposal allows to:

• Keep an exact record of permanent attribute values and temporary changes
• Make both temporary and permanent attribute values available to applications, allowing them to choose between both
• Automatically revert to using the permanent attribute values when the end date (date_off) has been reached

How to Map

Leave the existing tags untouched. Create another tag named temporary: followed by the name of the tag of which you want to change the value, and set the value as needed. Add temporary:date_on=*, temporary:time_on=*, temporary:date_off=* and temporary:time_off=* to the best of your knowledge.

Example 1: Reduced speed limit due to construction work

Suppose that due to construction work from December 1 to December 15, the usual speed limit of 80 on a road is reduced to 50.

highway=primary
maxspeed=80
temporary:maxspeed=50
temporary:date_on=2010-12-01
temporary:date_off=2010-12-15

Example 2: Road closed due to demonstration

A road is closed for a few hours due to a demonstration.

highway=tertiary
temporary:access=no
temporary:foot=yes
temporary:date_on=2011-05-01
temporary:time_on=08:00
temporary:date_off=2011-05-01
temporary:time_off=14:00

Note that, unlike in the above example, the temporary modification introduces a new tag rather than overwriting an existing one (as the road here does not have a regular access tag).

Example 3: Temporary name for an exhibition pavilion

An IT trade fair will be held at an exhibition ground; Pavilion 5 will be used for the Security Area.

building=yes
name=Pavilion 5
temporary:name=Security Area
temporary:date_on=2010-10-25
temporary:date_off=2010-10-30

Example 4: Temporary highway bridge

A highway bridge is being replaced: The old bridge gets demolished and a new bridge is erected in its place. Before demolition of the old bridge begins, a temporary bridge is erected and traffic is redirected across the temporary bridge until the new bridge is complete.

Tags on the old bridge:

highway=motorway
temporary:access=no
temporary:date_on=2011-04-01
temporary:date_off=2011-09-01

Tags on the temporary bridge:

temporary:highway=motorway
temporary:date_on=2011-04-01
temporary:date_off=2011-09-01

Example 5: Cycleway closed for construction work

A cycleway will be closed for construction work. Suppose the cycleway is tagged as follows:

highway=path
bicycle=designated

In this case add the following tags:

temporary:access=no
temporary:bicycle=no
temporary:date_on=2011-06-01
temporary:date_off=2011-06-15

There are some caveats for this example due to the semantics of access-related keys:

• Do not use temporary:access=no alone because it would not override the bicycle=* tag. Thus bicycle=designated would remain in place - which would imply that bicycles still can use the cycleway.
• Also, do not use temporary:bicycle=no alone because it would also override the implied access restriction for anything other than bicycles - which would imply that, for the duration of the construction work, e.g. pedestrians can use the cycleway.

Example 6: One-way road temporarily turned in opposite direction

A one-way road temporarily is used for traffic in opposite direction only, e.g. because of construction works in a nearby road. Suppose the one-way road is tagged this way:

highway=residential
oneway=yes

In this case add the following tags:

temporary:oneway=-1
temporary:date_on=2015-03-01
temporary:date_off=2015-03-15

If it is used for traffic in both direction, use temporary:oneway=no.

How to Interpret and Render

• Applications should first evaluate temporary:date_on=*, temporary:time_on=*, temporary:date_off=* and temporary:time_off=*. If the current date and time are within that range, the other temporary tags supersede their counterparts. For example, maxspeed=100 in combination with temporary:maxspeed=60 is to be interpreted and rendered as if it were maxspeed=60.
• A temporary:*=* tag will behave exactly as if the value of its permanent counterpart were changed. If foo=* implies certain values for bar=*, depending on the value of foo, then adding temporary:foo=* will also change the implicit values of bar accordingly (unless bar is set explicitly). This helps reduce complexity of software - only the date and time-related tags need to be evaluated, the rest gets replaced without further inspection.
• If any of temporary:date_on=*, temporary:time_on=*, temporary:date_off=* and temporary:time_off=* is missing, assume the current date for both days. The default for temporary:time_on=* is 0:00 (beginning of the day), the default for temporary:time_off=* is 24:00 (end of day). So any temporary change with the same date_on and date_off but no corresponding times lasts for one day (24 hours).
• Applications (including renderers) which are not aware of this tag can safely ignore it (and probably should). These will render the "permanent" state of all objects.
• Applications which use data offline should either ignore this tag or (preferred) prompt the user for the intended usage timespan and render the temporary changes effective in that timespan. With the latter approach, it is easy to create an inner city map for a planned event beforehand, reflecting all road closures which will be in place during that event.

Comments

i miss the example of oneway=yes for use in construction. when they make surface or bridges new. --Lübeck (talk) 18:58, 22 June 2014 (UTC) Please use the Discussion page for discussion.

See also

Proposed_features/temporary_(conditional) - this proposal with conditional time syntax.