Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-22 Thread Richard Fairhurst
[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?

2020-11-08 Thread Richard Fairhurst
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

2020-10-21 Thread Richard Fairhurst
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?)

2020-10-16 Thread Richard Fairhurst
Volker Schmidt wrote:
> I don't know what the routers need, to be honest.
> Anyone in the router business listening in on this conversation?

cycle.travel will take account of highway=crossing nodes (e.g. where a cycleway 
crosses a road), and adjust its routing weight accordingly. The adjustment is 
slightly different depending on the type of crossing and the highway= value of 
each connecting way.

It does not take any particular note of =crossing ways, other than to note that 
footway=crossing means that the rider should push.

It does not currently take any account of bicycle=no on a crossing, not least 
because bicycle=no is a very problematic tag - generally bicycle=dismount 
should be used instead, reserving bicycle=no for those circumstances where even 
pushing a bike is not legal (e.g. most public footpaths in England & Wales).

Richard
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Richard Fairhurst
Tod Fitch wrote:
> This thread has been quite amazing to me. My impression is that it
> starts with some routers (a.k.a data consumers, a.k.a. “renderers”)
> treating a “no” as a “maybe” and now people are looking for a new
> term to indicate that “we really, really, mean NO!”. This is worse
> than tagging for the render, it is obsoleting a straight forward
> and explicit tag value for a broken renderer.

No, you have got that the wrong way round, and it would be kind for you to be a 
bit surer of your facts before throwing around accusations of brokenness.

People have been using bicycle=no to tag footways where cycling is banned, but 
where you may push a bike, since the very earliest days of OSM. Here's an 
instance from 2006: https://www.openstreetmap.org/way/2606296/history . I'm 
pretty sure there weren't _any_ OSM routers in existence then.

The reason that routers will sometimes route via such a path, with an 
instruction to dismount, is that this tagging practice has always been 
widespread. It doesn't "start with some routers". It started with the tagging.

Fairly obviously, if the users of a particular router complain to the router's 
authors that they're being prevented from plotting a viable route, then the 
authors are pretty obviously going to change the router so they stop getting 
complaints.

So either fix the existing instances in OSM of bicycle=no being used to mean 
bicycle=dismount, or introduce a new tag.

Richard
cycle.travel
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-26 Thread Richard Fairhurst
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

2020-05-12 Thread Richard Fairhurst
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

2020-05-04 Thread Richard Fairhurst
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

2020-04-02 Thread Richard Fairhurst
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?

2020-04-02 Thread Richard Fairhurst
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

2020-04-01 Thread Richard Fairhurst
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

2020-03-29 Thread Richard Fairhurst
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

2020-03-28 Thread Richard Fairhurst
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

2020-03-28 Thread Richard Fairhurst
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

2020-03-07 Thread Richard Fairhurst
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

2020-02-25 Thread Richard Fairhurst
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

2020-02-25 Thread Richard Fairhurst
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

2020-02-25 Thread Richard Fairhurst
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

2020-02-25 Thread Richard Fairhurst
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?

2020-02-12 Thread Richard Fairhurst
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

2020-01-30 Thread Richard Fairhurst
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

2020-01-30 Thread Richard Fairhurst
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

2020-01-26 Thread Richard Fairhurst
Florimond Berthoux wrote:
> How to map a continuous sidewalk or cycleway ?

A couple of ideas were posted in connection with the London cycle
infrastructure database:

https://github.com/cyclestreets/tflcid-conversion/issues/30
https://github.com/cyclestreets/tflcid-conversion/issues/16

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] recreational vs functional routes

2020-01-09 Thread Richard Fairhurst
Joost Schouppe wrote:
> In the case of cycling, it would be really useful 
> for routers to be able to differentiate.

Yes - with my cycle.travel hat on, I'd find this very useful. Just an
optional route_type= tag on the relation would help.

I've mentioned on here a couple of times before [1] that there's a road bike
route in North Wales that is particularly problematic: it's signposted as a
bike route, but whereas other routes in the UK are for utility or touring
purposes, this one is specifically for road bike training and is wholly
unsuitable for all other purposes. (Almost all of its route is highway=trunk
or highway=primary with no cycling provision whatsoever.) Although it's a
signposted bike route and as such merits mapping, it is no more akin to a
standard route=bicycle than a stretch of mountain bike singletrack is.

cheers
Richard

[1]
https://lists.openstreetmap.org/pipermail/tagging/2019-October/048713.html,
https://lists.openstreetmap.org/pipermail/tagging/2019-September/047873.html



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] What access key for cargo bike ?

2019-12-20 Thread Richard Fairhurst
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

2019-12-14 Thread Richard Fairhurst
Francesco Ansanelli wrote:
> I added a bicycle route that implies the use of a funicular 
> (railway). I'm not sure how to "tell" in the relation that 
> you have to take the train and not ride the railway.

Just add the railway to the bike route relation, and make sure that each end
of the railway is directly connected to bike-routable ways. Here's
cycle.travel routing via the Tauern Tunnel:
https://cycle.travel/map?from=Salzburg=Grado

(Unfortunately someone appears to have broken the relation since I last ran
a routing update, removing the tunnel from it, so that'll need fixing...
sigh. https://www.openstreetmap.org/relation/2771761 )

cheers
Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (contact:phone)

2019-12-04 Thread Richard Fairhurst
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)

2019-12-04 Thread Richard Fairhurst
Sören Reinecke wrote:
> This proposal tends to make Key:contact:phone the official tag 
> for tagging phone numbers and to deprecate Key:phone which is 
> not fitting in the idea of grouping keys. Anyway it's bad to have 
> two keys for the exact same purpose in use.

Please just kill me now.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2019-11-07 Thread Richard Fairhurst
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"?

2019-11-06 Thread Richard Fairhurst
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"?

2019-11-05 Thread Richard Fairhurst
Martin Koppenhoefer wrote:
> do you have an example for a street where pushing the bicycle 
> is not allowed?

Potentially every public footpath in England & Wales. The law says only that
"usual accompaniments" are permitted, without specifying them. Cycling
organisations try to argue that this includes a bike, but I suspect the wish
is father to the thought in this one. Certainly one local council believes
it doesn't: 

https://www.cornwall.gov.uk/environment-and-planning/countryside/public-rights-of-way/rights-and-responsibilities-on-public-rights-of-way/public-rights-and-responsibilities/

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecating mini_roundabout

2019-10-23 Thread Richard Fairhurst
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

2019-10-23 Thread Richard Fairhurst
Florian Lohoff wrote:
> The point is that a mini roundabout does need a LOT of preprocessing 
> to put it into some graph for your classical A* or Dijkstra. You need 
> to eliminate the node and replace it with a circular road much like 
> a junction.

What? No. No. You don't.

I do precisely no preprocessing for mini-roundabouts in cycle.travel because
they're irrelevant. They're just normal crossroads or T-junctions with no
inherent priority other than traffic already making the turn (similar to a
four-way stop in the US), and some paint in the middle. They are treated
exactly as normal junctions and so they should be.

> You would expect (as you see a roundabout sign) to get instructions to 
> take the n.th exit. 

What? No. No. You wouldn't.

Mini-roundabouts are almost always at junctions with only three or four
exits. The Government guidance explicitly states so
(https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/561491/mini-roundabouts-report.pdf,
para 3.9).

Any UK driver would expect their satnav to say "turn left" or "straight on"
at a mini-roundabout, not "take the first exit".

Could I suggest that you refrain from tag-fiddling on a subject where you
clearly have no experience?

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Cycling relation misuse

2019-10-14 Thread Richard Fairhurst
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

2019-10-12 Thread Richard Fairhurst
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

2019-10-11 Thread Richard Fairhurst
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

2019-10-11 Thread Richard Fairhurst
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?

2019-10-09 Thread Richard Fairhurst
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

2019-10-09 Thread Richard Fairhurst
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?

2019-09-27 Thread Richard Fairhurst
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?

2019-09-26 Thread Richard Fairhurst
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

2019-09-21 Thread Richard Fairhurst
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

2019-09-21 Thread Richard Fairhurst
voschix wrote:
> I am trying to figure out where the surface default values by road 
> category and country are defined.

I don't believe there's a place where it's stated, but I work on these
assumptions:

- highway=track/bridleway is always unpaved unless stated otherwise
- highway=footway/path may be unpaved unless stated otherwise
- in developed countries, all "higher" highway types can be assumed paved
- in developing countries, anything from secondary down (or even primary)
may be unpaved
- in rural areas of the US, it's not safe to assume highway=residential is
paved if tiger:reviewed=no

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

2019-09-04 Thread Richard Fairhurst
Peter Elderson wrote:
> The network values identify transport mode and scope of routes, and 
> these "dimensions" also apply to node networks. We do not want to 
> add another dimension (configuration type) to the network=*  
> values of routes.
> 
> Instead, we are thnking about just adding a tag to identify segment 
> routes as parts of a node network. The nodes themselves do not need 
> this, since they ARE nodes and have a xxn_ref tag.
> 
> In short, we are thinking to simply add the tag network_type=
> node_network (or network:type=node_network) to the node2node 
> network routes.

I have a strong interest in this proposal. :) [1]

If I understand you rightly, a route like
https://www.openstreetmap.org/relation/1844941 would get an extra
network_type=node_network tag. Nothing else would change. (Correct me if I'm
wrong.)

You say "we don't want to add another dimension" but you are effectively
doing that; you're just doing it by adding a new tag rather than adding a
value. That's not _necessarily_ a problem but it would be better done in an
extensible way that might be useful for other tagging scenarios, rather than
special-casing this one scenario.

We currently have the "network=ncn|rcn|lcn" tag which broadly identifies the
_importance_ of the route.

What we do not have is a tag to identify the _character_ and _purpose_ of
the route. All bicycle routes (except MTB) get lumped together as a generic
route=bicycle. This is increasingly a problem as routes are devised and
signposted for performance cycling, bikepacking, and so on. For example,
there are two new performance cycling routes in Wales which I'd like to map
(https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would be
misleading if tagged in the same way as other NCN/RCN/LCN routes in Britain.

You're proposing a tag called "network_type", but it's a tag for the route,
and what you're using it to describe is the character and purpose of the
route. (The network is already mapped in the network super-relation.)

So I'd suggest that instead of network_type=, you add route_type= .

This would achieve the same purpose; be semantically more appropriate; and
be extensible to other routes where "route=bicycle" alone does not
adequately capture the character and purpose of the route.

Richard
cycle.travel


[1] I believe cycle.travel is the only OSM-based router that includes nodes
in its turn-by-turn instructions, e.g.
https://cycle.travel/map?from=51.0623,2.8582=51.0913,2.8531 .
cycle.travel also has a few localised rules for rendering in the Netherlands
and Belgium to cope with the sheer density of the node network.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Multiple tags for one purpose

2019-08-26 Thread Richard Fairhurst
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, ...)

2019-08-20 Thread Richard Fairhurst
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

2019-08-19 Thread Richard Fairhurst
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, ...)

2019-08-19 Thread Richard Fairhurst
On mobile, on train, apologies for lack of formatting. :)

Sarah - the problem is that when you say “one single simple 
instruction to the mapper: sort your route“, the instruction might be simple
but carrying it out isn’t.

Let’s say we have a cyclist, new to OSM, who wants to add a newly opened
section to an existing route. As Peter says, doing this to said
specification “usually requires lots of JOSM”. The steps involved to do this
in sorted order are:

1. spend half the afternoon trudging through contradictory pages on the OSM
wiki to find out what you have to do
2. apparently it involves this thing called “JOSM”. Download that
3. apparently that involves this thing called “Java”. Download that too
4. learn to use this 80s throwback of a GIS program with the UI of a
startled warthog
5. find route sorting stuff in JOSM somewhere 
6. make edit
7. get shouted at by sociopaths in changeset comments because unwittingly
you did something wrong 

(I have elided most of the intermediate steps.)

That isn’t how OSM works. It might be how Wikipedia works but we are better
than that. 

_If_ route ordering is to be expected, then the burden needs to be on the
editing software, not the mapper. That means invisible support in iD, P2,
and I’m guessing Vespucci and Go Map (I don’t know what their current
support is like). And tbh the burden of providing patches is on the few
people who are asking for it. Certainly I’m happy to implement something in
P2 if it’s an afternoon’s work and I’m given a fully fleshed out algorithm
which copes with the partly loaded relations that are standard for an online
editor, but I’m not going to spend two days of dev time on something for
which there is no great clamour outwith a couple of people on the tagging
list. 

cheers
Richard




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] roads with many names

2019-08-18 Thread Richard Fairhurst
Rob Savoye wrote:
> Where I live in rural Colorado, many of the roads have 3 names. 
> The county designated one like "CR 2", but often have an alternate 
> name everyone uses like "Corkscrew Gulch Road", and then many 
> have a US Forest Service designation like "FS 729.2B". 

name=Corkscrew Gulch Road
ref=CR 2
usfs:ref=FS 729.2B

I think this holds even if the "county-designated name" is CR 2. The "name
everyone uses" tallies with OSM standard practice; the official reference is
what we have the ref tag for.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

2019-08-18 Thread Richard Fairhurst
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, ...)

2019-08-17 Thread Richard Fairhurst
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, ...)

2019-08-16 Thread Richard Fairhurst
Peter Elderson wrote:
> I think it's fair to say there is almost no software that does 
> anything with route relations except rendering and exporting 
> as a gpx.

That's not true. Most bike routers based on OSM are aware of route relations
and use them to influence routing.

> Software needs a sorted or easily sortable relation. Currently, 
> no software can handle sorting when the routes get broken. 

That's not true either. I have software right here that reorders unsorted
relations, as well as skeletonising dual carriageways into single lines,
jumping over roundabouts and coping with other such issues. I know of two
other sites operating similar software and I'm sure there are more.

There are certainly issues with consuming route relations but sorting is
not, in my pretty extensive experience, one of them.

Peter, perhaps you could clarify what your experience is in consuming OSM
data? Have you written code to do so? Do you run a website that uses OSM?

Richard
cycle.travel




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Clashing access tags

2019-07-14 Thread Richard Fairhurst

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

2019-07-09 Thread Richard Fairhurst
brad wrote:
> I see tracktype as redundant with Surface, also very subjective, and 
> not useful.   Smoothness is very useful.

smoothness= is a horrible tag, please don't use it.

As a data consumer (for cycle.travel), I probably do more detailed parsing
of surface and related tags than any other consumer, and smoothness= is
almost always misleading and ambiguous. People use it to record their
arbitrary impressions of a path without any reference to an objective scale
whatsoever. There is no consensus as to whether the smoothness tags are
relative to the tagged/implicit surface or not: is it possible to have
smoothness=excellent for an excellently smooth gravel surface? What does
smoothness=good, highway=track actually mean? 

About the only circumstances in which it's useful are to record that a trail
is universally impassable. Otherwise it should die in a fire.

tracktype= isn't great but it has the advantage that it uses a clearly
arbitrary scale, so most people tag by reference to the photos on the wiki
rather than just because they think "this is horrible".

80% of the time surface= is all you need. We could do with more and better
documented values for it, especially for clarity around gravel. I could see
some virtue in another tag to be used _only_ when surface= is also present,
documenting how well the surface is maintained, so that you could
differentiate between (say) potholey, broken-up asphalt and immaculately
maintained asphalt.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Incorrectly tagging locks on rivers as canals

2019-04-26 Thread Richard Fairhurst
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

2019-04-25 Thread Richard Fairhurst
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

2019-04-25 Thread Richard Fairhurst
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

2019-04-11 Thread Richard Fairhurst
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

2019-04-11 Thread Richard Fairhurst
Volker Schmidt wrote:
> "highway=path" implies "bicycle=yes" (in most jurisdictions) - see the
> proposed Default-Access-Restriction for all countries

That's not a default that I feel enormously comfortable with. Whatever the
wiki might say, "bare" highway=path (no other tags) is often used for little
footpaths across city parks, sidewalks, and so on.

cycle.travel errs on the side of caution and therefore doesn't route along
highway=path unless there's an explicit access tag (or cycle route
relation).

Keeping bicycle=yes on bikes-allowed paths is useful information. If there's
no bicycle= tag, yes, it could mean "bike access is implied by a default
somewhere on the wiki" but it could also mean "this way is tagged
incompletely". Deleting the tags would remove information and make it harder
for routers to deliver real-world routing results. Please keep them.

cheers
Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Intermittently unprotected cycle track

2019-03-29 Thread Richard Fairhurst
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

2019-03-27 Thread Richard Fairhurst

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

2019-03-18 Thread Richard Fairhurst

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?

2019-03-15 Thread Richard Fairhurst
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

2019-03-15 Thread Richard Fairhurst
Mateusz Konieczny wrote:
> Yes, one of main points of StreetComplete is to allow editing 
> without knowing how objects are tagged, similarly iD.
> 
> It means that to count "how many people decided to use tag 
> XYZ" all iD users and all StreetComplete users count as say 
> 4 people because not each mapper is deciding on its own 
> but it is decision of whoever makes the software.

Oh, come on. Just because iD has an actual user interface doesn't mean that
every single iD user is unaware of the tags used. There are plenty of
experienced mappers (I'm one) who choose not to use JOSM because they just
don't like JOSM, believe it or not!

On topic: I don't have a great preference for either tagging scheme (they're
both a bit ungainly, I've found them both a bit of a PITA to support in
cycle.travel's tag parsing). cycleway=opposite_lane is concise but unclear.
Regardless, both are in widespread use so the wiki should document both.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging professional cycling competitions as route=bicycle?

2019-03-06 Thread Richard Fairhurst
They don’t belong in OSM for the reasons you state, and would be better
hosted independently on umap or similar. 

But in any case, they absolutely should not be tagged route=bicycle, as
routers and renderers use this as a signifier that “this road/path is
particularly suitable for cycling”. Professional bike races take place on
closed roads, sometimes even trunk roads/motorways, and certainly not just
those identified as bike-friendly. If these routes are to stay in OSM (which
they shouldn’t) then they should be route=bicycle_race or similar. 

cheers
Richard 



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Clarification unclassified vs residential

2019-02-21 Thread Richard Fairhurst
Florian Lohoff wrote:
> From the original meaning unclassified was the lowest class road 
> in rural or off city limits. residential was the lowest class road 
> within city limits. (Assuming that city limits mean residential 
> usage)

That's reasonable but not _quite_ true. highway=unclassified is often used
in urban areas to denote a minor distributor road. 

https://www.openstreetmap.org/way/145016745 is a good example
(https://goo.gl/maps/YUc6XfuA5wQ2 if you'll excuse the Google Street View
link). It's the distributor road for that estate, and of greater importance
than the largely cul-de-sac residential roads going off it; but doesn't have
a significant through-traffic purpose nor the engineering standards that
would imply highway=tertiary.

> [...]
> From OSRM profiles it isnt - So it doesnt make a difference for at 
> least OSRM.

OSRM's default profiles don't measure importance, only speed, and are fairly
blunt instruments which aren't used unmodified by anyone who's serious about
quality routing results. (Mapbox, OSRM's sponsors, override them with
traffic speed data, for example.) I wouldn't count them as a useful
indicator.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Clarification unclassified vs residential

2019-02-21 Thread Richard Fairhurst
Greg Troxel wrote:
> Finally, I'd suggest in the US treating unclassified and residential 
> as exactly the same in importance, because we have no real notion 
> of unclassified roads like the UK.

There is one de facto difference in the US, which is that
highway=unclassified means that someone has made the active decision to tag
the road that way, whereas highway=residential (numerically) probably just
means "this was class A41 in TIGER".

Therefore it's fair to assume that highway=unclassified in the US has a
similar meaning to elsewhere in the developed world - a minor road which is
not a significant through traffic artery, and which is paved unless
otherwise stated (by a surface= tag). highway=residential in rural areas of
the US, however, could mean anything from a drainage ditch via a faint
outline of a path to a three-lane tertiary that hasn't been retagged yet.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rivers intermittently navigable

2019-02-15 Thread Richard Fairhurst
Fernando Trebien wrote:
> motorboat:conditional only works if the periods where the river 
> is navigable are predictable, and that usually depends on the 
> variable amount of rain on the basin.

motorboat= is an access tag, so it represents whether a use class is
permitted on that way, not whether it's possible. 

I'd think a variant on depth= would be most appropriate. Something like
depth:summer=0.5-3.0 might indicate that the river depth in summer can
typically vary between 0.5m (i.e. only a canoe at a pinch) and 3m. Defining
"typically" is left as an exercise to the reader. :)

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging Digest, Vol 113, Issue 52 Co-ordinate sets vs. background informations = ODbL vs. CC

2019-02-15 Thread Richard Fairhurst
Sergio Manzi wrote:
> I strongly dissent with the tone of your mail.
> Everybody, not only you and the most vocifeferous ones, have the right to
> express 
> their opinion.

They do, but if the opinion is off-topic and unconstructive for the list and
likely to divert from the purpose of said list, then the list
admins/moderators are within their rights to ask the thread to stop, and
that's what I'm doing here.

Ulrich, your comments are seriously off-topic for the tagging@ list. If you
would like to continue the argument then I would suggest you use the talk@
list. It won't get you anywhere, but who am I to tell someone not to bang
their head repeatedly against a wall.

If you do so, please learn to participate in a threaded discussion, either
by replying to individual messages (not digests) or by using a web interface
like Nabble that permits you to do so. Thank you.

Richard
tagging@ list admin



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

2019-01-14 Thread Richard Fairhurst
Axelos wrote:
> ID is not suitable for this type of contribution (relations), he knows 
> how to do it, but in a superficial and irrelevant way.
> It's not up to OSM to adapt to ID, but the opposite. Since it is not 
> up to OSM to adapt to opencyclemap but the opposite (ref = icn). 
> Potlach 2 in 2019 is a joke!  It is an outdated publisher requiring
> dangerous technology (Adobe).

Maybe don't start editor flamewars on the tagging@ list? Use another list
for that please, like, I dunno, dev-null@, or maybe a list which isn't
administrated by me and is ideally written in a language I can't read.
Thanks.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Vehicle service tags

2019-01-04 Thread Richard Fairhurst
We don’t call people fools in subject lines on this list. Please check your
language before replying. 

Richard 
reluctant tagging@ list admin



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

2019-01-03 Thread Richard Fairhurst
Peter Elderson wrote:
> Sorry, I assumed Potlatch would work approximately similar to Id. 

If you're addressing a mailing list with 551 subscribers, could I suggest
you take a few minutes to actually research your statements before posting?

> Can it easily sort/reverse ways within relations, move elements 
> between relations, create and manipulate superroutes, and keep 
> all the routes (hiking, cycling, PT) happy when removing/splitting/
> extending ways?

Potlatch 2 can create and edit relations of any type and with any members
permitted by the OSM API.

You now appear to have changed from "Can't be done" to "Can it easily",
which is a different, subjective question and frankly not one I can be
bothered to answer.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

2019-01-03 Thread Richard Fairhurst
Peter Elderson wrote:
> I just did some work on a hierarchy of hiking routes. Can't be done with 
> Id or Potlatch

What specifically can't be done in P2?

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (Hierarchies route=bicycle)

2019-01-02 Thread Richard Fairhurst
Axelos wrote:
> Hello, I propose a concept for contributing cycling route.

Many thanks for looking at this - the current state of bike route
hierarchies is a mess, and trying to parse the many different tagging
practices so that cycle.travel can display them properly has been a
nightmare. It would be good to have a commonly agreed, intuitive standard.

From the description on the wiki page, I'm not sure how your proposal
differs from the practice documented at
https://cycling.waymarkedtrails.org/help/rendering/hierarchies . Could you
explain the difference?



A few passing comments:

> Example name = Boucle de la Moselle: Toul - Pompey

Please don't do this - the name tag is for an object's commonly agreed name,
and "Boucle de la Moselle: Toul - Pompey" is not the official name of any
part of the route. You could perhaps use the description= or note= tag
instead.

There are lots of examples of this in your proposal: "name=PAN Segment 1",
"name=Véloroute 50 : Étapes", and so on.

(Similarly, some people have tagged sections of EuroVelo routes in one
country with the network=ncn tag. This is wrong: EuroVelo routes aren't
National, they're International. I think this is probably a mistaken attempt
to get them to render on OpenCycleMap.)

> To do this effectively, you will need a powerful editor: JOSM.

This is a "tagging smell" (cf https://en.wikipedia.org/wiki/Code_smell). Any
tagging scheme that requires a particular editor is probably a bad scheme.

As it happens, you can certainly edit relations like this with Potlatch 2 no
problem and I guess you can with iD too; but before any tagging scheme like
this is adopted, you should create a tutorial for iD users. It shouldn't be
necessary to learn a whole new editor just to be able to tag a bike route -
as you yourself say, "Is the hierarchy of cycle routes reserved for
experts?". Bear in mind too that iD users _will_ edit these routes, so the
scheme should be intuitive and robust (of course, that should be the case
anyway!).

cheers
Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] EuroVelo tagging

2017-03-07 Thread Richard Fairhurst

Volker Schmidt wrote:

As EV routes are not managed as single entities, every route is split in
pieces managed on a country basis. I know the situation in Italy, as I am
involved in regional and national cycle routes here. EV routes are handled
by BicItalia which is part of FIAB, the "Italian Federation of Friends of
the Bicycle". All EV routes all have also BicItalia numbering (BicItalia
routes are ncn), but it is not necessarily the case that the Italian part
of a given EV corresponds one-to-one to a BicItalia route. So it makes
sense to tag the individual EV routes in one country as one icn and to tie
these icn routes in the different countries together by a super relation.
This means that any BI route that is also part of an EV is part of at least
to bicycle route relations (it typically is also part of lower level routes.


and Warin wrote:

My thoughts on the EV ... following my thinking on the above are;

Have 2 relations ... on on the EV, the other on the other entity (e.g.
BicItalia).


Agreed - I think this is the most sensible approach and it accords with 
most current practice. I'll add some text to the EuroVelo wiki page 
accordingly.


Jo wrote:

It ought to be possible to use hierarchy in those relations. That way you
would map them at the national level and group them for the international
level.


It's a seductive idea, but the problem with this is that the routes 
aren't always strictly hierarchical. For example, EuroVelo 1 in Britain 
uses parts of NCN 7 and NCN 73, but not all of them. So to do a 
hierarchical approach you would need "NCN 7 part one" in "EV 1 
super-relation" and "NCN 7 super-relation", "NCN 7 part two" in "NCN 7 
super-relation" only, and so on. This could get very complex very 
quickly - some parts of NCN 27 are in EV 1, some are in the Tour de 
Manche Anglo-French route, some are in the Dartmoor Way: the 90-mile 
route would need to be split at least four ways. I suspect it'd become 
exceptionally fragile and liable to be broken, and my main concern with 
getting the EuroVelo tagging confirmed is to make sure that there's an 
unambiguous reference so well-meaning newbies are less likely to break it.


cheers
Richard

(apologies for broken threading, tagging@ has disappeared from Nabble)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] EuroVelo tagging

2017-03-05 Thread Richard Fairhurst
Europe has numerous international cycle routes signposted and marketed 
as 'EuroVelo', and these are often mapped in OSM:


http://www.eurovelo.com/

Unfortunately the tagging is pretty inconsistent, especially when routes 
are shared with national/regional (NCN/RCN) routes, as is usually the 
case. Although a relation with 'network=icn' is the convention for 
international cycling routes, people do sometimes change this to 
'network=ncn' and 'ref=EV<...>' for tagging-for-the-renderer reasons. 
The result is that we have messy and inconsistent tagging.


At present the wiki project page doesn't have any tagging guidance:

https://wiki.openstreetmap.org/wiki/WikiProject_Europe/EuroVelo

I would like to suggest that we formalise existing good practice by 
saying that roads/paths on a EuroVelo route should directly be part of a 
route relation. That relation should be tagged:


route=bicycle
network=icn
ref=11 [or whatever the EuroVelo route number is]

Grouping several route relations together in a 'master relation' is all 
good (as these routes are often too long for one manageable relation), 
as is operator/brand tagging to indicate that this is EuroVelo in 
particular. But I'd like to document the above as the minimum, simplest 
thing. It seems to be generally accepted and is in line with NCN/RCN 
tagging.


Thoughts?

cheers
Richard

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] using Michelin's road classification (was: Routing in Liège)

2016-09-17 Thread Richard Fairhurst
André Pirard wrote:
> Last point is what source:???=Michelin ??? to use to prevent a 
> StijnRR or like arbitrarily destructing well thought out tagging 
> without notifying the author. I suggest
> source:highway=https://viamichelin.be/web/Cartes-plans 2016 2016.

No, you must not copy from copyrighted maps, which includes Michelin's.

Please confirm that you have not added, and are not going to add, any data
(including classification judgements) from Michelin maps, otherwise I guess
we'll have to ask the Data Working Group to suspend your OSM account and
revert your edits.

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/using-Michelin-s-road-classification-was-Routing-in-Liege-tp5882709p5882854.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Michelin info

2016-09-15 Thread Richard Fairhurst
André Pirard wrote:
> Reply to this message privately to receive info about how to easily
> compare OSM with the Via Michelin map using JOSM.

Um, I'm not 100% sure what you're proposing here, but please remember that
we must not copy any information from copyrighted maps into OSM.

Richard
reluctant tagging@ list admin



--
View this message in context: 
http://gis.19327.n5.nabble.com/Michelin-info-tp5882710p5882741.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Typo fix for tunnel=building_passage and how to proceed in the future

2016-09-10 Thread Richard Fairhurst
LeTopographeFou wrote:
> But do I have to ask for a vote/discussion for automated typo edits?

Very expressly no. There is no precedent for voting on automated edits, and
on the rare occasions it has been suggested then there has been significant
and well-founded opposition to the idea.

From the Automated Edits Code of Conduct: "We do not require or recommend a
formal vote, but if there is significant objection to your plan - and even
minorities may be significant! - then change it or drop it altogether."

In this case you're changing, I think, just 22 objects in total for things
that can't be interpreted as anything but typos. I suggest you just go ahead
and do it. :)

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/Typo-fix-for-tunnel-building-passage-and-how-to-proceed-in-the-future-tp5882268p5882288.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Fwd: How to tag: public lands that are accessed by permit?

2016-07-20 Thread Richard Fairhurst
Kevin Kenny wrote:
> I just want to be able to look at my map and answer the 
> quick question, "is there red tape that I have to plan for 
> before I plan a trip here?"

Yep. I asked a similar question at
https://lists.openstreetmap.org/pipermail/tagging/2016-February/028504.html
but there was no particular consensus.

access=permit seems to have moderate usage (slightly more than =license,
which is in any case misspelled) so I'd go for that.

cheers
Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/How-to-tag-public-lands-that-are-accessed-by-permit-tp5878730p5878819.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Relations in Transport for London: network and operator

2016-07-14 Thread Richard Fairhurst
Bjoern Hassler wrote:
> Second question: network. The wiki page
> http://wiki.openstreetmap.org/wiki/London_public_transport_tagging_scheme
> doesn't say much about "network", and these values are in use:
>
> - London Underground
> - National Rail
> - Network Rail
> - London Overground
> - TfL
> - District and Hammersmith & City Lines
>
> I would propose to retain the first four

Network Rail isn't a network, it's the company (FSVO company) that owns and
operates Britain's rail infrastructure. Anything tagged network=Network Rail
should probably be network=National Rail.

There is a slight factual impropriety as London Overground is properly part
of the National Rail network; it's little different to a strongly branded
PTE-run franchise like Merseyrail. But how you resolve this without getting
ridiculously trainspottery I don't know.

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/Relations-in-Transport-for-London-network-and-operator-tp5878259p5878280.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path

2016-06-15 Thread Richard Fairhurst
John Willis wrote:
> I am really having trouble understanding the reasoning behind the 
> resistance when it removes uncertainty and confusion while tagging. 

But it doesn't.

You're citing your own personal hierarchy between "trails" and "easily
traversed footways", which is fine. But that hierarchy is not ringing any
bells with me. I honestly have no idea how any of the paths around here
would be classified on such a hierarchy. We have thousands of miles of paths
which are walkable as of legal right, of every quality from wide tarmac to
barely discernible routes across ploughed fields, but we don't have any
concept of "trails" here[1] - it's largely an American/Australasian English
usage.

highway=motorway/trunk/primary/etc. works when a firm, easily understood
hierarchy can be established based on that road's importance in the
connected network. It falls down when that hierarchy is less clear-cut, and
it's very notable that road tagging is quite uniform and uncontested in some
countries (e.g. the UK) where there's a clear mapping between tag values and
observable characteristics, and less uniform in others (e.g. the US) where
that mapping is fuzzier.

For your idea of increasing the highway= options available to path mappers,
such a hierarchy would need to be apparent on the paths in most countries,
and to be documentable as such in a reasonably internationally consistent
manner. I haven't yet seen any case made that it is, and I doubt that it
could be. 

Richard

[1] other than the very few long-distance routes known as National Trails



--
View this message in context: 
http://gis.19327.n5.nabble.com/Subject-Feature-Proposal-RFC-highway-social-path-tp5870639p5875594.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Suggested way to map disputed country borders

2016-05-19 Thread Richard Fairhurst
Rory McCann wrote:
> Both of the example maps of Russia/Ukraine and India/Pakistan 
> require the use of another data set. Which is a shame. One should 
> be able to generate that from OSM entirely.

Why?

OSM's selling point is not "all geodata, ever, in one place". OSM's selling
point is personally researched data that reflects reality.

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/Suggested-way-to-map-disputed-country-borders-tp5873085p5873781.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Education 2.0

2016-04-15 Thread Richard Fairhurst
Шишкин Александр (Shishkin Aleksandr) wrote:
> IMHO, it is much better to have alternative advanced tagging 
> system from which data users can benefit much (e.g. search 
> by school's speciality).

As a general point, could I please encourage people not to second-guess what
data users might "benefit much" from, unless they themselves are those data
users.

It was that sort of thinking that brought us highway=path. "It will make
things easier for data users," they said. It didn't. It made it worse.

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-RFC-Education-2-0-tp5871664p5871916.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path

2016-03-26 Thread Richard Fairhurst
Alan McConchie wrote:
> Some commenters have suggested using the existing highway=path tag, 
> with supplemental tags such as access=no or informal=yes, or a new 
> supplemental tag path=social_trail, or adding an operator tag. However, 
> these supplemental tags are too easily ignored by data consumers and 
> renderers, which is problematic given the destructive and hazardous 
> nature of social trails in many areas.

First, big thanks for bringing this to the list.

I do think, however, you are mistaken with the above rationale, which
appears to be the sole rationale for the proposal.

access=no is absolutely a core tag within OSM, dating back to the very first
iteration of Map Features. It isn't "easily ignored". Any router which
ignores it is unambiguously bugged. Any renderer intended for walkers'
consumption which shows it as a walkable path is unambiguously bugged.

It is not, however, documented or safe to assume that renderers and routers
will always fall back to "no". There have been renderers which will render
the name for an unknown highway value, so 'highway=social_path;
name=Shortcut' would show on the map as a label saying 'Shortcut'. There are
routers which will assume a default speed for unknown highway values. That
isn't always daft: you can envisage a single typo in one two-node way
('highway=mptorway, maxspeed=70mph, surface=paved, access=yes...') which
would otherwise break routing across a continent if the router was entirely
fault-intolerant.


To widen the discussion, introducing new core path values is bad OSM
citizenship.

Path tagging in OSM is notoriously complex, for one reason: people keep
reworking the core model to deal with their edge-cases.

We began with highway=footway/bridleway/cycleway/track, surface=*, and
access/foot/bicycle/horse/motor_vehicle=*. With these values, you can model
the essential characteristic of 95% of paths (conservative estimate).

Some people identified edge cases which they felt were not adequately
captured by this scheme, and therefore introduced a new, more complex
scheme, highway=path.

Later, others identified still further edge cases and introduced yet more
values: access/foot/bicycle/etc.=designated. Later later, others identified
still further edge cases, and we got access/foot/bicycle/etc.=official.

And so on. Every such change has made the system more impenetrable for
mappers and consumers, and we have, I believe, a collective responsibility
to keep OSM usable. I won't bore you with the details of the Lua tag parsers
I use for cycle.travel's path routing and rendering, but they are insanely
complex - hashes upon hashes upon hashes, special cases upon special cases -
and yet there are still bugs and edge cases. How anyone who doesn't have
years of experience in OSM is meant to cope with this, I don't know.

The best way to map these, without adding further burdens to mappers or
consumers, is to use broad-brush, well-established tags such as:

 highway=footway
 access=no

and then, if you feel this doesn't fully capture your particular edge case,
some sort of _additional_ tag:

 social_path=yes

(The classic example of this is motorroad=yes, which the German community
introduced as a refinement on highway=trunk/primary, and which has since
become a successful and widely-adopted tag without breaking highway routing
or rendering.)

But please don't extend existing core tagging, such as highway=, in new and
exciting ways. It doesn't necessarily solve the problem in the way you think
it will, and it makes it harder for everyone to use OSM.

cheers
Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/Subject-Feature-Proposal-RFC-highway-social-path-tp5870639p5870698.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] importance=* tag (for transportation etc)

2016-03-19 Thread Richard Fairhurst
Andy Mabbett wrote:
> It's nowhere near as ridiculous as trying to render them according 
> to some arbitrary and subjective "importance" (Importance to 
> whom? The people who live near them? Tourists? Mountaineers? 
> Ornithologists? Aviators? Geologists? Climatologists? Oil 
> prospectors?).

Exactly.

Here's an example: https://en.wikipedia.org/wiki/Sg%C3%B9rr_Dearg

This is the notorious "Inaccessible Pinnacle". If you're a mountaineer,
specifically a Munro bagger, it's a highly significant peak: it's the
hardest Munro (Scottish peak over 3000ft) to get. If you're a tourist
looking for pretty mountains, though, it's probably not significant; it's
just, well, a bit of rock. Wider cultural significance? I couldn't tell you.
Somewhere between the two: certainly less than Ben Nevis, but how do you
decide the "importance" of the hardest peak to climb in Scotland which just
happens to be an anonymous lump of rock?

Importance means value judgements. One of the reasons OSM is so successful
is that our data doesn't make value judgements. This allows people to make
their own maps with their own value judgements. This is why OSM has become,
from nowhere, the world's pre-eminent geodata source for walking and cycling
- because every other dataset is car-biased. Let's not close off future uses
of OSM by imposing centralised value judgements on its data.

John Willis wrote:
> Trying to decide what mountains are worth labeling at different zooms 
> via some GIS data is ridiculous. 

It's only ridiculous, to be blunt, if you're no good at GIS. I show
identically-tagged pubs at different zoom levels on cycle.travel based on my
own criteria, not some importance scale that someone else has decreed. It
takes me about three lines of PostGIS and two lines of CartoCSS. It isn't
hard at all.

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/importance-tag-for-transportation-etc-tp5870183p5870224.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] shop=marine RFC

2016-03-15 Thread Richard Fairhurst
dieterdreist wrote:
> Maybe shop=sailing_supplies? Or ship_supplies?

Some of us have boats (not ships) with engines (not sails). :)

cheers
Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/shop-marine-RFC-tp5869777p5869896.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] shop=marine RFC

2016-03-14 Thread Richard Fairhurst
Richard Z. wrote:
> this meaning is not even in wiktionary. How many of those shops
> would even know they are called chandler?

All of them, in my (fairly extensive) experience.

http://reader.waterwaysworld.com/fullsearch.cgi?q=chandlery

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/shop-marine-RFC-tp5869777p5869814.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Path with permit required for bikes?

2016-02-09 Thread Richard Fairhurst

Hi all,

An important part of the Pacific Coast Bicycle Route now requires 
cyclists to get a permit:



http://www.examiner.com/article/cycling-through-camp-pendleton-is-changing
https://mccscp.wufoo.com/forms/camp-pendleton-bike-route-access-form/

How should this be tagged?

It's not quite 'bicycle=permissive' - that's generally used to imply 
that bikes are allowed in by goodwill of the landowner but don't have to 
book, whereas in this case a permit has to be expressly applied for.


Some possibilities:

reservation:bicycle=required
bicycle=permit
bicycle=license
	   [little used, but see 
http://wiki.openstreetmap.org/wiki/Tag:access%3Dlicense]


(Incidentally, =license should of course be =licence, because the lingua 
franca of OSM is British English. ;) )


cheers
Richard

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Formalising shoulder tagging

2016-01-29 Thread Richard Fairhurst
dieterdreist wrote:
> yes, Standstreifen, Standspur, Seitenstreifen, Randstreifen. I've 
> improved the proposal to make this clearer for non-native people 
> (added a definition (from WP), added more German synonyms, 
> images)

Thanks to everyone who contributed.

I've accordingly formalised the page and moved it to
http://wiki.openstreetmap.org/wiki/Key:shoulder .

cheers
Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/Formalising-shoulder-tagging-tp5865799p5866229.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Discussion about Multivalued Keys

2016-01-27 Thread Richard Fairhurst
Matthijs Melissen wrote:
> Take for example your example shop=supermarket, 
> shop=bakery. Independent of the exact way of tagging, 
> using a multivalued tagging scheme forces the renderer 
> to make a decision between a supermarket and a bakery 
> icon. Basically, there is no possible way for the renderer 
> to support a multi-valued key here!

That's not at all true. A rendering chain can choose to split out multiple
values and then render a different icon for each one. You don't even need
any preprocessing - you can do it on-the-fly with a SQL query, and I've done
exactly that in one (Mapnik-based) map I've produced.

I realise _openstreetmap-carto_ doesn't do that, but osm-carto takes a very
conservative approach of not doing much additional processing to the data. I
can understand that approach, but that doesn't mean "there is no possible
way" for anyone else to do it.

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-Remove-name-1-and-alt-name-1-from-wiki-tp5865654p5865995.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Discussion about Multivalued Keys

2016-01-27 Thread Richard Fairhurst
Matthijs Melissen wrote:
> Do you have an demo rendering (screenshot is fine) for that?

There's actually a couple of ways you can do it, but
http://crt.systemed.net/ uses one method - look for the brown service icons
which are next to each other. It's not OSM data in this case (it's the Canal
& River Trust's GIS data), but it is Mapnik and the principle is equivalent:
pulling multiple values from a single text field.

There are a couple of reasons I wouldn't recommend it for osm-carto, but
maybe in a couple of years we'll all have moved to GL-based rendering and
the styling decisions will be different. ;)

cheers
Richard




--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-Remove-name-1-and-alt-name-1-from-wiki-tp5865654p5866011.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Discussion about Multivalued Keys

2016-01-27 Thread Richard Fairhurst
Colin Smale wrote:
> If we were looking at this problem as if we were 
> designing OSM on a clean whiteboard

When OSM was first designed on a clean whiteboard[1], multiple values were
in fact possible. An object could have

name=Bridge Street
name=Banbury Road

and the API was happy - though, in practice, no (/very little) software
supported it.

This ability was only removed in API 0.6:

https://lists.openstreetmap.org/pipermail/talk/2009-January/033437.html

Richard

[1] beer mat



--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-Remove-name-1-and-alt-name-1-from-wiki-tp5865654p5866023.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Formalising shoulder tagging

2016-01-26 Thread Richard Fairhurst

Hi all,

At present there is no documented standard for tagging highway shoulders.

We have http://wiki.openstreetmap.org/wiki/Shoulder with 
shoulder=yes|no, which has been in 'draft (under way)' since 2010. In 
Australia, cycleway=shoulder appears also to be used.


Taginfo stats are:
shoulder = *7120, of which:
shoulder = no   3230
shoulder = yes  2743
shoulder = right964
shoulder:width = *  1794
shoulder:right = *  1047
width:shoulder = *  843
cycleway = shoulder 502

There are several gazillion miles (approximate value) of roads with 
shoulders around the world. We should have a way to tag them.


I'd therefore suggest simply formalising the most popular existing usage 
and the one on the wiki page - that is, shoulder=yes|no. As a default, 
I'd suggest shoulder=yes is presumed as the most common real-world 
situation, i.e.:


"A paved shoulder, wide enough to be used as an emergency
 refuge for cars, and for through passage by bicycles."

(Narrow shoulders can of course be tagged with shoulder:width, gravel 
ones by shoulder:surface, and so on.)


There are of course many refinements one could imagine, for peak-hour 
shoulder running, buses, etc. But since "the perfect is the enemy of the 
good" etc., I'd like to get the basic shoulder=yes|no agreed first.


Speak now or forever hold your peace!

cheers
Richard

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Please don't think name_1 tags are errors.

2016-01-15 Thread Richard Fairhurst
Kieron Thwaites wrote:
> Whichever iD developer thought that adding random _N suffixes was 
> a good idea deserves to be taken out back and shot.

Please withdraw that comment.

Advocating violence to people is not funny. You might want to say a
_feature_ should be taken outside and shot, but don't extrapolate it to a
person.

Being abusive to developers is not funny either. OpenStreetMap is unlikely
to prosper in an environment where the (precious few) developers can expect
to be abused on any random mailing list or issue tracker.

Thank you.

Richard
tagging@ list admin




--
View this message in context: 
http://gis.19327.n5.nabble.com/Please-don-t-think-name-1-tags-are-errors-tp5864875p5864887.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] highway = track vs. residential

2016-01-08 Thread Richard Fairhurst
Greg Troxel wrote:
> I more or less agree, from the US point of view, except that
> highway=residential has a meaning of something that is 
> legally a road.

highway=residential in the US _largely_ has the meaning "this was imported
from TIGER feature code A41 and hasn't been changed". One import - albeit a
fairly massive one :) - isn't in itself a reason to strike out on a
different way of tagging from the rest of the developed world.

> The real bug here is that we need to fix the tagging system to 
> make clear legal status and type vs. physical condition.

The tagging system already does that. You have the access=* tags, operator=*
tags, and designation=* tags for the former; and you have surface=*,
tracktype=*, lanes=* etc. for the latter. highway=* is a broad overview
covering the road's importance - it isn't intended to encapsulate absolutely
everything about a road in one magic value.

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/highway-track-vs-residential-tp5864267p5864408.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] highway = track vs. residential

2016-01-08 Thread Richard Fairhurst
Mike Thompson wrote:
> Although these are gravel surfaced roads (not yet tagged that way, 
> but physically that is what they are), the ones in question provide 
> access to two or more homes and/or ranches.  To me these are 
> not "tracks" but "residential." Before I change these back, I 
> wanted to check with the community.

Generally, in developed countries, highway=residential is predominantly used
for public roads in/near nucleated settlements with housing alongside. It's
more nuanced than simply "a road with a house on it" - "a road of
residential character" would be closer.

In the case you've pointed to I would therefore err towards
highway=unclassified, surface=gravel (or =unpaved in the case of armchairing
when the imagery's unclear). I wouldn't man the barricades against either
=residential or =track, but the latter is best reserved for ungraded
double-tracks and worse.

_However_, I absolutely would man the barricades to advocate surface tags,
and I'm really pleased to see you've added one. highway=track isn't ideal
for this road, but it's a whole bunch better than highway=residential with
no surface tag. There are a couple of places in the rural US (particularly
Kansas, occasionally Oregon) where mappers have removed the tiger:reviewed
tag on rural dirt/gravel roads without adding a surface tag, at which point
the road is indistinguishable from a nice paved street in a housing estate
and routing basically goes to s--t.

(In retrospect... when the TIGER import was run, we should have imported
A41-class roads as highway=residential in urban areas, and highway=road,
fixme=yes in rural areas, using urban area polygons to distinguish between
the two. But that's all natural=water under the bridge=yes.)

cheers
Richard




--
View this message in context: 
http://gis.19327.n5.nabble.com/highway-track-vs-residential-tp5864267p5864323.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] highway = track vs. residential

2016-01-08 Thread Richard Fairhurst
dieterdreist wrote:
> what's your stance on service?

Slightly difficult one, but I'd tend to concur with Florian that it's best
used for roads on private property (roughly "access-only"). When I use it I
always try and add an access and (if unpaved) surface tag - it's too
ambiguous otherwise.

cheers
Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/highway-track-vs-residential-tp5864267p5864342.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Sidewalk Tagging for Routing

2015-11-24 Thread Richard Fairhurst
John Willis wrote:
> Perhaps we can have a routing engine at will interpret 
> a sidewalk with residential road junctions as being 
> along a residential road and route for Jay Walking. 
> [...]
> I would rather the router always error on the side of 
> crosswalks

Jaywalking is a North American concept. Here in the UK you can walk wherever
you like, whether the road is residential, an A (primary/trunk) or B
(secondary) road or whatever - anywhere apart from a motorway or somewhere
else with an explicit prohibition. Please don't suggest that routers should
export this people-hostile custom to other countries!

http://www.vox.com/2015/1/15/7551873/jaywalking-history


Another issue with routing along pavements ("sidewalks") as separate ways is
the name tag. IME pavement-mappers rarely add the street name to the
pavement/sidewalk, but in fact the name applies to the pavement/sidewalk as
much as to the bicycle/car lanes. "Walk along unnamed footway then turn left
onto unnamed footway" is a less helpful direction than "Walk along Broad
Street then turn left onto Cornmarket Street". (The ref, on the other hand,
usually applies only to the bicycle/car lanes.)

Richard




--
View this message in context: 
http://gis.19327.n5.nabble.com/Sidewalk-Tagging-for-Routing-tp5860841p5860877.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "What can I ask ..." list for browsing people

2015-11-12 Thread Richard Fairhurst
André Pirard wrote:
> Thanks for your guessing what Simon means. Thanks for watching 
> on us, constable.

Please moderate your language. Thank you.

Richard
tagging@ list admin




--
View this message in context: 
http://gis.19327.n5.nabble.com/What-can-I-ask-list-for-browsing-people-tp5858567p5859943.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


  1   2   >