[Tagging] OSM Wiki
Hi Mateusz, in your edit https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aman_made%3Dwater_tap=revision=2408821=2112133 you added the sentence > For working one additional tags fitting it would be ... I don't really get the meaning 路♂️ Could you word it differently or explain and let me look for a wording? Thank you As you're very active in the wiki: Do we have a template (in the meaning as in Microsoft Word or LibreOffice Writer) for _the full wiki page_ describing a key/tag/value? I did only find templates in the MediaWiki sense, so {{something}}, but not the whole page including typical sections etc. Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is it man_made=water_tap?
Dear all, Mateusz wrote Tue Sep 27 2022 12:46:54 GMT+0200 https://commons.wikimedia.org/wiki/File:Clickable_water_tap.jpg You need to push button to activate (rather than turn handle) Is adding man_made=water_tap to it correct? IMHO yes. The OSM wiki explicitly lists several examples with push button taps. https://en.wikipedia.org/wiki/Tap_(valve) tells A tap (also spigot or faucet: see usage variations) is a valve controlling the release of a liquid or gas. This definition applies not only to screw-down but also to push button taps. The further text describes different types of taps. Amongst them: The term tap is widely used to describe the valve used to dispense draft beer from a keg, whether gravity feed or pressurized. If a pull-type tap is so widely called tap, a push-type does IMHO qualify too, as it is only inverted direction of movement. Regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
Dear all, Hungerburg wrote Mon Sep 26 2022 22:19:03 GMT+0200 Nearly two weeks passed since the RfC started. Quite some changes have happened. I’d like to invite a second reading, to help weed out remaining problems. https://wiki.openstreetmap.org/wiki/Proposed_features/highway=scramble "use of hands is required" is not defined at all, thus stays fully subjective: My sister needs hands where I do not even start to think about using hands, most people living in German cities will use hands where people from rural areas of Peru's Andes won't because their daily routine ways differ so much. → This massively reduces the added value of highway=scramble and invites for edit wars. I posted some definition possibilities in my mail of 2022-09-20, 17:00 scramble=grade* is mentioned in the current proposal. The grades definition posted earlier in this thread tells On grade 2 and 3 scrambles it’s worthwhile taking a rope at least 30m long, some eight-foot slings, HMS karabiners and maybe a very small rack, half a dozen large nuts and hexes at most. The proposal excludes any scrambles using equipment, so forbids all scrambles of grades 2+3 to be tagged as highway=scramble. Thus, only scramble=grade1 remains by definition, so it cannot add any information and shall be removed from the proposal. Regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Are different definitions for same key/value OK? – was: Re: Is tracktype=grade1 surface=compacted a valid combination?
Dear all, stevea wrote Mon Sep 26 2022 01:36:26 GMT+0200 Is tracktype=grade1 surface=compacted a valid combination? while the EN wiki page https://wiki.openstreetmap.org/wiki/Key:tracktype does not explicitly exclude it [...] the DE wiki page >> https://wiki.openstreetmap.org/wiki/DE:Key:tracktype tells (translated by me) "waterproof surface" and thus explicitly excludes the combination. As I said earlier, and as I've found in OSM across different countries / continents, there do seem to be and will seem to be "regional variations" like this. The wiki using words like "usually" might encourage this, but it also "encompasses" it, as we're not very likely to get "perfection" with tracktype=* grades across the whole world. Best practice seems to be denoting this in our respective wikis, which we appear to be on track doing so now. noting regional or language specific variances of a definition in the wiki is OK for manual mapping, but 1) causes quite a lot of wiki maintenance effort: Every language needs to contain all variances of all other languages because we can't expect e.g. all US citizens to understand French, German and Italian sufficiently well when they are touring Europe and driving the 3 hours from Euro-Airport (in France) through German speaking part of Switzerland to Italy. 2) makes it quite hard to create programs that work correctly and behave user friendly. Example below. 3) discussions are much more prone to misunderstandings if the same key/value is defined in different ways, like we recently saw for SAC scale in scramble topic (may or must a T5 path contain scramble sections?). 4) because we simply don't have the resources to implement 1+2 really 100%, we end up with data that does not match one of the definitions. And cleanup is really difficult, because you cannot tell which data was entered due to which definition. Example below. Example for 2): A seasoned US mapper travels central Europe and maps there using Vespucci. The mapper's mobile is still in English, so Vespucci cannot simply rely on "it's enough if German GUI covers German variance". Instead, it would now have to contain a piece of logic telling that temporarily, the English preset texts need to be changed to match German content (so all regional variations need to be existing in all preset languages). Moreover, the mapper shall be made aware of this switch, because a seasoned mapper won't read the texts all the time but instead directly click on a value out of routine. Things get worse if the mapper has still pending changes in US and jumps between changes in DE and US, as Vespucci needs to switch presets depending on which edit is shown to the user. Same applies to all other editors, all quality assurance tools, all routers, many analysis tools,... Example for 4): A highway=path is tagged as SAC T5. Does it contain a scrambling section as required by SAC, or does it not, because the EN variant of https://wiki.openstreetmap.org/wiki/Key:sac_scale did mention for years that scrambling is optional for T5, so someone may have tagged the path as T5 despite it does not contain a scrambling section, i.e. it shall be tagged as T4 only. As a consequence, we'd need to re-check the tagging for thousands of paths but we have AFAIK no effective means to document which paths have been checked (e.g. MapRoulette does not help much here). Hence, I speak up for and strongly prefer to limit variances of definitions as much as possible, e.g. where simply not at all applicable because of local law. How do you see it? Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is tracktype=grade1 surface=compacted a valid combination?
Dear all, stevea wrote Sun Sep 25 2022 00:43:53 GMT+0200 > Is tracktype=grade1 surface=compacted a valid combination? while the EN wiki page https://wiki.openstreetmap.org/wiki/Key:tracktype does not explicitly exclude it but "only" strongly suggests it by telling "Usually a paved surface (called also Sealed road)" for grade1 and "Usually an unpaved track with surface of gravel", the DE wiki page https://wiki.openstreetmap.org/wiki/DE:Key:tracktype tells (translated by me) "waterproof surface" and thus explicitly excludes the combination. Please allow me to add that what I'll call grade1 which ISN'T truly paved (or once was), but is essentially surface=compacted, is a distinctly different kind of road when it is wet, muddy or actively raining (at least for such tracks/roads around here). These become pretty slick and even "iffy" to drive upon (especially with > about 3% or 4% slope) Exactly this is one major reason why I consider most surface=compacted to not not qualify for tracktype=grade1. Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Motorcycle taxis, pedicabs
Hi Dolly, Has the OSM data model evolved since and are there proper ways to tag these? Do these fall under amenity=taxi? in India, all of the mentioned "taxi & bus" variants and some few more exist (e.g. big auto rickshaws that are used collevtively) and I think it really makes sense to be able to distinguish them because of very different characteristics (price, speed, risk, space for luggage, etc). Common waiting & boarding places that I still have in memory carry no mapping at all, e.g. in Hyderabad https://www.openstreetmap.org/query?lat=17.40175=78.56058#map=19/17.40145/78.56064 or Bengaluru https://www.openstreetmap.org/query?lat=12.84703=77.67096 so I cannot see & tell you how to tag. In case noone has a better answer: Maybe you find a way to contact Indian mappers? Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
Hi Yves, > "Please bear in mind that quite a lot of them can be re-tagged > automatically" Can you give a single example of similar automatic re-tagging in the past ? https://wiki.openstreetmap.org/wiki/Category:Automated_edits_log lists plenty, e.g. https://wiki.openstreetmap.org/wiki/Automated_edits/transform would be similar to our purpose as it moved from one tag to another tag. https://wiki.openstreetmap.org/wiki/Automated_edits_log and https://wiki.openstreetmap.org/wiki/Import/Catalogue do list further edits on large amount of data elements without individual consideration. Please note the "can be" as well as the limitation to those paths that can be transformed without any doubt and without creating nonsense It's just a possibility we shall be aware of in case the change to highway=demanding_path was only rejected by some because of too much work but else wise welcomed. Regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
Dear all, martianfreeloader wrote Tue Sep 20 2022 20:59:07 GMT+0200 But yes, you're totally right, it will still be a considerable task to > re-tag all the 2k via ferratas, 3k climbing routes and ~20k difficult > hikes. Please bear in mind that quite a lot of them can be re-tagged automatically, to pick just one example, all SAC T4 can be turned from highway=path sac_scale=alpine_hiking to highway=demanding_path demanding_path=alpine_hiking without any doubt and without creating nonsense. In the following course of time, people can add for example "scramble=1" – just like many streets exist in the database, are a helpful & meaningful information, but still wait for someone adding lit=yes/no. This reduces the manual transition effort to those "few" paths that are "nearby" the "border" between easy and demanding path. Yes, it will still need years – but that's very likely the same with any approach to make highway=path less ambiguous. Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
Dear all, Peter wrote Tue Sep 20 2022 14:02:24 GMT+0200 This would mean that there is a new primary tag `highway=scramble` which makes some currently existing primary tags obsolete: 1) `highway=via_ferrata` gets replaced by `highway=scramble + scramble=via_ferrata` 2) `climbing=route` gets replaced by `highway=scramble + scramble=climbing` 1. From previous discussion I got the impression that actual climbing and via ferrata are different from scrambling, i.e. not a type of scramble. I fully agree that climbing and via ferrata are no subset of scrambling because more difficult climbs/ferratas are going way beyond what a scramble is. But to my understanding, there is definitely a fuzzy overlapping zone in the sense simple climbs and via ferrata are at the same time scrambles. To me, definitions of UIAA climbing grade I are mostly equal to the posted definitions of scrambling grade 1, similar overlaps in higher grades until around UIAA IV. Same for the easiest 1-2 grades of via ferrata (see e.g. https://www.bergfreunde.eu/via-ferrata-grades-calculator/). This is not only in definitions but also in real life, e.g. in the Alps, simple via ferrata are done by many as scramble, i.e. they simply do not use the metal but the rock unless conditions are harsh. Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
g * can be walked upright without use of hands for balance or propelling by the vast majority of humans that are able to walk and have sufficient eyesight & cognitive abilities to recognize and cope with obstacles like branches [these restrictions compared to "walkable by everyone" shall avoid that even very easy paths would not qualify because e.g. some people won't walk it because of vertigo, or all blind people would face considerable risks not detectable by their stick] * could be driven – if path has an incline, downhill – with a bike or an empty stroller that are not of the most fragile type, if path's smoothness was good and with sufficient for the vehicle ["downhill" avoids discussion about single steps, "empty" avoids discussions due to level of risk/courage perception associated with babies, hypothetical values for smoothness & width avoid discussion that actual path can't be done by stroller] Everything else becomes a demanding path, so for example * crawling sections, e.g. in tunnels * a mostly flat path over demanding surface like big rock blocks https://3.bp.blogspot.com/-dXQsIyml3FM/WZCOAtfMVXI/B9I/Bp6aVmpxlg09iwC9gBMvawtZj6uID35CACEwYBhgL/s1600/DSCN0615.JPG * a path over "questionable" bridges like https://thumbs.dreamstime.com/b/gefallener-baumstamm-als-br%C3%BCcke-%C3%BCber-einem-fluss-im-gr%C3%BCnen-wald-handarbeit-155342057.jpg As a consequence, in some regions, most paths will become demanding paths. Additional tags could carry more detailed information about what makes that path demanding, e.g. height=0.5m or hazard=falling for a bridge section. Tertiary tags would be: `via_ferrate_scale=*` `climbing:grade:uiaa=*` `sac_scale=*` The secondary tags would be orthogonal. In case of conflict, the > most common use of the scramble should be tagged. The tertiary > tags can be used side by side if applicable. I'd strongly favor that already secondary tag may carry multiple values, because it would first time make it a no-brainer to map ways with multiple usage possibilities – which is quite often in the fuzzy overlapping zone of difficult hike & MTB trail, a scramble, easy via ferrata and easy climb. I suggest we first decide whether we find the general concept of highway=scramble to be useful and want to introduce it at all. In case we answer this positively, then focus on working out the exact details like what's the exact sac scale threshold, etc. Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
Dear all, Asa wrote Sat Sep 17 2022 14:11:45 GMT+0200 In one of the Snowdon photos, a woman is using hands for balance. I just observed that for Snowdon, the link https://www.walkupsnowdon.co.uk/snowdonia-walks/crib-goch/ was replaced by https://www.walkupsnowdon.co.uk/snowdonia-walks/scramble-up-y-gribin-ridge-and-y-lliwedd/ containing photos actually showing some hand use. My last post was based on the first link only, this post on both. Without knowing that trail, so from the photos alone, hands seem really _required_ only at 2-3 single points. Just because of these few points tagging a whole long, well walkable way (look at pic #7 or #9) as scramble feels plain wrong to me. Like tagging a whole long trail as ladder just because there are 4-5 rungs installed. For me, it would feel much more appropriate to have a highway=path containing single points tagged as barrier=step/block/debris/... where a step is so high you need a hand for balance or pull up. Or tagging the node as scramble=yes, see below. Is there really no more clear example for a whole way requiring to scramble? Some trail where everybody clearly sees at first glance it's going to be really difficult to do without hands? I mean pictures like https://cdn-images-2.click-mallorca.com/imagenes/excursiones/entreforc-torrent-pareis-21153-o.jpg just for something that does match the current definition of highway=scramble – which Torrent de Pareis does just not (despite perfectly matching https://en.wikipedia.org/wiki/Scrambling) because it contains few climbs above UIAA II that are preferred by most non-climbers to do with rope. I guess, that makes it a grade1 scramble then, whereas use of hands to advance might make a higher grade scramble? C.f. https://www.thebmc.co.uk/understanding-scrambling-grades The site is operated by a business, no idea if that is just something they made up or if use is spread wider. That web page is quite interesting, thanks for sharing. Who has sufficient experience to judge whether it's not only the publisher's but a more wide spread definition? Before doing a grade 2 scramble, they suggest to learn at least climbing V Diff which is an UIAA IV- according to converter in https://www.thecrag.com/en/article/grades Because the current proposal clearly limits highway=scramble to UIAA II, highway=scramble could only be used for scrambling grade 1 – but what about grade 2 and 3? In shade of this and other aspects, I encourage to *re-think Peter's suggestion of scramble=yes respectively scramble=1|2|3 which would allow to properly tag _all_ scrambles,* whatever grade, whether way or node (if it's only single points requiring hands like high steps), whatever way type (including via_ferrata that can be well scrambled without equipment, track, river bed,...). Also, that would bring OSM's definition much closer to the one posted above and to https://en.wikipedia.org/wiki/Scrambling I like on the proposed tag, that discriminating by use of hands makes it much more easy on mappers, many of which just do not have the desire to become proficient in sac_scale. I agree and at the same time I do not see a much better information precision until we have a much clearer definition of "when are hands required" That's no real issue for scrambles of grade 2+3, just grade 1. I doubt, that many routers or renderers will have to change anything. To the opposite, very few routers and renderes will have to. Thanks for triggering re-thinking it. I guess you're right – as a hiker and climber, I use virtually only data consumers that are able and expected to show/consider scrambles, but many people do only car navigation, kayaking, cycling,... and will even be happy to get rid of "all the useless clutter" Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
in wiki page. Moreover, I doubt we will come up with a definition that is resulting in mostly consistent tagging path/scramble. Both together limits the potential added value considerably, while nearly all data consumers (renderer, themes, editors, routers) use highway=path so would need to be altered which is a massive effort. IMHO it's not worth it. Peter wrote Thu Sep 15 2022 00:03:48 GMT+0200 > If a sign says a path will make you scamble somewhere Despite hiking in many different regions and terrains and grades, I can't recall I ever saw such a sign besides fun/prank/ironic ones like "student crossing" https://images-na.ssl-images-amazon.com/images/I/41ePl0GmRtL.__AC_SY300_QL70_ML2_.jpg Do you have some examples of serious ones? Besr regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
Dear Peter and all others, I gained the impression you do not find consent just because you are using different definitions for the same thing: SAC T4-T6. Peter wrote Thu Sep 15 2022 17:30:25 GMT+0200 Peter Which combination(s) of highway values, sac scale values and hazard values would exclusively represent a scramble Janko Any of the three combinations: highway=path + sac_scale=alpine_hiking highway=path + sac_scale=demanding_alpine_hiking highway=path + sac_scale=difficult_alpine_hiking Peter So, a selection of sac_scale values may or may not include scramble sections, beside other posible obstacles/hazards/challenges. If you specifically want to know where the scramble sections are, the sac_scale doesn't tell you, correct? Yes and no 浪 Janko's and Yves' answer that T4-T6 _require_ hands is correct when using the _German_ definition https://wiki.openstreetmap.org/wiki/DE:Key:sac_scale In contrast, the _English_ definition https://wiki.openstreetmap.org/wiki/Key:sac_scale did tell until now that hands are optional for T4+T5 and only mandatory for T6 – so it supported Peter's view – which was not consistent with the original definition of SAC telling "you’ll need to use your hands" already for T4, see https://www.sac-cas.ch/fileadmin/Ausbildung_und_Wissen/Sicher_unterwegs/Sicher_unterwegs_Wandern/2020_Berg_Alpinwanderskala_EN.pdf I just updated the EN wiki page to match with SAC's definition. To extend the answer on Peters original question: Based on SAC's definition, each path of grade SAC T4 and above is a scramble, because definition of T4-T6 is that at some point, one needs the hands to go further. Climbing, by all definitions I saw, needs hands. https://theuiaa.org/mountaineering/uiaa-grades-for-rock-climbing/ even mentions the word "scramble". So if someone does not want to use hands, exclude any object tagged as sport=climbing – and please note that UIAA grade I and II is not only suitable for cliffs but also a hiking path of SAC T5 or T6, so it is relevant on Peter's question. For https://wiki.openstreetmap.org/wiki/Key:hazard it's a little less clear, as there are not yet many agreed values for the kind of physical objects we are talking about. Probably relevant values found via taginfo are hazard=falling and =steep and =slip_danger and =steep_slope. Considering what surprisingly high steps specialized off-road vehicles can manage, the two worst values of https://wiki.openstreetmap.org/wiki/Key:smoothness will likely require pedestrians to use hands. Yves did trow in https://wiki.openstreetmap.org/wiki/Key:trail_visibility at Thu Sep 15 2022 17:06:25 GMT+0200. I am not creative enough to deduct from visibility whether hands need to be used, but I still list it as others might have an idea While above keys/values enforce use of hands and thus answer your question, these are not best to satisfy your expressed interest: To avoid scramble sections. Why not? 1) Some ways might simply not yet carry above mentioned tagging but wait for someone adding it. 2) There may exist some more keys/values not yet mentioned here. To more reliably avoid scrambles, you need to approach from the other side: Choose ways tagged as SAC T2 and T1 because they must not be a scramble, by their definition, and the relevant information is certainly existing in OSM DB. Only remaining bigger risk is that map and territory are not matching. Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
Dear Asa and others, Asa wrote Thu Sep 15 2022 23:38:40 GMT+0200 Imo, scramble would not only include via ferrata. Unlike what I wrote yesterday, there is indeed some overlap of scramble and via ferrata. There are via ferratas, that can be hiked/scrambled without gear: from what I see, highway=scramble would just "take over" a part of the existing overlap between highway=path and highway=via_ferrata but does not introduce new overlaps. Do you see new ones? In fact, there's a big number of ways where I find it difficult to tell apart between "very easy via ferrata" and "alpine hike with many safety measures" like https://wiki.openstreetmap.org/wiki/Key:safety_rope and https://wiki.openstreetmap.org/wiki/Key:rungs Greetings, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
Dear martianfreeloader, you wrote Thu Sep 15 2022 00:27:11 GMT+0200 I am a hiker and a climber, but I made experiences similar to Peter's on more than one occasion. I have been led along ways by osmand which were mapped as highway=path; obviously by other climbers. They were definitely not suitable for folks without climbing experience that want to go on a physically demanding hike Yet, these kind of paths/scrambles are often not considered "real climbing" in the narrower sense (mountaineers would usually still go without rope). from your description, I've the impression you're less seeking information specifically about scrambling (using hands) but more how demanding and dangerous a way is. Both is reflected by SAC hiking grade; T5 and T6 seem matching very well the ways you describe – too easy to be listed anywhere as a climbing route, so listed as hiking path while bearing too high falling risk for quite a share of hikers. In case my impression is correct, do you remember any of these ways and could check a hand full whether they are carrying SAC T grade? Then, this tag "just" needs to be considered by data consumers, i.e. humans shall set desired maximum hike difficulty and routers shall not suggest any paths that are more difficult. That works very reliable in BRouter, but I did not try OsmAnd much for that purpose. In case my impression is not correct, could you please tell with other words how your experiences link to highway=scrambling? Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Are rowboats covered by "boat=*" or "canoe=*"?
Am 23.06.2020 um 06:29 schrieb Joseph Eisenberg: The wiki page Key:boat <https://wiki.openstreetmap.org/wiki/Key:boat> says that tag is to specify "Legal access restriction for boats. In the sense of OSM these are small boats and pleasure crafts, including yachts." The picture shows a "no rowboats" sign: File:A.16_Fahrverbot.svg <https://wiki.openstreetmap.org/wiki/File:A.16_Fahrverbot.svg> But there is also a key canoe=* - the page Key:canoe <https://wiki.openstreetmap.org/wiki/Key:canoe> says: "Legal access restriction for boats without a motor or a sail like canoes, kajaks or rowboats." I can see how canoes and kayaks are basically the same, since both are narrow boats that usually carry 1 or 2 people and are propelled by paddles. But should rowboat access restrictions be under this key canoe=yes/no/designated, or are they under boat=yes/no/designated - or something else? I would consider a rowboat a 'boat' - but the problem is that the "No rowboat" sign does not mean the vehicle class but the 'drive' of the vehicle: "A boat that is _not_ driven by motor or sail." So it also forbids canoe/kayak. So the access can only be determined correctly if a rowboat is considered with the access canoe=*. E.g. the german regulations differ a) by drive - motor - sail - oars/paddle b) by class - sport (motor or sail boat/yacht - but not: canoe, kayak, rowboat, surf..., jetski) - waterski - wind-/kitesurfing - waterscooter/jetski So the access restriction boat=* could only be used for 'sport' boats with motor or sail. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] key, name, long or a partial abbreviation?
Don't ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag pedestrian lanes?
Am 20.10.2019 um 23:23 schrieb Clifford Snow: I'm not familiar with the laws of the country the picture [1] listed in the first post on this thread, but the diagonal yellow lines look to me like a don't park here rather than a sidewalk. Even the one pedestrian in the picture isn't walking the diagonal yellow lines. Can someone confirm that those yellow lines indicate a pedestrian way? FYI: https://www.bfu.ch/de/Documents/03_Fuer_Fachpersonen/05_Verkehrstechnik/Empfehlungen/bfu-Grundlagen/Laengsstreifen%20fuer%20Fussgaenger.pdf https://en.wikipedia.org/wiki/Road_signs_in_Switzerland_and_Liechtenstein at 6.19 Regards Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag pedestrian lanes?
Am 20.10.2019 um 11:24 schrieb Markus: On Sat, 19 Oct 2019 at 23:02, Martin Koppenhoefer wrote: +1, or e.g. sidewalk:right=lane there are a few instances tagged like this: https://taginfo.openstreetmap.org/tags/sidewalk%3Aright=lane 18 out of 30 are additionally tagged sidewalk=right. I think it's better to keep "sidewalk" out, otherwise it gets too confusing. Why not in analogy to cycleway=track|lane|... sidewalk=track|lane|... sidewalk=yes (as synonym for kerb) was thought too short ... again. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarification unclassified vs residential
Am 20.02.2019 um 10:22 schrieb Florian Lohoff: So for me retagging residential to unclassified is broken under the assumption that unclassified is something "better" than residential. It is even more broken when there is residential usage in which case unclassified is inappropriate. While discussing i found that there was some modification to the German version of unclassified not saying that unclassified is something "better" but suggesting that an unclassified should be dragged into city limits until the next higher class street. This lets user assume that unclassified is some higher priority than residential. I was treating those streets identical for the last 10+ years and only the city limits gave the indication whether to use unclassified or residential. Am i wrong with that usage? Even the english wiki says: "The tag highway <https://wiki.openstreetmap.org/wiki/Key:highway>=unclassified is used for minor public roads typically at the lowest level of the interconnecting grid network." As part of the interconnecting grid network it should connect to at least unclassified or higher roads - unless it is a dead end settlement. Tagging a through connecting road only because it is inside a city limit as residential makes no sense. And usually a connecting road from outside a city limit has at least a bit more traffic as an inner-city-only residential. So the conclusion an unclassified has a bit higher priority than a residential is not far from reality. Otherwise there is often the problem to tag the main access roads inside a bigger residential area. The practice to tag those as unclassified for a bit higher priority may not be optimal - but suitable. This discussion - and usage - is some years old now - and I thought you had at least knowledge of it from the german forum. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
Am 15.01.2019 um 14:43 schrieb Marc Gemis: On Tue, Jan 15, 2019 at 1:55 PM Georg Feddern wrote: tourism=caravan_site is the one where you (at least in Europe) only can stay with motorhomes (selfpropelled) - but not with caravans (towed). but the wiki states on https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcaravan_site "A caravan site, caravan park or RV park is a place where people with caravans / motorhomes / recreational vehicles can stay overnight" only tents are not mentioned. Yep - that is exactly, what I intended: It is the agreed meaning in OSM, tagged with a word (language) that is the opposite of the real usage in some countries. Now search as a user a place where you can rest overnight or stay some days with your caravan (camping trailer!) while driving through good Ol' Germany. ;-) Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Link roads between different highways type
On Tue, Jan 15, 2019, 11:52 Saeed Hubaishan <mailto:hubais...@outlook.sa> wrote: About the subject I used to tag the link with the lowest way class but in: https://wiki.openstreetmap.org/wiki/Link_roads_between_different_highways_types it guides to use the hightest way class. I think this is not right behavior link from motorway to tertiary way is tertiary way not motorway, and so. What do you think about this? Am 15.01.2019 um 13:19 schrieb Johnparis: > I agree with you. > > For roundabouts and circular junctions, I use the highest type. For link roads, the lowest. > > I could see an exception for motorway onramps, indicating "starting here you can't get off the motorway". > > I could agree with you - with the exception of motorway on- and off-ramps, which are always motorway_link up to the end of the motorway regulations. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
Am 15.01.2019 um 00:29 schrieb Dave Swarthout: Now, if we could only get rid of tourism_caravan_site and replace it with tourism=campground. Sigh. That'll never happen but it should. whoow - please do not stumble over the next misleading OSM-keys. ;-) I think you mean tourism=camp_site, which is used for placing tents, caravans and/or motorhomes - as campground?. tourism=caravan_site is the one where you (at least in Europe) only can stay with motorhomes (selfpropelled) - but not with caravans (towed). But I am quite sure, that is different for the USA, Australia ore other 'english' countries - may be even for the Brexiters. ;-) Language: You can use every word for every meaning - you just have to agree about what the meaning is. ;-) Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
Am 07.01.2019 um 08:20 schrieb Graeme Fitzpatrick: & here we go: https://wiki.openstreetmap.org/wiki/Shop%3Dcaravan :-) Seeing that apparently it's already been used 130 odd times, can I take that we don't actually have to RFC & vote on it? May be not necessary to RFC & vote - but I think to discuss (may be I missed that part already?) You intend to summarize up caravans, motorhomes and tents. But I mostly know of 'specialised' shops: - motorhomes only - caravans only - tents only (OK, I also know some 'supermarkets' with combinations.) At least I want to find the right dealer for me (e.g. motorhome), so it would be necessary to distuingish them. Because there are mixed shops and all fall under caravaning, I suppose a subkey would be necessary - but yet I did not found a useful one or know a possible new one. Any ideas? Regards Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] wheelchair designated parking space tagging?
Am 04.01.2019 um 23:22 schrieb Warin: Possibly there needs to be a main wiki page for 'disabled' features tagging, toilets, tactile paving, parking, access. On 05/01/19 07:58, Paul Allen wrote: On Fri, 4 Jan 2019 at 20:44, Richard <mailto:ricoz@gmail.com>> wrote: looking through the wiki can't find how parking space designated for wheelchair/disabled users should be tagged? Having a main page - and actualize it - is a really kind service. BTW: https://wiki.openstreetmap.org/wiki/Key:wheelchair _is_ such a main page. But I do not understand, why people who look-and-not-found something in the wiki do not _search_ it. https://wiki.openstreetmap.org/w/index.php?search=parking+disabled=Special:Search=default=1=43w1ocpu8z9o2545k2x9jn3vd https://wiki.openstreetmap.org/w/index.php?search=parking+wheelchair=Special:Search=default=1=bquqcdlt1bi3tzdtjohslf972 Regards Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] issues with the list of deprecated features
Am 15.10.2018 um 16:38 schrieb Martin Koppenhoefer: Am Mo., 15. Okt. 2018 um 14:21 Uhr schrieb Tom Pfeifer mailto:t.pfei...@computer.org>>: On 15.10.2018 10:57, Martin Koppenhoefer wrote: > 3. amenity=creche and amenity=nursery > For both tags amenity=kindergarten is suggested as alternative tagging, which seems clearly wrong > (kindergarten is usually for ages 3-6 while these tags are for ages 0-3). I thought the consensus was here that it depends on the country. In Germany, I see mostly the "Kita" (Kindertagesstätte) structure which in the same institution enrols age 0-6 in different departments or groups, and a lot offer afterschool supervision (Hort). This is easily expressed with the min_age + max_age tag, and some folks use after_school=yes. For the German situation, KiTa and Hort should/could well be tagged with childcare, but "Krippe"? And if we decide to tag a Krippe (creche/nursery) the same as a Hort or KiTa, but with age tags, isn't that inconsistent with Kindergarten? From my point of view, Hort and KiTa are both childcare places which extend beyond the times of kindergarten and school (and are after those, typically), while a Krippe is for babies up to 3 years and is more like a Kindergarten, apart from the age. It would really be much more logical and easier to introduce / accept nurseries (there's a reason there is a specific term for this in language, no?), then throw most but not all of "child-related-stuff" in the same cauldron where you will have to dig for age group and other specfic tags in order to make sense of it. There is always a reason having a specific term for different parts of childcare - it is simply easier to talk about a Krippe(nursery), Kindergarten, Hort(after school club) instead of a childcare with age_group 0-3, 4-6, 7-14. And it is quite logical to take these terms as tags - in the first attempt But is it really easier to end up with three different amenities - and so with different POIs - for a childcare which enrols all age groups? Nevertheless the min or max age sometimes differs at the same sort of institution - so you may look e. g. after a hort but still have to check for the valid age anyway. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete
Am 17.09.2018 um 16:17 schrieb Florian Lohoff: is it intentional that StreetComplete tags the maxspeed source/type in maxspeed:type instead of the much more used source:maxspeed? If you search the german forum you will find that it is indeed intentional: StreetComplete wird maxspeed:type taggen by westnordost ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=service // public road?
Am 23.05.2018 um 22:33 schrieb Greg Troxel: Florian Lohoffwrites: I now see increasing usage of service roads as a category below unclassified. People tagging "smaller roads" in the countryside as a service roads. I think this is basically wrong tagging. I find this a little disturbing and now got into an argument whereas my position is the above - broken down into my more strict language: - If the public has a right of way - The road is build/run by public authorities - Its not something obvious like a parking space - It cant be service It might not fit 100% everywhere, but no rule without its exception. Broadly agreed with your concerns. A very important characteristic of a place you can drive is - it is legally a road, where more or less anyone has a right to drive (and this can be public ownership or private). Typically this means that the ground on which it is built is carved out as a separate lot for ownership (or government owned). This can be government, or it can be a road in a subdivision which is in the US marked "private way" meaning that it is legally a road but privately owned. You can still get a speeding ticket on it, because the road use rules apply to private ways, but do not apply to what you do in your farm field. Whether they apply in a shopping center is an interesting question. I'd say: yes, you will be cited, and probably that does not hold up. But in some places (north carolina), the property owner can put up signs that the traffic laws apply anyway - I saw these at the biltmore estate. Basically "this is private but the unwashed public is here and we want the police to be able to bust them" :-) - not legally a road, in that there is no right of access, traffic laws do not necessarily apply, and there is no separate parcel for it This is basically "highway=primary/secondary/tertiary/unclassified/residential" vs "highway=service/track". It would be goo to have this be That's a wonderful theory - and you get a 'stew' mess of unclassified if you do that in mapping the reality ... The mapping differentiation in unclassified (mostly connecting roads), service without service=* (mostly destination roads) and track (for - due to history - public accessible rural driveways) is simply driven by reality. The first we had at navigating in the late 199x'/early 200x - resulting in advising horrible routes through undesirable ways. With the latter you have a reasonable routing (and rendering too, by the way). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] route/forward/backward members in all types of routes
Am 10.01.2018 um 12:32 schrieb Ilya Zverev: Selfish Seahorse wrote: The course of the route is determined by the order of the stops in the route relation. Therefore forward/backward roles would be redundant. But stops are not mandatory in public transport routes, unlike highways/railways! I am quite sure that in _reality_ a stop _or_ a platform is mandatory in a public transport route - otherwise you would just have a route with 'hitchhiking'? PTv1 - zero or more for both - aha ... PTv2 - mandatory for both, but if may be only one is present, the other is not really mandatory anymore - aha ... There is a reason for that I only map highway=bus_stop ... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road barrier
Am 28.11.2017 um 11:54 schrieb Selfish Seahorse: On 28 November 2017 at 11:26, Georg Feddern <o...@bavarianmallet.de> wrote: Yes, unfortunately the european common-in-use traffic sign "VEHICLES PROHIBITED EXCEPT MOTORBIKE/SIDECAR" or "Prohibited for any double-tracked motor vehicles" has no equivalent in the OSM access scheme. I think it is time for a =double_tracked (motor vehicles)! Are there places where only motorcars are prohibited, but other double-tracked motor vehicles are allowed? I do not know of any, but ... Otherwise, the description/meaning of motorcar=* could be adjusted. -1 motorcar=* is needed, because there are places, that are allowed for them _only_ (see parking). But Dave is right - the implication of motorhomes under motorcar is 'very unfortunate' too - for the same reasons. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road barrier
Am 28.11.2017 um 10:00 schrieb Martin Koppenhoefer: On 27. Nov 2017, at 13:51, Selfish Seahorse> wrote: Sorry for asking again, but does anyone know if motorcar=no implies that there is no access for all multi-track motor vehicles or only for motorcars? In case hgv are permitted I’d explicitly tag it with hgv=yes, but according to the wiki, motorcar only implies motorhome: https://wiki.openstreetmap.org/wiki/Key:access Yes, unfortunately the european common-in-use traffic sign "VEHICLES PROHIBITED EXCEPT MOTORBIKE/SIDECAR" or "Prohibited for any double-tracked motor vehicles" has no equivalent in the OSM access scheme. I think it is time for a =double_tracked (motor vehicles)! ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bus relation - circular route - report says not closed
Am 19.05.2017 um 04:21 schrieb Warin: P1) JOSM validator reports that the relation is not closed. Yet all elements appear and they are connected. I cannot verify/reproduce the first part/sentence with JOSM (11639 / 12039). As the relation editor indeed does verify and show the 'circular' aspect of the relation it could anyway be only a validator bug. P2) Roles forward/backward are apparently no longer used, and a role to indicate that both directions does not exist. Yet these may assist to have these kinds of roles? Not necessary - see above. 'Used' direction is always defined by order. P3) stop_position ... left side or right side of the way? On a train line this probably works well .. on a road that has traffic in both directions with parking on both sides .. stop_position does not have all that much information. Yep, thats the way of OSM - the information is in the order of the relation and the platforms. Thoughts? Done. ;-) Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Anti-slip surfaces
Hi, Am 17.04.2017 um 22:58 schrieb Dave F: What's the best tag to describe an anti-slip surface made from small grit pieces coating a layer of bitumen?. Often used on footbridges, sometimes pre-made & supplied in rolls to the site. Grit/gravel on their own appears inappropriate as they suggest a certain amount of looseness. it may be not 'the best' tag - but is it not very similar to 'asphalt'? Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*
Am 27.03.2017 um 17:29 schrieb Martin Koppenhoefer: 2017-03-27 16:34 GMT+02:00 Marc Gemis>: In the case you have added e.g. a stop sign on the way. A second mapper comes in, splits the way on the stop sign, reverts the direction of one of the spit parts. Now the node is at the end of 2 ways with different direction and one cannot know what is forward/backward in that node. But any good editor can give a warning/error for such a case. yes, the editor can issue a warning, but what should be the reaction then? Shall we discourage changing way directions because of a stop sign node on this way? Usually there's a good reason for people changing way directions, adding more complexity to these changes with highway signs depending on them is not necessary. It is just a warning, that this is one of the seldom situations where you need a relation - just check, obey and ignore afterwards. Furthermore the editor can check for the relation too. Yes there is a possibillity for such a situation, but I doubt they would be essentially - and it can be solved by a relation. But a pure possibility should not effect the majority of simple situations - it is OSM-like to consider simple solutions and spare relations for the difficult ones only. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Busways
Am 02.11.2016 um 22:57 schrieb Tijmen Stam: On 02-11-16 20:27, Martin Koppenhoefer wrote: careful with access=no, I suggest to use vehicle=no in this case, because you risk of excluding pedestrians (and other means of transport you didn't think about) as well (happened around here in the real life). That's a good one, although the way most busways are signed (with a round "no access" sign red border on white circle) in the Netherlands that means no access at all, not even to pedestrians, not even in the hard or soft shoulder. You mean C1? If I read it right, it is just closed to "persons in charge of animals or livestock" - but not for pedestrians at all. Or did I misunderstood you? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-us] Freeway exit tagging
Am 26.08.2016 um 14:18 schrieb Kieron Thwaites: I can, however, see the rationale behind tagging "none;slight_right", as well as tagging nothing at all, and as such, I think that this is an issue that we need to find consensus on. That said, I believe Paul is quite correct with his statement that machines "need to be told about these restrictions in order for them to be able to provide useful feedback from it" -- something that isn't explicitly present (or maybe not even implicitly so) but appears obvious to a human on the ground isn't necessary obvious to a machine. Please do not take it personally - I just toke your answer to hook on, because you agreed on "machines need to be told about these restrictions". May be I am a bit on the devils advocates side here ... ;) 1. Where are there any restrictions? There is no solid line between the 3 lanes. ;) 2. If you want to give the machine any advice, you should take "through|through|through;slight_right" because 3. "none|none|none;slight_right" does not give any advice for the both left lines - they still could be considered to take the exit. Well in reality that is the legal situation here - you just have to take care for the traffic on the lines. ;) But in this common case (standard single lane exit) I still do not see any necessarity for any advice to the maschine (or the driver), that if the route takes the right road one should use the rightmost lane ... Same situation with solid lines definitely need case 2 - because even you should 'implicitly know' to take the rightmost lane there is another point where you already _have_ _to_ be on the rightmost lane - the maschine needs this advice to announce it appropriate. But may be I am a bit too old and have driven too long with my own eyes and head - and without a navigation assistant. ;) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Freeway exit tagging
I consider the visual lane assistance as it is named - as an assistance useful where there are several options. If there is no assistance anybody who get the advice "take the exit" (*) should obviously use the rightmost lane. So even _no_ turn lane tagging would be an option for me in this (quite normal) case. (*) Please do not cry "What about left-hand driving" - it is a right-hand example! And any unusual left exit _should_ be tagged with lane assistance. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of larger surfaces for rendering and routing
Am 14.08.2016 um 23:24 schrieb Stefan de Konink: On zondag 14 augustus 2016 22:43:04 CEST, Marc Gemis wrote: IMHO, the value of the highway tag should define its use, not the surface from which it is made. So highway=pedestrian (or service or ...), surface=grass; area=yes makes more sense to me (or would you start defining highway=paving_stones, cobblestones, etc. as well ?). It seems that many people in this discussion take the value "grass" so something extreme. The fact grass is used, is because it is currently hides the surface in the rendering, and no other common value of unpaved areas exists that fits the bill. Personally I find highway=service, surface=grass, area=yes appropriate for the camping site For the whole camping site? Won't there be always some - at least virtually - defined parts for the tents/caravans (pitch) and some defined parts for the driving (ways)? but not when it rendered as paved road. It is not rendered as _paved_ road, it is rendered as _road_ ("part of the world where mainly rolling traffic will occure"). It is part of the renderer to decide, which part of the mapping he will show - based on the intention of the renderer. A highway renderer will show the highways - always in contrast to the surrounding, even if they have the same surface. A surface renderer will show the surface - and will ignore the difference of the use/service. Even a mixture is possible with casing and filling - may be that's what your intention is. Just by the seperation of the meaning 'using' and 'surface' - and just and only by the seperation in different tags. It is simply not neccessary to mix them up in one (main) tag. If you have tourism=camp_site highway=service camp_site=camp_pitch - and all with surface grass you have all opportunities for all different rendering - it just depends on the chosen renderer. A renderer could look at the surface tag to colour the area. No reason to start inventing new values for the highway tag. +1 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] nursing homes and group homes
Am 27.06.2016 um 12:17 schrieb Martin Koppenhoefer: +1 to social_facility=nursing_home Just some days ago I had to change with my father from a retirement home (with ambulant care) to a nursing home with 24/7 care. I looked at the social_facility scheme - stumbled about the disclaimer - was really confused at first - and changed the tagging then. First off all I understood the meaning of social_facility=group_home;social_facilty:for=senior for a retirement home / group home - as written in the description. But looking at social_facility=assisted_living _that_ describes a retirement home / group_home - at least in my opinion and understanding of the description. So I understand: retirement home /group home as social_facility=assisted_living nursing home as social_facility=group_home Does not really make sense of the tag names itself - but of there description. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging natural or historic regions
Am 28.03.2016 um 08:28 schrieb Martin Koppenhoefer: Am 27.03.2016 um 21:59 schrieb Colin Smale: If we can't mark polygons as fuzzy, then we can only allow 'accurate' polygons well, as was proposed above, we could introduce a way to store fuzzy areas without using polygons, or by using more than one polygon as one object May be: Using a minimum (core area) and maximum (extension area) estimation as one relation. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] service = parking_access for main ways on a parking lot
At all - what's the matter with the already said "highway=service" only if you can not distinguish the service or if it is a "bigger" service road? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] boundary relations and the subarea property
Am 27.11.2015 um 15:46 schrieb André Pirard: Have you noticed that some borderlines are *hexaplicated* (that they appear in 6 different relations) and that *that* is unhealthy redundancy that is made unnecessary by subareas? And that, unlike wanting to destroy an enemy, the programs I spoke of would be a great help building and checking the boundary ways mess using the non duplicated, simple, clean UK=England+Wales+Scotland subarea definitions? Well, next usecase then: I want the border/outline of any of those entities ... and not the area. Mostly there are two sides of a view - or two views on one problem ... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] improve tagging of traffic_calming
Am 20.11.2015 um 18:24 schrieb Gerd Petermann: I found 940 nodes which were tagged with highway=traffic_calming. Most of them were also tagged with e.g. traffic_calming=bump or traffic_calming=table or one of the other well documented values. A few were not tagged traffic_calming=*. I changed those few to traffic_calming=yes and removed the obsolete highway=traffic_calming tag from the other. I also verified that the changed nodes are on a highway=* way. If the highway=traffic_calming is obsolete in those cases - why isn't A few nodes were tagged with crossing=*, in those cases I added the tag highway=crossing (and kept the traffic_calming=* tag) highway=crossing obsolete in this cases? Regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] improve tagging of traffic_calming
Am 20.11.2015 um 17:29 schrieb Marc Gemis: On Fri, Nov 20, 2015 at 5:23 PM, Florian Lohoff <f...@zz.de> wrote: http://www.mapillary.com/map/im/LeaK3riwsMuv7f0i3Jt3XA/photo I would tag the crossing as a node and the "table" as part of the way, not as a node. If it is really enforced to identify a traffic calming only by presence of highway=traffic_calming - this is the only way because but a combination of highway=crossing; traffic_calming=table on a node could work as well. won't be identified as a traffic calming then. Otherwise: If a node with highway=crossing and with traffic_calming=* should be identified as a traffic_calming we won't need highway=traffic_calming anymore ... Regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag a fence made with metal bars?
Am 05.11.2015 um 15:59 schrieb Gonzalo Gabriel Pérez: Hi everyone, I'm reading in the wiki ( http://wiki.openstreetmap.org/wiki/Key:fence_type ) about the fence_type key and I think that it ambiguous the way that is described how could be tagged a fence made with metal bars like these, see pictures: http://www.puertasblindalock.com.ar/images/reja-de-seguridad-2.jpg http://4.bp.blogspot.com/_3mO9j6PCOQc/S3lYvlCmEaI/AAM/uBmMExArTnI/S660/35150559_1.jpg http://www.elforjador.cl/img/galeria/el_forjador_reja_3.jpg Which values between 'bars', 'wire' and 'metal' should be used? All your examples are just ' metal' - because - in my opinion - the pictures for 'bars' and 'wire' are just wrong. Under 'wire' I would understand some simple wire (one or more horizontal) between the poles - wire like in 'electric'. Under 'bars' I would understand some simple 'bars from metal between the poles - like the horizontal poles in the wooden 'pole' example. Regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] traffic_sign:forward=*
Am 03.11.2015 um 17:43 schrieb GerdP: I read the wiki a few times and still did not fully understand how this traffic_sign:forward idea should work. If you read (and use) _only_ traffic_sign:forward - I suppose you read only the german wiki page and then I understand your problem, because that can not work in all cases. If you read the english wiki page, you may understand the intention better - as there is also a traffic_sign:backward variant mentioned. It shall work as in reality and as "computered" in the human mind: Transform the information from the sign (node) to the way in the relevant direction - with all possibilities, but even all obstacles also ... I do not support this "node on way" strategy - I use only the node beside way as tagging for the sign itself - and "always on the right side" ;-) - at least here in Germany. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tunnel=culvert
Hello, Am 25.10.2015 um 11:44 schrieb Gerd Petermann: I do not fully agree here. In Germany, I often see a traffic sign "Vorsicht Düker" (~ "Attention! Culvert") next to these culverts. I am not sure why I should pay attention, but it seems that some people think that the traffic on the road should notify it. Maybe because it also often means that there is a barrier=fence along the road. In fact I thought that these signs are the explanation for the use of tunnel=culvert on a node. please be careful: A "Düker" is not a normal "culvert"! At a culvert the water is flowing on the same level in the culvert, normally with airy room above water level in the culvert. At a "Düker" the water is "pressured" on a level below the normal water level through the "Düker", so there is no room above water level. The normal road traffic has not to obey these sign - but any street work or use (crawling ;) ) at the waterside. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] manège - area for horse training
Am 15.10.2015 um 22:57 schrieb Warin: On 16/10/2015 7:08 AM, Volker Schmidt wrote: What the picture shows is a Carrière, which is to be tagged as leisure=pitch sport=equestrian +1 And someone will now say that it is not a sport... just like for cricket_nets ... Anyone for another key sport_practice? Would have similar values to the key sport but used for 'pitches' that are only used for practice/training as they cannot be used for the full 'sport'. -1 Ever worked/trained with horses? What is the key definition for sport? Concentration? Reactions? Best moves? Power? Is a carrière - sport_practice when there is just training but - sport when there is a competion? Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Pubs with accommodation
Am 28.09.2015 um 14:46 schrieb Andy Townsend: Depends on the pub, I'd say. Some places are both a hotel and a pub, some have essentially separate "hotel" and "pub" bits (for which 2 nodes within a building might work) and some (e.g. http://www.openstreetmap.org/node/75844692 ) are pubs that do accommodation, but not really hotels, so I'd use accommodation=yes for those. Why not the already established tourism=guest_house for this B offer? Regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=derelict_canal
Am 27.08.2015 um 18:49 schrieb Philip Barnes: A disused pub, providing it still looks like a pub, is still a useful navigational feature. Pubs have always been the normal way of giving directions. http://www.mapillary.com/map/im/PrKK4Y3JBpdF3jg6fnLM1g/photo Turn right by The White Horse, carry on passed The Old Post Office and Castle, turn left by the White Lion then left again by The Hawkstone. What could be simpler? Well - it is simple. But what you refer to is the simple _name_ - and that name may be still there in OSM if it's still sitting on the wall or sign. In opposite to the amenity ... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] To tag opening_hours=by appointment
Am 30.06.2015 um 19:15 schrieb Robin Schneider: On 30.06.2015 14:04, Marc Gemis wrote: in the local language (e.g 123 nach␣Vereinbarung http://taginfo.openstreetmap.org/tags/opening_hours=%22nach%20Vereinbarung%22 -- German for by appointment) IMHO this means that there is nothing to formalize. This also means that ...Sa 09:00-18:00 + appointment is a comment and nothing has to be parsed. This should be ...; Sa 09:00-18:00; Sa also by appointment Better express it as: Sa 09:00-18:00 || Sa only by appointment I understand Warin as: Sa 09:00-18:00 Sa only by appointment On 30/06/2015 8:09 PM, Warin wrote: The above example could become Mo-Tu,Th-Fr 09:00-13:00,14:00-18:00;We To mean that an appointment is required for Saturday between 9 am and 6 pm. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - obligatory usage - bicycle=obligatory
Am 14.04.2015 um 07:28 schrieb Mateusz Konieczny: On Tue, 14 Apr 2015 00:08:31 +0200 Volker Schmidt vosc...@gmail.com wrote: https://upload.wikimedia.org/wikipedia/commons/6/69/Separated_cycle_and_foot_path.jpg I would add also surface (and maybe smoothness) as this one seems to be quite bad. 3) How would you tag the segregated cycle-and-foot-way shown in Also, I would add also surface (and maybe smoothness) as this one for footway/cycleway seems to be quite bad. No wonder that smoothness ist supposed to be totally subjective - I would tend to the opposite quite good ... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New key proposal - paved=yes/no
Am 25.09.2014 11:48, schrieb Pieren: I think the main issue raised in this thread is to decide if each data consumer can decide alone what surface is paved or not (using this surface key and its hundreds values) or if we are able to find a common definition stored in the osm db (using this paved key). With the first option, the paved attribut can be inconsistent between applications. With the second option, the paved attribut is subject of personal interpretations from the contributors but this could be moderated when the surface key is also present. Definitely now we all know that there are different opinions for e.g. gravel as paved or unpaved at mappers and consumers. And where is the benefit to manifest the paved/unpaved meaning in the database? Beside edit wars I see absolutely nothing ... I vote for inconsistencies between applications - and not between mappers! A second tag would not change the mind of a consumer about the meaning ... Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed change to Tag:access=designated page
Am 24.08.2014 12:43, schrieb Friedrich Volkmann: For me, designated means that there's a respective sign, e.g. a cycleway sign = bicycle=designated. yes that is the typically (non native-language?) (mis)understanding of designated - and guided by the phrase A way _marked_ for a particular use. Nevertheless e. g. all highway=residential are _designated_ by law - without any signs at all... - which leads to _my_ understanding of designated ... Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering change: buildings within highway areas
Am 01.07.2014 12:34, schrieb Matthijs Melissen: On 1 July 2014 11:25, Janko Mihelic' jan...@gmail.com mailto:jan...@gmail.com wrote: If I'm right, this will mostly affect pedestrian areas (highway=pedestrian + area=yes) that have buildings mapped over them. Yes, that's correct. Did you consider buildings that are - at least partly - raised on pillars/columns with a pedestrian area underneath? Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] editing polygons in JOSM
Am 27.05.2014 21:12, schrieb Peter Wendorff: Am 27.05.2014 20:23, schrieb Tom Gertin: 1. Clip a polygon using another polygon 2. Cut a polygon using a line Cutting by a line is easy: [...] Clipping by a new polygon is basically the same - but draw that new polygon first instead of the line, then proceed as described above. As far as I know there is no automatic way to do one of these. I would recommend the plug-in utilsplugin2. This will give you new tools, e.g.: - Add nodes at intersections - Split object This will automate some, but not all of the neccesary steps. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway
Am 03.04.2014 21:43, schrieb Richard Z: On Thu, Apr 03, 2014 at 06:08:46PM +0100, Dave F. wrote: On 02/04/2014 17:14, Richard Z. wrote: as explained in the rationale the dimensions of the bridge/culvert are frequently only a fraction of the achievable precision. Think of a track crossing a small creek in a forest valley int the mountains. The GPS precision will be 10 meters if you are lucky, the brunnel 2-3m. Mapping this the old fashioned way will produce junk data, not precision. Rubbish. Please don't rely on a GPSr. It is only one, of many, ways to survey. If I see a small bridge over a stream, say 3m I'll map is as that, because that's how it accurately is in the real world. Some users have access to detailed aerial imagery to help map accurately. so again: *** a small creek in a forest valley int the mountains *** Where is your aerial imagery? I want that!! In the mountains you are very lucky if your imagery has less than 10 meter offset and forests render most aerial imagery useless. The offset (either GPS or imagery) has influence on _where_ you can map the bridge - but not much on _how_ you are able to map it. I'm neither a friend of a crossing node when there is no connection in reality. Missing or loosing the bridge tag I would always assume a ford there ... Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] surface=ground/dirt/earth
Am 13.03.2014 15:56, schrieb fly: On 13.03.2014 15:37, Fernando Trebien wrote: But do you think that earth and ground are different kinds of surface? Well, I would consider earth as earth where ground could be earth but does not have to be. All together, I think we could get rid of at least one out of the three tags after updating the descriptions but this will not that easy with existing tags in common use. aehm, well - and which one would you get rid of? Some times ago I remember a likewise identical discussion at the german forum. AFAIK: ground Used for ways where the underground consists of different and often changing parts like rock, earth, vegetation (generic value) - as you say above. earth Used for ways where the underground consists of - well, earth (natural sand) constantly. dirt See above - the term seems to be outside of OSM used for a man made / constructed work - which inside OSM seems to be the (defined) value compacted. So I would get rid of dirt, but keep 'earth' beside 'ground' as a useful value (smooth walking on hiking trails) . Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] origin of some fire_hydrant tagging
Am 26.02.2014 13:23, schrieb Richard Welty: i'm currently tinkering with what will be come a proposal to modify current hydrant tagging. my thinking is to add fire_hydrant:water_source={main,pond,stream,standpipe} and deprecate fire_hydrant:type=pond no objections except 'standpipe' - see below. then the issue is whether we want to modify fire_hydrant:type or replace it with a different tag altogether, say fire_hydrant:delivery if we keep type, should we replace pillar with plug or fire_plug or just let that go. I would keep hydrant:type - because it is a physical type/design in my opinion. With hydrant:delivery I would not assume the physical type, sorry. And I would keep type=pillar. With fire_plug I - and I suppose many others - would assume something you can connect with or to. And that are all hydrants in any design, it is too generic in my opinion. Regarding standpipe: I would understand 'standpipe' as the device you need to connect to underground hydrants. So I would not use standpipe for hydrant:source but 'riser' instead, may be distuingish between dry_riser or wet_riser. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] origin of some fire_hydrant tagging
Am 25.02.2014 17:08, schrieb Richard Welty: i'm wondering if anyone can speak to where the tagging for fire_hydrant:type came from? AFAIK the Germans are guilty again - and I plea myself for not-guilty. ;-) (see http://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant and their history) And yes - pond does not really match a hydrant 'type' - the hydrant type there may be still a 'pillar' or an 'underground', less a 'wall'. Is it possible, that in UK/US the 'pillar' type is the norm and the 'underground' type is not wide spreaded? At least the http://en.wikipedia.org/wiki/Fire_hydrant uses the term 'post- or pillar-type fire hydrant' - but I do not know who wrote that. At least there is a desire to distinguish between 'pillar' (or synonym) vice 'underground' vice 'wall'. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] wiki definition for man_made=works
Am 25.02.2014 22:06, schrieb John Packer: Then I think I am confused too. As the description is right now, what is the difference between building=factory and man_made=works ? yes, that is the point of the thread opener: man_made=works does not make sense for one building only. I always tag man_made=works for the whole area of a work/factory complex of one operator (as one object). landuse=industrial otherwise may be the whole industrial area with several works (it is a use, not an object). It does not collide with man_made=works and can exist parallel. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - opening hours open until
Am 26.02.2014 09:19, schrieb Philip Barnes: Surely you then need to define when curfew is, does it require a tag law=marshal? :) I don't think so - that's an info you should know or get as soon as you need it - wherever you are. Like the maximum speed without explicit signage - wherever you are. Or the tax free amount of travel goods. :) A more real world example, where hours vary, would be open sunrise to sunset, which is often used for rural car parks. Yes - that's why opening_hours already support this. ;-) Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - opening hours open until
Am 26.02.2014 10:21, schrieb Philip Barnes: This is going off the tagging issue, but it is a bit scarry that you are casually talking about curfews, where outside places like North Korea do they exist? A curfew to me, as a brit equals being arrested/shot for being on the street after a certain time. oh, sorry, this may be a translation problem - my fault. I used curfew (resp. take it from Martins post and looked it up in an online dictionary) in the meaning of legal closing time - the time, where all pubs (in an area) have to be closing by law - if they do not pay for a late concession/licence. In German(y) this is called Sperrstunde - this term can be used in the same civil/opening meaning for pubs - or in military as you stated above . Actually I do not know, if or where this is still in usage for pubs here - no need for that actually :) -, but I can remember, it was still in usage for pubs in my lifetime. I thought England (or maybe Great Britain) is still using this for pubs. At least, as this seems to be a problem, that causes the Prime Minister to intervene! ;-) http://news.sky.com/story/1205719/world-cup-pub-opening-ban-overruled-by-pm Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - opening hours open until
Am 25.02.2014 16:35, schrieb Robin `ypid` Schneider: On 25.02.2014 16:27, Martin Koppenhoefer wrote: I don't know in this specific (british) context, but my guess is that 12:00+ indicates (typically) until curfew, while late maybe has the meaning beyond curfew. All right. Interesting. If that is the case it might be better to write this explicitly (using fixed times and comments) because it is probably not desirable to add this to the syntax. well, for those who want to know it's open late it _is_ quite desirable. And if there are no fixed times, it is still open end but with different meaning. The current syntax + does not diffentiate between until curfew and beyond curfew. But this seems to be a desirable differentiation. Why not extend the syntax with such quite clear definition? E.g. + means open end until curfew -late means open end beyond curfew Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging lifeguard watch towers
Am 18.02.2014 14:40, schrieb Fernando Trebien: There's a discussion going on in the Brazilian community on which is the best tag for this. Among the suggestions are: - emergency_service=lifeguard - health_facility:type=first_aid Thinking from the point of view of applications (rendering and geocoding), I kind of feel that this may be a health amenity similar to amenity=doctors/clinic/hospital. I won't see them as a health_facility and would put them under emergency=lifeguard. http://wiki.openstreetmap.org/wiki/Key:emergency_%28facilities%29 Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] one-directinal bicycle dismount on oneway road ?
Am 19.01.2014 12:06, schrieb Colin Smale: In the UK there is a difference between no cycles and no cycling. Although in general you may be correct that a dismounted cyclist is effectively a pedestrian, there are also footways (or whatever you want to call them) signed as no cycles, which means that in these cases a dismounted cyclist is not equivalent to a pedestrian. Yes, I had that in mind, but that was not the question here. ;-) (You get what you ask. ;-) ) If foot=yes (explicit or implied) implies bicycle=dismount which corresponds to no cycling, I would suggest that bicycle=no would then mean no cycles i.e. not even if dismounted. Ouch - I won't mix this here. bicycle=no is long time used and defined as traffic, as use, not as object. So bicycle=no means no cycling a long time already. For no cycles there should be a new tag. There was a discussion some time ago. But watch out for talking about what is legally allowed as it varies widely by country! Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] noexit
Am 03.12.2013 14:48, schrieb André Pirard: I agree to: This tag is - not necessary for routing - senseless on ways - only useful on nodes (the last one, where no other way is connected) The wiki should be changed, especially the use on ways should be removed. But I do not agree to I doubt very much that this tags helps anybody or any quality-check program to understand anything. A note should suffice, and I think the best option would be to remove that confusing tag. It is useful for quality-check programs to determine This is not a missing connection to nearby ways. (false positives) A note would have to be clear and machine-readable for this case. It might be useful for renderers as on a map it might look as a connection (because of oversize of rendered ways). But this could be determined by preprocessing also. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] preproposal : internet webcam
Am 02.12.2013 11:31, schrieb Pieren: Adding a sub-tag will simply move the current 21700 man_made=surveillance elements without subtags in uncertainty. OK, that is a point, I agree here. I still think that a (public) webcam could be tagged differently from a CCTV because it's not the same purpose and not the same legislation even if it is a camera and may transit throught the net. One is public, the other not. May I suggest: man_made=public_webcam website=*('url' is deprecated in the wiki) May I suggest another direction to move in the situation? I see a camera - but absolutely do not know which purpose it has. Both opportunities (surveillance/webcam) are possible with this installation. Which tag should I use then? Shall I have to dig it out before tagging? Or shall I simply ignore the camera and do not tag it? If we want to extend the tagging, we should use a new but generic tag (camera?) in my opinion. Yes, this may result in parallel tagging - but we should not run in the next cul-de-sac with one's eyes open. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] preproposal : internet webcam
Am 29.11.2013 13:03, schrieb Egil Hjelmeland: On 29. nov. 2013 10:32, Jonathan wrote: I would agree, I think that covers it. A webcam is surveillance, it's a camera that is watching you making it available to anyone. Some would say that is a greater infringement than an official camera that is regulated. Maybe the wiki page needs re-wording to reflect that it doesn't matter who is watching just that if they're watching with a camera then it's surveillance. I think we live in different universes. This is the kind of stuff I am interested in: http://webcam.svorka.net/bollen/ http://webcam.sollia.net/image.jpg not living, just thinking: You can surveil the wheather condition, snow condition, forest fire there. ;-) Well, I think I understand what you mean - I would have prefered a generic man_made=camera instead of =surveillance. I normally can not decide which view angle, zoom or purpose it has. Only: There is someone watching - but what and why? Best regards Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway
Am 14.11.2013 10:13, schrieb Martin Koppenhoefer: Am 14/nov/2013 um 00:53 schrieb Robert Whittaker (OSM lists) robert.whittaker+...@gmail.com: I don't see why you can't tag the roads you're talking about with bicycle=no (or maybe something like bicycle=restricted for the cases where more significant use is allowed) and then add a second tag along the lines of bicycle:restriction=DE:use_cycleway to capture the fact that the legal exclusion of bikes is because of X country's parallel cycleway rules. You shouldn't do it, because it would be wrong. There is no legal exclusion of bikes on the road, there is an obligation - under certain circumstances - to use the cycleway, this is a difference and should not be tagged like an exclusion of bikes on the road (e.g. like on a motorway) @Martin: Your reply is only valid for the first line of the citation. @Robert: The rest of the citation sounds better than the proposed use_cycleway - at least for me. But its just the name, not the intention, which is the same for both. If there is a need for the additional tag of country-specific or if it may be as country-specific-implicit as other implications for highways already - I don't know. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway
Am 14.11.2013 10:47, schrieb Martin Koppenhoefer: Am 14/nov/2013 um 10:40 schrieb Georg Feddern o...@bavarianmallet.de: @Martin: Your reply is only valid for the first line of the citation. An approach which combines 2 tags in a way that the meaning is only true for the combination of both, but not for the single tag, does not work well IMHO. We shouldn't have tags like bicycle=no and with a second tag we say, hey, actually that is not a real no in this other tag over there. yes, you are right! The bicycle=no is missed in the first line of the citation (my fault) - but was meant by me. But my OK has gone for the bicycle=restricted instead of bicycle=use_cycleway. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway
Even I am not Pee Wee nor any author of the proposal, but Am 12.11.2013 19:29, schrieb Dave F.: How does this improve mapping/routing over using bicycle=no? How does your proposal distinguish the exceptions to the rule that you gave as an example below? consider a muscular trike, which is clearly classified as a bike and not allowed to ride where there is a sign No bicycle. The user/router knows, that this trike is not allowed or has to avoid simple cycleways - so the router has to use roads instead. But the 'normal' road has a strict bicycle=no now without the sign. Where shall he ride then? Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Usefulness of bicycle=dismount on ways
Am 16.10.2013 09:23, schrieb Volker Schmidt: (this thread is so long now, that I don't remember if I have inserted my problem with bicycle=no/dismount) Here in Italy we have heaps of pedestrian-only crossings, which are part of dedicated combined foot-cycle paths or even pure cycle paths. The legal requirements is that cyclists dismount to use them (which no cyclist does, but that's a different story). Where did you get this legal requirement from? As a tourist I wouldn't interprete the sign as forced to dismount, just as there is no combined footway/cycleway anymore. In this case I would just be carefully pay attention to the traffic situation - and go on as on every other combined road with motorvehicles. This feature of JOSM indicates to me that there is most likely widespread use of bicycle=no on crossings with the meaning of bicycle=dismount. (according to taginfo the combination crossing and bicycle is used on 42000 nodes, bicycle=dismount is used on 1900 nodes, bicycle=no is used on 56000 nodes A similar problem exists with cycle barriers (chicanes), where often bicycle=no is used to indicate that you have to dismount to pass the obstacle. I don't know how routers handle these cases. I fear that in the end we will be landed with the impossibility for routers to distinguish between bicycle=no and bicycle=dismount at least on nodes of type crossing and barrier. You already got the point: bicycle= no at OSM is always interpreted (and defined) as no cycling. bicyle=* is an access role, a part of vehicle(!) traffic, not an object. It does not say anything about dismounted yet - this is an interpretation of foot=* which is the implicit role in most cases then. And in the majority of situations in the world this is the normal combination. There are only some singular situations where pushing bicycles as an object is not allowed. In this situations I am always puzzled, what I have to fear, if I would carry the bicycle like a suitcase or parcel/packet ... none I suppose, but I never was in such situation yet. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Usefulness of bicycle=dismount on ways
Am 07.10.2013 19:13, schrieb Richard Welty: On 10/7/13 1:08 PM, John F. Eldredge wrote: I remember seeing such a cyclists must dismount on the narrow footway of a bridge over the James River, in Richmond, Virginia, USA. Not only was the footway narrow, [...] there's a cyclists must dismount sign for the footway along the Dunn Bridge between Albany and Rensselaer NY. well, if it is tagged as highway=footway you already have to dismount - otherwise it would be tagged as highway=cycleway. So where is the need for a bicycle=dismount here? I only see the practical need for a bicycle:dismount=no where bicycles are even not allowed dismounted. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Usefulness of bicycle=dismount on ways
Am 08.10.2013 20:16, schrieb Volker Schmidt: Just for your reference - while for many cases, I agree that bicycle=no is appropriate, there are quite interesting cycleways in the Czech Republic, where using bicycle=dismount for nodes on a path would make things easier for people editing OSM. Consider this: http://img.ct24.cz/cache/900x700/article/20/1936/193540.jpg http://img.ct24.cz/multimedia/videos/image/646/medium/193542.jpg (and don't ask me what idiot proposed a cycleway like this). This is the standard way of doing things here in Italy as well. At every end of cycleway sign you are legally supposed to dismount and cross the lateral road as pedestrian well, as it is also signed as the end of the legal footway/sidewalk - in my opinion it is no need for a _dismount_ there. In my opinion it is just a legal backdoor, that on these driveways (or serviceways?) you leave the legal cycleway/footway (with the regarding legal rights above the otherwise crossing traffic) and have to obey the crossing traffic for your own risk - even as walker, but also as cyclist. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of local produce
Am 03.07.2013 05:43, schrieb Bryce Nesbitt: Some farm stands actually sell in-season produce direct off the adjacent farm. Others, which look the same from the road, sell imported goods only. A third type offers the goods from various local farms. How could I tag the difference? May be something like offer=* with - on-site - local - retail ? Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New Proposal
Am 01.05.2013 12:53, schrieb Philip Barnes: The slip roads are straight ahead, whilst the through route curves to the right. The tag is need to tell the router that straight ahead is not stay on the same road. Hope that explains it. uhm, had you ever considered to tag both following ways as *_link? In my opinion - the A56 is a trunk_link, because you have to leave the previous lanes. - the A682 is a primary_link, because you leave the A56. In _both_ cases you need a hint from the router to be warned (like keep left or keep right). And AFAIK this would be already supported by routers. Just my 2 cents. Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] fire_hydrant extensions proposal
Am 11.03.2013 13:29, schrieb Richard Welty: On 3/11/13 7:25 AM, Andreas Labres wrote: Please keep in mind, there already a rather big list of possible tags: http://wiki.openstreetmap.org/wiki/DE:Tag:emergency%3Dfire_hydrant (only in German) and what the OpenFireMap displays (the diameter): http://openfiremap.org/?zoom=17lat=48.11435lon=16.31743 3) water main diameter (not hydrant diameter) internal hydrant diameter isn't going to play in the US, nor is pressure in bar, hence the proposal for extending the tagging system. fire_hydrant:main_diameter is the same as fire_hydrant:diameter - at least in the current tagging usage and 'mappers meaning'. fire_hydrant:diameter is used for the _main_ _pipeline_ diameter, where the hydrant is fed from - as this is indicating the possible value of the water supply. (In theory the pressure is normalized ... in practice, well ...) Sure, this is a bit misleading ... it was developed from a german point of view regarding the signs and a short-as-possible key ... The hydrant pipe inner diameter is not tagged yet - afaik. In Germany the interfaces are standardized anyway - and the (underground) standpipe diameter may possibly vary (50, 80, 100), as it is a movable part from the fire brigade. Regards Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] business closed for renovation - tagging best practice
Am 17.01.2013 16:42, schrieb Janko Mihelić: Well then you decide what its status is. Is it an abandoned building (building=yes), or is it a temporarily closed McDonalds (building=yes, amenity=restaurant, temporary:opening_hours=off). If someone says Meet me at the abandoned McDonalds, you could find that with the temporary tag :) That's more information than just building=yes. so you will find a restaurant with closed doors ... while searching for an opened one. If it is an _abandoned_ restaurant it is no restaurant anymore. In this case I would remove the amenity tag and leave the name only - in fact it _is_ just a building with a big name sign then (case here with a Burger King since around 2 years). Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Names on relations and not component ways
Hello, Am 04.01.2013 14:43, schrieb dies38...@mypacks.net: I recently created a waterway where I put the name of the waterway on the relation but not on the component ways which are grouped by the relation. To me, not duplicating data would seem to be the better overall practice, and duplication of well, it's one acceptable perception to enter the data into a 'relational' database - opposite to the 'keep it simple on every way' perception. But why do you duplicate the tag waterway=river on every way then ...? Regards Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Source tag - deprecated for use on objects?
Am 02.01.2013 18:16, schrieb Martin Koppenhoefer: +1, the smaller (and more sorted by kind of change action) changesets get, the better the chance that the following mapping will understand easily what it is about. There is really no point in grouping different kinds of edits in the same set of changes, just because you happen to do them at the same time. Sometimes I see e.g. a restaurant just by driving by. Mapping at home - I draw a building outline from Bing - add amenity and name from survey - add address info from internet research (depending on my own memory) And you really think I will add that in 3 (three!) different changesets? Regards Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] SF Muni tram lines are layer=1? and general tagging levels considerations
Am 18.12.2012 07:31, schrieb A.Pirard.Papou: On 2012-12-17 22:16, Martin Koppenhoefer wrote : 2012/12/17 A.Pirard.Papou a.pirard.pa...@gmail.com mailto:a.pirard.pa...@gmail.com We badly need precision. . In fact, the only effect of assigning a layer is that upper layer objects hide lower layer ones (it's not a mind your step warning ;-)) it is a way to describe in the database which object is above which or whether they are at the same level. Agreed. And this is why I said that the tag should be called level. Transforming that into layers is a renderer's matter that is strictly forbidden to speak about. Yet... possible - but its a historical evolution you have to 'correct' then. And I (and possibly others too) see the key 'layer' differently, see below. I have traced lengths of streams * stream as a constant layer=-2 way, uninterrupted end to end (even if they don't look so deep), * roads are at level 0 * and bridges and culverts at level -1, in the manner mentioned above. very strange way of mapping IMHO, how did you come to this idea? Exactly as you say above. They are the actual relative levels of these objects. I have never seen a bridge sitting on a road (and hiding it, even just as a hint). Well, so you just understood the layer key as 'a level of the physical object' whereas in my opinion the layer key is defined as 'a level of a map feature (OSM object)'. Physical 'level' is described best by ele (elevation, absolute) or may be by the key 'level' (as in buildings, relative). The key 'layer' is just a relative hint for renderer - at least in my opinion. Bridge and the 'road element' may be seen as different physical objects. But in OSM bridge and 'road element' are seen as one object (one OSM way) as long as no bridge relation is used. So you are just not able to divide them in different OSM layers therefor - at least not until you map different 'layer' for bridge and road element then. Regards Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clean-up the seamark landmark tags on the wiki (and perhaps later in the db)
Hi, Disclaimer: I have nothing to do with the SeaMap, I'm just a coast dweller. Am 23.11.2012 11:48, schrieb Frederik Ramm: True - a cemetery is a cemetery and whether or not cemeteries are used as landmarks by seamen doesn't change that. I do not see, that the seamark:xxx=cemetery will replace the landuse=cemetery, so I do not see a fearable change there. I see that there is a notable difference for navigating purposes possible - not every cemetery on the sea is automagically a seamark:xxx - but I may be corrected here. It is inconceivable to have something tagged landuse=cemetery and seamark:landmark:category=ferris_wheel. Please keep on the spur - no one talks about such main differences - but you cannot tag two different impacts with just one simple tag. Furthermore, is landmark really something that can be sensibly limited to the scope of naval tagging? Can there be something that is a landmark for navigation on water but not a landmark for other purposes, and vice versa? Living in Karlsruhe this is said easily - no pun intended - but living at the coast I know of the differences even I am no 'seaman'. Yes, I consider some landmarks only visible on land and some seamark:landmark only visible by sea. The problem is, to distinguish those at the 'border strip'. Will OpenSeaMap soon start adding seamark:type=shop, seamark:shop=convenience to existing shop=convenience objects if these shops can be used by sailors? Now I think you draw a 'Black man' (bogeyman) on a black wall ... We have bothered much about that as long as OpenSeaMap tagged offshore stuff but I think we cannot tolerate this on the 30% of the world surface that have 99.9% of the data ;) Well, 'routable maps' and 'navigation charts' are for quite the same purpose - but each need there own special tags sometimes, may be even on the same object. I do not see that some(!) additional data on a border strip is really a problem here. Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map for surface/smoothness?
Am 11.09.2012 18:14, schrieb Martin Vonwald (Imagic): Am 11.09.2012 um 16:10 schrieb Georg Feddern o...@bavarianmallet.de: http://roads.osm4people.org/?zoom=7lat=49.60305lon=10.72137layers=B0TFF Thanks! This covers surface, but smoothness isn't supported as far as I can see. not yet - but you may ask at http://forum.openstreetmap.org/viewtopic.php?id=17496p=1 perhaps he will implement it. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Am 31.07.2012 10:33, schrieb Petr Morávek [Xificurk]: Kytömaa Lauri wrote: Petr Morávek [Xificurk] wrote: 2) A relation exists with member ways without ref tag. This means that the route is essentially mapped and any further editor is correcting errors, that he found. Then someone comes and adds a ref tag to one of the ways - why? He drove by, and saw a different ref sign next to that road from one intersection and the next one. He has no knowledge of where the ref on the relation comes from, and if it is still valid on all the ways currently part of the relation. He only knows that this way has a ref=new value, and it's all he can enter. Locals will eventually notice, and resurvey the whole area - they'd have to resurvey anyway. If he knows for sure, that on that road from point A to point B is ref=42 and not ref=56 as the OSM data says, then the user should fix it as I wrote in previous email. Remove the ways from the current relation and add the correct ref tag to the ways themselves, or create a new relation for them. Problem fixed! Note, that if the edit was mistake after all, then QA tool analyzing road network should catch that. If he's not really sure about his data, but wants to alert locals hey, here may be something wrong, then he should use FIXME tag as for any other dispute. Well, I am quite happy with relations and I would like to use them only as you want, too. On the other hand I have the practical expirience, that OSM lives from new contributors - and new contributors have a quite simple approach: - E. g. they add nodes, where already buildings exist, because there is no icon in their editor, they expect there. - They simply do not see relations in their first periods of mapping. I am quite sure, they would add those ref tags as described above, simply because it is their first view. (I have no practical expirience of that right now - but simply because the refs are still on the ways yet here in Germany.) As a QA contributor you just have two opportunities: - Remove all ref tags from the ways and organize in relations - again and again. - Tag all ways with the ref tags appropriate. (Double the data with redundancy). You will not get a consistant and straight solution anyway, I am quite sure. If I understood your scenario correctly, it can be summarized as: Let's use conflicting ref tags for road disputes instead of fixme tag. Personally, I don't support this view. I would understand as: Live with the (mapping) reality and use the (QA) possibilities it opens up. Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ferry routes, what's the correct approach?
Am 31.07.2012 22:50, schrieb LM_1: Not knowing how different routers use access I believe that ways marked as access=customers should be routed with some sort of warning. The same goes for access=private. Quite commonly the real final destination would be in some limited access area and so routers do not have to absolutely avoid more restrictive access values than public. Quite commonly the ferry would not be the real final destination - but in the middle of the route. Routers commonly do not use more restrictive access values in the middle of a route ... access=customer may be also parking places with bothside access. access=private may be also big company areas with bothside access. Commonly routers shall not use those - so why should they use them at ferry terminals? You may have to pay a fee to access, but I would call this a public traffic route. In particular if there is no other possible route. As long as there is no other easy way I would tag for routers in this case. Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping larger Mini-roundabouts
For highway=pedestrian, at platforms and many other things we allow to add area=yes to a feature to turn a circular way (ring) to a circular area (filled area, polygon). If - and that's in fact more or less the result of the discussions we had in the last days - the difference between mini roundabouts and roundabouts is the traversability of the center part, I would say, mapping a mini roundabout as a way would in theory be sufficient without area=yes, because area=yes would be implied. On the other hand I would propose to add area=yes to avoid confusion both at data consumer side as well as on mapper side (yes, they MEANT it to be a mini roundabout, I guess, because they knew it's an area without obstacle in the middle). +1 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping larger Mini-roundabouts
How about diameter=15 on the mini-roundabout node? This is factually correct, verifiable on the ground and (IMHO) non-controversial; routing would not be affected (no need to route over areas) and renderers can draw a bigger blob. Problem solved, simples. +1 (as to Peter) I would prefer this method - but would allow the mini-roundabout-tag on areas for compatibility reasons - may the latter rest upon 'already mapped' or 'stubborn resistance'. ;-) Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping larger Mini-roundabouts
Am 06.06.2012 14:09, schrieb Pieren: On Wed, Jun 6, 2012 at 1:10 PM, Simone Saviolo simone.savi...@gmail.com wrote: On the other hand I would propose to add area=yes to avoid confusion both at data consumer side as well as on mapper side (yes, they MEANT it to be a mini roundabout, I guess, because they knew it's an area without obstacle in the middle). +1 +1 for me too. I'm confused now. You mean an area=yes on a node tagged as mini_roundabout ? It is obvious, that you did not cite Peters first sentence - but it is mandatory to read it in context, to avoid your confusion. ;-) -1 for area=yes for something that is traversable only for wide vehicles Uhmm, it is still traversable physically - it is just only allowed for wide vehicles. Like painted lines/areas on dual carriageways ... -1 for area=yes on nodes. +1 -1 for circles with area=yes and implied oneway restriction. I think I understand your point here - but the simple node still has a oneway restriction too. Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Martin Koppenhoefer dieterdre...@gmail.com hat am 29. April 2012 um 17:39 geschrieben: 2012/4/29 Kytömaa Lauri lauri.kyto...@aalto.fi: http://i46.tinypic.com/2cfqivn.png Which value would people use for the lanes=*? I think I wouldn't tag any lanes explicitly here. Looks like a residential road. I wouldn't expect many trucks in this zone, but if I were to map more detail I'd add a width-tag. +1 Any 'default' assumption of any user of the data would give a value between 1 and 2 anyway. As you can see, an assumption of 2 may be the better one here - if you take passenger cars into account. As you can see, an assumption of 1 would be the better one here - if you take lorries into account. Independently of 1, 1.5 or 2 any router would consider this road with nearly the same value for the traffic considerations. Any renderer has a better info with width. What info do you think has lanes=1.5 then? What do you think a user can derive from this info? Looks as if 2 cars can pass each other without big problems. +1 At least no problems regarding traffic time or the mere usage to reach the point you want. But look at the pole right behind - I think they won't try to pass everywhere without advanced caution. Georg___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] contact:phone or phone to combine with amenity=telephone
Am 26.04.2012 18:07, schrieb Mike N: On 4/26/2012 8:51 AM, Martin Koppenhoefer wrote: Can we use the taginfo stats to revert the change made the 2nd may 2010 where phone has been replaced by contact:phone and add a big deprecate notice on the contact: namespace wiki ? (overall, we still have 10 times more phone than contact:phone, 20 times more website than contact:website, etc) +1 from me, but I know there are other mappers opposing this and trying to push the contact: prefix. I agree with those wanting the 'contact:' format that it is unambiguous and might be easier to use and analyze, but since no data consumers use it (that I know of), 'phone' is preferred.I know of several data consumers on mobile apps that use 'phone'. well, I too appreciate the namespaces if they avoid ambiguity - but is there really any ambiguity with phone, fax, email, website, webcam? contact: is a mere categorisation than distinction - and so it is just stuffing for me. Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Am 27.04.2012 09:23, schrieb Ilpo Järvinen: On Thu, 26 Apr 2012, Martin Koppenhoefer wrote: What do you think of lanes=3.5? I have an example here: Not sure, how many lanes these are, could be 5 or even 5.5? Depends on the car widths and the experience of the drivers: Heheh... :-) ...there's one major difference between 1.5 and=2.5, ie., whether the traffic in one direction almost always interferes with the opposite direction of the traffic, in the latter case it shouldn't happen So you mean 1.5 is the same as 1 regarding the almost always interfere? ;-) Georg in the mood too - but in jolly springtime mood ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Am 26.04.2012 13:07, schrieb Colin Smale: 1) the hard shoulder is sometimes opened to traffic, creating an extra lane on the right this case is used in Germany in several regions e.g. http://www.staufreieshessen2015.hessen.de/irj/servlet/prt/portal/prtroot/slimp.CMReader/HMWVL_15/Staufrei_Internet/med/c6f/c6f50ce6-66e7-3e21-79cd-aae2389e4818,---- and this leads very fast to the question: Shall this lane - be counted - because it is a managed lane, but that it is only sometimes - or not - because it is most of the time an emergency lane The article is ambiguous here. Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Block names (vs street names) in Brasilia
Am 25.04.2012 08:58, schrieb Elena ``of Valhalla'': On 2012-04-24 at 21:46:35 -0400, Nathan Edgars II wrote: On 4/24/2012 2:13 PM, Alex Barth wrote: Pieren - thanks for pointing out that area=yes is highway only. How could the documentation for it be clearer [1]? It's not highway only. For example, it can be used on railway=platform: http://www.openstreetmap.org/browse/way/94063273 or man_made=pier: http://www.openstreetmap.org/browse/way/71124853 but in both cases the meaning is contrary to the default for the main tag, this feature has not been described by tracing its center line, but its perimeter as far as I know and always have considered, that is the meaning in _all_ cases - because area was invented to differentiate between the linear and area meaning of a tag, if it is ambiguous. And it is documented - at least actually - for the use in both directions, so even to distinguish a linear feature from a default area feature (area=no). But back to the block name question, I do not think area=yes is in anyway necessary there: If you consider block as an address feature, addr:block should be used at the address itself, not at the block area in total. If you consider to describe just the block area - just the perimeter - to name it, I think place=locality on a closed polygon would be sufficient. Only if you need to describe the block as an entity - as an 'administrative object' or something like that - you need a special place= block value. Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Block names (vs street names) in Brasilia
Am 25.04.2012 12:29, schrieb Martin Koppenhoefer: -1, place=locality shouldn't be used here, because according to the wiki it is not to be used for settlements or parts of them Objection granted! I abandon this question, Your Honour! ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=services/rest_area
Am 20.04.2012 10:46, schrieb Nathan Edgars II: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it (usually) has fuel and food, but it links to Wikipedia:rest area. Should the Wikipedia link be removed (and added to http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)? Uhmm, difficult, because the linked wikipedia article refers to rest area _and_ service area. I would differ between highway=rest_area as rest area (min. parking and rest rooms, may be a picnic area or a very small kiosk, but no further service) and highway=services as service area. (min. any 'full' service like refuel, restaurant, accomodation) Should the word 'usually' be removed? Possibly, at least I am expecting a fuel service at highway=services - but that may be a result of my german / european practice. I do not know of service areas with accomodation only, just of fuel and optional restaurant, optional accomodation. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sidewalks and tagging for the renderer
Am 11.04.2012 11:35, schrieb Martin Koppenhoefer: in the case of parallel ways it is impossible to tell whether you can filter them out or not (there could be a separation or they could be on different height levels), especially if people are mapping sidewalks the same as separated footways. Thats a point - and the differentiation should be really considered in the tagging. My main concern is routing, not rendering. I wouldn't take them into account in routing, because I feel you would get worse results. E.g. 100 m South of the spot you posted above: http://www.openstreetmap.org/?mlat=53.865988mlon=27.651201zoom=18layers=M Imagine you stand there and want to go to the parking on the other side of the road: You take very 'short way' examples - to show the point of concern, thats ok. But these are examples where - I think - no one would even consider to use routing. On the other hand: 1. Use 'practicable' examples (far longer ways) and you will see, that many (not all) of these 'problems' fade away, because the routing will use those crossings anyway and lead to the right side before . If there is no sidewalk on the destination side or another adequate footway - it will use your approach anyway ... 2. A person who can see the situation can see the routing too - and may shorten the route on his own risk. A person who does not .. well, I would not recommend them a shorting anyway ... Another similar issue is that with these sidewalks people often don't connect crossing footways to the street, they only connect them to the sidewalk. There are examples for this also in your area, so unfortunately simply omitting them won't do the job either, because you would get gaps near crossings. A crossing footway over a street with bothside sidewalk must not always be connected to the street - carriageway and sidewalk are considered as different transport route with different usage then. For routing there is no need to connect them. For renderer there is no need to consider which is top or bottom - he may choose itself by usage preference. (Distinction of bridge and tunnel presumed.) The signal points or the 'consider a hazard' points may be outside of the crossing point itself. Connections are only needed at points where you can really use a parting transport way (which may be a street without sidewalk). Third, try to cross these not on the crossing staying alive: http://upload.wikimedia.org/wikipedia/commons/thumb/1/14/Partyzanski_praspekt_8.jpg/300px-Partyzanski_praspekt_8.jpg http://kp.ru/f/4/image/26/67/396726.jpg I'll do next time I visit your town. What should be the problem? You wait until there is no car coming or all cars stop and then you cross. Yes - I see, you have _seen_ the point already. ;-) cheers, Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sidewalks and tagging for the renderer
Am 11.04.2012 12:47, schrieb p...@trigpoint.me.uk: I am wondering what happens where there are no crossings, or outside of built up areas where there are no sidewalks. That's quite easy: Where there are no crossings - no crossings can be used, any routing will use the nearest point approach - with 'wild crossing' (your destination is on the other side of the road) or use the road - the rest is your personal responsibility to adhere the laws and to preserve your health. Where there are no sidewalks - well, there are no sidewalks, you and the router will have to use the 'road'. A router that does consider sidewalks, will _prefer_ sidewalks and use roads otherwise. A router that does not consider sidewalks will use the roads anyway. Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Turn Restriction usage
Am 11.04.2012 15:42, schrieb Simone Saviolo: 2012/4/11 Ross Scanloni...@4x4falcon.com: No. The router should know not to do this. Likewise as below the router should not make u turns at traffic lights. Based on what? How does the router know that the two ways are two carriageways of a single road? Couldn't they be a straight road, that becomes a oneway street at a certain point, and at that point a junction brings to a oneway secondary road? The name of the way, the fact that you are turning 180 degrees on the same way. I don't agree. First, if you're on the same way, you're not turning, but going straight and following the road. In the case of the OP, I expect to see three ways, two of which tagged oneway=yes. Second, if you turn more than 180 degrees, you're hopefully going on a bridge ;-) Third, think of a situation like this: http://osm.org/go/0CKuMhs89- in your example the angle at the considered point is far from dangerous or considerable. Your angle is in the range up to 45° and doesn't even reach 90° (a typical crossing / turn situation). Points of no u-turn - that have to be considered - have angles - beyond 90° (may be a sharp turn or a crossing at a combine situation) - mostly beyond 120° and often beyond 150° This is the range to consider - and that is possible for a router. The angles depend a bit on the mapper's 'style' and should be considered by the mapper - but in most cases the angle will reach those range anyway - a split and combine would not be 'rectangle'. (U-turns at dual-carriage ways with two 90° turns because of a via-way have to be considered separately. If not allowed - even only by law - a turn restriction may be helpful there.) Greetings Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sidewalks and tagging for the renderer
Am 12.04.2012 15:15, schrieb Martin Koppenhoefer: Am 12. April 2012 08:44 schrieb Georg Fedderno...@bavarianmallet.de: A router that does not consider sidewalks will use the roads anyway. No, a router that doesn't consider sidewalks would with the currently suggested tagging use the sidewalk and think it was a usual footway. Sorry, I kept my own Am 11.04.2012 11:35, schrieb Martin Koppenhoefer: in the case of parallel ways it is impossible to tell whether you can filter them out or not (there could be a separation or they could be on different height levels), especially if people are mapping sidewalks the same as separated footways. Thats a point - and the differentiation should be really considered in the tagging. with the suggested tagging footway=sidewalk and sidewalk=yes as differentiation in mind (writing quite the same time). Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging