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 _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
