Hi,

it's a good thing that someone finally tries to clarify access
documentation - it definitely needs some care. I agree with your
reasoning to replace the image with editable content and some of your
definitions (such as avoiding to put an entry into the hierarchy
multiple times and separating water/land).

Nevertheless, some changes require a bit of discussion, but I guess you
expected this, didn't you? ;)

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.

Therefore, considering an automobile a generic "motorcar" that is
affected by those restrictions applying to generic motorcars should work
well, it doesn't need an own category.

> * 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

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.

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.

> * 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 know from experience that it is hard to find good terms for these
concepts, but maybe you can help me a bit to understand it.

Tobias Knerr

_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Reply via email to