[OSM-talk] access tagging concepts (was: Re: opencyclemap and car directions)

[Ben Laenen]

Tobias Knerr wrote:
> Ben Laenen wrote:
> > So that's completely incorrect, bicycle:oneway=no already appeared on
> > http://wiki.openstreetmap.org/index.php/Proposed_features/Access_restrict
> >ions a long time before the extended conditions for access tags proposal
> > was created (although, indeed, not a definite proposal for such a syntax
> > -- it still could all change -- but in the mean time it was seeing some
> > usage while testing it out). But that's far from an "isolated situation
> > for oneway only".
> 
> Nevertheless, it "hasn't been part of a solution that can be used to
> express all of these cases yet". It has been part of a brainstorming
> process - but that's not a solution. Maybe it can lead to a solution.

That's basically what I said as well. But it needs work and input from other 
people to come up with a solution. I'm not able to solve the whole issue 
myself -- I lack the time for that and my ideas would be influenced too much 
by local situations.


> > Yeah, so that proposal of mine hasn't seen much change recently.
> > Basically because I have the impression almost no-one else but me seems
> > interested in creating formal definitions of access tags, and because
> > proposals like yours would come up without really looking at what was
> > written on that page.
> 
> I'm not sure what exactly you would consider a formal definition.
> Description of the structure using some kind of grammar? Evaluation
> rules? Something I didn't even think of?

A formal definition is something like a state machine that takes as input the 
way and its tags, relations, tags on its node etc, and something describing 
the way of transport (vehicle type, actual weight, maximum allowed weight 
etc.), and has as output whether that road can be used. Some kind of algorithm 
if you want.

For now, these rules are basically just defined by a few sentences in the wiki 
in plain English, and it's not hard to find cases that become ambiguous.


Some examples:

oneway=yes
bicycle=yes

-> are bicycles allowed in both directions or not?


day_off=saturday
bicycle=yes

-> cyclists allowed on Saturday? oh, and pedestrians?
if you said cyclists allowed, then what about this:


day_off=saturday
motor_vehicle=no
motorcycle=yes

-> motorcycles allowed on saturday? Or is it just an exception on 
motor_vehicle=no the rest of the week?


> Certainly, all of these would be entirely possible for "Extended
> conditions" tags and their evaluation, though.

Not saying it's not possible, they surely can be defined properly in some way. 
But they aren't yet. And as a result it may be that trying to implement it may 
result in some strange effects conflicting with common sense.


> I'm always open for better solutions. I also believe that a syntax being
> used isn't an argument for not replacing it if something better comes
> along. I wouldn't expect you to necessarily take "Extended condition"
> syntax into account when creating your own concepts, and I don't think
> it's a practical necessity, either, as none of these cases is very
> widespread yet.

It does matter when the two ideas would result in the same tag meaning two 
different things.


> Also, what would you have expected me to do in that situation back then?
> Yes, there was this page that hadn't been very active even then and
> didn't offer much except some "brainstorming". Yes, maybe someone would
> come up with a solution based on it, but there was no indication that it
> would develop into anything.
> 
> So I what I did was this: I spent hours thinking about other solutions,
> discussing syntax, writing software prototypes for different syntax
> variants and so on. No, I'm not convinced that my proposal is the ideal
> solution. I'm now convinced that it is a *working* solution, though,
> which integrates most of the existing tags and allows them to be defined
> consistently. Still, if you can come up with something better, please do.

Well, there's the problem in that last sentence: I can't do that myself, as 
I've said above as well.

What I could have done indeed was immediately creating a proposal like yours. 
It's just that I preferred not to until I was sure how to put it into a more 
general framework for handling access tags.

By the way, I'm certainly not mad or anything that you decided to take the 
shortcut by not thinking about the bigger picture. Indeed, what else was there 
to do if you wanted to tag these things. So I also had my own few tags to map 
these things. Those tags weren't meant to be final in any way (in fact, I'm 
actually more a fan of something like "oneway=yes;[bicycle]no", instead of 
"oneway=yes + bicycle:oneway=no"). So I didn't put them into a nice proposal 
yet. But your proposal makes it look like it would make it a final syntax, and 
that that is the only proper way to tag. Something I wanted to avoid until the 
big picture was more or less worked out.


My main concern for example about your (extended) proposal is the usage for 
the colon for everything, and adding values in the key. The colon is already 
used for so many things (namespace, specification, condition...), and values 
in keys is asking for trouble.

Greetings
Ben