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

Tobias Knerr osm at tobias-knerr.de
Fri Dec 4 16:16:39 GMT 2009


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




More information about the talk mailing list