Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
[cross-posted to talk-us@ and tagging@, please choose your follow-ups wisely] Brian M. Sperlongano wrote: > It seems that we are increasingly doing things to simplify the > model because certain tooling can't handle the real level of > complexity that exists in the real world. I'm in favor of fixing > the tooling rather than neutering the data. I sincerely hope "I'm in favor of fixing" translates as "I'm planning to fix", though I fear I may be disappointed. More broadly, we need to nip this "oh just fix the tools" stuff in the bud. OSM optimises for the mapper, because mappers are our most valuable resource. That's how it's always been and that's how it should be. But that does not mean that volunteer tool authors should rewrite their tools to cope with the 0.1% case; nor that it is reasonable for mappers to make stuff ever more complex and expect developers to automatically fall in line; nor that any given map has a obligation to render this 0.1%, or indeed, anything that the map's creator doesn't want to render. The Tongass National Forest is not "in the real world", it is an artificial administrative construct drawn up on some bureaucrat's desk. It's not an actual forest where the boundaries represent a single contiguous mass of trees. Nothing is lost or "neutered" by mapping it as several relations (with a super-relation for completeness if you insist), just as nothing is lost by tagging Chesapeake Bay with the series of letters "c","o","a","s","t","l","i","n" and "e". Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
Joseph Eisenberg wrote: > you are not going to get a custom rendering from one set of vector tiles. Sure you are. You're not going to get every possible custom rendering from a single set of performant vector tiles, granted, but half of Mapbox's entire business model is custom rendering from one set of vector tiles. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Artificial
Matthew Woehlke wrote: > On 21/10/2020 00.57, Robert Delmenico wrote: > > The word 'Man' in the Old English sense 'mann' had the primary meaning of >"adult male human" > Citation needed My degree is in Old English (and the other early medieval languages of the British Isles) and I can assure you that the sentence quoted is, frankly, beallucas. "Man"/"mann" in OE is usually gender-neutral. Go look at a parallel text of Beowulf if you don't believe me. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Crossing tagged on both way and node (was: What does bicycle=no on a node means?)
Volker Schmidt wrote: > I don't know what the routers need, to be honest. > Anyone in the router business listening in on this conversation? cycle.travel will take account of highway=crossing nodes (e.g. where a cycleway crosses a road), and adjust its routing weight accordingly. The adjustment is slightly different depending on the type of crossing and the highway= value of each connecting way. It does not take any particular note of =crossing ways, other than to note that footway=crossing means that the rider should push. It does not currently take any account of bicycle=no on a crossing, not least because bicycle=no is a very problematic tag - generally bicycle=dismount should be used instead, reserving bicycle=no for those circumstances where even pushing a bike is not legal (e.g. most public footpaths in England & Wales). Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?
Tod Fitch wrote: > This thread has been quite amazing to me. My impression is that it > starts with some routers (a.k.a data consumers, a.k.a. “renderers”) > treating a “no” as a “maybe” and now people are looking for a new > term to indicate that “we really, really, mean NO!”. This is worse > than tagging for the render, it is obsoleting a straight forward > and explicit tag value for a broken renderer. No, you have got that the wrong way round, and it would be kind for you to be a bit surer of your facts before throwing around accusations of brokenness. People have been using bicycle=no to tag footways where cycling is banned, but where you may push a bike, since the very earliest days of OSM. Here's an instance from 2006: https://www.openstreetmap.org/way/2606296/history . I'm pretty sure there weren't _any_ OSM routers in existence then. The reason that routers will sometimes route via such a path, with an instruction to dismount, is that this tagging practice has always been widespread. It doesn't "start with some routers". It started with the tagging. Fairly obviously, if the users of a particular router complain to the router's authors that they're being prevented from plotting a viable route, then the authors are pretty obviously going to change the router so they stop getting complaints. So either fix the existing instances in OSM of bicycle=no being used to mean bicycle=dismount, or introduce a new tag. Richard cycle.travel ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM
Sarah Hoffmann wrote: > That said, my favourite solution here would indeed be to add a new > main tag highway=trail and slowly retag the existing mountain > paths starting with the most dangerous/abused ones. Fully agree with this, other than the slight detail that =trail is the wrong value. In some usages (particularly American English), "trail" can mean any medium/long-distance off-road path, including nicely manicured, tarmaced bike routes. For example, the Katy Trail, the Trail of the Coeur d'Alenes, and brands such as Rails-to-Trails and traillink.com. I suspect that highway=trail would immediately be repurposed for those and we'd be deeper into the same mess. OSM, of course, speaks British English, but we do try to avoid obvious ambiguities (hence footway=sidewalk rather than =pavement). highway=mountain_path works for me for tagging mountain paths. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
I love the fact that we are now 50 messages into discussing, for the second time, a change that would be made ostensibly for the benefit of data consumers, and yet no one has asked any actual data consumers. https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_Ship_B Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
Soren Reinecke wrote: > I request to replace all occurrence of the non-prefixed > versions of the contact keys like Key:phone, Key:email. > Key:website to be replaced with the prefixed ones like > Key:contact:phone, Key:contact:email, Key:contact:website As someone with admin access over this mailing list, I request that you do not keep bringing back proposals which were extensively debated beforehand and generally rejected. It wastes everyone's time. I don't particularly want to start banhammering people from the list but will do so if necessary. Thank you. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Route names that aren’t names
Peter Elderson wrote: > Suggestion for rendering: > What about osmc:name=* > I know, doesn't exist, but it's a logical companion of osmc:symbol. > Definition would be: name to show on the map. > Definition should be: just the simple name as found in the field, or > the nae ecerybody knows and uses, no extra's. That's pretty good _except_ for the tag name, I think. The osmc: prefix comes from a particular (fairly obscure) bit of software called OSM Composer, and for historical reasons it's become the popular tag for symbols, but there's no reason to perpetuate that into other tags. I'd be 100% on board with using route_name= with your suggested definition. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Can highway=cycleway be limited to MTB?
brad wrote: > The proper tag is highway=path, foot=yes, horse=yes, bike=yes. That's an utterly terrible set of tags _unless_ you also specify a surface tag. highway=cycleway is, by default, a way whose construction standards are "good enough to ride a bike on". Great! I can route along it. highway=path doesn't provide that assurance. It just says "this is a path of some sort". highway=path, bicycle=yes might be a wonderful paved path. It might also be a 50cm-wide cliff-edge path where, by some freak of legislation, you're permitted to ride along there. To your death. (There are lots of mountain paths in Scotland that would qualify for that. No-one would tag them as highway=cycleway. But bikes are technically permitted.) If you tag trails with "highway=path, foot=yes, horse=yes, bicycle=yes" and nothing else, you are royally screwing up routing. Please don't. Yours, a frustrated bike router author. -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Route names that aren’t names
Yves wrote: > Inevitably, the current situation is stained by the abilities of the > actual renderer, and the other way around. Maybe those renderers > should sit around a wiki page and document how ideal tag could be > and how they can be used in rendering, also taking into account > the ability to parse nested relations or not with their respective > toolchain. With my cycle.travel hat on: I already show route refs (as shields). I would like to show route names without duplicating the ref or showing extraneous information. I don't really mind whether the tag is name= or official_name= or route_name= or brian= or whatever. Parsing nested relations is no problem, I already do that. To be honest, I'm perfectly happy to sit down for a day, armed with a bunch of regexes, and go through the current list of names to get alternatives that I can hard-code into cycle.travel. But that doesn't help anyone else! Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Route names that aren’t names
Sarah Hoffmann wrote: > These days I wonder if it wouldn't be better if we introduce a > tag that explicitly contains the name only. How about > official_name for a, well, official name of the route and > local_name for one that is used by everybody else. Interesting thought. That really isn't a terrible idea. Well, ok, it _is_ a terrible idea in that one really shouldn't have to explain that the name tag is for the name and the ref tags is for the number, but we are where we are; and changing current usage appears likely to encounter resistance from the usual tedious sludgifiers. I'm slightly nervous of officlal_name because it's prone to sludgifiers (previous message refers). I wonder whether route_name= might work best if a reasonable definition were formulated? Something like "The popularly accepted name (and name only) for the whole route, excluding route number and geographical/similar qualifiers", illustrated with a set of examples. Yes, the key's a bit tautologous, but we have thousands of route=bicycle with route=?cn where the "c" stands for "cycle", so that's already a lost cause... Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Route names that aren’t names
Dave Fox wrote: > I'm not sure I'm seeing the problem. What /is/ the "actual" name > for UK cycle routes? > NCN 4 is named as National Cycle Network Route 4 as that's what > Sustran call it. > I'm not convinced names & refs *have* to be mutually exclusive. Sure. NCN 4 is called "NCN 4" in the same sense that the M4 is called the "M4". That's fine - plenty of people refer to it that way. But OSM convention, dating back 15ish years, is that in situations like this, you put the number in the ref alone. The M4 just has ref=M4, not name=M4. There are of course plenty of NCN routes which do have names. NCN 8 is Lon Las Cymru. NCN 68 is the Pennine Cycleway. NCN 4 west of the Severn Bridge is the Celtic Trail. NCN 1 from Newcastle to Edinburgh is Coast & Castles. (It's a side-issue, but Sustrans doesn't really have a consistent way of referring to route numbers: you'll hear Sustrans staff refer to "Route 5" or "NCN 5" or "National Cycle Network Route 5" or "National Route 5". I was at a video conference with Sustrans staff earlier this week and heard several variations. :) ). Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Route names that aren’t names
Hello folks, Route relation names aren’t in a great state, are they? Let’s say that I want to render cycle route names on a map (because, well, I do). I zoom in on a way along the East Coast of Britain and I find it’s a member of this route: https://www.openstreetmap.org/relation/9579 name=NCN National Route 1 Hm, ok. That’s not the name of the route, it’s a duplication of the ref (and network) - something we’ve known not to do with the name/ref tags for roads since time immemorial. No matter, there are other relations for the way, so let’s see if they’re any better: https://www.openstreetmap.org/relation/9476069 name=EuroVelo 12 - North Sea Cycle Route - part United Kingdom 5 That’s _definitely_ not the name of a route. “part United Kingdom 5” is some OSM mapper’s shorthand. If I were to tell someone that I’m having a holiday on “part United Kingdom 5”, even someone who works for the route authorities at Sustrans or the European Cycling Federation, they’d look at me blankly. Anyway, this has a parent relation: https://www.openstreetmap.org/relation/9476239 name=EuroVelo 12 - North Sea Cycle Route - part United Kingdom Nope, that’s not great either. It in turn has a parent relation: https://www.openstreetmap.org/relation/1207220 name=EuroVelo 12 - North Sea Cycle Route That’s not good. It duplicates the ref and the network; it enforces arbitrary punctuation upon the data consumer. It is, I guess, the least wrong of any of these names. But that’s not saying much. This isn't just a British thing, or an NCN thing, or a EuroVelo thing. Refs in names are depressingly ubiquitous. Better still: there are hundreds of routes with something like ref=12-83, name=(12) - (83) - with the added brackets meaning you can’t even filter them out based on a simple match. Then there are routes called "Aare-Route (Etappe 3)” and "Alpenpanorama-Route- Etappe 6 (Thun-Fribourg)” and "[D10] Elberadweg [Abschnitt K] Dessau-Roßlau - Elster [linkselbisch]”. I wish I were making this up. The upshot: bad luck if you want to render the actual names of routes on a map. You can’t. A modest proposal: let’s use the name= tag in route relations for route names. Let’s use the ref= tag for route numbers. If it doesn’t have a name, it shouldn’t have a name= tag. Same as we do everywhere else. If you need somewhere for a mapper-facing route description (and I can see that you need that for “part United Kingdom 5”), then I guess the obvious place to put that is the note= tag. But let’s keep it out of the name tag; and let’s have a concerted effort to remove them from existing name tags. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
Phake Nick wrote: > First of all, I don't think there are any existing routing engines > for trains on rail or bus or minibuses on street Sure there are. https://github.com/geofabrik/OpenRailRouting https://github.com/railnova/osrm-train-profile https://signal.eu.org/osm/ https://github.com/Project-OSRM/osrm-profiles-contrib/blob/master/5/6/bus.lua etc. etc. etc. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] URL tracking parameters
Frederik Ramm wrote: > The fact that advertising and correctness do not usually go hand in > hand certainly needs no discussion. Er, yeah, it does actually. In the UK, at least, you're not meant to claim incorrect things in adverts. There's a body called the Advertising Standards Authority that polices that, and there's a whole load of statute law on the subject (Trades Descriptions Act, Control of Misleading Advertisements Regulations etc. etc.). Clearly there are shades of grey there and some advertisers will try to get away with half-truths. But that does not mean that, if a hotel owner says "hey, there's a hotel here, and it's called Bob's Hotel" we should automatically assume they're doing it for a purpose other than correctness and therefore "remove the whole POI". cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] URL tracking parameters
Jez Nicholson wrote: > Whilst I'm firmly against tracking codes, we could give the benefit of > the doubt and assume that they just cut-and-paste the URL and did > not intend to place tracking. Yes. And we don't even need to do that: we can verify it with about 30 seconds' Googling. Looking at https://www.openstreetmap.org/way/156041136, website= has been set to https://www.hilton.com/en/hotels/bhxsadi-doubletree-stratford-upon-avon/?WT.mc_id=zVSEC0GB1DT2NaturalSearch3GoogleMyBusiness4luau-SAU_Aug5luau6BHXSADI7EN8i1 Now, if you Google "Hilton Stratford-upon-Avon", and copy the link from the "Website" button on the right, you get: https://www.hilton.com/en/hotels/bhxsadi-doubletree-stratford-upon-avon/?WT.mc_id=zVSEC0GB1DT2NaturalSearch3GoogleMyBusiness4luau-SAU_Aug5luau6BHXSADI7EN8i1 It's the same link. Every character. So they're clearly not trying to track visitors expressly from OSM, they've just copied the URL. Where they've copied it from we don't know (they might have an internal spreadsheet of URLs, or they might have just Googled their own property - stranger things have happened). cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] URL tracking parameters
Frederik Ramm wrote:
> I'd remove things from OSM that have been clearly added as part of
> an advertising campaign, because that means the information is not
> trustworthy. The purpose of an advertising campaign is not to
> provide unbiased, factual information, hence OSM cannot be the
> vehicle for an advertising campaign.
In the example cited, the "whole POI" wasn't added as part of an advertising
campaign, the property owner just added metadata:
https://www.openstreetmap.org/node/2411243835/history .
But more broadly, we value data for its correctness, not for its provenance
(assuming licence-compatible). You are inventing a suspected rationale ("an
advertising campaign") on the part of the contributor; judging them by your
own standards which aren't the agreed/stated values of OSM anywhere I can
see; and concluding that the data should be deleted. That's... a stretch?
I mean, isn't it also possible that, now we've all made such an outstanding
success of OSM and it's used in approximately eight gazillion mapping apps,
Hilton Hotels think it would be useful if their customers could use their
favourite mapping app to find a hotel they're staying in?
Anyway, brb, got to delete https://www.openstreetmap.org/node/312915889 from
the map.
cheers
Richard
--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] URL tracking parameters
Frederik Ramm wrote: > Since OSM is not the place for marketing, I would in these > situations remove the whole POI, and not just the tracking > parameters. ¿Que? You'd remove an entire hotel from the map because... ok, I'm having trouble finishing that sentence: because what exactly? cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] implied surface values?
Volker Schmidt wrote: > Do we have any agreed implied surface values for the different > street categories ? per country? We had this thread already, didn't we? https://lists.openstreetmap.org/pipermail/tagging/2019-September/048330.html https://lists.openstreetmap.org/pipermail/tagging/2019-September/048338.html Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] road names and refs
Kevin Kenny wrote: > I think we can both agree that in practice there is no clear > consensus on what to do in the specific case where a road > has a reference but no other name. Honestly, there is, and it's as Paul and I have described - you put the ref in the ref tag and leave the name tag blank. This is how it has been in OSM since pretty much day one. If a newbie in Europe puts a ref in the name tag, it gets stomped on pretty quickly. The reason it might seem otherwise in the States is that the TIGER import didn't populate the ref tag, just the name tag, and a lot of the TIGER import still hasn't been cleared up. So there's a bunch of TIGER-derived roads which have things like "name=County Road 23" (or Township Road, or "Co Rd", or many other variations). This was never an active decision to do it this way; it's just that lots of TIGER hasn't been fixed, particularly the rural areas where unnamed County Roads are more common. Fixing this wouldn't be a bad thing for a mechanical edit to do. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] road names and refs
Rob Savoye wrote: > I was wondering about tagging roads properly. Previously it > was mentioned to use 'ref' for county roads, ie... "ref='CR 12'", > but as the road sign says "County Road 12", I was wondering > about the proper way to tag this. Should 'CR' be expanded in > the 'ref' to "County Road", or should 'ref' be 'CR 12', and then > "name='County Road 12'" ? This also applies to state Forest > Service roads as well that lack a name tag. I'm working on > cleaning up some ancient crap from the TIGER import... You asked this back in August and the answers still apply: https://lists.openstreetmap.org/pipermail/tagging/2019-August/047455.html "County Road 12" is a ref. It is not a name. People often refer to roads by their ref. That's fine. I will say "I'm taking the A3400 to Stratford" rather than "I'm taking Shipston Road, which becomes London Road, which becomes Stratford Road, which becomes Shipston Road again etc. etc.". There are signs that say A3400 and signs that say Stratford Road etc. That's fine too. It doesn't mean the name is A3400. It just means I'm using the ref in conversation. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Continuous Sidewalk or Cycleway
Florimond Berthoux wrote: > How to map a continuous sidewalk or cycleway ? A couple of ideas were posted in connection with the London cycle infrastructure database: https://github.com/cyclestreets/tflcid-conversion/issues/30 https://github.com/cyclestreets/tflcid-conversion/issues/16 Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
Joost Schouppe wrote: > In the case of cycling, it would be really useful > for routers to be able to differentiate. Yes - with my cycle.travel hat on, I'd find this very useful. Just an optional route_type= tag on the relation would help. I've mentioned on here a couple of times before [1] that there's a road bike route in North Wales that is particularly problematic: it's signposted as a bike route, but whereas other routes in the UK are for utility or touring purposes, this one is specifically for road bike training and is wholly unsuitable for all other purposes. (Almost all of its route is highway=trunk or highway=primary with no cycling provision whatsoever.) Although it's a signposted bike route and as such merits mapping, it is no more akin to a standard route=bicycle than a stretch of mountain bike singletrack is. cheers Richard [1] https://lists.openstreetmap.org/pipermail/tagging/2019-October/048713.html, https://lists.openstreetmap.org/pipermail/tagging/2019-September/047873.html -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What access key for cargo bike ?
Florimond Berthoux wrote: > I’m really here just to know the english word. > In France we also say "vélo cargo" (cargo bike), so I’d go for > cargo_bike if none disapprove. It's definitely a cargo bike in British English too. Richard (owner of a Circe Morpheus, which is a cargo bike of sorts: https://www.circecycles.com/products/solutions/cargo/ ) -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rail segment in a bike route
Francesco Ansanelli wrote: > I added a bicycle route that implies the use of a funicular > (railway). I'm not sure how to "tell" in the relation that > you have to take the train and not ride the railway. Just add the railway to the bike route relation, and make sure that each end of the railway is directly connected to bike-routable ways. Here's cycle.travel routing via the Tauern Tunnel: https://cycle.travel/map?from=Salzburg=Grado (Unfortunately someone appears to have broken the relation since I last ran a routing update, removing the tunnel from it, so that'll need fixing... sigh. https://www.openstreetmap.org/relation/2771761 ) cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (contact:phone)
MARLIN LUKE wrote: > Reading a thread like this honestly won't encourage any participation > from outsiders (myself included) With the best will in the world, I don't think it's productive or welcoming to encourage outsiders to think that they should come into OSM and tell everyone that 2 million users should stop using an intuitive, plain-English tag that has been in use for over 10 years, entirely for abstruse, unproven benefit. OSM wants more participation from outsiders, absolutely. We want you to come and map the world. Starting a long involved discussion about not using the word "phone" to tag phone numbers is not "mapping the world". It is distracting people, newcomers included, from the task of mapping the world. It is distracting developers from important work on making tools easier for newbie mappers. It is, basically, Brandolini's law in action: "the amount of energy needed to refute bullshit is an order of magnitude bigger than to produce it". Please participate. Please participate by _mapping_. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (contact:phone)
Sören Reinecke wrote: > This proposal tends to make Key:contact:phone the official tag > for tagging phone numbers and to deprecate Key:phone which is > not fitting in the idea of grouping keys. Anyway it's bad to have > two keys for the exact same purpose in use. Please just kill me now. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?
Jmapb wrote: > Maybe I'm missing something here but I don't see any reason why > data consumers, including the bicycle modes of routing engines, > should ever interpret bicycle=no in a way that permits walking > bicycles. This is exactly why we have a bicycle=dismount tag. Because mapping is imperfect. I don't see any theoretical reason why data consumers should ever interpret highway=residential in a developed country as anything other than a paved road, but hey, you try bike routing across the US with that assumption and see where it gets you. (Probably: dehydrated and dead in a ditch in New Mexico.) People often tag bicycle=no when the reality is =dismount. People also tag bicycle=no when the rules say =no but in real life =dismount is tolerated. I'm not going to send someone on a 3-mile detour when they could push their bike for 30m instead, even though a never-enforced sign says thou shalt not. Richard cycle.travel -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?
Martin Koppenhoefer wrote: > IMHO we need neither bicycle=dismount, nor similar tags for mofas, > mopeds, motorcycles and other vehicles. If you dismount, you are > a pedestrian (according to many jurisdictions) But not according to all justifications, as I have explained wrt the UK. > As this is a very rare restriction, it is probable that many > applications will not want to deal with it. I am very happy to add such a restriction to cycle.travel's routing if a sane value can be agreed, and I'm sure other cycle routers would do the same. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?
Martin Koppenhoefer wrote: > do you have an example for a street where pushing the bicycle > is not allowed? Potentially every public footpath in England & Wales. The law says only that "usual accompaniments" are permitted, without specifying them. Cycling organisations try to argue that this includes a bike, but I suspect the wish is father to the thought in this one. Certainly one local council believes it doesn't: https://www.cornwall.gov.uk/environment-and-planning/countryside/public-rights-of-way/rights-and-responsibilities-on-public-rights-of-way/public-rights-and-responsibilities/ Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecating mini_roundabout
Florian Lohoff wrote: > From the document you mention i have the feeling that that is a > British special. It is, pretty much. Plus a few in places heavily influenced by British practice (Ireland and Hong Kong), and also France as Philip says. The Wikipedia description actually puts it quite well: https://en.wikipedia.org/wiki/Roundabout#Mini-roundabouts . "Mini-roundabouts use the same right-of-way rules as standard roundabouts, but produce different driver behaviour." In other words, though you have to give way to traffic already on the roundabout (like a normal one), two factors combine to make people treat it more like a normal junction. The small size means that it doesn't take long to traverse, and you're more likely to encounter traffic approaching than actually crossing it. Second, the design of approaching roads is intact (there's little 'flaring'), which suggests facto priority for the major roads - even though all approaches in theory have equal priority, in practice the major road is usually dominant. It's much more like a US four-way stop than a full roundabout, but UK Government guidance (rather annoyingly) advises against four-way stops and there are very few in the UK. I think the best suggestion in this case would be to update the documentation, particularly in translated pages, clarifying that the tag is intended for the formal mini-roundabout design as found in the UK, Ireland, France etc., and not for any flat roundabout. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deprecating mini_roundabout
Florian Lohoff wrote: > The point is that a mini roundabout does need a LOT of preprocessing > to put it into some graph for your classical A* or Dijkstra. You need > to eliminate the node and replace it with a circular road much like > a junction. What? No. No. You don't. I do precisely no preprocessing for mini-roundabouts in cycle.travel because they're irrelevant. They're just normal crossroads or T-junctions with no inherent priority other than traffic already making the turn (similar to a four-way stop in the US), and some paint in the middle. They are treated exactly as normal junctions and so they should be. > You would expect (as you see a roundabout sign) to get instructions to > take the n.th exit. What? No. No. You wouldn't. Mini-roundabouts are almost always at junctions with only three or four exits. The Government guidance explicitly states so (https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/561491/mini-roundabouts-report.pdf, para 3.9). Any UK driver would expect their satnav to say "turn left" or "straight on" at a mini-roundabout, not "take the first exit". Could I suggest that you refrain from tag-fiddling on a subject where you clearly have no experience? Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cycling relation misuse
brad wrote: > There are several variations and gpx tracks available on the net for > the great divide route. There are also many websites which > discuss the route and show maps. It's in the public domain. It is only "public domain" (US usage) if the creators have disclaimed all copyright in it, or if it's not eligible for copyright protection. I'm not aware of the Adventure Cycling Association doing the former, or any US case law for the latter. (But my knowledge of US case law is very imperfect, so if you could point to either, that'd be helpful!) "It's on lots of websites" does not mean something is free of copyright. There are plenty of places where you can download cracked versions of Adobe Photoshop but I'm pretty sure that's still copyrighted. :) Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cycling relation misuse
Phyks wrote: > * Some are dedicated to a very particular category of cyclists, > often racing bikes. We have `route=mtb` for mountain bikes, > we might have `route=racing_bikes` for racing bikes? Typical > example is https://www.openstreetmap.org/relation/163266 > (which might actually fall into the tag to render category) Agreed. I raised this in https://lists.openstreetmap.org/pipermail/tagging/2019-September/047873.html in connection with https://www.visitsnowdonia.info/ffordd-brailsford-way, which is a signposted bike route (two routes, in fact) around North Wales, but entirely unsuitable except for experienced cyclists on road bikes - much of it is on highway=trunk. A new route_type= tag on the relation would be a good way to go. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cycling relation misuse
Martin Koppenhoefer wrote: > wouldn't it be better to delete them from OSM if they are made up? It would, but I have limited hours in the day to police every single cycle route relation in OSM. I lose track of the amount of time I spent on user messages and changeset comments trying to get the Great Divide Mountain Bike Route properly tagged as route=mtb... it even says Mountain Bike in its name, for crying out loud. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cycling relation misuse
John Willis wrote: > I want to delete these fake “mountain workout” relations that > should be mapped in strava or a similar workout app. Fully agree. Go for it. OSM is for verifiable, signposted cycle routes and verifiable, real cycling infrastructure. If a route is on the way to being signposted then it can be mapped with state=proposed. There are literally millions of personal favourite rides in guidebooks and on third-party websites but with no supporting evidence on the ground. There is no place for these in OSM. (I have a fair few lines of code in cycle.travel's rendering and routing codes to blacklist certain routes in OSM which are made up or otherwise unsuitable.) Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to map Irish pubs?
ebel wrote: > I've used `theme=irish` once or twice. But I don't think anyone > else does, and it's not supported. I asked about cycle cafés a while back (e.g. https://www.cafe-ventoux.cc) and the consensus was also to use theme: https://lists.openstreetmap.org/pipermail/tagging/2015-September/026494.html Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Pedestrian and highway crossings of tramways
Vɑdɪm wrote: > The #2 gives railway=tram + railway=tram_crossing which seems to > be a needless repetition -- a tautology. It's easy to deduce that a > crossing on the tramway track is a crossing of the tramway track, > isn't it? This is ultimately the same issue as the one raised by Martin the other day: https://lists.openstreetmap.org/pipermail/tagging/2019-October/048533.html There is no need to have railway=crossing, railway=level_crossing, railway=tram_crossing and railway=tram_level_crossing. They are semantically identical. The type of ways (tram or heavy rail, footpath or road) is already expressed in the way tags and doesn't need to be duplicated in the node tags. Let's just standardise on the simplest tag, railway=crossing, and nuke the others. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Was there every a proposal for the disused:key=* / abandoned:key=* lifecycle prefixes?
Paul Allen wrote: > Ummm, which pub in St Dogs? The Teifi Netpool Inn is more of a guest > house with a bar than a pub with guest rooms these days. The White > Hart closed but there's currently an attempt by locals to raise the > money to take it over. (One quick Google later...) Goodness me, the Teifi Netpool looks unrecognisable (and not for the better). O tempora, o mores etc. Pleased to see that Bessie's in the Gwaun Valley is still the same as ever though! cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Was there every a proposal for the disused:key=* / abandoned:key=* lifecycle prefixes?
Paul Allen wrote: > BTW, that's on national cycle route 82, so whether or not it really is > a pub would be of interest to some mappers. Oh, has that closed? That's a shame. (I stayed in St Dogmaels a few years ago, thought the Castle Inn looked wonderfully old-fashioned, and was planning to go but was diverted by some other excellent pubs nearby. Not least the one in St Dogmaels itself which served Gwynt y Ddraig Black Dragon. I'd hoped to return one day... ah well.) > Mapping it as amenity=pub + disused=yes would (if carto > is consistent with other times I've tried disused=yes) render it as a pub > where disused:amenity=pub does not render it as a pub. Sure, but OSM isn't just about rendering, let alone just osm-carto rendering. A "find a pint of beer near me" app which does a proximity search for amenity=pub won't work very well if some of those pubs... aren't pubs. amenity=pub means "actually a pub", not "thing that looks like a pub". cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Default values for surface by road category and country
Tom Pfeifer wrote: > In the outskirts of Berlin, I have unpaved highway=residential in good > neighbourhoods, that are muddy when wet and dusty when dry. Thus Germany > qualifies as developing country? No, it qualifies as somewhere you should tag unpaved roads with a surface= tag. Hence the phrase "assumed paved" - if the assumption's wrong, then tag the surface accordingly. Volker was asking about defaults, not a single unalterable surface for each highway type! Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Default values for surface by road category and country
voschix wrote: > I am trying to figure out where the surface default values by road > category and country are defined. I don't believe there's a place where it's stated, but I work on these assumptions: - highway=track/bridleway is always unpaved unless stated otherwise - highway=footway/path may be unpaved unless stated otherwise - in developed countries, all "higher" highway types can be assumed paved - in developing countries, anything from secondary down (or even primary) may be unpaved - in rural areas of the US, it's not safe to assume highway=residential is paved if tiger:reviewed=no Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn
Peter Elderson wrote: > The network values identify transport mode and scope of routes, and > these "dimensions" also apply to node networks. We do not want to > add another dimension (configuration type) to the network=* > values of routes. > > Instead, we are thnking about just adding a tag to identify segment > routes as parts of a node network. The nodes themselves do not need > this, since they ARE nodes and have a xxn_ref tag. > > In short, we are thinking to simply add the tag network_type= > node_network (or network:type=node_network) to the node2node > network routes. I have a strong interest in this proposal. :) [1] If I understand you rightly, a route like https://www.openstreetmap.org/relation/1844941 would get an extra network_type=node_network tag. Nothing else would change. (Correct me if I'm wrong.) You say "we don't want to add another dimension" but you are effectively doing that; you're just doing it by adding a new tag rather than adding a value. That's not _necessarily_ a problem but it would be better done in an extensible way that might be useful for other tagging scenarios, rather than special-casing this one scenario. We currently have the "network=ncn|rcn|lcn" tag which broadly identifies the _importance_ of the route. What we do not have is a tag to identify the _character_ and _purpose_ of the route. All bicycle routes (except MTB) get lumped together as a generic route=bicycle. This is increasingly a problem as routes are devised and signposted for performance cycling, bikepacking, and so on. For example, there are two new performance cycling routes in Wales which I'd like to map (https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would be misleading if tagged in the same way as other NCN/RCN/LCN routes in Britain. You're proposing a tag called "network_type", but it's a tag for the route, and what you're using it to describe is the character and purpose of the route. (The network is already mapped in the network super-relation.) So I'd suggest that instead of network_type=, you add route_type= . This would achieve the same purpose; be semantically more appropriate; and be extensible to other routes where "route=bicycle" alone does not adequately capture the character and purpose of the route. Richard cycle.travel [1] I believe cycle.travel is the only OSM-based router that includes nodes in its turn-by-turn instructions, e.g. https://cycle.travel/map?from=51.0623,2.8582=51.0913,2.8531 . cycle.travel also has a few localised rules for rendering in the Netherlands and Belgium to cope with the sheer density of the node network. -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Multiple tags for one purpose
Valor Naram wrote: > some long time ago I wondered why we have two tags for one > purpose sometimes? For example: A mapper can use either the > tag `contact:phone`or `phone` to add a phone number to the > database. I think this makes the database dirty and for > developers - like me - it's annoying to support two or more tags > for one purpose. As an annoyance in consuming OSM data, I find this ranks about #936 on the list tbh. If you really want to spend your life going through the bulk edit process 500 times then knock yourself out, but the effect it'll have is minimal. Developers have to cope with synonyms anyway, because mappers express nuance with new values, but most data consumers aren't interested in the nuance. (For example, in cycle.travel, I treat access values of =yes, =designated, =official, =permissive the same.) If you want to make it easier for developers to consume OSM tags, the best way would be to write and curate documentation covering the 90% cases, ideally using a github-like PR model that's resistant to getting sidetracked by the 10% (the OSM wiki problem). The second best way would be to code libraries in common scripting languages (maybe drawing on common data tables) that make parsing OSM tags easier. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)
Kevin Kenny wrote: > There's also something to be said for using the ugly editors to > prove the concept, because at this point, we don't yet know how > to do everything, much less how to make it novice-friendly! The > exception is simple linear routes, and Sarah or I can give you > algorithms - or at least heuristics - for maintaining sort order > on those. I have an algorithm like that too - it skeletonises dual carriageways and roundabouts, hops over small jumps, and so on. But that's very different from the steps to implement in an online editor, which has many more constraints. (P2 doesn't have access to the full set of JTS/PostGIS tools, for example!) _If_ the issues can be identified clearly and the realistic steps to fix them enumerated, then we're getting somewhere. > I do want editors minimally to observe the 'don't break the route' > principle. About 80% of the broken-route problem can be solved > simply by, "when splitting a way, both the pieces become members > of any route relations in which the original way appeared, with the > same role if one is specified, preferably preserving continuity if > either or both endpoints was shared with the neighbouring way > in the relation." At least iD, Meerkartor and JOSM all do that. As does P2, I believe (I didn't write that bit of code) - iD's code might actually be based on P2's. That does make me wonder how much of a problem this is in reality if the four major desktop editors already support it. > For what it's worth, I think that the "route editing is complex" > problem partly drives the 'startled warthog' and '1980s throwback' > issues. In my experience, newer and prettier UI's try so very hard > to be pretty and novice-friendly that in many cases, they simply > reach a ceiling of complexity beyond which they can't cope or > become an obstacle to the power user. Generally I tend to think that a data model that can't be edited with a simple UI is a bad data model; and that "power users" are a curse on Wikipedia and rapidly becoming the same in OSM, especially when their main role is to generate abstruse content as self-gratification but which no-one will ever actually consume. But that's just me being a grumpy old man too. :) cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Branched and alternative roujtes
My use-case for cycle.travel is having a single polyline that I can make into a route guide at https://cycle.travel/routes . Currently there’s two dozen: I’d like there to be thousands. So: > - diversions and alternatives Give them consistent roles so I can ignore them. > - routes with different endpoints in the forward/backward directions Not fussed. I only do the route in one direction. > - spur routes Again, consistent roles so I can filter them out. > - one-way routes that may be circular If there’s an agreed start point, then put the node in the relation with an appropriate role. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)
On mobile, on train, apologies for lack of formatting. :) Sarah - the problem is that when you say “one single simple instruction to the mapper: sort your route“, the instruction might be simple but carrying it out isn’t. Let’s say we have a cyclist, new to OSM, who wants to add a newly opened section to an existing route. As Peter says, doing this to said specification “usually requires lots of JOSM”. The steps involved to do this in sorted order are: 1. spend half the afternoon trudging through contradictory pages on the OSM wiki to find out what you have to do 2. apparently it involves this thing called “JOSM”. Download that 3. apparently that involves this thing called “Java”. Download that too 4. learn to use this 80s throwback of a GIS program with the UI of a startled warthog 5. find route sorting stuff in JOSM somewhere 6. make edit 7. get shouted at by sociopaths in changeset comments because unwittingly you did something wrong (I have elided most of the intermediate steps.) That isn’t how OSM works. It might be how Wikipedia works but we are better than that. _If_ route ordering is to be expected, then the burden needs to be on the editing software, not the mapper. That means invisible support in iD, P2, and I’m guessing Vespucci and Go Map (I don’t know what their current support is like). And tbh the burden of providing patches is on the few people who are asking for it. Certainly I’m happy to implement something in P2 if it’s an afternoon’s work and I’m given a fully fleshed out algorithm which copes with the partly loaded relations that are standard for an online editor, but I’m not going to spend two days of dev time on something for which there is no great clamour outwith a couple of people on the tagging list. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] roads with many names
Rob Savoye wrote: > Where I live in rural Colorado, many of the roads have 3 names. > The county designated one like "CR 2", but often have an alternate > name everyone uses like "Corkscrew Gulch Road", and then many > have a US Forest Service designation like "FS 729.2B". name=Corkscrew Gulch Road ref=CR 2 usfs:ref=FS 729.2B I think this holds even if the "county-designated name" is CR 2. The "name everyone uses" tallies with OSM standard practice; the official reference is what we have the ref tag for. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)
Sarah Hoffman wrote: > On Sat, Aug 17, 2019 at 01:11:17AM -0700, Richard Fairhurst wrote: > > Peter Elderson wrote: > > > The point is, as it is it's not good enough for data use besides > > > rendering. you can't rely on route relations for anything but > rendering > > > > Once again: pretty much every OSM-based bike router uses route relations > to > > influence routing. (That might give you a clue to one of the > strategies.) > > But this is a task which is essentially the same rendering. I was addressing Peter's point that route relations can only be used for rendering, which is demonstrably false - they're used for influencing weighting in routing. > The problems come in if you want to go the other way. When you start with > the relation, want to determine where the route goes along. That > information > is simply not contained in the route relations as long as you don't impose > a > couple of restrictions. [...] > I consider sorting and the use of roles essential for that. I'd fully agree on roles. The use of 'alternate' and 'forward'/'reverse' roles for bike route relations dates back to the earliest days of bike route mapping in OSM and is well established by now. But just as long established in OSM is the principle that - since mappers are our most precious resource - we optimise for the mapper, not for ease of consumption. Allowing relations to be unsorted is an example of that. If a relation represents a linear route, it's a SMOP to put the ways in the right order. There are two obvious strategies. 1 is: create an empty polyline P with endpoints P1 and P2; iterate through the relation members; every time you encounter a way with an endpoint P1 or P2, add it to the polyline (potentially in reverse order) and remove it from consideration; repeat until there are no ways left. This is broadly the approach I've used until now. 2 is more involved but more fault-tolerant and flexible; create a routing graph, then route from the relation's startpoint to its endpoint using a very heavy uplift for members of this relation. This is a useful approach where the route actually _is_ non-contiguous but you nonetheless want to include connecting routes between the sections. (Quite a lot of American rail-trails are like this, as are several UK National Cycle Network routes.) This is an approach I'm investigating at present. Approach 1 does of course fail if the relation doesn't represent a single linear route. That would, however, still be true if the route was ordered. There's probably a little more that editing software can do here, but unless you want to require people to have 12 months of OSM experience before they can map a change to their local cycle route, ultimately the solution is to have better QA tools. Something like OSM Relation Analyser is faultless algorithmically but the UI is less than immediate. If we were to have an OSM Inspector-like view of lacunae, spurs and other relation issues, it would be a whole lot easier to fix them. I occasionally wonder about coding this but I'd love it if someone were to beat me to it. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)
Peter Elderson wrote: > I would like to see this software in operation! Could you give me the > links of some applications I use my code in the backend of cycle.travel. It's not open source. I've seen code used by one other OSM-based site and there's a further one that's clearly using something similar. There are at least two really obvious strategies for dealing with relations like this. > The point is, as it is it's not good enough for data use besides > rendering. you can't rely on route relations for anything but rendering Once again: pretty much every OSM-based bike router uses route relations to influence routing. (That might give you a clue to one of the strategies.) Again I ask: perhaps you could clarify what your experience is in consuming OSM data? Have you written code to do so? Do you run a website that uses OSM? Because you're making some very confident pronouncements about "you can't fix that with software", "impossible", "a lot of work for data users", "no software can handle ", "the only way to get reasonable outcome" etc. etc. that don't accord at all with my experience. Yet you've been a mapper for under two years and don't appear to have any software development to your name at all. But I might be missing something. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)
Peter Elderson wrote: > I think it's fair to say there is almost no software that does > anything with route relations except rendering and exporting > as a gpx. That's not true. Most bike routers based on OSM are aware of route relations and use them to influence routing. > Software needs a sorted or easily sortable relation. Currently, > no software can handle sorting when the routes get broken. That's not true either. I have software right here that reorders unsorted relations, as well as skeletonising dual carriageways into single lines, jumping over roundabouts and coping with other such issues. I know of two other sites operating similar software and I'm sure there are more. There are certainly issues with consuming route relations but sorting is not, in my pretty extensive experience, one of them. Peter, perhaps you could clarify what your experience is in consuming OSM data? Have you written code to do so? Do you run a website that uses OSM? Richard cycle.travel -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Clashing access tags
Hi all,
Occasionally I encounter tag combinations like this:
bicycle=designated
highway=proposed
(from https://www.openstreetmap.org/way/335831004)
where the "bikes can ride along here" of the first tag is contradicted
by the "this hasn't even been built yet" of the second.
Similarly, on occasion I've found ways which are tagged access=no
("nothing is allowed along here") but are part of a bike route relation
("bikes can ride along here").
To some degree they're similar to "trolltags"
(https://wiki.openstreetmap.org/wiki/Trolltag) - where the meaning of
one tag is "radically changed" by another.
Two questions:
1. Is there any precedent for how to parse these contradictory tags? At
present cycle.travel will assume the most optimistic outcome, which is
good for a cycle route which goes over a private road and the mapper has
forgotten to add bicycle=permissive, but not good for a new cycleway
which hasn't yet been constructed.
2. Can we get warnings about this into validators etc.? I note iD
doesn't warn about it. (No idea what JOSM does.)
cheers
Richard
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] track smoothness/quality
brad wrote: > I see tracktype as redundant with Surface, also very subjective, and > not useful. Smoothness is very useful. smoothness= is a horrible tag, please don't use it. As a data consumer (for cycle.travel), I probably do more detailed parsing of surface and related tags than any other consumer, and smoothness= is almost always misleading and ambiguous. People use it to record their arbitrary impressions of a path without any reference to an objective scale whatsoever. There is no consensus as to whether the smoothness tags are relative to the tagged/implicit surface or not: is it possible to have smoothness=excellent for an excellently smooth gravel surface? What does smoothness=good, highway=track actually mean? About the only circumstances in which it's useful are to record that a trail is universally impassable. Otherwise it should die in a fire. tracktype= isn't great but it has the advantage that it uses a clearly arbitrary scale, so most people tag by reference to the photos on the wiki rather than just because they think "this is horrible". 80% of the time surface= is all you need. We could do with more and better documented values for it, especially for clarity around gravel. I could see some virtue in another tag to be used _only_ when surface= is also present, documenting how well the surface is maintained, so that you could differentiate between (say) potholey, broken-up asphalt and immaculately maintained asphalt. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Incorrectly tagging locks on rivers as canals
Volker Schmidt wrote: > Going back to the original example, I would say, not only the lock but > the entire cut, in particular way > https://www.openstreetmap.org/way/24335 > should be tagged as waterway=canal. This scheme applies to most river-lock > arrangements, the "cuts" are nearly almost artificial canals. Yes. There's a very big difference from a boating point of view. Taking my home river as an example, the River Severn, a lock cut such as the one upstream of Holt Lock makes the approach very easy: https://www.openstreetmap.org/#map=17/52.26849/-2.26653 Boating on this is exactly like boating on a canal. There is no discernible current and you can simply hover in midchannel while the lock is prepared for you (all locks on the Severn are keeper-operated). Compare this to Gloucester Lock: https://www.openstreetmap.org/#map=18/51.86538/-2.25197 Here there is no canal approach from upstream - you're straight off the river into the lock. If you try to hover in midchannel then you will get swept over Llanthony Weir and River Canal Rescue will have to come and Tirfor your boat off, which happens two or three times a year to the great embarrassment of the boat-owner. Consequently you are asked to phone the lock-keeper in advance so that he can prepare the lock for you and you can motor straight in. There are lots of warnings about this both off and online, and rightly so (https://canalrivertrust.org.uk/refresh/media/thumbnail/27339-new-river-severn-navigation-guide-april-2016.pdf, https://www.canalworld.net/forums/index.php?/topic/95567-ship-lock-gloucester/=comments#comment-2121288, http://www.severn-boating.co.uk/sharp.htm etc.). On some of the larger American river navigations the lock structures are built right within the main river channel - such as this new $3bn (!) lock on the Ohio River: https://en.wikipedia.org/wiki/Olmsted_Locks_and_Dam - so similar caution to Gloucester would apply, particularly in times of high flow. On a major navigation like that you'd be expected to use VHF to keep in contact with the lock-keepers, of course. So there is a very big difference between locks with a canal approach and no canal approach, and that should be reflected in the tagging. Richard (boat-owner, regular contributor and former editor of Waterways World, former editor of British Waterways' website, founder of Melton Mowbray Navigation restoration project yadda yadda yadda) -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Incorrectly tagging locks on rivers as canals
DaveF wrote: > Have these diversions been given a 'XYZ Canal' name? if not then > it's a river. hahahahaha cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Incorrectly tagging locks on rivers as canals
DaveF wrote: > The water flowing through it is still river water. The water flowing down lots of canals is ultimately river water :) - the Llangollen Canal is fed by the River Dee, the Mon & Brec by the Usk, and so on. Generally, where a lock has been built, this is in an artificial cut slightly away from the main flow of the river. This is usually referred to as the "lock cut". In some places this is not that much longer than the lock itself (often the case on the Thames), whereas in others it can be significantly longer (the Aire & Calder/Calder & Hebble). Meanwhile, the main course continues over the weir. As "cut" is usually a synonym for "canal" and they're artificially constructed, it's fairly justifiable to describe a lock cut as waterway=canal, I think. I guess you could put the whole lot in a river navigation relation if that... floats your boat? cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] what is the meaning of bicycle=yes on highway=path
Volker Schmidt wrote: > I presume that your router would fall into the same trap, or does it > evaluate mtb:scale? Of course it does. :) cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] what is the meaning of bicycle=yes on highway=path
Volker Schmidt wrote: > "highway=path" implies "bicycle=yes" (in most jurisdictions) - see the > proposed Default-Access-Restriction for all countries That's not a default that I feel enormously comfortable with. Whatever the wiki might say, "bare" highway=path (no other tags) is often used for little footpaths across city parks, sidewalks, and so on. cycle.travel errs on the side of caution and therefore doesn't route along highway=path unless there's an explicit access tag (or cycle route relation). Keeping bicycle=yes on bikes-allowed paths is useful information. If there's no bicycle= tag, yes, it could mean "bike access is implied by a default somewhere on the wiki" but it could also mean "this way is tagged incompletely". Deleting the tags would remove information and make it harder for routers to deliver real-world routing results. Please keep them. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Intermittently unprotected cycle track
Thanks everyone for the comments! althio wrote: > My preference would be to keep the geometry, map it as a continuous > highway=cycleway. > For the bits without divider, I don't like protected=no however. > I would go with no additional tagging, and more geometry (as you said: > crossings and junctions), and let the geometry speaks. On balance I agree and I'll go for this solution. Please send out a search party if I haven't returned in three days from the maze of nested relations that is cycle routes in East London. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Intermittently unprotected cycle track
Hi all, Let me introduce you to one of London's better cycleways: https://www.openstreetmap.org/#map=19/51.53397/-0.00715 https://cycle.travel/map?lat=51.5254=-0.0335=17 You might look at this and think "that doesn't look like 'better' to me, it's full of 45-degree bends". And based on OSM you would of course be right. In reality it isn't full of 45-degree bends. It's a continuous straight route. But although it's mostly protected (i.e. concrete barrier separating it from the car lanes), the protection gives out at junctions and crossings, so turning traffic can cross. Here's an example (apologies for Google link): https://goo.gl/maps/rFHNHdCxMCp Currently, it's mapped in OSM as a highway=cycleway for the segregated bits, and then it rejoins the highway=primary road (with cycleway=lane) where the barrier gives out. This is correctish in terms of tagging but not in terms of geometry. The current mapping implies 45-degree turns which the cyclist doesn't have to take - they just continue straight on. Breaking geometry to enable tagging is bad in itself, misleading on renderings, and unsurprisingly confuses the heck out of routers. How should we represent this? My gut feeling is that it would be better to map it as a continuous highway=cycleway but with 'protected=no' for the bits where the concrete divider isn't there. Another alternative might include deleting the cycleway completely and just using cycleway=track on the car road, but this seems suboptimal as you can't then easily apply tagging that applies distinctly to the cycleway (surface, route relation membership, etc.) without lots of namespacing. Or we could just go with highway=cycleway and no additional tagging, on the basis that 'unprotected' is implied by the pedestrian-crossing tags and the junction geometry - i.e. obviously there's no protection there because we have a junction which cars can turn across. Any preferences? cheers Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme
Andrew Davidson wrote: As you've actually consumed the data I'm interested to know what problems you have found The bit of my routing profile that parses cycleway tags has a big "Abandon hope all ye who enter here" sign hanging over it and I try not to revisit it too often. ;) cycleway=opposite is one of the most misnamed tags in OSM. It doesn't appear to mean "cycleway", it means bikes can use the road. It doesn't appear to mean "opposite", it means contraflow, i.e. proceed against (motor) traffic. Apart from that, it's brilliant. oneway:bicycle=no is nice and unambiguous. Mapping that onto the scenario where there's a painted lane for contraflow cycling, but not for with-flow, is complex. My preferred accompanying tag would be cycleway:backward=lane, but that's rarely used. as I think that this is one thing that is missing from most tagging debates on this list. It's all very nice to have the world's greatest tagging scheme but it's useless if no one can consume it at the end. Fully agree, and I really do wish people wouldn't try to second-guess what's useful for data consumers. As a recent example I would offer up https://lists.openstreetmap.org/pipermail/tagging/2019-March/043991.html where the second paragraph provoked in me a reaction roughly analogous to https://tenor.com/view/it-crowd-moss-computer-throw-gif-5404468 ... Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Superroutes - good, bad or ugly?
marc marc wrote: > imho nearly no routing tools (nor foot nor bus) is currently > able to use a relation type=route with relations as child. cycle.travel can. I don't particularly care what's decided, but I would like it to be consistent (which right now it certainly isn't), and personally I don't see the need for type=superroute when you can just have relations as children of type=route. I like Sarah's proposal for route_segment=yes. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme
Mateusz Konieczny wrote: > Yes, one of main points of StreetComplete is to allow editing > without knowing how objects are tagged, similarly iD. > > It means that to count "how many people decided to use tag > XYZ" all iD users and all StreetComplete users count as say > 4 people because not each mapper is deciding on its own > but it is decision of whoever makes the software. Oh, come on. Just because iD has an actual user interface doesn't mean that every single iD user is unaware of the tags used. There are plenty of experienced mappers (I'm one) who choose not to use JOSM because they just don't like JOSM, believe it or not! On topic: I don't have a great preference for either tagging scheme (they're both a bit ungainly, I've found them both a bit of a PITA to support in cycle.travel's tag parsing). cycleway=opposite_lane is concise but unclear. Regardless, both are in widespread use so the wiki should document both. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging professional cycling competitions as route=bicycle?
They don’t belong in OSM for the reasons you state, and would be better hosted independently on umap or similar. But in any case, they absolutely should not be tagged route=bicycle, as routers and renderers use this as a signifier that “this road/path is particularly suitable for cycling”. Professional bike races take place on closed roads, sometimes even trunk roads/motorways, and certainly not just those identified as bike-friendly. If these routes are to stay in OSM (which they shouldn’t) then they should be route=bicycle_race or similar. cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarification unclassified vs residential
Florian Lohoff wrote: > From the original meaning unclassified was the lowest class road > in rural or off city limits. residential was the lowest class road > within city limits. (Assuming that city limits mean residential > usage) That's reasonable but not _quite_ true. highway=unclassified is often used in urban areas to denote a minor distributor road. https://www.openstreetmap.org/way/145016745 is a good example (https://goo.gl/maps/YUc6XfuA5wQ2 if you'll excuse the Google Street View link). It's the distributor road for that estate, and of greater importance than the largely cul-de-sac residential roads going off it; but doesn't have a significant through-traffic purpose nor the engineering standards that would imply highway=tertiary. > [...] > From OSRM profiles it isnt - So it doesnt make a difference for at > least OSRM. OSRM's default profiles don't measure importance, only speed, and are fairly blunt instruments which aren't used unmodified by anyone who's serious about quality routing results. (Mapbox, OSRM's sponsors, override them with traffic speed data, for example.) I wouldn't count them as a useful indicator. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarification unclassified vs residential
Greg Troxel wrote: > Finally, I'd suggest in the US treating unclassified and residential > as exactly the same in importance, because we have no real notion > of unclassified roads like the UK. There is one de facto difference in the US, which is that highway=unclassified means that someone has made the active decision to tag the road that way, whereas highway=residential (numerically) probably just means "this was class A41 in TIGER". Therefore it's fair to assume that highway=unclassified in the US has a similar meaning to elsewhere in the developed world - a minor road which is not a significant through traffic artery, and which is paved unless otherwise stated (by a surface= tag). highway=residential in rural areas of the US, however, could mean anything from a drainage ditch via a faint outline of a path to a three-lane tertiary that hasn't been retagged yet. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rivers intermittently navigable
Fernando Trebien wrote: > motorboat:conditional only works if the periods where the river > is navigable are predictable, and that usually depends on the > variable amount of rain on the basin. motorboat= is an access tag, so it represents whether a use class is permitted on that way, not whether it's possible. I'd think a variant on depth= would be most appropriate. Something like depth:summer=0.5-3.0 might indicate that the river depth in summer can typically vary between 0.5m (i.e. only a canoe at a pinch) and 3m. Defining "typically" is left as an exercise to the reader. :) Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Digest, Vol 113, Issue 52 Co-ordinate sets vs. background informations = ODbL vs. CC
Sergio Manzi wrote: > I strongly dissent with the tone of your mail. > Everybody, not only you and the most vocifeferous ones, have the right to > express > their opinion. They do, but if the opinion is off-topic and unconstructive for the list and likely to divert from the purpose of said list, then the list admins/moderators are within their rights to ask the thread to stop, and that's what I'm doing here. Ulrich, your comments are seriously off-topic for the tagging@ list. If you would like to continue the argument then I would suggest you use the talk@ list. It won't get you anywhere, but who am I to tell someone not to bang their head repeatedly against a wall. If you do so, please learn to participate in a threaded discussion, either by replying to individual messages (not digests) or by using a web interface like Nabble that permits you to do so. Thank you. Richard tagging@ list admin -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)
Axelos wrote: > ID is not suitable for this type of contribution (relations), he knows > how to do it, but in a superficial and irrelevant way. > It's not up to OSM to adapt to ID, but the opposite. Since it is not > up to OSM to adapt to opencyclemap but the opposite (ref = icn). > Potlach 2 in 2019 is a joke! It is an outdated publisher requiring > dangerous technology (Adobe). Maybe don't start editor flamewars on the tagging@ list? Use another list for that please, like, I dunno, dev-null@, or maybe a list which isn't administrated by me and is ideally written in a language I can't read. Thanks. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Vehicle service tags
We don’t call people fools in subject lines on this list. Please check your language before replying. Richard reluctant tagging@ list admin -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)
Peter Elderson wrote: > Sorry, I assumed Potlatch would work approximately similar to Id. If you're addressing a mailing list with 551 subscribers, could I suggest you take a few minutes to actually research your statements before posting? > Can it easily sort/reverse ways within relations, move elements > between relations, create and manipulate superroutes, and keep > all the routes (hiking, cycling, PT) happy when removing/splitting/ > extending ways? Potlatch 2 can create and edit relations of any type and with any members permitted by the OSM API. You now appear to have changed from "Can't be done" to "Can it easily", which is a different, subjective question and frankly not one I can be bothered to answer. Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)
Peter Elderson wrote: > I just did some work on a hierarchy of hiking routes. Can't be done with > Id or Potlatch What specifically can't be done in P2? Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)
Axelos wrote: > Hello, I propose a concept for contributing cycling route. Many thanks for looking at this - the current state of bike route hierarchies is a mess, and trying to parse the many different tagging practices so that cycle.travel can display them properly has been a nightmare. It would be good to have a commonly agreed, intuitive standard. From the description on the wiki page, I'm not sure how your proposal differs from the practice documented at https://cycling.waymarkedtrails.org/help/rendering/hierarchies . Could you explain the difference? A few passing comments: > Example name = Boucle de la Moselle: Toul - Pompey Please don't do this - the name tag is for an object's commonly agreed name, and "Boucle de la Moselle: Toul - Pompey" is not the official name of any part of the route. You could perhaps use the description= or note= tag instead. There are lots of examples of this in your proposal: "name=PAN Segment 1", "name=Véloroute 50 : Étapes", and so on. (Similarly, some people have tagged sections of EuroVelo routes in one country with the network=ncn tag. This is wrong: EuroVelo routes aren't National, they're International. I think this is probably a mistaken attempt to get them to render on OpenCycleMap.) > To do this effectively, you will need a powerful editor: JOSM. This is a "tagging smell" (cf https://en.wikipedia.org/wiki/Code_smell). Any tagging scheme that requires a particular editor is probably a bad scheme. As it happens, you can certainly edit relations like this with Potlatch 2 no problem and I guess you can with iD too; but before any tagging scheme like this is adopted, you should create a tutorial for iD users. It shouldn't be necessary to learn a whole new editor just to be able to tag a bike route - as you yourself say, "Is the hierarchy of cycle routes reserved for experts?". Bear in mind too that iD users _will_ edit these routes, so the scheme should be intuitive and robust (of course, that should be the case anyway!). cheers Richard -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] EuroVelo tagging
Volker Schmidt wrote: As EV routes are not managed as single entities, every route is split in pieces managed on a country basis. I know the situation in Italy, as I am involved in regional and national cycle routes here. EV routes are handled by BicItalia which is part of FIAB, the "Italian Federation of Friends of the Bicycle". All EV routes all have also BicItalia numbering (BicItalia routes are ncn), but it is not necessarily the case that the Italian part of a given EV corresponds one-to-one to a BicItalia route. So it makes sense to tag the individual EV routes in one country as one icn and to tie these icn routes in the different countries together by a super relation. This means that any BI route that is also part of an EV is part of at least to bicycle route relations (it typically is also part of lower level routes. and Warin wrote: My thoughts on the EV ... following my thinking on the above are; Have 2 relations ... on on the EV, the other on the other entity (e.g. BicItalia). Agreed - I think this is the most sensible approach and it accords with most current practice. I'll add some text to the EuroVelo wiki page accordingly. Jo wrote: It ought to be possible to use hierarchy in those relations. That way you would map them at the national level and group them for the international level. It's a seductive idea, but the problem with this is that the routes aren't always strictly hierarchical. For example, EuroVelo 1 in Britain uses parts of NCN 7 and NCN 73, but not all of them. So to do a hierarchical approach you would need "NCN 7 part one" in "EV 1 super-relation" and "NCN 7 super-relation", "NCN 7 part two" in "NCN 7 super-relation" only, and so on. This could get very complex very quickly - some parts of NCN 27 are in EV 1, some are in the Tour de Manche Anglo-French route, some are in the Dartmoor Way: the 90-mile route would need to be split at least four ways. I suspect it'd become exceptionally fragile and liable to be broken, and my main concern with getting the EuroVelo tagging confirmed is to make sure that there's an unambiguous reference so well-meaning newbies are less likely to break it. cheers Richard (apologies for broken threading, tagging@ has disappeared from Nabble) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] EuroVelo tagging
Europe has numerous international cycle routes signposted and marketed as 'EuroVelo', and these are often mapped in OSM: http://www.eurovelo.com/ Unfortunately the tagging is pretty inconsistent, especially when routes are shared with national/regional (NCN/RCN) routes, as is usually the case. Although a relation with 'network=icn' is the convention for international cycling routes, people do sometimes change this to 'network=ncn' and 'ref=EV<...>' for tagging-for-the-renderer reasons. The result is that we have messy and inconsistent tagging. At present the wiki project page doesn't have any tagging guidance: https://wiki.openstreetmap.org/wiki/WikiProject_Europe/EuroVelo I would like to suggest that we formalise existing good practice by saying that roads/paths on a EuroVelo route should directly be part of a route relation. That relation should be tagged: route=bicycle network=icn ref=11 [or whatever the EuroVelo route number is] Grouping several route relations together in a 'master relation' is all good (as these routes are often too long for one manageable relation), as is operator/brand tagging to indicate that this is EuroVelo in particular. But I'd like to document the above as the minimum, simplest thing. It seems to be generally accepted and is in line with NCN/RCN tagging. Thoughts? cheers Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] using Michelin's road classification (was: Routing in Liège)
André Pirard wrote: > Last point is what source:???=Michelin ??? to use to prevent a > StijnRR or like arbitrarily destructing well thought out tagging > without notifying the author. I suggest > source:highway=https://viamichelin.be/web/Cartes-plans 2016 2016. No, you must not copy from copyrighted maps, which includes Michelin's. Please confirm that you have not added, and are not going to add, any data (including classification judgements) from Michelin maps, otherwise I guess we'll have to ask the Data Working Group to suspend your OSM account and revert your edits. Richard -- View this message in context: http://gis.19327.n5.nabble.com/using-Michelin-s-road-classification-was-Routing-in-Liege-tp5882709p5882854.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Michelin info
André Pirard wrote: > Reply to this message privately to receive info about how to easily > compare OSM with the Via Michelin map using JOSM. Um, I'm not 100% sure what you're proposing here, but please remember that we must not copy any information from copyrighted maps into OSM. Richard reluctant tagging@ list admin -- View this message in context: http://gis.19327.n5.nabble.com/Michelin-info-tp5882710p5882741.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Typo fix for tunnel=building_passage and how to proceed in the future
LeTopographeFou wrote: > But do I have to ask for a vote/discussion for automated typo edits? Very expressly no. There is no precedent for voting on automated edits, and on the rare occasions it has been suggested then there has been significant and well-founded opposition to the idea. From the Automated Edits Code of Conduct: "We do not require or recommend a formal vote, but if there is significant objection to your plan - and even minorities may be significant! - then change it or drop it altogether." In this case you're changing, I think, just 22 objects in total for things that can't be interpreted as anything but typos. I suggest you just go ahead and do it. :) Richard -- View this message in context: http://gis.19327.n5.nabble.com/Typo-fix-for-tunnel-building-passage-and-how-to-proceed-in-the-future-tp5882268p5882288.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: How to tag: public lands that are accessed by permit?
Kevin Kenny wrote: > I just want to be able to look at my map and answer the > quick question, "is there red tape that I have to plan for > before I plan a trip here?" Yep. I asked a similar question at https://lists.openstreetmap.org/pipermail/tagging/2016-February/028504.html but there was no particular consensus. access=permit seems to have moderate usage (slightly more than =license, which is in any case misspelled) so I'd go for that. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/How-to-tag-public-lands-that-are-accessed-by-permit-tp5878730p5878819.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations in Transport for London: network and operator
Bjoern Hassler wrote: > Second question: network. The wiki page > http://wiki.openstreetmap.org/wiki/London_public_transport_tagging_scheme > doesn't say much about "network", and these values are in use: > > - London Underground > - National Rail > - Network Rail > - London Overground > - TfL > - District and Hammersmith & City Lines > > I would propose to retain the first four Network Rail isn't a network, it's the company (FSVO company) that owns and operates Britain's rail infrastructure. Anything tagged network=Network Rail should probably be network=National Rail. There is a slight factual impropriety as London Overground is properly part of the National Rail network; it's little different to a strongly branded PTE-run franchise like Merseyrail. But how you resolve this without getting ridiculously trainspottery I don't know. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Relations-in-Transport-for-London-network-and-operator-tp5878259p5878280.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path
John Willis wrote: > I am really having trouble understanding the reasoning behind the > resistance when it removes uncertainty and confusion while tagging. But it doesn't. You're citing your own personal hierarchy between "trails" and "easily traversed footways", which is fine. But that hierarchy is not ringing any bells with me. I honestly have no idea how any of the paths around here would be classified on such a hierarchy. We have thousands of miles of paths which are walkable as of legal right, of every quality from wide tarmac to barely discernible routes across ploughed fields, but we don't have any concept of "trails" here[1] - it's largely an American/Australasian English usage. highway=motorway/trunk/primary/etc. works when a firm, easily understood hierarchy can be established based on that road's importance in the connected network. It falls down when that hierarchy is less clear-cut, and it's very notable that road tagging is quite uniform and uncontested in some countries (e.g. the UK) where there's a clear mapping between tag values and observable characteristics, and less uniform in others (e.g. the US) where that mapping is fuzzier. For your idea of increasing the highway= options available to path mappers, such a hierarchy would need to be apparent on the paths in most countries, and to be documentable as such in a reasonably internationally consistent manner. I haven't yet seen any case made that it is, and I doubt that it could be. Richard [1] other than the very few long-distance routes known as National Trails -- View this message in context: http://gis.19327.n5.nabble.com/Subject-Feature-Proposal-RFC-highway-social-path-tp5870639p5875594.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Suggested way to map disputed country borders
Rory McCann wrote: > Both of the example maps of Russia/Ukraine and India/Pakistan > require the use of another data set. Which is a shame. One should > be able to generate that from OSM entirely. Why? OSM's selling point is not "all geodata, ever, in one place". OSM's selling point is personally researched data that reflects reality. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Suggested-way-to-map-disputed-country-borders-tp5873085p5873781.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Education 2.0
Шишкин Александр (Shishkin Aleksandr) wrote: > IMHO, it is much better to have alternative advanced tagging > system from which data users can benefit much (e.g. search > by school's speciality). As a general point, could I please encourage people not to second-guess what data users might "benefit much" from, unless they themselves are those data users. It was that sort of thinking that brought us highway=path. "It will make things easier for data users," they said. It didn't. It made it worse. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Feature-Proposal-RFC-Education-2-0-tp5871664p5871916.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path
Alan McConchie wrote:
> Some commenters have suggested using the existing highway=path tag,
> with supplemental tags such as access=no or informal=yes, or a new
> supplemental tag path=social_trail, or adding an operator tag. However,
> these supplemental tags are too easily ignored by data consumers and
> renderers, which is problematic given the destructive and hazardous
> nature of social trails in many areas.
First, big thanks for bringing this to the list.
I do think, however, you are mistaken with the above rationale, which
appears to be the sole rationale for the proposal.
access=no is absolutely a core tag within OSM, dating back to the very first
iteration of Map Features. It isn't "easily ignored". Any router which
ignores it is unambiguously bugged. Any renderer intended for walkers'
consumption which shows it as a walkable path is unambiguously bugged.
It is not, however, documented or safe to assume that renderers and routers
will always fall back to "no". There have been renderers which will render
the name for an unknown highway value, so 'highway=social_path;
name=Shortcut' would show on the map as a label saying 'Shortcut'. There are
routers which will assume a default speed for unknown highway values. That
isn't always daft: you can envisage a single typo in one two-node way
('highway=mptorway, maxspeed=70mph, surface=paved, access=yes...') which
would otherwise break routing across a continent if the router was entirely
fault-intolerant.
To widen the discussion, introducing new core path values is bad OSM
citizenship.
Path tagging in OSM is notoriously complex, for one reason: people keep
reworking the core model to deal with their edge-cases.
We began with highway=footway/bridleway/cycleway/track, surface=*, and
access/foot/bicycle/horse/motor_vehicle=*. With these values, you can model
the essential characteristic of 95% of paths (conservative estimate).
Some people identified edge cases which they felt were not adequately
captured by this scheme, and therefore introduced a new, more complex
scheme, highway=path.
Later, others identified still further edge cases and introduced yet more
values: access/foot/bicycle/etc.=designated. Later later, others identified
still further edge cases, and we got access/foot/bicycle/etc.=official.
And so on. Every such change has made the system more impenetrable for
mappers and consumers, and we have, I believe, a collective responsibility
to keep OSM usable. I won't bore you with the details of the Lua tag parsers
I use for cycle.travel's path routing and rendering, but they are insanely
complex - hashes upon hashes upon hashes, special cases upon special cases -
and yet there are still bugs and edge cases. How anyone who doesn't have
years of experience in OSM is meant to cope with this, I don't know.
The best way to map these, without adding further burdens to mappers or
consumers, is to use broad-brush, well-established tags such as:
highway=footway
access=no
and then, if you feel this doesn't fully capture your particular edge case,
some sort of _additional_ tag:
social_path=yes
(The classic example of this is motorroad=yes, which the German community
introduced as a refinement on highway=trunk/primary, and which has since
become a successful and widely-adopted tag without breaking highway routing
or rendering.)
But please don't extend existing core tagging, such as highway=, in new and
exciting ways. It doesn't necessarily solve the problem in the way you think
it will, and it makes it harder for everyone to use OSM.
cheers
Richard
--
View this message in context:
http://gis.19327.n5.nabble.com/Subject-Feature-Proposal-RFC-highway-social-path-tp5870639p5870698.html
Sent from the Tagging mailing list archive at Nabble.com.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] importance=* tag (for transportation etc)
Andy Mabbett wrote: > It's nowhere near as ridiculous as trying to render them according > to some arbitrary and subjective "importance" (Importance to > whom? The people who live near them? Tourists? Mountaineers? > Ornithologists? Aviators? Geologists? Climatologists? Oil > prospectors?). Exactly. Here's an example: https://en.wikipedia.org/wiki/Sg%C3%B9rr_Dearg This is the notorious "Inaccessible Pinnacle". If you're a mountaineer, specifically a Munro bagger, it's a highly significant peak: it's the hardest Munro (Scottish peak over 3000ft) to get. If you're a tourist looking for pretty mountains, though, it's probably not significant; it's just, well, a bit of rock. Wider cultural significance? I couldn't tell you. Somewhere between the two: certainly less than Ben Nevis, but how do you decide the "importance" of the hardest peak to climb in Scotland which just happens to be an anonymous lump of rock? Importance means value judgements. One of the reasons OSM is so successful is that our data doesn't make value judgements. This allows people to make their own maps with their own value judgements. This is why OSM has become, from nowhere, the world's pre-eminent geodata source for walking and cycling - because every other dataset is car-biased. Let's not close off future uses of OSM by imposing centralised value judgements on its data. John Willis wrote: > Trying to decide what mountains are worth labeling at different zooms > via some GIS data is ridiculous. It's only ridiculous, to be blunt, if you're no good at GIS. I show identically-tagged pubs at different zoom levels on cycle.travel based on my own criteria, not some importance scale that someone else has decreed. It takes me about three lines of PostGIS and two lines of CartoCSS. It isn't hard at all. Richard -- View this message in context: http://gis.19327.n5.nabble.com/importance-tag-for-transportation-etc-tp5870183p5870224.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=marine RFC
dieterdreist wrote: > Maybe shop=sailing_supplies? Or ship_supplies? Some of us have boats (not ships) with engines (not sails). :) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/shop-marine-RFC-tp5869777p5869896.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=marine RFC
Richard Z. wrote: > this meaning is not even in wiktionary. How many of those shops > would even know they are called chandler? All of them, in my (fairly extensive) experience. http://reader.waterwaysworld.com/fullsearch.cgi?q=chandlery Richard -- View this message in context: http://gis.19327.n5.nabble.com/shop-marine-RFC-tp5869777p5869814.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Path with permit required for bikes?
Hi all, An important part of the Pacific Coast Bicycle Route now requires cyclists to get a permit: http://www.examiner.com/article/cycling-through-camp-pendleton-is-changing https://mccscp.wufoo.com/forms/camp-pendleton-bike-route-access-form/ How should this be tagged? It's not quite 'bicycle=permissive' - that's generally used to imply that bikes are allowed in by goodwill of the landowner but don't have to book, whereas in this case a permit has to be expressly applied for. Some possibilities: reservation:bicycle=required bicycle=permit bicycle=license [little used, but see http://wiki.openstreetmap.org/wiki/Tag:access%3Dlicense] (Incidentally, =license should of course be =licence, because the lingua franca of OSM is British English. ;) ) cheers Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Formalising shoulder tagging
dieterdreist wrote: > yes, Standstreifen, Standspur, Seitenstreifen, Randstreifen. I've > improved the proposal to make this clearer for non-native people > (added a definition (from WP), added more German synonyms, > images) Thanks to everyone who contributed. I've accordingly formalised the page and moved it to http://wiki.openstreetmap.org/wiki/Key:shoulder . cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Formalising-shoulder-tagging-tp5865799p5866229.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Discussion about Multivalued Keys
Matthijs Melissen wrote: > Take for example your example shop=supermarket, > shop=bakery. Independent of the exact way of tagging, > using a multivalued tagging scheme forces the renderer > to make a decision between a supermarket and a bakery > icon. Basically, there is no possible way for the renderer > to support a multi-valued key here! That's not at all true. A rendering chain can choose to split out multiple values and then render a different icon for each one. You don't even need any preprocessing - you can do it on-the-fly with a SQL query, and I've done exactly that in one (Mapnik-based) map I've produced. I realise _openstreetmap-carto_ doesn't do that, but osm-carto takes a very conservative approach of not doing much additional processing to the data. I can understand that approach, but that doesn't mean "there is no possible way" for anyone else to do it. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-Remove-name-1-and-alt-name-1-from-wiki-tp5865654p5865995.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Discussion about Multivalued Keys
Matthijs Melissen wrote: > Do you have an demo rendering (screenshot is fine) for that? There's actually a couple of ways you can do it, but http://crt.systemed.net/ uses one method - look for the brown service icons which are next to each other. It's not OSM data in this case (it's the Canal & River Trust's GIS data), but it is Mapnik and the principle is equivalent: pulling multiple values from a single text field. There are a couple of reasons I wouldn't recommend it for osm-carto, but maybe in a couple of years we'll all have moved to GL-based rendering and the styling decisions will be different. ;) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-Remove-name-1-and-alt-name-1-from-wiki-tp5865654p5866011.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Discussion about Multivalued Keys
Colin Smale wrote: > If we were looking at this problem as if we were > designing OSM on a clean whiteboard When OSM was first designed on a clean whiteboard[1], multiple values were in fact possible. An object could have name=Bridge Street name=Banbury Road and the API was happy - though, in practice, no (/very little) software supported it. This ability was only removed in API 0.6: https://lists.openstreetmap.org/pipermail/talk/2009-January/033437.html Richard [1] beer mat -- View this message in context: http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-Remove-name-1-and-alt-name-1-from-wiki-tp5865654p5866023.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Formalising shoulder tagging
Hi all, At present there is no documented standard for tagging highway shoulders. We have http://wiki.openstreetmap.org/wiki/Shoulder with shoulder=yes|no, which has been in 'draft (under way)' since 2010. In Australia, cycleway=shoulder appears also to be used. Taginfo stats are: shoulder = *7120, of which: shoulder = no 3230 shoulder = yes 2743 shoulder = right964 shoulder:width = * 1794 shoulder:right = * 1047 width:shoulder = * 843 cycleway = shoulder 502 There are several gazillion miles (approximate value) of roads with shoulders around the world. We should have a way to tag them. I'd therefore suggest simply formalising the most popular existing usage and the one on the wiki page - that is, shoulder=yes|no. As a default, I'd suggest shoulder=yes is presumed as the most common real-world situation, i.e.: "A paved shoulder, wide enough to be used as an emergency refuge for cars, and for through passage by bicycles." (Narrow shoulders can of course be tagged with shoulder:width, gravel ones by shoulder:surface, and so on.) There are of course many refinements one could imagine, for peak-hour shoulder running, buses, etc. But since "the perfect is the enemy of the good" etc., I'd like to get the basic shoulder=yes|no agreed first. Speak now or forever hold your peace! cheers Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
Kieron Thwaites wrote: > Whichever iD developer thought that adding random _N suffixes was > a good idea deserves to be taken out back and shot. Please withdraw that comment. Advocating violence to people is not funny. You might want to say a _feature_ should be taken outside and shot, but don't extrapolate it to a person. Being abusive to developers is not funny either. OpenStreetMap is unlikely to prosper in an environment where the (precious few) developers can expect to be abused on any random mailing list or issue tracker. Thank you. Richard tagging@ list admin -- View this message in context: http://gis.19327.n5.nabble.com/Please-don-t-think-name-1-tags-are-errors-tp5864875p5864887.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway = track vs. residential
Greg Troxel wrote: > I more or less agree, from the US point of view, except that > highway=residential has a meaning of something that is > legally a road. highway=residential in the US _largely_ has the meaning "this was imported from TIGER feature code A41 and hasn't been changed". One import - albeit a fairly massive one :) - isn't in itself a reason to strike out on a different way of tagging from the rest of the developed world. > The real bug here is that we need to fix the tagging system to > make clear legal status and type vs. physical condition. The tagging system already does that. You have the access=* tags, operator=* tags, and designation=* tags for the former; and you have surface=*, tracktype=*, lanes=* etc. for the latter. highway=* is a broad overview covering the road's importance - it isn't intended to encapsulate absolutely everything about a road in one magic value. Richard -- View this message in context: http://gis.19327.n5.nabble.com/highway-track-vs-residential-tp5864267p5864408.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway = track vs. residential
Mike Thompson wrote: > Although these are gravel surfaced roads (not yet tagged that way, > but physically that is what they are), the ones in question provide > access to two or more homes and/or ranches. To me these are > not "tracks" but "residential." Before I change these back, I > wanted to check with the community. Generally, in developed countries, highway=residential is predominantly used for public roads in/near nucleated settlements with housing alongside. It's more nuanced than simply "a road with a house on it" - "a road of residential character" would be closer. In the case you've pointed to I would therefore err towards highway=unclassified, surface=gravel (or =unpaved in the case of armchairing when the imagery's unclear). I wouldn't man the barricades against either =residential or =track, but the latter is best reserved for ungraded double-tracks and worse. _However_, I absolutely would man the barricades to advocate surface tags, and I'm really pleased to see you've added one. highway=track isn't ideal for this road, but it's a whole bunch better than highway=residential with no surface tag. There are a couple of places in the rural US (particularly Kansas, occasionally Oregon) where mappers have removed the tiger:reviewed tag on rural dirt/gravel roads without adding a surface tag, at which point the road is indistinguishable from a nice paved street in a housing estate and routing basically goes to s--t. (In retrospect... when the TIGER import was run, we should have imported A41-class roads as highway=residential in urban areas, and highway=road, fixme=yes in rural areas, using urban area polygons to distinguish between the two. But that's all natural=water under the bridge=yes.) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/highway-track-vs-residential-tp5864267p5864323.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway = track vs. residential
dieterdreist wrote: > what's your stance on service? Slightly difficult one, but I'd tend to concur with Florian that it's best used for roads on private property (roughly "access-only"). When I use it I always try and add an access and (if unpaved) surface tag - it's too ambiguous otherwise. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/highway-track-vs-residential-tp5864267p5864342.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Sidewalk Tagging for Routing
John Willis wrote:
> Perhaps we can have a routing engine at will interpret
> a sidewalk with residential road junctions as being
> along a residential road and route for Jay Walking.
> [...]
> I would rather the router always error on the side of
> crosswalks
Jaywalking is a North American concept. Here in the UK you can walk wherever
you like, whether the road is residential, an A (primary/trunk) or B
(secondary) road or whatever - anywhere apart from a motorway or somewhere
else with an explicit prohibition. Please don't suggest that routers should
export this people-hostile custom to other countries!
http://www.vox.com/2015/1/15/7551873/jaywalking-history
Another issue with routing along pavements ("sidewalks") as separate ways is
the name tag. IME pavement-mappers rarely add the street name to the
pavement/sidewalk, but in fact the name applies to the pavement/sidewalk as
much as to the bicycle/car lanes. "Walk along unnamed footway then turn left
onto unnamed footway" is a less helpful direction than "Walk along Broad
Street then turn left onto Cornmarket Street". (The ref, on the other hand,
usually applies only to the bicycle/car lanes.)
Richard
--
View this message in context:
http://gis.19327.n5.nabble.com/Sidewalk-Tagging-for-Routing-tp5860841p5860877.html
Sent from the Tagging mailing list archive at Nabble.com.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] "What can I ask ..." list for browsing people
André Pirard wrote: > Thanks for your guessing what Simon means. Thanks for watching > on us, constable. Please moderate your language. Thank you. Richard tagging@ list admin -- View this message in context: http://gis.19327.n5.nabble.com/What-can-I-ask-list-for-browsing-people-tp5858567p5859943.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
