Proposal talk:Temporary (conditional)
End date
As much as I regret it, you can't require an end date. Even in our western countries where information is relatively easy to be obtained, it's not always immediately obvious when the end date is. But it gets much worse in countries where such information simply isn't disclosed, or in situations where the time period is unpredictable, for example natural disasters or wars.
I would rather suggest that renderers ignore temporary features without end date that haven't been updated in for example a year. --Pbb (talk) 07:53, 23 May 2016 (UTC)
- It can't really be required, there are not database constraints in OSM ;) Perhaps really really recommend it. The mapper has a much better estimate than a renderer/router with a flat "one year".--Jojo4u (talk) 20:49, 24 May 2016 (UTC)
Multiple temporal changes
I would suggest using a Semi-colon value separator for multiple temporary values:
temporary:maxspeed=40 @ (2016 Jun 01 - 2016 Jun 15);20 @ (2016 Jun 16 - 2016 Jun 30) --Pbb (talk) 07:53, 23 May 2016 (UTC)
Since there is no consensus on constructs like temporary:1:* and temporary_1:* your suggestion (taken over from conditionals restrictions) is the best for now, thanks!--Jojo4u (talk) 18:05, 23 May 2016 (UTC)
Why not :conditional?
I don't see the reason to introduce another tagging scheme to map features that change over time. Tagging with the :conditional suffix is already well established and supported by various tools.
- temporary:access=no @ (2016 Apr 01 - 2016 Sep 01)
- access:conditional=no @ (2016 Apr 01 - 2016 Sep 01)
Both tags are equally easy to distinguish from regular tags because of the time range given and can be semi-automatically checked and deleted after the end date has passed. --Mueschel (talk) 19:52, 15 September 2016 (UTC)
- The new namespace is deliberate: An application which supports conditional syntax but has long data update times will display wrong information for a good while. Applications should only use the data if they support fast enough update rates.--Jojo4u (talk) 21:07, 27 September 2016 (UTC)
- This argument also implies that you can't tag any conditional that applies to only one hour per day, because software does not update fast enough. Naturally, all conditionals are only active during the time they apply. If a conditional will never happen again, or not within the next x weeks (up to the user) it will just not be shown. --Mueschel (talk) 05:52, 28 September 2016 (UTC)
- My answer was not very well tailored to your question. I just want to make sure nobody supports non-recurring conditions "by accident". In an application, which updates seldomly and is just picking up the non-recurring conditions at this time, more harm is done than good. Construction plans often change and this topic just needs frequent updates.--Jojo4u (talk) 12:58, 22 October 2016 (UTC)
- It seems to me to make sense to merge these two tagging schemes. The only thing against *:conditional=* that I can come up with, is that maxspeed:conditional=50 @ (2015 Dec 01 - 2015 Dec 15) doesn't look as intuitive.--Pbb (talk) 19:46, 5 October 2016 (UTC)
- If you have a motorway with limited speed while the road is wet (maxspeed:conditional=100 @ wet) you mixing up temporary and "stable" values: maxspeed:conditional=50 @ (2015 Dec 01 - 2015 Dec 15); 100 @ wet. This is very confusing: Can you drive 100 if it rains? Maybe you can use the lowest value for defining the current maxspeed, but if you define oneway:conditional=-1 @ (2015 Dec 01 - 2015 Dec 15); yes @ (09:00-15:00) you can't say which value is the correct. When defining the new temporary:* scheme it should always overwrites the contitional values. If you have two schemes you also can delete all temporary:* tags if the roadworks are completed. --Christopher (talk) 20:55, 5 October 2016 (UTC)
- Good point there. Temporary for one-time exceptions, and conditional for regularly repeating ones? (If we do combine both, maybe the more generic namespace name "exception" would be better?)
- Your example of conflicting conditions is relevant, also when we don't combine. I guess increasing significance from left to right would be logical, in which case your example should be formulated as maxspeed:conditional=100 @ wet; 50 @ (2015 Dec 01 - 2015 Dec 15). This is going to become a problem with validation, since these errors will be hard to catch.
- The conditional syntax already has 6 steps of conflict resolution. A new rule #1 could be "a one-time condition - identified by using years in the time specification - takes precedence over recurring rules". But what is the gain here? The mapper has none since he needs to mix-up recurring and non-recurring values making the value field very crowded (think of ID). The data customer without support for temporary restrictions has none because many conditional values now might fail to parse since semicolons or time-ranges with years are not supported. --Jojo4u (talk) 12:58, 22 October 2016 (UTC)
Prefix or postfix
I'm not sure if prefix ("temporary:*") or postfix ("*:conditional") is better, both seem to be in use with other tags: disused:amenity=pub, note:en=This is an English note. --Pbb (talk) 06:53, 6 October 2016 (UTC)
- When reviewing namespace examples it becomes clear that a prefix is like a category, giving context to the subkey. It's also often the the same as the value of the main key (e.g. power=generator + generator:output=*). A suffix is often modifying how to interpret the value (left/right/forward/backward or :lanes extension or language-suffix in names). Temporary fits more to a suffix description. The usage as a prefix was carried over from the non-conditional proposal where it made more sense. I also thought of it as a separate namespace for temporary-aware data customers. In the light of this thoughts it might be better to use *:temporary - with the rule that it must be the rightmost prefix.--Jojo4u (talk) 12:20, 22 October 2016 (UTC)
- A suffix is more suitable to "*:conditional" keys. I agree the statement of jojo4u, that temporary is a modifier to discribe how to interpret the value. As a developer I can say if you store the data for temporary tags as an prefix into a database using typical B-tree indexes it would be faster to find all the tags. I also see the temporary:*=* prefix as an kind of Lifecycle prefix like disused:railway=*. If you need to remove all tag from a highway after roadworks finished you don't forget any tags when they ordered by name. For futher discussions I created an postfix and prefix example for a average way nearby a crossroad.
prefix:
- highway=road
- lanes=4
- lanes:backward=3
- lanes:forward=1
- maxspeed=70
- maxspeed:conditional=50 @ wet
- temporary:lanes=3 @ (...)
- temporary:lanes:backward=2 @ (...)
- temporary:maxspeed=30 @ (...)
- temporary:note=roadworks by ... during holidays
- temporary:turn:lanes:backward=left|through;right @ (...)
- turn:lanes:backward=left|through|right
postfix:
- highway=road
- lanes=4
- lanes:temporary=3 @ (...)
- lanes:backward=3
- lanes:backward:temporary=2 @ (...)
- lanes:forward=1
- maxspeed=70
- maxspeed:conditional=50 @ wet
- maxspeed:temporary=30 @ (...)
- note:temporary=roadworks by ... during holidays
- turn:lanes:backward=left|through|right
- turn:lanes:backward:temporary=left|through;right @ (...)
--Christopher (talk) 19:57, 26 October 2016 (UTC)
Temporarily closed hotel
How would I tag a hotel that is closed for 2 years during renovation? temporary:access=no seems a bit odd to me in this situation... --Pbb (talk) 11:58, 20 March 2017 (UTC)