Re: [Tagging] date not in YYYY-MM.DD format should go into a sufix edtf ?
On 6/5/23 8:12 PM, Minh Nguyen wrote: Having tried to use both formats in both projects, I do think EDTF is the better format overall, and I wouldn't mind seeing it used in OSM. However, the ad-hoc format does have one advantage in being able to express dates in the Julian calendar directly, rather than making mappers perform the conversion themselves. [1] https://github.com/OpenHistoricalMap/issues/issues/547 one of the things i've been contemplating for OHM time format development is a strategy for dealing with Julian dates and potentially non-western dates. but it's a lot and i've been too busy to make any progress on this for a while. the thing to keep in mind is that there is nothing much that processes OSM dates, where as OHM needs to process dates to do the things. this is what drives the differences. richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
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
[Tagging] relation proposals
it's not obvious from reading the wiki where proposals for relations or modifications to existing relations should go. the long stalled proposal for circuits (race courses) is supposedly in the wrong place, but i have no idea what the right place is. i don't plan to try to revive that proposal, but rather i am about to write a proposal for a new subtype of route to serve the same purpose. i'd like to know the right place to put it. thanks, richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging for fairgrounds
On 8/27/20 12:35 PM, Paul Allen wrote: > > As is fair. Without further qualification, I'd interpret "fair" as a > (temporary, mobile) funfair: an annual event with fairground rides, > stalls, etc. I think American usage may tend more towards trade fairs. > > As for mapping the temporary funfair thing, that's difficult, at least > around > here. Every November the town's biggest car park is closed to parking > for a week and is used for several fairground rides and a couple of food > stalls. > As part of the same event, for a couple of days most of the town centre is > closed to traffic and the streets are filled with market stalls selling > all sort > of things of varying quality, from real bargains to absolute garbage (like > eBay made physical). Hard to map. > > There is also an annual agricultural-based show held in some large fields. i'm fine with a british english equivalent if there is one. temporary fairgrounds in the US are things on the order of the world's fairs, which are really international and frequently last for two seasons, the long side of temporary. again in the US, state and county fairgrounds are permanent facilities which function as event space when the fair is not actually going on. the midway is usually temporary, but the buildings for, say, agricultural exhibits are permanent, as is the race track (at many fairs), which might be for horses or cars. all of the following are fair grounds in upstate NY washington county fair grounds: https://www.openstreetmap.org/#map=17/43.09455/-73.54859 rensselaer county fair grounds: https://www.openstreetmap.org/#map=17/42.90539/-73.58926 altamont fairgrounds: https://www.openstreetmap.org/#map=17/42.69712/-74.02660 NY State fairgrounds: https://www.openstreetmap.org/#map=16/43.0749/-76.2197 tagging is wildly inconsistant because there is not clear guidance on these structured fairgrounds in the wiki. and they are all over the US. this is a just a quick sampling. while i recognize that at the present time, OHM concerns are of limited interest here, tagging historic fairs is a use cae for this tagging as well. my map of the 1964-5 NY World's Fair (a work in progress) is a case in point: https://www.openhistoricalmap.org/#map=16/40.7465/-73.8439=O so these things do exist, a fair number of them in the US, and are not really temporary. richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] tagging for fairgrounds
i've had a little discussion of this over on the slack tagging channel. i'm currently working on some historic World's Fair/Exhibition sites, and also have reviewed a number of fair grounds in the US. we really don't have any tagging specific to these sorts of structured park-like areas that have extensive exhibition spaces. park and recreation ground are not quite there. so i'd like to propose one of these two landuse=fairground leisure=fairground i'm ok with either. the idea is that these represent a structured area with pavilions or exhibition spaces, perhaps a midway, and so forth. it would be applicable both to such things as the periodic "World's Fairs" and to the many local fairgrounds (they're all over the US, tied to county and state fairs during the summer.) fairgrounds in the US are currently tagged somewhat erratically as mappers guess at what tags apply. richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ 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
[Tagging] route=raceway?
there is a long stalled proposal for a relation type of circuit for handling motor racing tracks. i suspect it will never be approved, the last time i brought it up there was a general lack of response. but it seems to me that a new relation type is not necessary anyway. probably adding a new subtype to route relations would be more than sufficent: type=route route=raceway this would more than suit my requirements and i have no problem with going through and changing all the circuit relations i've done in OSM to use this tagging scheme. there are some subtags from the circuit proposal that would be useful to carry over for things like start and finish lines. thoughts? richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ 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
On Sun, May 31, 2020 at 09:20:43AM +1000, Graeme Fitzpatrick wrote: > On Sun, 31 May 2020 at 01:18, Tod Fitch wrote: > > > > > > > > On May 30, 2020, at 7:57 AM, Rob Savoye wrote: > > > > > >> Date: Sat, 30 May 2020 15:46:31 +0200 > > >> From: Daniel Westergren > > > > > >> *An additional issue:* > > >> 6. sac_scale is currently the only tag (possibly together with > > mtb:scale) > > >> to denote the difficulty of a hiking trail (that is, the way, not the > > >> route). But it's very geared towards alpine trails and there is not > > enough > > >> nuance in the lowest levels. > > > > > > As a climber, I don't think we'd want to apply YDS to hiking trails. > > > To me, YDS should only used for technical routes requiring equipment > > > (usually). > > > > As a Sierra Club member in Southern California (where the YDS originated > > long before my time), a hiker and a former climber I must mention that 1, > > 2, 3, and 4 on the YDS are basically levels of difficulty in hiking. > > Climbers really only work with 5 and its various subdivisions. Ruling out > > the whole scale simply because one level of it is dedicated to climbing is > > a bit much. > > > > OTOH, the Australians have a bush walking scale that does not, from what > > I’ve seen, include levels for climbing so that might be choice that does > > not automatically connote a different outdoor activity. > > > > So would we try & combine a walking scale & a climbing / alpine scale into > one, or have two scales? > > Two would probably make a lot more sense, with "Walking / Hiking" 1 - 5, > then sac starting at about 4/5. .. and don't forget via ferrata's have their own scale, athough they *should* be using higway=via_ferrata - and climbing routes *should* be using route=climbing > Something else that I've just thought about & not sure whether it would > need to be mentioned - possibility of encountering dangerous wildlife? > > Yes, there are 1000 things in the Australian bush that'll kill you :-), but > none of them will actually eat you! (not even Drop Bears! > https://australianmuseum.net.au/learn/animals/mammals/drop-bear/ :-)) Same > applies to (virtually?) all of Western Europe, but how about North America, > Africa, Asia & so on? Do we have / need a way of tagging that bears (or > whatever) may be encountered while walking in this area? as most of the bears here should have a GPS transmitter there should be a live map displaying areas where they might be encountered (don't think anyone will release their exact position as it might encourage idiots seeking an adrenaline push or poachers). Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Features underwater (inside reservoirs)
On Sat, Jun 06, 2020 at 11:47:23AM +0100, Paul Allen wrote: > On Sat, 6 Jun 2020 at 10:22, Lanxana . wrote: > > > Location=underwater [3] -> it seems that it’s appropriate but the > > description tells “installed between a water surface and the floor > > beneath”, it isn’t the case… > > > But see also https://wiki.openstreetmap.org/wiki/Key:location which does not > say "installed." I suspect that "installed" was used in the page you found > because it was written by somebody who does not have English as a first > language or was written by somebody who was only thinking of man-made > POIs. Or maybe it was written by somebody who didn't like using the > word "located" because it seemed a little repetitious so went with > "installed." the description in Key:location has been there since 2012 while the other page was created 2019.. changed location=underwater. Richard ___ 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
On Fri, Mar 06, 2020 at 10:07:08AM +, John Doe wrote: > > Stereo and I have been working on a schema that makes it easier to create and > maintain public transport route relations. We would like to invite feedback, > questions, and suggestions, so it can mature and hopefully gain widespread > use. > > https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations Very much like the possibility to map routes without specifying every single way segments. One thing that seems hard to deduce is that eg buses take different routing depending on various policies. For example local buses in many places will never enter a freeway because they may have standing passengers which restricts them to a maximum operating speed incompatible with the use of freeways. Some use toll roads preferentially while others avoid them deliberately. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
On Sat, Mar 07, 2020 at 11:29:02AM +0900, Joseph Eisenberg wrote: > I appreciate the proposal authors for helping to simplify mapping bus > routes. > > I agree that in many cases it would be correct to only include the bus > stops or train platforms in the relation, especial for longer-distance > routes, where the bus or train might take several different routes > depending on traffic or other reasons > > However, there are also public transit services where the bus can stop > anywhere along the route. This is the most common type of bus here in > Indonesia. In this case there are no fixed stops except for the 2 end > points, but the minibus follows the same streets and passengers can wave > their hand or request a stop anywhere along the route. > > These routes, common in Asia, Africa and Latin America, should be mapped > just as a set of ways. Some flexibility might be good, like the possibility to specify some "principal" route segments. However I am not sure that it would add anything that can't be done with via points quite easilly. I would hate to get back to the point where every tiny way-piece has to be added to the relation, including segments of roundabouts and nonsense like artificially fixing the route to a particular lane/track if multiple are available just because a way must be selected. Rcihard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
On Fri, Mar 06, 2020 at 04:07:02PM +0100, Peter Elderson wrote: > I wouldn't know. It seems strange to me that established routes have to be > re-routed to display or use them. How can you be sure the re-created route > is the one that is defined by the operator? Keeping as an example the city > PT map. Is the route "defined"? I would think the operator only defines stops and schedules. Most of the time busses and trains tend follow a nearly fixed route but may deviate from it anytime if there is a reason. 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] relation types: circuit proposal and an alternative
On 1/7/20 4:18 PM, marc marc wrote: > Le 07.01.20 à 20:58, Richard Welty a écrit : >> a profound lack of interest >> https://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Circuit > > maybe it's due to the funny url for a propal > moving it at the right place may help so i looked over the general proposal page here https://wiki.openstreetmap.org/wiki/Proposal and there are no actual guidelines about what URL to use, and while the non-relation proposals are generally in one place, the relation proposals are often similar to the one for the circuit relation proposal. on top of that, the "directory" for proposals seems to me to be a poorly maintained mess. i want to enter a proposal for my additional tags for route relations, and i'm happy to move the circuit proposal if i can get some clear direction. my hope would be to get some genuine discussion going about the pros and cons of each, then move one through. i suspect that adding some new tags to the existing route relation will be easier than getting the circuit relation through, but that's just a hunch. richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ 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
[Tagging] relation types: circuit proposal and an alternative
a couple of months ago, i brought up the circuit proposal again, to a profound lack of interest. it is being used, by myself and others, because it does serve a need. as a reminder the original proposal is here: https://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Circuit but in the past couple of days, i've had an idea, and you all know how dangerous that can be. what if, instead of adding this circuit type, we instead recognized that the route relation already exists and the purposes of the rather specialized circuit relation could be handled simply by adding a raceway or race_circuit subtype. additionally, there is a need in OHM that arises for a similar route relation variant type for horse racing tracks, which has to do with temporal tagging of race tracks that have served both purposes in their lifecycles, sometimes but not always at the same time. this seems like a really clean way to get what's needed while sticking with a relation that already exists. the additional tags for things like start line, finish line, etc. would be added much like the specialized tags for outher types of routes. thoughts? richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles
On Sat, Dec 07, 2019 at 12:28:23PM -0500, Jmapb wrote: > On 12/7/2019 11:52 AM, s8evq wrote: > >On Sat, 7 Dec 2019 10:30:37 +1100, Warin <61sundow...@gmail.com> wrote: > >> > >>For nodes .. think the roles of ways should be done first, but some > >>thoughts for later proposal/s. > >> > >>Are they necessary? > >> > >In my limited experience mapping hiking routes, I have not yet come across > >any real use for nodes in hiking relations, but I'm curious if other people > >have good uses. > >As far as I know, there is also not much documented in the wiki on the topic > >of nodes in hiking/cycling relations. > > Possibly for checkpoints? > > https://wiki.openstreetmap.org/wiki/Key:checkpoint I would also use them for Tag:man_made=cairn if they are used to mark the hiking trail Richard ___ 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] Additional detail of Levee mapping via embankments
On Tue, Nov 19, 2019 at 08:16:43AM +0900, John Willis via Tagging wrote: > On Nov 19, 2019, at 6:53 AM, Richard wrote: > > > > Other than that, "dyke_area" or "area:dyke" in analogy to > > https://wiki.openstreetmap.org/wiki/Key:area:highway ? > > I think dykes/levees are made of inner and outer embankments, and pairing > them might be the only way to do it properly. > > Whatever is decided for embankments (I will work on some examples today) I > think a levee/dyke will have to be a relation of *some* sort (built on top of > the existing man_made=dyke tag) - either a relation of this way plus: > - 4 “levee lines (inner top+bottom) > - 2 embankments+ 2 embankment_area polygons > - 4 embankment lines. > > Mapping them as a total area (lower inner to lower outer) with a single > polygon with the man_made=dyke as the “top” down the middle is unacceptable > to me. The “top” is often a mappable area (with large levees worthy of this > detail). If it big enough to need this detail, it has a pretty large and > varying top area as well (as examples have shown). I didn't mean to map it *only* as a total area - instead I would suggest a man_made=dyke_area (or area:dyke, dyke_building..) overlapping all elements of the levee (embankemnts top/bottom, man_made_dyke and other) - thus in addition to micromapping those elements The man_made=dyke_area would serve to group all the elements together, thus avoiding the need for a relation in most cases. Very similar to the way man_made=bridge works today: replace the complicated Bridge/tunnel relation with a simple area. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Additional detail of Levee mapping via embankments
On Mon, Nov 18, 2019 at 11:15:49AM +0900, Joseph Eisenberg wrote: > > 1) Map the central line as man_made=dyke, or highway + cutting=yes / > embankment=yes as relevant. This line should not be 100 kilometers > long, but a reasonable length: probably no more than 10 kilometers, > and even shorter in a major city. > > This step is enough for most uses. You don't actually have to do steps 2 or 3. > > 2) If you want to, you can map the top line of any man_made=embankment > lines, if desired. > > 3) Finally (this part is very optional), you could map the area of the > cutting or embankment or dike as a series of closed ways. Don't make > them more than a kilometer or 2 long, since it's a pain to edit them > if they are too huge. It's better to use a few smaller closed ways > rather than a huge multipolygon to map complex features with holes. a couple of points: * people may confuse what the "area of embankment" is, my intuition is this would be the top area of the embankment not the slope of it as you perhaps intend it. * still thinking in most case it would be better to map eg the bottom edge of the embankment where there is a clear cut bottom edge as it much easier than mapping a slope area. If you map both the edge of the embankment and the slope, the top ways will be "shared", which means either a multipolygon or drawing the ways on top of each other. Slope areas would typically get another area attributes (surface, landuse, vegetation), again to be solved with multipolygons or the hacky way. * the comparison with riverbanks may miss some points: rivers are named so they are easier to piece together. Two adjacent embankment areas may be a valid attempt to map an edge of an embankment for example. River areas are just water and don't have any other landuse or vegetation attributes. * it would be nice to have a concept that extends easily to earth banks, cliffs and cuttings. > (We should not use a new tag like man_made=levee for this, because > "levee" is American English for "dike", so it would be better to use > man_made=dyke_area or something similar.) After googling dyke I am wondering if we should make an exception and use American English in this very particular case ? Googling levee gives me much more useful information than "dyke". Other than that, "dyke_area" or "area:dyke" in analogy to https://wiki.openstreetmap.org/wiki/Key:area:highway ? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Additional detail of Levee mapping via embankments
On Fri, Nov 15, 2019 at 12:17:41PM +0900, John Willis via Tagging wrote: > The “reply-to” email address might be being secretly changed by some mail > clients - when I choose “reply” to Peter’s mail, it chooses the tagging > group. When I choose reply to Martin’s, it chooses Martin. This is Mail.app > on MacOS 10.13.6. I have never really had this issue before. > In my mail client I have redefined "reply" to "reply-all" which so far works for all lists regardless of their settings. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Additional detail of Levee mapping via embankments
On Wed, Nov 13, 2019 at 06:54:52PM +0900, John Willis via Tagging wrote: > > On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer > > wrote: > > A relation seems easier to evaluate and explicit, while a spatial query > > heuristic will inevitably fail in some cases > > > I think there is a need for a basic relation, if I understand Martin > correctly, to simply associate the two lines, (for example, an =embankment > and an =embankment_base pair). When mapped, they are not joined. They are > merely adjacent. I am not sure of what “type” of relation to choose in iD, > but I assume someone will tell us which type to use. > > When mapping a simple cutting or embankment, you would have only one “base” > line adjacent - so there is little ambiguity, and the relationship can be > inferred (IIUC), but in complicated tagging, there could easily be a > situation where which base belongs to which line is unclear, and lead to > problems. > > Simply putting them into a relation says “these members are related” and the > renderer can know for certain that these two ways that don’t share nodes are > a pair, no inference needed. perhaps as a last step to perfection we might need some relations. Otoh quite pragmatically - what is the use of associating/relating those two lines (base and top)? Do we map them to make it clear if you run there you fall down a cliff or earth bank or run into a cliff? No need for relations for that. Also I am not convinced there is always a one-one relation between a cliff base and cliff edge? If we really wanted to render the "slope/cliff area" in some special style we would probably have to map that as an area, not relation of two or more lines. But I think for small slopes, the top and base lines if rendered should be good enough and for high slopes/cliffs DEM derived countour lines would be better. Btw as we get into more details we might want to map ramps as well. > This again raises the question of levees - is the levee worthy of it’s own > levee relation? do you put all 4 embankment lines into relation with the > man_made=dyke line? this seems to be the only solution to: > > - properly group the embankments with the levee > - not have to use super=relations (putting the embankment relations into a > levee relation) > - providing the most flexibility to weird situations > - allowing for the extent of the top of the levee to be defined (large levees > have varying width tops with usable areas, as shown, in which a “way” is > insufficient ). We use man_made=bridge (area) to group ways on a bridge.. so I am wondering would man_made=levee to encompass the whole levee area work in an equivalent way? I think it is only a quirk of OSM history that dyke and embankment are linear features and we would do many things differently today - and maybe we should do it now. Also somewhat related, waterway=dam can be either linear (the crown of the dam) or area. I think we should have one tag for the crown of the dam and one for the area because it would be often useful to map both of them. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Additional detail of Levee mapping via embankments
On Sat, Nov 16, 2019 at 06:21:13PM +0900, John Willis via Tagging wrote: > Still looking for feedback on the idea, Specifically: my idea.. > - lower base way or area sharing nodes with the top line in embankment / > cutting, etc? way instead of area. Simpler to do and more flexible. Also I would favor the "namespaced" variants (natural=cliff:base, man_made=embankememnt:base). Makes it clear that those are optional/additional details and leaves a clear path for further extensions (eg :ramp: ?) > - relation or no relation needed? see how far you get without relations. > - map levee with embankment pairs, or map with two pairs of levee specific > tags in a relation with the =dyke way? draw man_made=levee covering all elements Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Additional detail of Levee mapping via embankments
On Wed, Nov 13, 2019 at 07:04:42AM +1000, Graeme Fitzpatrick wrote: > On Wed, 13 Nov 2019 at 05:05, Richard wrote: > > > > > We need new tags for the bottom of embankmets, top of cuttings, bottom of > > cliffs, earth_banks > > and maybe a few others if we want to map them. > > > > Imho all those should be tagged ways such as cliff:base, relations could > > be used optionaly > > to relate a particular cliff edge to a particular cliff base which would > > define the > > area of the slope. > > > > Here is what I see: > > * man_made=embankment_base or man_made=embankment:base > > * man_made=cutting or man_made=cutting:top - top edge of cutting in > > analogy to > > man_made=embankment (126 pieces in database but straightforward to > > extend) > > * natural=cliff_base or natural=cliff:base > > * natural=earth_bank_base or natural=earth_bank:base > > > > Just a thought - how about a new area tag to show the "sides" of these > features, something like natural=slope? natural=slope could be somewhat misleading.. people would map all kind of other slopes. Could be natural=cliff:area ? However because embankemnt:area would be very misleading, it would have to become man_made=embankment_slope:area ? > You have your line to mark the top edge of the cliff or embankment, then > mark the visible area of the wall / side / bank down to it's base as the > =slope, which would be much simpler than mucking around with relations > (which I, & apparently quite a few others, don't really understand?) should not have even mentioned the relations, not a big fan of them either;) So it boils down to either * mapping the slope area * mapping the upper and/or lower bounds of the slope area Depending on case the one or other possibility may be better but I am not sure they can be used together. My feeling is that simple tagged ways (that is top and bottom edge) are more flexible and scale better to complex cases than areas. > Could also have height to say this bank is 5m tall; normal land cover tags > would apply to say it's grass, scrub, bare rock etc; incline to show it's > at 45° & so on. We have all this already? In my experience adding height=XXX to natural=cliff ins't very useful. The height (or width) varies along the cliff. > > Would also be nice if it rendered, perhaps as either fine diagonals or > cross-hatching (of course, the ideal would be if it rendered like map > contour lines - on a gentle slope the lines are wide apart, getting > narrower together as it get's steeper :-)) we have other methodes for countour lines > & when I've just had a look, natural=slope has actually been used 1466 > times, https://taginfo.openstreetmap.org/tags/natural=slope#overview, > despite being undocumented - searching the wiki for "slope" takes you to > the "incline" page https://wiki.openstreetmap.org/wiki/Key:incline, which > appears to for intended for roads? wondering what those slopes mean? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Additional detail of Levee mapping via embankments
On Tue, Nov 12, 2019 at 01:53:55PM +0900, John Willis via Tagging wrote: > > > > On Nov 12, 2019, at 10:26 AM, Joseph Eisenberg > <mailto:joseph.eisenb...@gmail.com>> wrote: > > > > If you are mapping an area, as in this case, just use a closed way or > > multipolygon. > > How would a closed way (area polygon) denote “top” and “Bottom”? > > if embankments can be easily expressed as a single simple polygon, how data > users infer “top” and "bottom” from that is beyond me. > > That is the issue: I don’t understand how a polygon would represent that, and > I think those two different pieces of mapping need to be explicitly tagged. do not search the problem on your side of the screen:) We need new tags for the bottom of embankmets, top of cuttings, bottom of cliffs, earth_banks and maybe a few others if we want to map them. Imho all those should be tagged ways such as cliff:base, relations could be used optionaly to relate a particular cliff edge to a particular cliff base which would define the area of the slope. Here is what I see: * man_made=embankment_base or man_made=embankment:base * man_made=cutting or man_made=cutting:top - top edge of cutting in analogy to man_made=embankment (126 pieces in database but straightforward to extend) * natural=cliff_base or natural=cliff:base * natural=earth_bank_base or natural=earth_bank:base I would favor the ":" variants, it might have been nicer if we had a scheme like cliffe:edge and cliff:base and same for cutting, embankment, earth_bank from the beginning. The "old" defs like man_made=cutting can be left or man_made=cutting:base can be defined as an alias. 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"?
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] amenity=hospital on things that are not hospitals - is it a good idea?
On Mon, Oct 28, 2019 at 09:44:50AM +0100, Mateusz Konieczny wrote: > "sign having a hospital icon and no name can simply be tagged > type=destination_sign + amenity=hospital" > https://wiki.openstreetmap.org/wiki/Relation:destination_sign if similar stuff occurs frequently I would suggest opening also a JOSM validator ticket Richard ___ 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] Areas of bare soil (clay, silt, loam) such as badlands?
On Mon, Oct 21, 2019 at 01:25:27PM +0900, Joseph Eisenberg wrote: > That sounds right. So natural=badlands could be used on a node, or on > an area covering the heavily-eroded, bare soil area of the landform? There is also natural=earth_bank and natural=gully Richard ___ 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] Feature Proposal - RFC - sunbathing
On Tue, Sep 03, 2019 at 07:52:38AM +1000, Warin wrote: > In Australia most people 'sunbathe' on a beach of sand. Some 'sunbathe' in > their own backyard. High rates of sun exposure gets 'melanoma' and there are > publicity campaigns to get people to cover up from sun exposure. wildy offtopic so I bite my tongue to reply to that. Richard ___ 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] What sport=* for automobile racing?
On 9/1/19 8:20 AM, Richard Welty wrote:
> On 9/1/19 12:12 AM, Warin wrote:
>>
>> On 31/8/19 9:49 am, Joseph Eisenberg wrote:
>>> There's also some uses of
>>> sport=speedway which is also unclear.
>>
>> Speedway is a oval dirt course that is usually used by cars and motorcycles.
>
> in some national contexts, sure. the definition in the US is not that
> restrictive.
on reflection, a better solution (i think) is to just use surface tags
that already exist. if you want query terms you could add
circuit_type={oval|road_course|drag}
and perhaps off road, although road_course+dirt might suffice.
richard
--
rwe...@averillpark.net
Averill Park Networking - GIS & IT Consulting
OpenStreetMap - PostgreSQL - Linux
Java - Web Applications - Search
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What sport=* for automobile racing?
On 9/1/19 12:12 AM, Warin wrote: > > On 31/8/19 9:49 am, Joseph Eisenberg wrote: >> With highway=raceway, the most common tags are sport=motor, >> sport=motocross and sport=karting (and even some sport=rc_car for >> remote controlled model cars). These are specific types of motorsport, >> except for "sport=motor", which can include automobiles, motorcycles >> and go-karts, so it's not very specific. > > Reason: Some tracks accept racing from all different kinds of motor vehicles > e.g. trucks, cars and motorcycles. > >> There's also some uses of >> sport=speedway which is also unclear. > > Speedway is a oval dirt course that is usually used by cars and motorcycles. in some national contexts, sure. the definition in the US is not that restrictive. richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What sport=* for automobile racing?
On 8/30/19 7:49 PM, Joseph Eisenberg wrote: > There are 5 uses of sport=autocross, 2 of sport=auto, 1 of sport="auto > racing" (with a space). > > It would be useful to have a specific tag since automobile racing, > motocross and karting use rather different raceways in most cases. > > Perhaps sport=auto_racing would be clear, and generic enough to cover > most types? https://en.wikipedia.org/wiki/Auto_racing > > Also, it looks like there are some other types of motorcycle racing, > other than motocross (which is specifically on dirt tracks / > raceways). > > Would sport=motorcycle be good for these? It's used 7 times. some karts do run on full sized auto racing circuits, but kart specific tracks are generally much smaller in scale. lots of motorcycle racing on pavement uses the same circuits as cars. but again, sometimes motorcycles run on narrower circuits that are unsuitable for auto racing. i don't have a proposal here, just conveying information. richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Relations/proposed/circuit
i would like to get a discussion of this proposal started again: https://wiki.openstreetmap.org/wiki/Relations/Proposed/Circuit it fills a need i have and i've been using it in both OSM and OHM. i have made a couple of new comments on the Talk page. right this instant i'm looking at mapping street circuits and i think it'd be nice to talk about this before i commit any time to them. richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ 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] 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] oneway=reversible and conditional restrictions
Hi, some time ago there was a discussion how to tag this. The good news is that OsmAnd developers worked on implementing it, so it might actually work:) Unfortunately I don't have the possibility to check it myself now, if you are interested have a look at https://wiki.openstreetmap.org/wiki/Tag%3Aoneway%3Dreversible https://github.com/osmandapp/Osmand/issues/6271 Apparently the impact is much more than just oneway=reversible as conditional restrictions are now "implemented" in OsmAnd. Richard ___ 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] New description of waterway=pressurised
On Mon, Jun 10, 2019 at 10:30:38PM +, marc marc wrote: > Le 09.06.19 à 01:12, Richard a écrit : > > The water level drops a few inches and > > suddenly the "pipe" is no longer water filled > > intermittent=yes/no that says that sometimes there is no water at all. But not that sometimes it is "pressurised" and sometimes not pressurised. > some industrial installations (I am thinking of an waterway between > retention basins at the Grande-Dixence Dam, part of which is natural) > have been under water since before I was born. > to say that this can no longer be a waterway=pressurised is to say that > it should be divided into 2, a waterway=pressurised-in-a-mandmade-stuff > and a waterway=pressurised-in-a-cave, this kind of micro-mapping > has its place in a subkey, not as a top-level value. my objection is against mapping natural caves with pressurised. If the cave becomes part of an engineered project it is somewhat different. I would be curious about more details and if this is a one in the world situation. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] lanes = 0
On Thu, Jun 13, 2019 at 12:59:27PM +1000, Warin wrote: > Hi, > > > There are a few uses of lanes=0... I would think these are errors. Even if > unmarked a road would have at least one lane otherwise it is not really a > road. > > > But looking at tag info there are a fair few uses fo it in various > locations. So ... what is it used for? this might also be something like an attempt at oneway=reversible Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New description of waterway=pressurised
On Mon, Jun 03, 2019 at 04:27:36PM -0400, Nita Rae Sanders wrote: > Here is one possible example of what you seem to be describing … way 84255726 > > Within Florida's Oleno State Part, the Santa Fe River vanishes into a > sinkhole. It then reappears at River Rise Preserve State Park. the > route, as depicted in the way (a mile +/-), is the presumed > subterranean path. The way is tagged as tunnel=yes, which seems odd, > yet descriptive (but as a tunnel, it would be natural and not > man-made). BTW I made a draft of a proposal for natural=cave some time ago: https://wiki.openstreetmap.org/wiki/Proposed_features/natural%3Dcave Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New description of waterway=pressurised
On Fri, May 31, 2019 at 08:59:08PM +, marc marc wrote: > I don't understand the logic of changing the meaning of a tag recently > validated by a proposal without prior consultation. > a natural siphon was before your modification a waterway=pressurised, > now no more. > > the fact that the approved proposal did not want to go into the details > of speologies is not a sufficient argument. > > the fact that some contributors do not know if the whole underground > part of the river is a syphon or not is not a sufficient argument > either, in this case it is sufficient to use location=underground as > proposed in the image of the propal. > but if someone knows that a section is a pressurized siphon, it's a good > thing he refine the info The idea that you should map anything in a natural cave as "pressurised" is a fundamentally flawed concept. The water level drops a few inches and suddenly the "pipe" is no longer water filled or only parts of it. Other parts of the cave will become pressurised after a rain that fills the cave with water? The fact that it has been approved only demonstates that our approval process is defying reality and physics Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Definition of Sport
On 5/24/19 11:20 AM, Martin Koppenhoefer wrote: > > > Am Fr., 24. Mai 2019 um 15:55 Uhr schrieb Markus > mailto:selfishseaho...@gmail.com>>: > > I personally like the definition by the European Sports Charter > (article 2, paragraph 1a): > > "Sport" means all forms of physical activity which, through casual > or organised participation, aim at expressing or improving physical > fitness and mental well-being, forming social relationships or > obtaining results in competition at all levels. > > > > what about shooting or chess? Chess clearly isn't a physical activity, > while for shooting there may be discussion. > The council of Europe also cites snooker along with chess as sports [1], > probably darts would fit well in this list too ;-) i am an active participant in motor sports. does this count or not? richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely complicated conditional values
On Thu, Apr 25, 2019 at 02:06:27PM +0200, Tobias Zwick wrote: > Even shorter, because if there are conflicting rules in the conditional, the > last one is taken, says the wiki. (Not sure if this is really implemented in > applications that work with that data though): just wondering, does anyone have an idea how far the software support for conditional goes? Richard ___ 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] Feature Proposal - RFC - Grain Storage Centre
On 4/5/19 11:19 AM, Cédric Mélac wrote: > https://wiki.openstreetmap.org/wiki/Proposed_features/Grain_Storage_Centre > Defintion: A large site with many silos and barns which concentrates > crops from farms around before selling at best prices. these are commonly called Elevators in the US. i don't know what british usage is. note that there are also bin sites, which don't have the market/sales aspect but are places where bins may be found, sometimes in large number, for storage. in the US, elevators may be straight up commercial, or may be coops. don't know if that is worth capturing or not. -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ 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] Emergency vehicle country-specific law
On 3/7/19 12:49 PM, OSMDoudou wrote: > I would expect the police would first re-organize the scene to revert > circulation. > > > > If the house on fire is just a few meters in the opposite one-way > direction, they might go directly, but technically they would break the > law, if I read the articles correctly. > > > > So, we should map what it authorized and not authorized under normal > circumstances, otherwise we map no restriction at all (because the > policy may always reorganize things in urgent situations). i think OSM should stick to mapping what is legal. first responders frequentlhy have permission to ignore the restrictions that apply to normal motorists, but they usually have relevant policies that probably don't belong in OSM proper and which aren't knowable without interviewing the responders in question (and i've interviewed a bunch while developing requirements, i have some insight into common policies.) richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Emergency vehicle country-specific law
On 3/6/19 5:17 PM, Jarek Piórkowski wrote:
> On Wed, 6 Mar 2019 at 16:29, Richard Welty wrote:
>> i spent some time looking at a project to build OSM based
>> emergency maps. i concluded we needed to do layers of
>> information, some of which were appropriate to host in
>> OSM and others which were not. there would have been a
>> program to conflate the data to produce an OSMAnd or similar
>> data file that met the department needs but avoided
>> dumping inappropriate data into OSM.
>
> Out of curiosity, if you don't mind/can share - what was not
> appropriate for OSM? Internal preferences or policies ("prefer to go
> down 1st rather than 2nd even though both look the same" - if only so
> drivers don't have to make that decision every time separately) or
> something else/more?
mostly, policy things like that. a lot of the things that FDs care
about are local policy rather than local regulations. if we stick to
the classical OSM theory that we map things that are observable
(which is something that is not fully honored of course) then
local policies are something a mapper on the ground can't see
unless they interview firefighters (which i've done a bit of.)
there are other examples. for example, the Chief of the Port
Henry department in upstate NY oversees a district that
is adjacent to Lake Champlaign, so you would think he has
a big enough water source. but the RR tracks running down his
side of the lake frequently carry huge trains loaded with
light crude oil. if one derails and catches fire, he can't
get to the lake. so he's been testing water flow of the streams
feeding the lake. that's the sort of data that's you can get
that benefits the FDs, but is not ground observable in the
usual OSM manner.
a lot of rural FDs have designated landing sites for EMS
helicopters. they're not secrets, you can go to the local
FD and ask about them. but they are generally not marked, so
again, a mapper can't just walk up to them.
in the case of the Albany NY FD, there are streets downtown
that present challenges for some equipment. this matches
roughly with your example. it ends up being things like
if we want to get this piece of equipment to this building,
we need to go the wrong way on this street.
the thing i learned from all the interviews, though,
that is most interesting, is that the firefighers know
their districts, they don't need such aids if they're
responding at home. the value comes in when a company
crosses district borders to assist. this means that
a real tablet OSM app to support emergency services
should be a regional solution to support mutual
assistance calls.
richard
--
rwe...@averillpark.net
Averill Park Networking - GIS & IT Consulting
OpenStreetMap - PostgreSQL - Linux
Java - Web Applications - Search
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
