Christiaan Welvaart wrote: >> http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags > > This proposal does not seem specific enough. Shouldn't it list exactly > which simple keys can be modified this way, especially for the > :<transport mode> extension?
There is no need to list keys because it can be used for every access-related key. Nevertheless, I'll probably create a more detailed page about conditional tagging in the future which can include base keys. > For example, with this proposal it is > possible to create both bicycle:backward and oneway:bicycle, while I > would really prefer to only have the former. If we don't try to abolish oneway completely, I would prefer the latter in most situations. My opinion is that a base key should not be able to remove a restriction introduced by another base key. For example, hgv=yes should not be able to remove a maxweight=3.5 restriction. Similarly, an access tag (such as access:bicycle:*=* or short bicycle:*=*) should not be able to remove an oneway tag. This principle makes understanding and evaluating the tags much easier, imo. To get a value for maxheight, you check all maxheight:* keys and nothing else. The same goes for oneway and all other base keys. One example why I think oneway and access (including the transport mode and category tags) should not affect each other: In front of a station, there is a road that must not be used by motor vehicles except busses. This road also is an oneway road, with no exceptions. Therefore, I consider it natural to tag this - oneway = yes - (access:)motor_vehicle = no - (access:)bus = yes This can easily be understood if oneway isn't influenced by the other tags. If, however, we consider oneway=yes just another way of saying (access:)vehicle:backward=no, then we suddenly have a problem: Neither of the two conditional expressions "vehicle:backward" and "bus" is more specific than the other one, so we cannot determine whether the yes from "bus" or the no from "vehicle:backward" is relevant here. To sum up: Yes, both bicycle:backward and oneway:bicycle are direction-dependent restrictions for bicycles. However, they are still different because only oneway:* keys should be able to overwrite other, less specific oneway keys. In practice, this means that :backward will rarely be useful for bicycle, it makes more sense in combination with maxspeed and sometimes other base keys. >> As evaluation is the aspect that needs to be documented (routing graph >> creation is up to the application), I believe forward/backward shouldn't >> be introduced or documented separately but instead as a part of >> conditional tagging. > > Is it really a problem if work is one in this respect as long as it does > not contradict the conditional tagging proposal? There were some suggestions to use brackets instead of colons for this (such as bicycle[backward]=no or hgv[06:00-10:00]=delivery) because conditions are not what colons have been used for before - for example, they don not have a defined order. Probably, though, colons are better anyway because using different syntax for different postfix semantics would only lead to confusion and inconsistent uses... > A (transport mode) category is simply a group of transport modes and/or > other categories that are sometimes treated similarly regarding road > access (by law). Ok, thanks, I now understand what you mean. I thought it had something to do with the access values (forestry, delivery and so on), because except for destination, they are not mentioned by your description at all. Tobias Knerr _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
