[Tagging] Feature Proposal - RFC - UPRN & USRN
Hi all, Mappers in the United Kingdom are looking to agree two tags for mapping 'Unique Property Reference Numbers' and 'Unique Street Reference Numbers'. To support this effort I volunteered to create the relevant proposal pages on the wiki. To view and comment on these please see: https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn These pages have already been posted to talk-gb and talk-ie (for Northern Ireland) a few days ago. As long as there are no major blockers here, we will move to the voting stage shortly. Thank you, *Rob* ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cycle lanes & cycle tracks - my findings and a proposal
Hi All, Sorry for the late reply after starting this thread a few days ago. I was surprised to see how far this topic has expanded (even into OSM should have fault lines so we can re-align after earthquakes!), so I just want to refocus on cycling. 1. A Quick Recap >From the countries that I have researched so far (UK, Netherlands, Germany) there is a consistent difference between a cycle LANE (Fietsstrook, Radfahrstreifen), and a cycle TRACK (Fietspad, Radwegen). In all countries a cycle LANE is a area within the main roadway (carriageway) that is allocated for cycle use. It is indicated by a painted line on the road surface. For all purposes in OSM it can be considered as a 'lane' as there is no separation from the other lanes that form the road and therefore nothing physically stopping a cyclist from changing to a different lane at any point along the road. Motor vehicles may be prohibited from using this lane (UK: "Mandatory cycle lane") or not (UK: "Advisory", Netherlands "Fietssuggestiestrook"). Contrast this to a cycle TRACK, which is physically separate from the main roadway. The separation may be a kerb, barrier/wall, strip of grass or just a row of parked cars. In different countries the TRACK may be one-way or two-way, shared with pedestrians, mandatory for cyclists, and so on. Irrespective of all of these things is the key fact that the cycle TRACK is physically separated and therefore the cyclist cannot simply move from the track to the main roadway at any point / at will. 2. The cycleway=* tag The current cycleway tag attempts to cater for both of these and as a result it is not particularly clear for new users. I believe the fact that renderers and routing software haven't picked up the cycleway tag with any widespread enthusiasm is evidence that improvements can be made. 3. So what is important For a cyclist I feel that the most important thing is "I am travelling from A to B with my child. How _safe_ is it for cyclists? Will there be cycle lanes and/or cycle tracks to use in the _direction_ of my travel?" Based on this question the useful things to know are: * Direction * Safety 3a. Cycle LANES By having a tag specifically for cyclelanes we can indicate both direction and type of lane (an partial indication of safety). For example: highway=secondary cyclelane:forward=share_busway cyclelane:backward=advisory Exact lane positioning can then be picked up by the lanes fans ( http://wiki.openstreetmap.org/wiki/Lanes) 3b. Cycle TRACKS As these are physically separate from the other lanes of the main roadway (and therefore a cyclist is not free to switch back and forth between cycle track and roadway), my personal preference is to map them as a separate way. Our German mappers raised the concern that cyclists must use the cycletrack and are not allowed to use the roadway unless the cycletrack is obstructed, for example. They have pointed out that they do not like the use of bicycle=no on the main highway as cyclists are not legally banned from using the road in all circumstances. Although I think they are being hopeful that bicycle=no is only being used when it is illegal, can I suggest bicycle=secondary, bicycle=non-primary, or bicycle=alternative for this case (another suggestion already made is bicycle=destination)? For cases where it is difficult to draw a separate way then consider: highway=secondary cycletrack:left=two-way Any feedback will be much appreciated, but please keep in mind the ease of the system for new users and long-term maintainability. Cheers, Rob p.s. In my opinion "no" is not a strong enough word to ensure that it is only used when access is illegal/prohibited, especially when shown in Potlatch2's drop down menu with no explanation. Much better would be access=illegal -> please start a new thread if you would like to discuss this :-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cycle lanes & cycle tracks - my findings and a proposal
>In Denmark, they use lanes/tracks that are immediately alongside the road >and separated by a shallow kerb, and turn into lanes on the approach to >junctions. You can certainly move on and off them very easily. OK. I assume they are not allowed to be used by cars? In these cases the track can be tagged as part of the highway (as in the example in my previous email), however as many people have pointed out it is difficult to add all the detail unless you draw it as a separate way. I was about to write that someone suggested to use some form of "degree of separation" but thought it was rude not to credit them. Turns out the suggestion was yours! Unfortunately the suggestion was misunderstood to mean "angle". To clarify "degree of separation" can also be read as "amount of separation". Possible values could include "shallow kerb". Regards, RobJN ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] New access tag value needed?
There seems to be a need for a new value for the access tags. The new value would indicate that the way can be used (as it is not illegal / prohibited), but it is advised to use a different route. There are at least 2 cases I am aware of where this would help: 1. For cycle tracks drawn as separate ways from the highway >* Our German mappers raised the concern that cyclists must use the cycletrack >and*>* are not allowed to use the roadway unless the cycletrack is obstructed, >for*>* example. They have pointed out that they do not like the use of >bicycle=no on*>* the main highway as cyclists are not legally banned from >using the road in all*>* circumstances. ** 2. Cycle only paths in the UK In the UK there are some cycle paths that are signed as "cycle only" but there is no legal condition prohibiting use by pedestrians. The official signage guidance states: "the route is not intended for pedestrians, there should be a convenient footway or footpath nearby." - - - **Although I think we are being hopeful that access=no is only **used when it is illegal, there has been resitance in both cases to use =no. Can I therefore suggest access values such as =secondary,* *=non-primary =alternative Are any of these preferred? Regards, RobJN * * * ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New access tag value needed?
Thanks Martin, Maybe I wasn't very clear in my first email (not helped by poor formatting), but I'm not looking to add a "suggested route". I am trying to indicate cases that have legal binding (or very strong advice from government). For example: 1. A road in Germany should not be used by cyclists if there is a cycle track next to the road UNLESS the cycle track is not passable, etc. 2. A cycle track in UK that is marked as cycle only does not legally prevent pedestrian use but official guidance states: "the route is not intended for pedestrians, there should be a convenient footway or footpath nearby." I see that something like "alternative" may end up being used for suggested routes, but is there any other (potential new) values for the access tag that may help here? RobJN >2012/5/30 Rob Nickerson <http://lists.openstreetmap.org/listinfo/tagging>>: >**>* There seems to be a need for a new value for the access tags. The new >value*>* would indicate that the way can be used (as it is not illegal / >prohibited),*>* but it is advised to use a different route.* This is a feature often talked about (suggested routes), which might be suitable for OSM or not (I guess most of the mappers actually consider this not suitable because advices are a matter of subjective judgement and interpretation). It is definitely nothing to store in an access-value, as access if for legal accessibility _only_. If you wanted to tag non-suitability you should use another namespace/tag (additionally). Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Extended tagging schema - my thoughts
Hi all, One of the issues raised with the extended conditions tag schema was the use of variable values in the key part of the tag. For example maxspeed:wet = 80 is in the form constant:variable=variable. This has been deemed to break the basic tagging rules. Can I therefore give alternative suggestions: * maxspeed=120; 80?wet; 60?wet+hgv Here '?' can be interpreted as 'if' and '+' as 'and'. Many alternatives can be proposed using alternate symbols (or none at all). In fact, it is already in use: * opening_hours=Mo-Sa 10:00-20:00; Tu off This is off the form constant=condition value; condition value. Using this existing schema, the maxspeed example becomes: * maxspeed=120; wet 80; wet+hgv 60 Advantages: Easy to reduce back to the basic condition, editors can implement this in a fancy GUI; expandable, can use bots to analyse/fix Opinions welcome, Regards, RobJN ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Extended tagging schema - my thoughts
(Foolish me - meant to send that email to the tagging list. It's now posted there so suggest any more responses are to the tagging list.) Yep, many formats can be used. First thing is to see if the idea is liked by anyone, including Eckhart, who raised the issue on the tagging list today. Regards, Rob On 9 August 2012 17:14, Pieren wrote: > On Thu, Aug 9, 2012 at 5:51 PM, Rob Nickerson > wrote: > > > * maxspeed=120; 80?wet; 60?wet+hgv > > > > Here '?' can be interpreted as 'if' and '+' as 'and'. > > It's maybe more readable if you write "120; wet ? 80 ; wet+hgv ? 60" > > Pieren > ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Extended tagging schema - my thoughts
Hi All, I've been thinking a bit more about this and would like to improve on my initial thoughts from yesterday. So expanding on the existing opening_hours type tag, I would like to suggest the following format for extended access tags: * := ; ... Explanation: 1. can be 'access', 'maxspeed', maxweight', etc.. Default value is 'access'. This means that if : is omitted the extended tag falls back to the current use (e.g. hgv=destination). 2. is the transportation types given on the current wiki page. If omitted the rule applies to all transportation types (this is the current use). 3. The takes inspiration from the opening_hours tag (e.g. opening_hours=Mo-Sa 08:00-18:00; Su off - here "Mo-Sa" is condition 1, 08:00-18:00 is the value, etc..). If condition 1 is omitted then value1 is assumed to be the default value for the tag key. 4. There would be a limited number of (approved) rules and vehicles => therefore a limited number of tag keys. 5. Condition formats should be pre-approved (e.g. 'wet', 2 letter day types, 24hr clock types, etc.). Examples: * maxspeed=120 * maxspeed:hgv=80 * maxspeed=120; wet 80 * bicycle=yes; 10:00-18:00 no Advantages: This proposal has a limited number of tag keys (both rule and vehicle) have to come from an 'approved' list. The format is already in use in the open_hours tag, and is as easy to understand as any other extended schema. The format also falls back to match existing tag usage. Possible issues: 1. How to include 'forward', backward' - possible solutions include (a) ::=... (b) ::=... (c) :=forward ; backward . The issue with (c) is that it may require pairing with other conditions - e.g. "bicycle=yes; backward+10:00-18:00 no" (bicycles allowed except in a backward direction between 10am and 6pm). 2. What if the condition is "Mo-Fr 10:00-16:00"? This would break the format of a space character separating . Possible solutions include using brackets, or using a different character to separate the condition from the value. For example (a) bicycle=(Mo-Fr 10:00-16:00) no (b) bicyle=Mo-Fr 10:00-16:00?no 3. Maxweight except for access might be a bit tricky, but thinking about it you have the condition "destination" having no restricted maxweight. So we can therefore use "maxweight=5.5; destination unset" (which reads that there is a maxweight of 5.5t, with no maxweight restriction when using the road for 'destination' access. 4. Order of the condition value pairs. These should be seen as building blocks -> condition 1 holds true unless condition 2 overrides it, which in turn is true unless condition 3 overrides it... Regards, Rob p.s. To address some criticisms of my earlier proposal: >Here are some disadvantages of merging everything into a single value: > - readability and ease of manual editing suffers This suffers in any lenthy tag schema. Thr proposal is consistent so editors can be adapted to provide a fantastic GUI. > - you lose backward compatibility The proposal falls back to existing tag schemas therefore providing backwards compatability. > - you don't integrate widely used conditions like forward, hgv, … now fixed > - you run into the (real) risk of exceeding the 255 byte limit imposed on > values That would have to be one hell of a complicated access rule!! ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended tagging schema - my thoughts
Eckhart wrote: >* > - you lose backward compatibility*>* *>* The proposal falls back to >existing tag schemas therefore providing*>* backwards compatability.* No, it doesn't. If you set maxspeed=120; wet 80, then none of the existing routing programs can use this tag anymore. The Extended Conditions proposal uses the tagging maxspeed=120, maxspeed:wet=80, which allows existing routing programs to still use the maxspeed key. >* > - you run into the (real) risk of exceeding the 255 byte limit imposed on >values*>* *>* That would have to be one hell of a complicated access rule!!* Oh, you haven't seen anything. German inner city pedestrian zones are infamous for complex access restrictions (taking into account bicycles, delivery traffic, destination traffic, taxis, all of them depending on the day of week and the time of the day, and sometimes even on the direction). Eckhart - Apologies. What was meant was that software need only cut off the extended values to return to existing systems (and thus compatibility). For example "maxspeed=120; wet 80" is chopped down to "maxspeed=120 ". As there are lots of tags in use, it will be tricky to find a schema that is both liked and does not break a single thing. As for 255 bytes. All vehicles have their own tag, so would be tricky to hit 255 bytes. Regards, Rob p.s. I am trying to suggest an alternative that does not put all the conditions in the tag key (as this was one of the big criticisms). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended tagging schema - my thoughts
Thanks both, I will look into options for better maintaining compatibility. One possible solution would be to prefix extended tag keys with "e:" for a transitional period. I'm not a big fan of this as it is messy. The problem is sometimes you just have to make big changes even if this breaks compatibility. The better OSM data users will take steps to adapt their software. Cruel but things do change. I decided to throw some ides out there after the earlier proposal failed to gain approval in its first vote. I think it is key to get this sorted out - only just the other day it was confirmed on the osmf mailing list that the auto industry has asked how OSM plans to "close the gap" between OSM and commercial navigation mapping. Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended tagging schema - my thoughts
-- Tobias wrote: -- Have you seen the "Conditional restrictions" proposal that was linked here yesterday? http://wiki.osm.org/Proposed_features/Conditional_restrictions It is basically the same idea. The most important difference is that it uses a ":conditional" suffix. This makes it backwards compatible, unlike your solution which would put things like "120; wet 80" into the established maxspeed tag. > * maxspeed=120 > * maxspeed:hgv=80 These would look the same with "Conditional restrictions". > * maxspeed=120; wet 80 This would become maxspeed = 120 maxspeed:conditional = 80:wet --- Thanks Tobias, I had skim read it but must have missed the point as it is almost exactly what I ended up with!! Credit to Ole and apologies - I really need to slow down and read things properly. Ole, I wrote up my proposal [1] and it turned out almost exactly the same as yours (if you include my point 2 in the "But Wait..." section). Feel free to take any ideas you want. For example my syntax uses a whitespace to separate condition from value, so "(Mo-Fr 07:00-17:00)" in your proposal becomes a combined condition of "Mo-Fr&07:00-17:00" in mine. One of the things I struggled with was the maxwight / length conditions. So where you suggest "motor_vehicle:conditional=no:(10:00-18:00 AND length>5)", I would have used "maxlength:motor_vehicle:e=unset; 10:00-18:00 5" - meaning no restriction is set except when between 10am and 6pm, in which case a maxlength of 5m applies. I went for this as it didn't require the > character. As noted, feel free to take any parts of my proposal, or drop me an email if you would like to discuss anything. For now my proposal is on hold, and my support with you. [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_access_tags ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Clarify tag access doc
Although I don't know the history of the access tag, I would expect that "designated" and "permissive" might have something to do with Public Rights of Way in the UK: * If a path is designated as a "Public Footpath" then you have a legal right to walk on it and there is a legal structure protecting these and dictating how the local government should keep a record of them. * The public has a right to request a path be added to the list of "Public Footpaths" if they can prove prior use (pre some date I can't remember). To prevent this happening a landowner can optionally decide to make a "Permissive Footpath". Again this has some legal consequences but to the landowner it may be more appealing to have a permissive path over his land rather than risk someone challenging him on the grounds that the path be added as a "Public Footpath". * Having said all this the UK guidelines are now to use "designation=public_footpath" and no need for an 'access' tag. For permissive paths I have seen both "foot=permissive" and "designation=permissive_footpath" Regards, Rob p.s. If it helps, I don't understand the access tag either!! ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Dear List,
{This is a cross post - please reply to the tagging mailing list or the
proposals [2] talk page }
- - - Announcement - - -
Several attempts have in the past been made to develop a tagging scheme
that is capable of handling the more complex access restrictions (e.g. No
motor vehicles between 10am and 6pm except vehicles less than 5 meters
[1]). Voting has started on the latest proposal [2]. Due to the wide reach
of this proposal, I am announcing it here and encouraging users to
carefully consider the proposal and vote.
To help, I have summarised the alternate proposals (in alphabetic order and
including this one) [3]. Note that not all of these are in active
development. I have also attempted to write the case for and case against
this proposal.
As a reminder of terminology, a Tag consists of 'Key' and a 'Value' pair
(key=value). For example "maxspeed=80".
- - - Case "For" - - -
Extract by the proposal author from the proposal's wiki page [2]:
//start quote// This proposal overcomes some objections to previous
attempts at tagging conditional restrictions.
* No variable parts in the key. This is essential as keys are used to
search for data in the OSM database. If a key comprises a variable part it
can no longer be retrieved during search unless you know the exact
condition you are looking for (database searches do not allow wildcards in
search keys). Variable parts in keys will also lead to an undesired
proliferation of unique keys.
* Avoids the requirement for problematic characters in the key such as "<"
or ">"
* Clear distinction between scope (transportation mode, vehicle class) and
condition.
* Possibility to combine conditions using operators.
* The conditional restriction can be defined as a single tag. Some prior
proposals required multiple tags such as hour_on and hour_off tags. For
objects having multiple restrictions this could lead to problems (which
tags belong to which restriction?)
* The syntax of the key is essentially identical to the established access
key syntax with an additional qualifier ":conditional".
* Backward compatible. Doesn't break any established tagging schemes.
//end quote//
- - - Case "Against" - - -
Extracts from those who have currently (18/09/2012) voted against the
proposal:
//start quotes//
* Breaks a lot of tags which came "natural" to the mappers, e.g.
maxspeed:wet=80 becomes maxspeed:conditional=80 @ wet, access:disabled=yes
becomes access:conditional=yes @ disabled, …
* Creates arbitrary distinctions: depending on whether something is defined
to be a transportation mode or a condition, it belongs either in the key or
in the value, e.g. "hgv" is a transportation mode, but "hazmat" is a
condition
* Has bad editor support: adding a conditional restriction like "speed
limited to 80 when wet" to a set of ways is quite complicated if there are
already different restrictions on those ways; merging :conditional tags in
JOSM by default produces a value that is completely wrong, yet cannot be
identified as wrong.
* It's to difficult for users, not intuitive. There are too many subkeys
and subvalues. I think value with logic instruction (AND) (and maybe
special/new signs (@)) are not good tagging rules.
//end quotes//
- - - How to Vote - - -
0. Take a moment to conside the pros/cons and their relative importance /
how would you do it differently?
1. Log-in to OSM wiki (as far as I know this is not your usual OSM
username/password.
2. Navigate to the proposal page [2]
3. Click edit (to the right of the "Voting" heading
4. Add "{{vote|yes}} --" or "{{vote|no}} --" after the existing
votes.
Kind Regards,
RobJN
[1] Example Signpost:
http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg
[2] The Proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions
[3] Summary of alternate proposals:
http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_access_tags
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Hi All, Despite some of the perceived benefits of this proposal being challenged (mainly in regards to their relevance), the overwhelming thing that was clear was that this proposal was well thought out. Ole looked carefully at the feedback that was given during previous proposals and worked to find solutions for many of them. There will never be a 100% perfect solution due to the fact that, in the absence of a tag scheme, many alternate tags have crept into use. Despite this I feel it is important to push ahead with a conditional restrictions tagging scheme as it provides some form of standardisation and therefore simplifies the task of downstream users (which ultimately will lead to more use of OSM's fantastic data). To put this into some context, recall that there was a discussion recently (on talk list I think), where it was made clear that the German auto industry had asked OSM how we intend to "close the gap" between us and commercial navigation. As noted by Andy, I do however agree that this proposal (like many others) could slip under the radar of many people. Due to it's potential reach, I would have liked to have seen something posted to the Developer mailing list during the Draft & RFC stages. Kind Regards, Rob p.s. I know voting isn't popular, but it is one part of communications (i.e. giving feedback) and I encourage you to reconsider it if you have so far opted not to vote. http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
-- Eckhart wrote -- Hi Rob, Am Mittwoch, 19. September 2012, 18:08:30 schrieb Rob Nickerson: >* Despite some of the perceived benefits of this proposal being challenged*>* >(mainly in regards to their relevance),* Except for one claimed benefit, I did not question the relevance of the claims, but their validity. Maybe you should read mails before summarizing them? -- End -- Hi Eckhart, Please accept my apologies that my English was not clear. I did read your mails and my wording should be seen as it was intended - that is, the perceived benefits may not be "relevant" due to the "invalidity" of the thing they are trying to fix. I will try to be more exact next time. Kindest regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional Restrictions vs. Extended Conditions
>Hi everybody, > >it probably comes as no surprise that I am against the Conditional >Restrictions proposal and in favor of the Extended Conditions proposal. >My main reason is that I believe the Conditional Restrictions proposal is so >complicated it will kill mapping of those conditions almost completely, while >its benefits are only dubious. == The following responses are not specific to this proposal only == I disagree that it will kill mapping of these features. I expect some people are holding off mapping these until there is an accepted tag schema (otherwise they may have to go back and waste time correcting anything they do add once a schema is decided upon). As for the complexity, I feel that the wiki page can be improved to help explain the proposal better (for example by using colours like seen on an alternate proposal [1], and adding some image examples). Regards, Rob [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_values ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Seasonnal roads
>Hi, > >I'm looking how to tag a road with seasonal opening or closing. ... >Up to now, I was using "opening_hours=*" with "Nov-Apr off". Hi Éric, Have you tried: http://wiki.openstreetmap.org/wiki/Conditional_restrictions Work is under way to help make the page clearer, but essentially your tag would be: * vehicle:conditional = no @ Nov-Apr This would restrict bicycles as well so replace vehicle with motor_vehicle is this is more appropriate. Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Difficult passability
As noted some of these things change very quickly (I know some of the other things you mentioned can and do change, but the frequency is a lot less). The issue of then using these tags in a routing app / software is one a staleness. Perhaps the router should not use them when deciding the best route but should present them as route comments instead. As such the notes=* tag or perhaps obstacle=* & danger=* would work well. These values can then be any text rather than a set list of values. Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Seasonnal roads
-- Éric wrote: -- For mountain pass in Alps, this could be just access:conditional = no @ Nov-Apr For African tracks, something like smoothness:conditional = horrible @ May-Oct smoothness:conditional = very_horrible @ Nov-Apr or smoothness = horrible smoothness:conditional = very_horrible @ Nov-Apr All with seasonal=yes to indicate the random aspect of the time condition. Do you agree? -- End -- That seems logical to me. One word on using "access:conditional" though - this would indicate no access, including on foot. For more details see [1] and [2]. Essentially there is a hierarchy of subcategories for transportation modes. Rob [1] http://wiki.openstreetmap.org/wiki/Access#Transport_mode_restrictions [2] http://wiki.openstreetmap.org/wiki/File:Access_hierarchy_simple.png ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Seasonnal roads
*>One of the main mountain highways here is closed to licensed vehicles*>during the winter months, but snowmobiles are permitted. Would >vehicle:conditional apply to snowmobiles? > >-- >Clifford Hi Clifford, "vehicle" does include snowmobiles. Essentially there is a hierarchy of transportation modes that are explained at [1]. On the German language version of this page there is a nice image explaining it [2]. So "snowmobile" is in the "motor_vehicle" class, which itself is in the "vehicle" class. Using vehicle:conditional would apply to everything within the vehicle class (including all motor_vehicles and snowmobiles). You would need to use: * vehicle:conditional = no @ * snowmobile = yes Here "snowmobile" is a more specific transportation mode than "vehicle" and therefore overrules the conditional restriction. Replace by those winter months in which the restriction applies. Regards, Rob [1] http://wiki.openstreetmap.org/wiki/Access#Transport_mode_restrictions [2] http://wiki.openstreetmap.org/wiki/File:Access_hierarchy_simple.png ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Seasonnal roads
>* For more details see [1]*>* and [2]. Essentially there is a hierarchy of >subcategories for*>* transportation modes.*>* [2] >http://wiki.openstreetmap.org/wiki/File:Access_hierarchy_simple.png* This scheme should be more wildly used. It seems to be use only in the German wiki. Eric --- Hi Eric, The scheme exists on all language pages of the access key, but the German version includes the image that makes things a lot easier to understand. I am including improving the key:access page as part of my work on the conditional restrictions page. To anyone else who is reading this and is now concerned, please rest assured that I will consult on any chnages on this mailing list before making any changes. Regards, Rob p.s. Feel free to add a comment to the seasonal=* wiki page. Something of the form "you may also like to use" rather than "you should also add this tag...". If you have any questions on how to edit the wiki, let me know and I'll try to help out. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Conditional restrictions accepted – turn restrictions ahead?
Hi Eckhart, Your right, voting has come to an end for the Conditional Restrictions proposal, which was approved. A statement was not made on this list as Ole and I are working on how best to write the feature page so that some of the concerns raised (about complexity / difficulty to understand) are reduced as much as possible. Like Martin, I'm not hugely convinced about the need for complicated turn restrictions (most of the restrictions will be on the road and the detail on the turn sign will simply be advanced warning for the driver). Having said that, you have provided a few examples so I have looked into it: 1. Currently we tag a no left turn restriction using "restriction = no_left_turn". 2. If we want this to apply only to HGVs then the key is changed so that it become "restriction:hgv =no_left_turn". To draw the comparison with "Conditional Restrictions" the above tags cover of , and the tag value. There is no need to specify as this is already captured in the relation (from, via, to). Therefore the only part left to add is the condition. At the moment there are 2 ways to do this 3. Using "except = *" (where * is a vehicle type). e.g. except = bicycle 4. Using day on, day off, hour on, hour off In summary we already have both "applies" type tags (1, 2 and 4) and "except" type tags (3, and the inverse of 4!). My gut instinct is that adding an "applies = *" tag would further complicate the issue. In conclusion I would be in favour of adding the conditions directly to the restriction or except tag (depending on how the road sign is written). Yes this breaks backward compatibility but there are a lot less turn restrictions in OSM than the other restrictions and if the conditions are not met then the restrictions does not apply so it shouldn't really be tagged anyway! == Some Examples == * Example 1: "no u-turn" restriction for HGVs longer than 6 metres: * restriction:hgv = no_u_turn @ (length > 6) * Example 2: no right turn Monday to Friday 8am to 4 pm: * restriction = no_right_turn @ (Mo-Fi 08:00-16:00) * Example 3: no left turn except PSV's on Monday to Friday 8am to 4 pm: * restriction = no_left_turn * except = psv @ (Mo-Fi 08:00-16:00) This then depreciates the need for day on, etc... tags which I'm not a fan of - I think it is better to tag what is on the sign e.g. (Mo-Fr 08:00-19:00). Happy to hear your thoughts. Rob p.s. I think it would be nice to see a few more real world examples if anyone has any photographs (or can remember the conditions). p.p.s It would be nice to know how many routing software apps are using these turn restriction relations. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?
> To draw the comparison with "Conditional Restrictions" the above tags > cover of , and the tag value. > There is no need to specify as this is already captured in > the relation (from, via, to). I am not sure you can say this. It should work where the junction angles are close to 90 degrees, but for a shallow "Y" junction things might need a hint as to whether it is a curve to the right with a junction to the left, or a curve to the left with a junction to the right... Colin - - - Hi Colin, Sorry, we're talking about 2 different things. I was making the comparison with Conditional Restrictions which includes direction (forward or backward). These values are not needed. Can I suggest that if you with to discuss such values as no_slight_right_turn (or whatever), then you start a new thread. It may also be worth looking back through the original proposal for turn restrictions to see if any comments were made then. Cheers, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?
I'm still not convinced that you need to introduce a new tag (be that "applies" or "condition"). 1. Although it is difficult to calculate how many turn restrictions have some form of "condition", the numbers can't be that many in comparison to normal restrictions that apply at all times. Adding the condition data to the "restriction=*" tag therefore will not break the majority of restrictions (they stay unchanged). Similarly adding the information in a new tag will not break the majority of restrictions. 2. For those restrictions that do have conditional details, if: a) you add the details in "restriction = " you break the current tagging and routing software will not know how to interpret it. The routing then does not include the turn restriction (i.e. no restriction when you want one), or if b) you add the condition to a new tag then the routing software does not see it (i.e. you have a restriction when you don't want one). Both cases need the routing software to be updated... 3. ...and that is exactly what a Request For Change (RFC) is for. It is as the name suggests a communication with your users : "Hey guys, we want to change this to make it better. What do you think? Great, can you update your systems so that you are ready for the new tags" As you see all proposed ideas will need the end users to change something. And, in fact, as we currently don't have a way of including conditions, we may already have incorrect turn restriction in OSM. _Conclusion_: Whatever we do should keep the tagging as simple and easy to understand as possible. As we already have some "applies" type information in "restriction:hgv = no-u_turn", my gut instinct is to include all the "applies" type info in this tag. Hence the example "*restriction:hgv = no_u_turn @ (length > 6)*". Regards, Rob p.s. Any change to day on, day off, hour on, hour off, will also break the existing scheme (but is in my opinion worthwhile). p.p.s. All my previous examples are fictional. More real world photos fully appreciated. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?
On 16 October 2012 23:38, Eckhart Wörner wrote: > Hi Rob, > > (Putting tagging ML back in To since this might be of interest to other > people as well, I hope you don't mind.) > > > On topic: In your suggestion you proposed "applies = *". What would you > do > > with the following: > > > > * day_on, etc... > > * restriction:hgv, etc > > * except > > > > Would you suggest deprecating them? Thus a restriction that applies to > only > > hgv's becomes: > > > > restriction = no_u_turn > > applies = no (to switch it off for all transportation modes) > > applies:hgv = yes (to switch it back on for HGVs) > > yeah, that's the idea. The implied default would be something like > "applies=yes, applies:foot=no" so that by default, turn restrictions apply > to everyone but pedestrians. > > The big advantage of using "applies" is that from a language POV it is > immediately clear what is meant, and that the syntax will be *exactly* the > same as in Conditional Restrictions. > > day_on, … should definitely get deprecated, those tags are an unholy mess: > people mess up off and on; people interpret them them as both "from day A > time B to day C time D" and "from time B to time D each day between day A > and day C". > except can probably stay, it can easily be translated (except=bus > translates to applies:bus = no) > restriction:hgv should get deprecated / reverted, someone recently sneaked > this into the wiki page without any discussion. > > Eckhart > Hi, No problem with you moving this back online (I wanted to check that I wasn't putting words in your mouth first). Thanks for the clarification. I spotted you had reverted some recent changes (thanks) but wasn't aware that restriction:hgv was also a recent addition. I think deprecating these would be step in the right direction and removes many of the concerns I had with using a new tag (namely you end up with "applies" type data within both "restriction:hgv = " and "applies="/"condition="/whatever the new tag is called). I suggest we write up a wiki page proposing the changes. That way we can better track the discussion :-) Rob p.s The talk page for Turn Restrictions is stupidly long. Will take a while to work through it to see if there are any helpful tips in there! ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating
Hi, In the UK I've spotted that some maximum weight road signs have just the weight limit on the sign, whilst others also include a picture of a HGV. I've only realised this difference recently and have not had time to research the legal side of things but the brief description on the Department for Transports website suggests the sign with the HGV only applies to that type of vehicle. If this is indeed the case, can we simply use the following (as appropriate): * maxweight:hgv = * * maxweight = * Rob p.s. These discussions don't seem specific to the conditional restrictions tag scheme. Have you had a look on the talk page for maxweight, there are some other interesting comments there!! ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating
Thanks Eckhart, I've just had a bit more time to have a look at different weights and found the following terms: 1. *gross vehicle weight rating* (also *gross vehicle mass*, *GVWR*, *GVM*) - This appears to be a maximum operating weight specified by the manufacturer (hence a "rating") and includes the vehicle weight, cargo weight and others (driver, passenger, fuel, etc..) 2. *gross combination weight rating* (also *Gross Combination Mass* and *maximum authorised mass*) - Same as the above plus the weight of a trailer. 3. gross weight - taking the literal meaning of both words, I interpret this to mean weight before any deductions. To me this includes all the same components of GVWR, but is an actual measurement, rather than a manufacturers rating). To find this out you would have to drive onto a weighbridge. The question is, do the road signs mean actual weight or "weight rating"? Given that example for the UK it is hard to say for sure. I will see if I can find out. Does Germany's road signs specifically mean manufacturers weight rating? Rob [1] http://en.wikipedia.org/wiki/Gross_vehicle_weight_rating [2] http://en.wikipedia.org/wiki/Gross_combined_weight_rating [3] http://www.answers.com/topic/gross-weight http://en.wikipedia.org/wiki/Truck_scale ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating
I've just checked the UK road sign guidance too [1]. Section 5.15 (page 35 describes the sign with the image of a HGV and a weight restriction number. It clearly states that this is a restriction for "environmental reasons" (e.g. where roads are narrow and unsuitable for large vehicles, or to protect residents from the nuisance caused by lorries in residential streets) and is not used for "structural limits". It appears that this is a Gross Vehicle Weight Rating (GVWR) from the sentence stating that the limit applies even if unladen and below the weight. Section 5.31 to 5.33 gives the other sign (the one with a weight limit that applies to all vehicles). Again this is a maximum weight rating: "Specifying gross vehicle weights makes enforcement simpler as it is necessary only to check the vehicle’s plated weight against that on the sign, eliminating the need for a vehicle to be taken to a weighbridge for checking." Annoyingly this is complicated by the possible additional of a bottom panel reading "Except empty vehicles". Conclusion - in the UK all weight limits are Gross Vehicle Weight Rating limits and thus maxweight=* and hgv:maxweight=* would be enough. The "Except empty vehicles" is an interesting condition and could be tagged as maxweight=18 + maxweight:conditional= no @ empty vehicle (or something similar). How does this compare to other countries? Rob [1] https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/4460/traffic-signs-manual-chapter-03.pdf ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating
>Hi Rob, > >Am Montag, 26. November 2012, 20:33:08 schrieb Rob Nickerson: >>* Conclusion - in the UK all weight limits are Gross Vehicle Weight >>Rating*>>* limits and thus maxweight=* and hgv:maxweight=* would be enough.*> >except that maxweight does *not* limit the Gross Vehicle Weight Rating, but >the actual weight. > >Eckhart > If that was the case then all tags in the UK would be wrong. On the wiki page (which is unedited since Nov 2010), there is no reference to "actual" or "rating" weight. It does however state "a legal weight limit" which in the UK is always a weight rating (as per the previous emails). If you genuinely have a need for distinguishing between actual weight and manufacturers weight rating then could you use "maxweight:type=GVWR" or similar? Rob [1] http://wiki.openstreetmap.org/wiki/Key:maxweight ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating
Hi martinq, Good summary. We must have been working on it at the same time as I have just copied the wiki discussion to [1] (and liberally edited it to break it into sections and make it easier to follow). I suggest we keep discussions to this mailing list and the maxweight talk page (where it is most applicable). The wiki definition, in my opinion, does not specify either way. Rob [1] http://wiki.openstreetmap.org/wiki/Talk:Key:maxweight ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Fwd: Door to door routing to buildings with multiple occupants
-- Forwarding message from talk as more appropriate to tagging list -- Hi, A mapper who is new to my area is interested in mapping disabled access at a micro level. Specifically he would like to achieve door-to-door mapping for key shops and amenities, and has made a good start by adding entrance doors to several buildings. My Question: Where should amenity=* and addr:*=* be tagged? One suggestion was to add all the detail to the entrance node, but this seems odd to me. For single occupancy buildings I suggested tagging the building as amenity=*, etc as the entrance node on the building can be easily matched with these. But what about a building with multiple occupants and entrances. For example 2 shops in one building. One option is to tag the building with building=yes and then add the amenity tags to individual nodes, but then how would door to door routing work? An alternative is to just split the building in to 2 areas (but technically its 1 building). Can we use some form of indoor mapping (e.g. room=yes, amenity=*)? Is there a better solution? All ideas welcome. Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
The conditional access restrictions proposal did not specify that this :wet tag suffix would be deprecated (in fact it stated quite the opposite). From a developers point of view however, it is beneficial if we use a consistent tagging scheme, which is what the conditional tag was designed to introduce. I would therefore suggest switching to the new tagging scheme, however I'll leave you to decide for yourself. As always the "anything is better than nothing" rule applies in this situation. Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
Quiet often if such a change is made ("does not deprecate" -> "recommend to
stop using") it is by someone other than the original proposal author.
Irrespective of this the proposal procedure is a RFC - Request For Change -
process. What it does is to say "hey guys, I think we should change this,
if you agree vote for it and update any systems you have that may be
effected". In this regard, I was pleased to see a proposal specifically for
changing tag recommendations:
http://wiki.openstreetmap.org/wiki/Proposed_features/drop_recommendation_for_place_name
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Restrictions based on the weight of a trailer
How about: overtaking:trailer:conditional=no @ (05:00-22:00 AND weight>0.75 ) The "access" wiki page lists "trailer=* (needs to be towed by another vehicle which has its own restrictions)", which suggests that trailer should be seen as a separate identity, thus "weight" applies to the trailer only. Had the weight been the combination of vehicle plus trailer then we may have needed to come up with something to describe this. One possibility would be to borrow from [1], however this is a weight rating (set by the manufacturer), rather than an actual weight. Rob http://en.wikipedia.org/wiki/Gross_combined_weight_rating ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - roller_coaster key
Good start :-) One point that jumps to mind: I would imagine that you will find the "layer=*" tag to be better than "level=*". All the best, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Grades for obstacle=vegetation
I'm not a fan of "garde1" ... "grade5". I always, always, always have to look up the meanings when using it for track type (even though JOSM has a drop down list, the meaning are not given within JOSM). How about something like "light" (push back with hands, walk around), "medium" (as with light but may require a little bit of climbing/stepping over, and "heavy" (requires chopping tools to cut). Personally I think anything requiring a saw or more time consuming tools should be separated out in its own tag. However if you want to include it I suggest "densely_overgrown". Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Tree Shrine
I would like to see a tagging proposal that covers more general cases such as trees planted in memory of someone (for example see http://www.thenma.org.uk/ ). For this we would need tags describing when the tree was panted, who it was planted by (if planted by a well known person or charity), and who it is planted in memory of. Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clean up *=milestone (WAS: pk vs kp on *=milestone and default unit?)
Hi, I hadn't looked at the "milestone" wiki page before, assuming it referred to (the now historic) actual stone distance markers. Looking at the page, it seems to be used for modern signs. In the UK we have distance markers along motorways (Driver Location Signs). An example can be seen here: http://wiki.openstreetmap.org/wiki/Key:carriageway_ref In the picture: * M27 is the road reference (i.e. ref=M27) * B indicates that you are travelling on the main carriageway _towards_ the starting reference point of 0.0km (i.e. carriageway_ref=B) * 2.8 is the distance from the starting reference point in km (this is surely the "milestone" tag??) Yes, that's in km despite being in the UK. I believe that's called EU harmonisation :-) Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Through_route next steps
Hi, The next steps with any tag proposal that reaches a hung jury is to read through the comments and update the proposal to address the issues raised. In this case I think the wiki page needs to be clearer about what this tag is for (a few photo/aerial image examples would help), and how it differs from other tags. Let me know if you want a helping hand. Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Through_route next steps
>@Rob: >Did you ever try to describe the junction with the Lane and Road >Attributes? No, I didn't. And as I've been busy with organising SOTM I didn't even fully read the tag proposal (hence I didn't vote). I hope you agree that my general comment about reading through and attempting to address the critical points on the through_route proposal is the right way forward. Yes, this may mean dropping the tag proposal altogether and working with a different tag instead. In my opinion, what the through_route tag was aiming to do is still a good idea. I see it as more important for small unclassified country roads, rather than multi-lane highways. Here in the UK many small historic rural roads can have tight bends and often, if there is a connecting road, a satnav will give an instruction to turn right/left when one is not in fact needed (or not give an instruction when one is needed). Best, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - gross weight
Hi, I agree that the meaning is correct (legally), but I think we need to try and simplify the jargon in the one line summary section. How about: maxgross_weight: All vehicles have a registered upper limit on their allowable mass (when fully loaded). This is often known as the "Gross Weight", and it is found in the vehicle documentation. This tag indicates the maximum value that can use the way irrespective of whether the vehicle is fully loaded or not. Obviously, keep the legal meaning, but add this (or similar) for people who just want a quick answer. Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Visual editor for the wiki (WAS: How to overcome lack of consensus)
Daniel wrote: > - Make it easier to edit the wiki. Hi Daniel, I agree - the wiki can be hard to edit if you have never done this before. This is why I requested a visual editor (that is now used by Wikipedia) to be added. Unfortunately this requires an update to the version of MediaWiki that we use so is not a simple case of installing a plug-in. Hopefully it will be picked up sooner rather than later but in a volunteer based project patience is essential :-) https://trac.openstreetmap.org/ticket/4920 Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Visual editor for the wiki (WAS: How to overcome lack of consensus)
Quote: I'm not sure I'd rush into it, anyway. Even granted that en.wikipedia probably uses more complex markup and templates than we do, uptake of the visual editor (among new editors and otherwise) doesn't seem very high, and no one outside of the WMF seems very impressed by its current state of development. - End quote - Well we are a little way off as this requires the next version of mediawiki to be marked as stable (and then rolled out on our site) so plenty of time to fix any bugs. In regards to its usefullness it is worth considering the aim of our wiki. Is it to help the community share knowledge or is it for something else? In my opinion as long as the VisualEditor does not have show stopper bugs we should aim to adopt it as soon as possible. The benefit to our community (of many non wiki markup users) is substantial. As always statistics on use welcome. Rob ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Gritting routes
Hi All, I have some winter gritting/salting routes that I am trying to work out how best to tag them. I was thinking of creating a route relation, but I may need to add some new roles: * "forward:grit" implies the gritting truck grits this road whilst travelling in the direction of the way. * "forward:travel" implies the gritting truck drives along the direction of the way but does NOT grit it. Is this ok? I also have a concern that JOSM warns me if I try to add the same road way to the route twice. For gritting routes this is necessary - for example, grit Road A to roundabout, u-turn and travel back on Road A (but do not grit). In this example Road A would have to be added to the relation twice first as forward:grit and then as backward:travel. Is it okay if I ignore JOSMs error in this case? Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Gritting routes
In fact if I'm going to allow roads to appear twice in the relation then I can just build a continous route with no gaps and do away with the forward: and backward: bits altogether (just keeping 'grit' and 'travel' as my two roles). Rob On 23 Mar 2014 22:07, "Rob Nickerson" wrote: Hi All, I have some winter gritting/salting routes that I am trying to work out how best to tag them. I was thinking of creating a route relation, but I may need to add some new roles: * "forward:grit" implies the gritting truck grits this road whilst travelling in the direction of the way. * "forward:travel" implies the gritting truck drives along the direction of the way but does NOT grit it. Is this ok? I also have a concern that JOSM warns me if I try to add the same road way to the route twice. For gritting routes this is necessary - for example, grit Road A to roundabout, u-turn and travel back on Road A (but do not grit). In this example Road A would have to be added to the relation twice first as forward:grit and then as backward:travel. Is it okay if I ignore JOSMs error in this case? Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Gritting routes
Thanks, Happy to ignore JOSMs error, but don't want to have someone else change my route relation if it flags as a QA bug (hence posting here to gather people's thoughts & ideas). They're as stable as bus routes in my area as the local authority has to ensure the correct roads are gritted and the best way to do this is to have prearranged routes. Rob ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Gritting routes
> Craig said: > >What is the point in mapping roads where the gritter drives, if it is >not gritting there? How is that useful for anyone? > In the UK any government data based on a map tends to be derived from the national mapping agency and as such creates licence issues. We therefore opt to use the gritting "route schedules". These are literally a list of instructions in the form: * Leave depot, turn Right * GRIT to end of road, turn left * TRAVEL to main street, turn left * GRIT to ... and so on... I'm in two minds about whether to map the route as a relation, but I have to follow the route on the map just to work out which roads are gritted and which are not, so I may add it at the same time. Also if I add them to OSM then I can demonstrate a benefit to the local council - they could use the OSM data in a navigation device in the gritting trucks (thus ensuring that the correct route is followed every time and that excess grit is not wasted). Regards, Rob p.s. For some context, whether a road is gritted or not is quite important in the UK as we are lazy and don't tend to bother with winter tyres/chains etc.. There is a fine balance between gritting more so that the roads are kept moving (economic and safety benefit) and gritting less to reduce direct costs and the corrosion/environmental cost of excess salt/grit. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=track access
> >Going slightly off topic, I notice the UK listing is missing byway, a >recognised highway classification. > >Dave F. Hi Dave, The highway=byway tag is deprcated: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbyway The legal status of UK Rights of Way now belong in the "designation" tag, and the highway is tagged with an appropriate value (mostly track, but could be service if part of the route is now a paved road (e.g. an access driveway to a property along the right of way): http://wiki.openstreetmap.org/wiki/Public_rights_of_way_in_England_and_Wales#Byways Best, Rob ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=track access
Well highway=byway is a very UK specific thing so global renders and routing won't pick it up. Its also not a legal thing in itself. The council can provide the actual status. Where are these? Also there is the suspected:designation=* tag if you're not sure. R On 30 May 2014 08:28, "Dave F." wrote: On 21/05/2014 23:28, Rob Nickerson wrote: > > > > >Going slightly off topic, I notice the UK listing... Hi Rob I believe byway shouldn't be deprecated. In my area most of them are signed as just 'byway' on the ground. There is no indication of their legal status (BOATs etc), & AFAIA, there is no non copyrighted source for these. I think many that have been tagged with designation=* have been sourced from OS data. Cheers Dave F. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] man_made=pipeline - is onewayness implied?
There's no "onewayness" for natural gas pipelines. They may have a prevailing direction, but the direction of flow is not determined by the pipe. It's determined by the pressure differential (gas will flow from high to low pressure) and this can be changed via use of compressor stations. A natural gas pipeline should not be tagged as oneway. Rob ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Forest vs Wood
Hi, Sorry to raise this issue again but it really does need resolving: * for ensuring good data; and * to prevent forest and wood being rendered as the same thing [1] Currently the descriptions in the green box on the right of the wiki page (and thus those that get picked up by taginfo and other software) are: Wood: Woodland with no forestry Forest: Managed woodland or woodland plantation. In my eyes this is pretty clear. What am I missing / why does there seem to be so much confusion? Regards, Rob [1] https://github.com/gravitystorm/openstreetmap-carto/issues/647#issuecomment-52756701 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Forest vs Wood
On 20 August 2014 18:45, Rob Nickerson wrote: > > Wood: Woodland with no forestry > Forest: Managed woodland or woodland plantation. > > I think for me the wording isn't quite right. For me landuse=forest is something that has been planted for the purpose of harvesting trees. Therefore planting trees to prevent landslides, or to block road noise, or to provide leisure is not a case of landuse=forest. Similarly simply managing trees (even if by a national "Forestry Commission") for the purpose of keeping an area safe to the public is not a case of landuse=forest. Perhaps a crop=tree tag would have made more sense than landuse=forest?? I quite like Imagico's idea (below). I think we should implement that and then if in a year or so there is still a mess between landuse=forest and natural=wood we should introduce a new tag (crop=trees which now provides the overlay pattern) and treat landuse=forest and natural=wood as the same thing. "The orthogonality of natural=wood and landuse=forest SK53 <https://github.com/SK53> pointed out could be emphasized in rendering by drawing only natural=wood as a solid color area and distinguish landuse=forest with a different overlay pattern indicating the use for forestry (some trees+piles of logs symbolism maybe)" ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] The "not-shops": industrial, industry, or business
Hi all, Sometimes shop=*, office=* and craft=* do not adequately cover all business types. For example, I have mapped an industrial area that includes the following businesses: 1. A fork lift truck hire company (business to business sales). 2. A commercial bakery selling to business producing goods in their premises and delivering them to the customer. 3. A audio equipment company selling and hiring equipment to professional broadcast companies. In all three cases shop=* doesn't seem right as these are business to business sales (b2b) and are often delivered rather than picked up by the customer. I have found 3 alternate tags in use. Does anyone have a preference for me to formalise as a proposal? http://taginfo.openstreetmap.org/keys/industrial http://taginfo.openstreetmap.org/keys/industry http://taginfo.openstreetmap.org/keys/business I quite like business as it captures everything from conference suites to fork lift truck hire. Having said that, the industrial tag is most used and has an existing proposal page (but this suggests the tag is used as a refinement to the landuse=industrial tag): http://wiki.openstreetmap.org/wiki/Proposed_features/industrial Any preferences before I spend time to write a proposal page? Regards, Rob p.s. The ultimate aim is to be able to add a tag so that we have clear data in OSM (rather than just a name and address) and then file a request to get the business name rendered as currently addr:housenumber is rendered in preference to name (unless there is a tag such as craft/shop/office). This is not a tagging for the render issue - we are missing a valuable tag to describe the type of business. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] The "not-shops": industrial, industry, or business
Thanks for the responses so far. I'm not suggesting a business=tag_what_ever_you_like tag. In fact I only really care about having a suitable key. I like business=* as this covers everything, but you could say that business is used as a level 1 tag and then level 2 tags would be shop=, craft=, office= plus the addition of industrial= and commercial= for everything else. Rob ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Route relations - Forward & Backward
Dave, My understanding is the same as yours. That is, I map them according to the wiki guidelines: > "Forward" means the route follows this way only in the direction of the way, and "backward" means the route runs only against the direction of the way. Adding these roles to the members that make up the relation allow you to have circular bus routes and know the direction of travel. It also allows you to deal with splits in the road (e.g. a dual carriageway mapped as two separate ways in OSM) or where the "out" and "in" just differ. Having said that, the other mappers method also has all the information in to figure out the route, just not sure if existing tools will cope with that (I actually like including the way twice as this allows you to have all the ways linking in JOSMs relation editor, but not sure if this is frowned upon). Rob ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - UPRN and USRN
Hi all, Following on from the RFC on the Unique Property Reference Number (UPRN) and Unique Street Reference Number (USRN) for use within Great Britain, please note that these are now open for voting: https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn Whilst I have done the work on the wiki page, these tags were first proposed over on the talk-gb mailing list. They were discussed there and at the SotM online meeting that the UK community held. Voting is scheduled to close in two weeks. Thank you *Rob* ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
