Ben Laenen wrote: > Tobias Knerr wrote: >> There is a concept that covers all of these and uses oneway:bicycle: >> http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_fo >> r_access_tags >> >> The bicycle:oneway structure, to my knowledge, hasn't been part of a >> solution that can be used to express all of these cases yet and is >> mostly just there as a solution for this single situation (opposite >> traffic on oneway ways). Imo, that's a too limited perspective. > > So that's completely incorrect, bicycle:oneway=no already appeared on > http://wiki.openstreetmap.org/index.php/Proposed_features/Access_restrictions > 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. > 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? Certainly, all of these would be entirely possible for "Extended conditions" tags and their evaluation, though. > But now with your syntax which is advocated as good > syntax to use and superseding other possibilities just because it is a > proposal, it makes life harder to create the formal framework because we now > have a whole new set of tags that have to be taken into account, and would > rule out a lot of possibilities of perhaps a better syntax. 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. 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. Tobias Knerr _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk