Proposal:Temporary (conditional)
| Temporary (conditional) | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | Jojo4u |
| Tagging: | temporary:*=* @ (time range) |
| Applies to: |   
|
| Definition: | A temporary change to certain properties of a feature |
| Statistics: |
|
| Rendered as: | - |
| Draft started: | 2016-05-22 |
Proposal
This proposal is a further development of Proposed features/temporary by User:stanton by adding the conditional_restrictions syntax instead of the deprecated day_on=*, etc.
A temporary change to properties of feature. 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.
Temporary tagging is thought to be useful to data customers who update their data set at least weekly.
Rules
- A temporary: prefix in the key is used to separate the temporary changes from the main tagging. Note: There is currently discussion whether using a
:temporarysuffix in the key would be better, please join discussion on Talk page - The Conditional_restrictions syntax is used to specify the type and duration of the temporary modifications.
- For the time range opening hours-syntax (including the year) is used.
- The end date must be specified. If it's unknown it should be guessed and updated when new facts arise.
- Behaviour in case of overlapping temporary time ranges is currently not defined.
- It is recommended be used for temporary changes which are planned to persist short than twelve months. For temporary changes which are planned to persist longer it seems more advisable to directly change the main tags.
Syntax
temporary:<key> = <value> @ (<time-range>) [;<additional-value> @ (<additinal-time-span>)]
- temporary: prefix is added before the temporary key.
- @ () is the Conditional_restrictions syntax.
- <time-range> is opening hours time-range syntax with years.
- Addiditional values and time spans under the same key are separated by semicolon, as done in conditional restrictions.
Rationale
In areas with active mapping communities there is interest and capability to document temporary modifications, such as road closures due to construction work, in OSM.
Opening_hours syntax
Compared to other options (e.g. date namespace) the opening_hours syntax has more flexibility. E.g. tagging of lane closures during off-peak hours due to construction works are possible.
Temporary prefix
Using a a temporary=* prefix has the following benefits:
- 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. Temporary tagging has an end date required and 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.
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 has been reached
Brief closures vs. long update times
In the past temporary changes has been tagged by directly changing the affected tags, e.g. setting maxspeed=*, to reflect the temporary speed limit in effect during construction work. This has one major drawback: Offline OSM data used by data customers is often only updated after several month. A one-day closure may be still active after months in some data sets.
Therefore the documentation on construction=* is now recommending not to directly change the tags for closures which are planned shorter than six to nine months (verified as of may 2016). In light of the benefits of this proposal the window for exclusive use of the temporary prefix is proposed to be enlarged to 12 months.
The new tagging proposal allows to:
- Allowing up-to-date information for frequently updated datasets while not disadvantaging the infrequent updated.
Specifying the end time
By specifying the end date - even when guessing is needed - the problem of forgotten, indefinite temporary tagging is averted. Temporary tagging is for areas with active mappers.
Examples
Leave the existing tags untouched. Create another key named temporary: followed by the name of the key of which you want to change the value, and set the value as needed, followed by @ (<time-range>).
Examples for time range
Recommended is the Monthday range with years, useful examples:
2016 May 22 - 2017 Jan 022016 May 22-232016 May 22 - Jun 23 Mo-Fr 08:00-16:002016 Jun 24 20:00-24:00; 2016 Jun 25-2016 Jun 26; 2016 Jun 27 00:00-05:00
Use the opening_hours evaluation tool for validation.
Month range with year (2016 May - 2017 Jan) seems currently unsupported.
Example 1: Reduced speed limit due to construction work
Suppose that due to construction work from December 1 2015 to December 15 2015, the usual speed limit of 80 on a road is reduced to 50.
highway=primary
maxspeed=80
temporary:maxspeed=50 @ (2015 Dec 01 - 2015 Dec 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 @ (2016 May 01 08:00-14:00)
temporary:foot=yes @ (2016 May 01 08:00-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 @ (2015 Oct 25 - 2015 Oct 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 @ (2016 Apr 01 - 2016 Sep 01)
Tags on the temporary bridge:
temporary:highway=motorway @ (2016 Apr 01 - 2016 Sep 01)
Example 5: Cycleway closed for construction work
A cycleway will be closed for construction work. Suppose the cycleway is tagged as follows:
In this case add the following tags:
- temporary:access=no @ (2016 Jun 01 - 2016 Jun 15)
- temporary:bicycle=no @ (2016 Jun 01 - 2016 Jun 15)
- temporary:foot=no @ (2016 Jun 01 - 2016 Jun 15)
There are some caveats for this example due to the semantics of access-related keys:
- temporary:access=no must be used to deny access to horses and inline skates.
- temporary:bicycle=no/temporary:foot=no must be used to overwrite the non-temporary values of the same keys. The temporary prefix does not introduce a new "clean" access hierarchy.
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 @ (2016 Mar 01 - 2017 Jan 01)
Example 7: Road with temporary one-way in one direction, then in other
Due to construction work, a road temporarily is signed as one-way for six months. For the first four months in one direction and afterwards in the other direction for the remaining two months.
highway=residential temporary:oneway=-1 @ (2016 Mar 01 - 2016 Jun 30); yes @ (2016 Jul 01 - 2016 Aug 31)
How to Interpret and Render
- Applications should first evaluate the time span. 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 time span need to be evaluated, the rest gets replaced without further inspection.
- 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 update their data set at least weekly in order to reflect the fast nature of temporary tagging.
Features/Pages affected
See also
Comments
Please comment on the discussion page.