Proposal talk:Conditions for restriction relations

From OpenStreetMap Wiki
Jump to navigation Jump to search

Several points

Why not use "if:vehicle" instead of "if:mode"? The former is clearer on what it means

I also wonder if there's really a need to have the "if:" prefix. There wouldn't be any confusion without the "if:". Or would there be any other meaning possible for a "time" tag?

Furthermore, this is starting to look a lot like the access relations which I tried to create years ago but were always dismissed because some people apparently like it more to put the same unreadable tag and key string for a difficult restriction on 20 road segments instead of creating one relation. --Eimai 00:04, 9 July 2011 (BST)

  1. I'm using "if:mode" because a mode of transport doesn't need to be a vehicle, it could also be "foot" or "horse".
  2. The "if:" prefix isn't strictly necessary, just like the addr:* prefix wouldn't be necessary for keys like "housenumber". But it makes it easier to document all these tags in the same place, and most importantly should make it absolutely clear that the same semantics (= all "if:" conditions need to be fulfilled) apply to all "if:" tags. I also expect that it might become less clear which tag is a restriction and which tag is a condition if more relation types emerge (see 3).
  3. That's not a coincidence, this proposal is actually designed to be compatible with more universal restriction relations, and I had a tab with your old suggestions open while writing it. As I mention on the proposal page, "these tags can be used for all restrictions that are mapped as relations. Currently, we only tag turn restrictions as relations." So this proposal does not try to introduce relations for other restrictions. Whether or not these would be a good idea should be decided independently. But while it can be discussed whether or not relations should be used, I'm convinced that that if you use a relation, you should model the conditions as separate tags instead of squeezing them into a single key. --Tordanik 12:30, 9 July 2011 (BST)

not new

Please have a look on archives. We have something like "restriction:time=blabla". --Pieren 08:17, 10 July 2011 (BST)

There are no restriction:time=* tags in the database, there is no wiki page for that tag, and there isn't even a proposal for it as far as I can tell (search doesn't provide any useful results). So the problem clearly isn't solved yet. I'm sure that similar suggestions have been made before, though, and I've already confirmed that this proposal is using inspirations from the several years' worth of discussions about the issue. --Tordanik 14:27, 10 July 2011 (BST)

Not sufficiently flexible?

Isn't it time we had a more flexible scheme for restrictions in general? Some kind of metalanguage with AND, OR and NOT with parentheses, with some built-in functions/variables? Then you could have "access=(OR(psv,AND((DAY=TUESDAY),(MONTH=JAN))))" - PSVs always allowed, and all vehicles are allowed on Tuesdays in January. A simple syntax could be flexible enough for all circumstances and easily extensible without having to have discussions about the use of tags to reflect some esoteric combination of conditions. We could leverage existing standards for the syntax: XML, JSON or even a Javascript function, so that routing/rendering applications could easily evaluate the conditions dynamically.

Bottom line is I think this current proposal, although in line with established practice, is still limited and IMHO it's high time to look at a framework which would allow us to not need these discussions so much.--Csmale 10:27, 23 July 2011 (BST)

You have probably already guessed that I'm trying to solve these problems without abandoning the concept of intuitively human-readable value syntax. It is clear that this proposal alone is not sufficient, but with straightforward extensions (primarily an if_not:* prefix) I cannot think of anything that it could not describe.
Sticking to a small set of possible constructs does not just make manual editing easier, it also makes it easier to build editing tools. A GUI that lets you add "if"s and "if not"s is easier to build and use than a tool for editing arbitrary boolean expressions.
So unless you can give an example of a situation that could not be expressed with "Conditions for access tags" (for restrictions modelled as tags) or if[_not]:* tags (for restrictions modelled as relations), I don't see a reason to introduce additional complexity. --Tordanik 12:06, 23 July 2011 (BST)
I think the complexity of Proposed_features/Access_restrictions speaks for itself (check out the talk-page as well!), along with the fact that that proposal seems to have bled to death without any conclusion. We really need to take a step back. It's not just about covering any specific examples that I or anybody else can find today; we need a structure which will support today's needs and has the intrinsic extensibility to cover a wide range of cases that haven't been thought of yet without needing a wholesale redesign. I don't think a patchwork of tags with ever increasing complexity and the associated challenges of making them unambiguous and yet universally applicable is the way to go in the longer term. --Csmale 00:50, 24 July 2011 (BST)
All right, my view of the situation:
  • We want to model restrictions - speed limits ("you may not go faster than x"), access rules ("you may/may not use this road"), maximum parking durations ("you may not stay here longer than y"), and so on.
  • Sometimes, these restrictions do not apply for everyone or in all circumstances. "This speed limit only applies when the road is wet." "This access permission is only valid for forestry vehicles." "This maximum parking duration only applies Monday to Friday and has an exception for customers" ...
I think that all restrictinos we want to map can be broken down to fit this structure. Currently, we sometimes use "shortcuts" for tagging that create more special cases that are not really necessary (access=agricultural could be broken down into "access=yes if:user=agricultural"; hgv=yes means "access=yes if:mode=hgv") which makes things seem more complex than they actually are.
So we need to model restrictions, the limitations of the restrictions, group these to make it clear which belong together, and make it clear for what streets they apply.
  • restrictions and limitations/conditions for the restrictions can each be modelled as tags
  • grouping and association with streets is the only problem that remains. We could model this right now as one relation for each restriction, with the tags for the restrictions and the conditions, and with the streets affected by the restriction as members. The question is whether that doesn't make editing rather hard with our current tools. But it is feasible in principle, and just an issue of either making relations easier to edit, or introducing an alternative concept ("tag groups" or something similar) into the API.
That's why I ask for examples that do not work with a concept like this: I believe that the issue is essentially solved in theory. --Tordanik 09:39, 24 July 2011 (BST)

Comment Pierren

Responding to the question

why create a prefix "if" when the tag applies to the relation anyway

there are several reasons:

  • The "if" prefix makes it clear that the same semantics apply to all these tags. Random tags don't necessarily make it clear what happens when more than one of them is used at the same time: Is it enough that one of them is true, or need all of them be fulfilled at the same time, or does it depend on the exact tags used? The tags with the if prefix are clearly defined by this proposal to use the latter option.
  • As Csmale's comment above already hints at, we might want to consider another prefix ("if_not:*", "except:*" or whatever) in the future for the more exotic cases.
  • The prefix "if" lets us easily distinguish the restriction expressed by the relation from the additional conditions. This is not as obvious right now, as we only use relations for turn restrictions. But if we ever use relations for other restrictions, it could become essential. When a relation could e.g. express a weight limit, but also express a speed limit that only applies for vehicles exceeding a certain weight, a weight tag's role is not really instantly clear without the prefix. That's not a concern right now, of course, but then the "if" doesn't really hurt any more than "addr" does.

--Tordanik 20:14, 23 July 2011 (BST)

why not using the restriction namespace

while i'm for the refinement of turn restrictions, i also don't like the "if" in front of the transportation mode. why not use "restriction" as a namespace? this way multiple transportation modes can be described in one relation, if needed. i would also drop the "if" for the time based condition. simply "time" is enough since the meaning is clear in the context of turn restrictions. example:


and if you have different time based restrictions for different kinds of transportation modes you could write it like this:

--Flaimo 19:33, 24 July 2011 (BST)

Yes, it could also work like this, but it is not an improvement all things considered:
  • Multiple separator characters (colons and dots) => people will not understand when to use which
  • variable parts in the keys => filtering gets harder (neccessary evil with tags, avoidable with relations)
  • more flexible syntax => harder to write editing tools and evaluations
  • Some conditions in the key and some in the value => inconsistent (ok, that's really just my personal opinion)
But if someone else prefers Flaimo's suggestion, please tell me nevertheless - widespread support for that syntax style like would blow my mind, but at least I might learn something from a surprise like that. --Tordanik 20:42, 24 July 2011 (BST)
I like Flamio's suggestion. The dot before time could be replaced by a colon, but other than that it is consistent with Proposed_features/Conditions_for_access_tags and Proposed_features/parking:lane. Our simple key=value scheme is not really suitable to model complex situations like time dependent restriction, so you have to bend it a little. This is still the sanest solution i've seen. See Proposed_features/Extended_conditions_for_access_tags for more "interesting" ideas.--Bk 21:53, 25 July 2011 (BST)
actually it is even more consistent with my own access proposal, but i didn't want to open that can of worms again :-) --Flaimo 23:00, 25 July 2011 (BST)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Conditions_for_restriction_relations&oldid=2512997"