On Sat, 22 Aug 2009, Tobias Knerr wrote: > Christiaan Welvaart wrote: >> Added a separate tag for cars, because AFAICT any routing app computing >> routes for cars uses this transportation mode. If routing would be done >> for 'motorcar', ways tagged as hazmat=no, for example, could not be used >> because the motorcar *could* be a hazmat vehicle. > > This reasoning is not quite valid. The restrictions for a vehicle > category are affected by categories higher up in the hierarchy, not by > those below. At least this is the idea behind current documentation such > as http://wiki.openstreetmap.org/wiki/Computing_access_restrictions , > and I don't see why we should be restricted to leaves of the category tree.
I made mistake in the position of motorcar compared to the last version of the hierarchy picture, which I now fixed. ( http://wiki.openstreetmap.org/wiki/Image:Access_modes.png ) I did not know the Computing_access_restrictions wiki page, maybe the text about evaluation I added to Key:access should be replaced by a link to that page. >> * Direction specific restrictions >> >> I listed :backward and :forward postfixes for access keys > > What you are doing here seems like picking raisins from conditional > tagging and trying to handle it as a special case. I'm not sure whether > you are aware of my proposal? > > 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? 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. > While direction may be considered as something special when constructing > a routing graph (unlike most other parameters it will have different > values during creation of the same routing graph; unless you are really > sophisticated and use changing time, it will be the only parameter like > this), it's not a special case for *evaluation*: It's just another > parameter needed to get the value of a base tag for the current situation. In the model I used, there is no base tag wich a value: each way direction has completely separate access restrictions. It only applies to the data in OSM, not a "routing graph". > 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? >> * Evaluating access tags > > Your use of "category" and "(transport) mode" confuses me, especially as > they both seem to be things that can be a key. I did not invent these names, but as I understand it, a transport mode is a distinct way of physically moving around, in other words a class of traffic participants. Differences within a class are not relevant for access to a road, while differences between classes are, in some cases. 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). So such a category is used to limit the number of tags needed to describe access for a particular way. Christiaan _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
