Re: [OSM-talk] Changes to Key:access wiki page
hi, On Sat, 22 Aug 2009, Tobias Knerr wrote: 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 I didn't really answer this question yet. My idea with :forward and :backward was to group all access restrictions - keys that take yes/no/destination/private/etc. - with the access key. So I also sometimes write e.g. access:vehicle:forward=no . But time restrictions should also be included, e.g. as :Tfrom-to, so one could write (crazy) things like: access:vehicle:forward:Tmo-fr=destination access:vehicle:forward:Tsa-su=yes access:vehicle:backward:Tmo-fr=delivery access:vehicle:backward:Tsa-su=no A problem with oneway= is that it cannot accept the whole range of access values - only yes/no. So the above cannot be done with :oneway AFAICT. (max)height/weight/width/speed could maybe also be included with access, but I think it is better to treat them as access limits and keep them separate. Then the conditions proposal looks good for these keys. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Tue, 25 Aug 2009 10:47:14 +0200 (CEST), Christiaan Welvaart c...@daneel.dyndns.org wrote: hi, On Sat, 22 Aug 2009, Tobias Knerr wrote: 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 I didn't really answer this question yet. My idea with :forward and :backward was to group all access restrictions - keys that take yes/no/destination/private/etc. - with the access key. So I also sometimes write e.g. access:vehicle:forward=no . But time restrictions should also be included, e.g. as :Tfrom-to, so one could write (crazy) things like: access:vehicle:forward:Tmo-fr=destination access:vehicle:forward:Tsa-su=yes access:vehicle:backward:Tmo-fr=delivery access:vehicle:backward:Tsa-su=no A problem with oneway= is that it cannot accept the whole range of access values - only yes/no. So the above cannot be done with :oneway AFAICT. (max)height/weight/width/speed could maybe also be included with access, but I think it is better to treat them as access limits and keep them separate. Then the conditions proposal looks good for these keys. When you are getting this complicated on it, maybe it is better to handle this in relations? This way each special condition can be handled separately without cluttering the map with tags. A road can have a set of general access tags, and than use relations for the complicated access conditions, such as psv only on school days, goods delivery 10-12 mon-fri + 11-12 saturdays in july, destination for taxies exept saturdays after 22, and so on. That will allow you to do all these special condition without access:vehicle:forward/backward. I havn't seen that complicated access restrictions in the areas I map, so I have no need for it, but I know that reality is a little different in Europe. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Tue, 25 Aug 2009, Aun Johnsen (via Webmail) wrote: On Tue, 25 Aug 2009 10:47:14 +0200 (CEST), Christiaan Welvaart c...@daneel.dyndns.org wrote: hi, On Sat, 22 Aug 2009, Tobias Knerr wrote: 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 I didn't really answer this question yet. My idea with :forward and :backward was to group all access restrictions - keys that take yes/no/destination/private/etc. - with the access key. So I also sometimes write e.g. access:vehicle:forward=no . But time restrictions should also be included, e.g. as :Tfrom-to, so one could write (crazy) things like: access:vehicle:forward:Tmo-fr=destination access:vehicle:forward:Tsa-su=yes access:vehicle:backward:Tmo-fr=delivery access:vehicle:backward:Tsa-su=no A problem with oneway= is that it cannot accept the whole range of access values - only yes/no. So the above cannot be done with :oneway AFAICT. (max)height/weight/width/speed could maybe also be included with access, but I think it is better to treat them as access limits and keep them separate. Then the conditions proposal looks good for these keys. When you are getting this complicated on it, maybe it is better to handle this in relations? This way each special condition can be handled separately without cluttering the map with tags. A road can have a set of general access tags, and than use relations for the complicated access conditions, such as psv only on school days, goods delivery 10-12 mon-fri + 11-12 saturdays in july, destination for taxies exept saturdays after 22, and so on. That will allow you to do all these special condition without access:vehicle:forward/backward. I havn't seen that complicated access restrictions in the areas I map, so I have no need for it, but I know that reality is a little different in Europe. I guess using relations is an option. But AFAIK the vast majority of roads in the world only needs a highway tag for access, and most specific access restrictions are simple. My example was not really practical, if such complicated restrictions exist they are likely rare. This would mean that an access restriction relation needs a completely new specification that will not be used much, while the system I described scales from simple situations to quite complicated ones. Also, having access restrictions in two locations (tags on the way/node and in relations) only complicates things. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
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
Re: [OSM-talk] Changes to Key:access wiki page
On Mon, 24 Aug 2009, Tobias Knerr wrote: Christiaan Welvaart wrote: http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags 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. Interesting, wouldn't it then be better to always use maxweight instead of hgv, since AFAIK the only property of hgv is its weight? 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. This can be defined. As I described it one would have to write bus:forward=yes , but people may indeed expect bus=yes to work. 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. It is not clear from the text on the proposal page that oneway:transportation mode is more specific than transportation mode:forward ... It would be nice to have an explicit description of how all the different tags can be evaluated. One thing I don't like about using the oneway tag in complex situations is that oneway works the opposite way of regular access restrictions: oneway=no allows access in both directions, while access=no denies access. This could be a reason why having *both* oneway:* and access:*:forward/:backward is not such a good idea. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
Christiaan Welvaart wrote: 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. This can be defined. As I described it one would have to write bus:forward=yes , but people may indeed expect bus=yes to work. Yes, it can be defined, of course. I believe that the results of an independent evaluation per base key rule comes close to what many people assume about the tag's meaning (its impossible to match all current expectations, unfortunately, because different people have different, sometimes contradicting opinions in absence of clear definitions) and are rather easy to understand. It is not clear from the text on the proposal page that oneway:transportation mode is more specific than transportation mode:forward ... It would be nice to have an explicit description of how all the different tags can be evaluated. I'm going to put together a comprehensive description of how I think access evaluation w.r.t. conditional tagging could work as soon as I have the time. I hope that this will make things clearer. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Mon, 24 Aug 2009, Martin Koppenhoefer wrote: 2009/8/22 Christiaan Welvaart c...@daneel.dyndns.org: hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - Added a tag for low performance mopeds, because in some countries they are by law neither a bicycle nor a true moped. currently there is no more mofa (I guess this is not English, as it is an abbreviation of Motorfahrrad = motor-assisted bicycle) on the page and no definition for moped (until which ccm it is considered to be such, or what else is the criteria). I put some descriptions in the hierarchy, are those good enough? Indeed mofa is AFAIK the german word for this vehicle class (25km/h mopeds), I could not find a proper english word for it. IMHO motor_vehicle should not include mofa, lawn-mowers and other stuff like this. AFAIK mofas (below 50 ccm) are in many countries considered as bicycles, at least outside town. The general sign to exclude motorcars and motorcycles often don't exclude mofas. If mopeds *are* considered motor vehicles it seems a bit arbitrary, because mopeds and low performance mopeds aka mofas are very similar (at least in the EU), even though they may be treated somewhat differently by traffic rules. That said, I do not care much about the exact categorization of 'mofa' as long as it is clearly defined so everyone knows the meaning of access tags on a way. (For dutch traffic law it would make sense to define motor_vehicle as motorcycles, cars etc. - excluding any mopeds.) Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
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
Re: [OSM-talk] Changes to Key:access wiki page
On Sat, 22 Aug 2009, Craig Wallace wrote: On 22/08/2009 20:33, Christiaan Welvaart wrote: I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. 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. Maybe the actual tag is not needed, in which case the description can stay but the tag removed. There already is a separate tag for cars: key:motorcar. I think trying to define this as different from an automobile is confusing. Have a look at Wikipedia for example, which says they are different terms for the same thing: http://en.wikipedia.org/wiki/Automobile I think your definition of motorcar (category: motor vehicles with more than 2 wheels / more than 1 track) is confusing / wrong. goods/ hgv / psv / hazmat etc should be in the hierarchy directly below motor vehicle, not below motorcar. Finally figured out what was going on: I did not look closely enough at the picture apparently - fixed. BTW what is a hov? I assume it's high occupancy vehicle, ie a vehicle with more than a certain number of passengers in it. In some places they are allowed to use bus lanes etc. Sure, but is this not a bit too complicated to put between the regular access tags? For tagging, hov= can be used although it makes me wonder what the exact qualifications are. But a routing engine supporting this should also allow specifying that at some point the number of passengers drops below the limit. With hov in the hierarcy this would mean the remaining passengers are suddenly sitting in a different kind of vehicle. That seems strange at least (: Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
2009/8/22 Christiaan Welvaart c...@daneel.dyndns.org: hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - Added a tag for low performance mopeds, because in some countries they are by law neither a bicycle nor a true moped. currently there is no more mofa (I guess this is not English, as it is an abbreviation of Motorfahrrad = motor-assisted bicycle) on the page and no definition for moped (until which ccm it is considered to be such, or what else is the criteria). IMHO motor_vehicle should not include mofa, lawn-mowers and other stuff like this. AFAIK mofas (below 50 ccm) are in many countries considered as bicycles, at least outside town. The general sign to exclude motorcars and motorcycles often don't exclude mofas. And yes, some discussion _before_ changing the features would IMHO have been better. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Changes to Key:access wiki page
hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. * Transportation modes The transportation mode hierarchy picture is replaced by a simple outline, because the picture was not integrated in the text and too small to read on the page itself (could both be fixed), and having to figure out how to modify the picture complicates editing of this wiki page. The hierarchy is however the only definition of several transportation mode categories so quite important. IMHO the picture can be re-added but not replace the outline. Some transportation modes were listed in two unrelated categories. This needlessly complicates determining the correct tags for a real-world situation. Specifically, the meaning of access tags becomes very unclear if they belong to unrelated categories. There was apparently a good reason for doing this but I have not found a clear explanation. (Note that *=agricultural is not necessarily defined by this hierarchy, only tags like agricultural=no.) 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. Maybe the actual tag is not needed, in which case the description can stay but the tag removed. BTW what is a hov? Added a tag for low performance mopeds, because in some countries they are by law neither a bicycle nor a true moped. Separated land (road), water, and rail based transportation because they can be treated separately(?). * Direction specific restrictions I listed :backward and :forward postfixes for access keys but apparently forgot explicit descriptions. The examples should be enough for now. Some roads (around here at least) have complicated oneway restrictions that cannot be modeled with oneway= and cycleway=opposite*. The postfixes allow specifying any restriction (yes/no/destination/etc.) for any transportation mode in either direction. I'd like to deprecate cycleway=opposite because it is used for roads that have neither a cyclelane nor a cycleway in that direction, so using a cycleway tag does not make much sense. * Evaluating access tags In order to know the meaning of a set of access tags on a way with some highway tag (in case of roads), it is necessary to define how access for each transportation mode can be computed from these tags. I added a section about this which hopefully matches current tagging practice. It does not include time-based, height, width, or weight restrictions so it is certainly not yet complete. Many of the values listed at the top of the page are also missing. The idea is that this model links tagging to routing so if it used, while currently AFAIK one needs to find out how a router computes access and tag accordingly or accept broken routing in one or more routing engines. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
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
Re: [OSM-talk] Changes to Key:access wiki page
On 22/08/2009 20:33, Christiaan Welvaart wrote: hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. 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. Maybe the actual tag is not needed, in which case the description can stay but the tag removed. There already is a separate tag for cars: key:motorcar. I think trying to define this as different from an automobile is confusing. Have a look at Wikipedia for example, which says they are different terms for the same thing: http://en.wikipedia.org/wiki/Automobile I think your definition of motorcar (category: motor vehicles with more than 2 wheels / more than 1 track) is confusing / wrong. goods/ hgv / psv / hazmat etc should be in the hierarchy directly below motor vehicle, not below motorcar. BTW what is a hov? I assume it's high occupancy vehicle, ie a vehicle with more than a certain number of passengers in it. In some places they are allowed to use bus lanes etc. I'd agree with most of the rest of your changes on that page. Craig ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Sat, 22 Aug 2009 21:33:27 +0200 (CEST), Christiaan Welvaart c...@daneel.dyndns.org wrote: hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. * Transportation modes (Note that *=agricultural is not necessarily defined by this hierarchy, only tags like agricultural=no.) Not all tags in access need everey value, in many cases when specifying, yes/no/dedicated cover more than enough. Only the general access need this variety of values. BTW I know of cases which could be tagged access=private + agriculture=yes + forestry=yes. Even more appropriate is hgv=no + agriculture=yes, since many of these agricultural vehicles can have a max weight far above 3.5 tonnes, I have myself maneuvered almost 10 tonnes (tractor of 2 tonnes + cargo trailer of 0.5 tonnes + 5+ tonnes of cargo). Some roads accessing farmland are actually signed with hgv=no. Separated land (road), water, and rail based transportation because they can be treated separately(?). I do not know enough about rail transport, but having only one subkey makes it abit superflous. For additional keys for water transport, see my point on the talk page. boat= should be a master key of motorboat= and sailboat=, and add fishing_vessel= and ship= as master keys as well, all other values suggested on the talk page are written hierchally under ship= Yes, there is a big point in separating boats and ships, just as separating mopeds and hgv. * Direction specific restrictions IMO this does not belong on access, but rather on oneway= as they are dictating special condition of the oneway key. * Evaluating access tags There is a list of national specific defaults of the access keys to highway=, I do not remember where it was now, but think the page is linked under 'See Also' Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
Hi! Christiaan Welvaart schrieb: I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. It is a good thing that you try to complete and clarify the page. However I must protest the way of doing it: Change the access tag page and only start a discussion on a single mailing list afterwards is not a good way to do this: - some of your best practices may not be quite as universally applicable as you think - some of your changes require discussion - which just started. But for everybody looking at the wiki, it appears your changes are approved recommendations - you are completely circumventing the proposal process, and everybody who is interested in feature changes and is watching the proposal page in order to be informed is simply excluded from the discussion. So in short: Regardless of the content: You should have created your version of the page as a seperate copy, maybe on the discussion page, announced it as a proposal and only changed the main access tag page _after_ some discussion and refinement. I believe even well-meant edits that change the meaning of established feature pages without prior discussion and bypassing everybody watching the proposals are creating chaos and are responsible for some of the confusion we are having about apparently simple tags like footway. So please, don't do it. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
