Proposal:Conditional values

Conditional values
Proposal status:	Obsoleted (inactive)
Proposed by:	Martinq
Tagging:	[[Key:*:cond|*:cond]]=*
Statistics:
Draft started:	2012-04-08

This proposal describes a unified approach for tagging feature values, which depend on circumstances (of use): The time and date of use, weekday, the vehicle properties (weight, height...), the weather, age, sex, number of people, ownership of permits...

Terminology

• Conditional (feature) values are values, where the mapper cannot define a single constant value. Instead the applicable value can only be determined when the circumstances of use are known. Example: maximum speed of 80km/h when driving a truck, 100km/h when driving a motorcar
• Circumstances are described by properties, which must be known by the application using the data to determine which conditional (feature) value applies. Examples: means of transportation (bicylce, pedestrian, motorcar), date, time, weather, permits, sex
• Condition is a rule based on circumstance properties, which defines whether or not the associated value applies. Examples: "when driving a truck with weight>7.5t", "from 8:00 to 17:00", "every 2nd Friday in a month"

Objective

• No weird programming language type syntax: If a mapper reads a sign "80 km/h for HGV>7.5t, 22:00-07:00", mapping should be as close as possible to that. maxspeed:condition{time(22:00-07:00) & vehicle[hgv]+not(weight<=7.5)}=80 can't be the answer. Key:opening_hours is already borderline - or can someone interpret this: Dec 25-Su-28 days - Mar Su[-1]: 22:00-23:00.
• KISS: If something fits on a road sign, why are mappers enforced to translate that into zillion tags?
• As few rules as possible: Every rule makes it harder for casual mappers to interpret the conditonal values correctly. For example if somebody must know that 'and' has precedence over 'or', then something like bicycle or hgv and delivery could be interpreted wrong.
• As intuitive and easy as possible for the mappers -- but not impossible to parse and evaluate for the data users
  • I want to ensure this by providing a reference implementation for evaluation of conditonal values

And before somebody asks: I am aware of this problem

Proposal

To define conditional values for a key a_key, proposed tagging is

a_key:cond = a_value a_condition

a_value should accept the syntax of any value including values composed of lists with ';'.

Conditional maxspeed examples: maxspeed:cond = 80 if vehicle is a hgv and weight>7.5t (or shorter: 80 if hgv & weight>7.5).

Syntax/grammar for conditions (if, except, when, not...) and the properties of the circumstances (e.g. weight, vehicle) that can be used in conditions are described subsequently.

Multiple conditional values

In the case of several conditional values it is permissible

• to separate them by ';'
  • a_key:cond = value1 cond1;value2 cond2;...
• - or - defining several :condN key/value pairs
  • a_key:cond = value1 cond1
  • a_key:cond2 = value2 cond2
  • ...

Conditions (syntax/grammar)

Conditions use the circumstances (defined by properties, see below) to define when the preceding value applies. The syntax/grammar allows several variants, from 'close to natural language' (avoiding a technical touch, but rather 'bulky') to more technical, but shorter expressions (which of course must still be understandable by everyone without excessive lookup in the wiki).

Note: This makes parsing difficult, but I don't start voting without an (open) reference implementation.

Start of a condition

There are two basic forms, both require a space after the value:

• Non-technical:
  • Starts with if, when or except (and some special cases),
  • a space,
  • and the main part of the condition
    • Example: maxspeed:cond = 80 if vehicle is a hgv and weight>7.5t
• Square brackets: Main condition within [...], if or when can be omitted.
  • Example: maxspeed:cond = 80 [vehicle is a hgv and weight>7.5t].

This section is not finished. I am currently working on a way to describe the different options/alternatives of describing conditions -- in a way which is understandable for non-engineers. I will update this section and provide the full information.

Circumstances

Circumstances, described by properties, must be known by the application in order to evaluate the condition and determine the value.

A lot of such properties have already been defined in OSM to overcome issues in describing access, opening hours or parking conditions. Sadly, these are isolated solutions: For example vehicle types and vehicle properties are already well defined for describing vehicle dependent access. But yet there is no straightforward way (which is not a sudoku type of riddle) to use the vehicle types also in parking conditions (e.g. where busses can park at a certain time only, but cars always).

The new approach clearly separates the attributes of the mapped objects from the circumstances of use and generalizes them for use in any arbitrary condition and not just for a special tagging group (like access or parking conditions), e.g. it is possible to restict the access of a road to the age now or have extended opening hours of a shop if you arrive with an HGV.

Note: The objective of this proposal is NOT to redefine the access keys. But the fact that the access key is the only major key which was developed to express access under certain conditions, there is an inevitable overlap with this concept. I took advantage and used access as basis for several circumstance properties. Thus the final proposal could replace access tags, e.g. access=yes + access:cond=no if hgv and weight>7.5t, but this is just a (theoretical) side effect.

• Date and time (is it Monday or Sunday, is it May or July, is it 10:00 or 18:00?)
  • Note: A lot of work has been put into Key:opening_hours, which effectively describes conditions with value 'on' or 'off' based on date and time.
• Sex/gender
• Age
• Means of transport (foot/pedestrian/walking, horse/hore-riding, driving/vehicle, ski/skiing, inline skate, boat/ship, etc)
  • vehicle types (bicycle, carriage, moped, mofa, motorcar...)
  • rickshaw, van
• Load, e.g. hazmat
• Purpose of travel
  • agricultural, forestry, delivery (load/unload)
  • emergency
  • public transport
  • commercial (maybe also purpose of vehicle, like public transport?)
  • public transport, public service (e.g. a tourist bus wouldn't have this property)
• Relationship (name to be improved)
  • customer, visitor, resident, owner
• Vehicle properties
  • weight, axle load, height, width, draught...
    • Note: It depends on the condition if the weight is compared to an upper bound (max weight) or a lower bound (min weight).
  • Formal: admissible total weigth, admissible speed, engine power
  • trailer, caravan, sidecar...
  • single-tracked or double-tracked (vehicle)
  • motorized
  • passengers (number of) driving in the car
• Possession of permits (and similar formal stuff)
• Weather related:
  • rain/raining, snow/snowing, sunshine
  • wet, snow-covered
• Events
  • Calendar based: school holidays, public holidays, easter, etc. -- related to date /time
  • sunset, sunrise
• Destination of travel
  • TODO, not sure about this

The basic concept is that every property stands on its own and no relationship is implied, thus if a rickshaw is legally used as taxi or for public transport, then the relevant properties are also set (same for motorized, etc.). It is not necessary to decide on a single type of vehicle, e.g. hazmat or hgv, taxi or motorcar, etc. - and no strict hierarchy like presented in access is required (e.g. rickshaw can be a motor vehicle but if a pulled rickshaw not even fall in the vehicle category). This puts more burden on the applications, because local legislations may differ (e.g. a taxi is public transport in one country, but maybe not in another one), but makes it easier for the mappers, because they always map what they see on a sign e.g. access:cond = yes if public transport without having to worry if taxis or tourist busses fall into that category and don't have to translate that into access:taxi and access:tourist_bus.

Some items defined in the Key:access cannot be found:

• designated or official: This is a fixed property of the way and does not depend on circumstances
• private, permissive, maystay: I see them as an atrribute of the tagged object (which may have its own conditional values)

Travel of direction (forward, backward) is currently not interpreted as 'circumstance', theoretically it could be. Because it has to do with geometry (digraph) I currently vote for keeping :forward and :backward extensions.

Rationale & alternatives

Why not following the current idea of adding the information to the key?

Read also Talk:Proposed_features/Extended_conditions_for_access_tags#Move_parameters_from_key_to_value for a discussion key vs. value.

There is no killer argument - it is a rather conceptional and philosphical question. My rationale:

• Keys refer to the feature or attribute - we don't have several attributes, we just have conditional values for a single attribute: There is one maxspeed attribute at one time for a user. I think intuitively people would state that the "maxspeed value depends", rather than seeing the situation as "there is an maxspeed attribute for HGVs from 22:00-05:00 with value <x> and an maxspeed attribute for...". Thus, I believe that it more intuitive to put the circumstance conditions for a conditional value belong to the value itself -- not the attribute.
• Keys are intended for lookup and have a more restrictive syntax. Values naturally provide more flexibility. If we want to use a more natural approach, this means, that we would get more variability into the keys.
• Keys get long if conditions must be combined (e.g. only on specific time and date and vehicle) and tend to get awkward syntax. Overall, I think it more acceptable to have longer values than having abbreviated key-monsters.
• Several values per key allowed: If the maxspeed has four conditional values, why should we be enforced to describe that in four keys?

What about forward and backward? Aren't they also circumstances of use?

I decided to don't treat them as circumstances of use. There is also no fact based rationale, but I see them as a universal way to tag a way, which has a built-in (mandatory) direction in OSM, for both directions differently. In theory an API change could overcome the limitation and make these extensions obsolete.

Rendering

Due the fact that the value depend on the circumstances of use, it is difficult to include/render such values in an universal (street) map. But specialized maps (for bicycles, HGVs, hikers...) should evaluate the conditional values and try to determine the values and/or render relevant conditions. User selectable specialized layers on electronic maps can also be used to add conditional information to a base map.

Applies to

All type of OSM tags/features with conditional values on nodes, ways and in relations.

Background

Tagging of conditional values, which do not have a constant value but depend on circumstances, is a common (and old) problem in OpenStreetMap:

• access to streets and paths depends on time, date or the mode of transportation (vehicle, by foot...)
• Seasonal roads (ice roads, winter closure, etc)
• Road signs with exceptions or limited validity (maximum speed for HGVs, etc.)
• Parking allowance often depends on time, date or permits

Solutions that allow tagging of such conditions (circumstances) have been developed. But investigation (and the burden of use) shows some limitations and flaws:

• Combination of conditions: When circumstances are described as separate keys (hour_on, hgv), it gets unnecessary difficult or impossible to describe combinations (80km/h for HGV>7.5t between 22:00-07:00)
• Conflicts when several time or vehicle restrictions occur at once (a restriction to Mo-Fr 08:00-18:00 and Sa 08:00-12:00 cannot be described with hour_on/off day_on/off)
• Conditions described as separate keys tend to get ambiguous, because it is not clear to which value they relate
• "Engineering" restrictions like "80km/h for HGV>7.5t between 22:00-07:00" into tag primitives like hgv, hour_on is not easy (how many mapper could do that without lookup in the wiki), unnecessary burdensome and prone to error (psv=no, psv:hour_on=10:00, psv:hour_off=16:00 mean that PSV are - or are not - allowed between 10-16?)
• Quality assurance: Several tags have to be reassembled to check if the tagging still matches that latest information like "Mo-Fr 08:00-12:00 except busses and delivery by HGVs".

Solutions so far always try to address some flaws specific to a tag (e.g. access) and invent tags and extensions to describe the condition. However, the fundamental problem may be deeper: Tags describing the object and its attributes are mixed with tags that try to express conditions under which some of the tags values apply.

Features/Pages affected

Features and proposal using alternative (specialized) solutions for conditional values:

• Proposed features/Conditions for access tags
• Proposed features/access restrictions 1.5
• Proposed_features/Dry_weather
• Key:parking:lane
• Key:opening_hours

Comments

Please use the Talk:Proposed features/Conditonal values discussion page.