Re: [Tagging] Proposal: Use description instead of name for route relations

[Paul Johnson]

Presently, it's common for route relations to have names that violate "name
is only the name" and "name is not ref" and "name is not description" rules
for name=* tags.

On Sun, Oct 8, 2023, 10:24 Volker Schmidt  wrote:

> Could you give some more examples to illustrate what the problem is that
> you want to resolve.
>
>
> On Sun, 8 Oct 2023, 00:23 Kevin Kenny,  wrote:
>
>>
>>
>> On Sat, Oct 7, 2023 at 4:50 PM Andrew Hain 
>> wrote:
>>
>>> I have started a new proposal: that the name tag should be restricted to
>>> the same meaning for route relations that it has on other elements and that
>>> the description tag should be used otherwise.
>>>
>>
>> The proposal is unclear and appears to deprecate route and way names of a
>> form that are common around here for what I consider to be good reasons.
>> (In any case, 'description' appears to be an inappropriate tag for whatever
>> it is you are proposing.) More details on the talk page.
>> --
>> 73 de ke9tv/2, Kevin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Use description instead of name for route relations

[Paul Johnson]

On Tue, Oct 17, 2023 at 4:51 AM Warin <61sundow...@gmail.com> wrote:

>
> On 17/10/23 04:17, Paul Johnson wrote:
>
> Presently, it's common for route relations to have names that violate
> "name is only the name" and "name is not ref" and "name is not description"
> rules for name=* tags.
>
>
> I don't find it common in 'my area' of mapping. One or two examples would
> demonstrate the situation?
>
>
> In any case:
>
> The name tag is used on may things for example; buildings, parks, schools,
> highways ...
>
> The use of the name tag as 'name only' applies where ever the name tag is
> used. This is similar for other tags such as elevation, width, colour etc.
> No matter what feature they are used on the tags carry the same
> characteristics and restrictions. It is not necessary to repeat
> these characteristics and restrictions for every main feature.
>
Routes have names, too!  For example, here's the relation for OK 51, named
for the name of the route.  https://www.openstreetmap.org/relation/3108562

Meanwhile, I 40 in Arkansas has a good example of a name that is actually a
ref and a description, not a name.
https://www.openstreetmap.org/relation/6843700

 Finally, OK 19 is an example of a properly described no-name route.
https://www.openstreetmap.org/relation/7479405
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Use description instead of name for route relations

[Paul Johnson]

On Wed, Oct 18, 2023 at 2:31 AM Warin <61sundow...@gmail.com> wrote:

>
> On 17/10/23 23:22, Paul Johnson wrote:
>
>
>
> On Tue, Oct 17, 2023 at 4:51 AM Warin <61sundow...@gmail.com> wrote:
>
>>
>> On 17/10/23 04:17, Paul Johnson wrote:
>>
>> Presently, it's common for route relations to have names that violate
>> "name is only the name" and "name is not ref" and "name is not description"
>> rules for name=* tags.
>>
>>
>> I don't find it common in 'my area' of mapping. One or two examples would
>> demonstrate the situation?
>>
>>
>> In any case:
>>
>> The name tag is used on may things for example; buildings, parks,
>> schools, highways ...
>>
>> The use of the name tag as 'name only' applies where ever the name tag is
>> used. This is similar for other tags such as elevation, width, colour etc.
>> No matter what feature they are used on the tags carry the same
>> characteristics and restrictions. It is not necessary to repeat
>> these characteristics and restrictions for every main feature.
>>
> Routes have names, too!  For example, here's the relation for OK 51, named
> for the name of the route.  https://www.openstreetmap.org/relation/3108562
>
> Meanwhile, I 40 in Arkansas has a good example of a name that is actually
> a ref and a description, not a name.
> https://www.openstreetmap.org/relation/6843700
>
>  Finally, OK 19 is an example of a properly described no-name route.
> https://www.openstreetmap.org/relation/7479405
>
>
> Ok. I still don't see a necessity of repeating the name tag information
> inside the relation tag... Will you also repeat the ref tag information,
> the description tag information? How about the surface tag, maxspeed tag
> etc etc..
>
The name of the route has nothing to do with the name of the member ways.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Do we map pedestrian crossings twice?

[Paul Johnson]

On Tue, Jun 9, 2020 at 9:03 PM Jack Armstrong 
wrote:

> Users have been adding pedestrian crossing tags on ways in addition to the
> street connecting nodes. In effect, a single pedestrian crossing is tagged
> twice. To me, this would seem contrary not only to the OSM wiki page,
> “Tag:highway=crossing”, but also contrary to, “One feature, one OSM
> element”.
>
Looks like two double carriageway roads.  Effectively two crosswalks for
each road thanks to the roadway going each way.  So, 8 crossings is correct
in this case.  Granted, bad design from a safety perspective, but that's
not on us, that's on whatever engineer thought that was a good idea.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag correct number of lanes for freeway on/off ramps?

[Paul Johnson]

On Fri, Jul 3, 2020 at 3:19 PM Matthew Woehlke 
wrote:

> Consider https://www.openstreetmap.org/#map=17/42.85888/-73.77169. As I
> write this, I-87 is annotated as having 3 lanes south of the on/off
> ramps (south of 146). However, the off ramp starts all the way back at
> the Sitterly Road overpass, and the on ramp doesn't fully merge until
> just before the emergency vehicle turn-around only slightly north of
> said overpass. Accordingly, there are actually four lanes for these
> stretches.
>
> What is the correct way to model this?
>

It's hard for me to explain so try the example in
https://www.openstreetmap.org/changeset/87518597#map=14/42.8442/-73.7720 on
for size?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Paul Johnson]

On Sun, Jul 12, 2020 at 11:48 AM Robert Skedgell  wrote:

> On 12/07/2020 15:48, Mike Thompson wrote:
> > Hello,
> >
> > According to the wiki[0], it seems that the network tag has different
> > meanings and possible values based upon if it is applied to a route
> > relation where route=road vs. route=bicycle/mtb/foot/etc.
> >
> > If I am understanding this correctly, when route=road, network= the
> > specific network that the road is part of, for example, a US Interstate
> > would be US:I[2]
> >
> > For bicycle/mtb/foot etc. it seems that the network tag indicates the
> > scope of the network, for example a nationwide network cycling network
> > would network=ncn[1]
> >
> > 1) Why can't the network tag have consistent meaning across all route
> > types? For a mapper, as well as a data user, this is confusing.
> > 2) The scope of a cycling/walking/etc. network should be evident from
> > the geographic extent of its members, so isn't network=icn/ncn/etc.
> > redundant? In any event, if the specific network is specified, it will,
> > in most cases, also indicate the general scope.
> How do you know the scope of a network if there is no tag to indicate
> that member routes belong to it?
>
> The very short NCN route 425 in south-east London is network=ncn because
> it's a Sustrans route. THe scope of the route is very local, but the
> scope of the network is national. Without the network tag, how would a
> renderer or router determine whether it was an ncn, rcn or lcn? All
> three exist in Greater London.
> https://www.openstreetmap.org/relation/4247567
>

Ideally?  Make it work like the route=road networks.  "network=UK"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Paul Johnson]

Disambiguation.  US:FS:Hood and US:FS:Ozark are two different national
forest service networks with entirely different numbering schemes.  Plus
network=CA by itself would be Canada, not California, which is US:CA...

On Sun, Jul 12, 2020 at 5:07 PM Peter Elderson  wrote:

> Well, recreational routes and networks simply are not that organized, and
> jurisdiction or authority doesn't apply to most of them. I guess that is
> why the values are more generic.
>
> I still don't understand why you tag "US" while it's obviously a bunch of
> roads in the US. or Interstate when the road clearly crosses state lines. I
> think that"s more redundant than tagging "we classify this route as a
> regional route", even though it might cross two national borders in a few
> places and half the roads are outside our borders, and we don't know the
> current operator or provider.
>
> Peter Elderson
>
> Op 12 jul. 2020 om 23:41 heeft Mike Thompson  het
> volgende geschreven:
>
> 
>
>
> On Sun, Jul 12, 2020 at 9:53 AM Peter Elderson 
> wrote:
>
>> Aren't Interstate and US evident from the geographic extent as well?
>>
> Yes, that is my point, or at least it is evident with the current mapping
> practice.  Road routes are not tagged (at least not according to the wiki)
> with network=nrn/rrn/etc.  Whether a road network is national, or
> otherwise, is evident for two reasons:
> 1) All the routes with the same network tag will be spread across some
> geographic extent. So, one could see that there are routes all across the
> US with "network=US:I" and could conclude that this is a national network.
> 2) By the network tag itself, for example, in the "network=US:I" tag,
> there is no smaller jurisdiction indicated after US, so it must be a
> national network.
>
> If a hiking route was tagged with network=US:FS (Forest Servies) for
> example, one could see that (if that practice was generally followed), that
> there the Forest Service operates hiking routes all across the US (and not
> anywhere else), and thus that such a network was national in scope.  And,
> the scope would be evident from the network tag itself, as there is no
> smaller jurisdiction following "US" in the network tag.
>
> In anyevent, my main point is we should be consistent and treat all route
> relations the same.  If it is desirable to explicitly know the scope, why
> not have a "scope" tag, or leave the scope in the network tag, and have a
> new tag for "specific_network" (or whatever folks want to call it).
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Paul Johnson]

On Mon, Jul 13, 2020 at 1:04 AM Peter Elderson  wrote:

> Sounds to me that the scheme is creating a problem rather than solving
> it... requiring a lot of prior knowledge and tables to code, and expert
> knowledge and tables to decode.
>

It's the same scheme already used for highways.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Paul Johnson]

On Sun, Jul 12, 2020 at 7:00 PM Mike Thompson  wrote:

>
>
> On Sun, Jul 12, 2020 at 4:18 PM Paul Johnson  wrote:
> >
> > Disambiguation.  US:FS:Hood and US:FS:Ozark are two different national
> forest service networks with entirely different numbering schemes.  Plus
> network=CA by itself would be Canada, not California, which is US:CA...
> Paul, do you have a list of accepted abbreviations for our various
> National Forests in the US?  Is it on the wiki?
>

 I don't, seems like by extension it works like county routes, where it's
US:FS:Name.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Paul Johnson]

I thought we were talking about bicycle routes, not recreational routes.

On Mon, Jul 13, 2020 at 11:22 AM Peter Elderson  wrote:

> I can't see how that applies to recreational route networks in Europe.
>
> Mvg Peter Elderson
>
> Op 13 jul. 2020 om 15:33 heeft Paul Johnson  het
> volgende geschreven:
>
> 
>
>
> On Mon, Jul 13, 2020 at 1:04 AM Peter Elderson 
> wrote:
>
>> Sounds to me that the scheme is creating a problem rather than solving
>> it... requiring a lot of prior knowledge and tables to code, and expert
>> knowledge and tables to decode.
>>
>
> It's the same scheme already used for highways.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Paul Johnson]

What is a recreational route and how's it got anything to do with talking
about modality?

On Mon, Jul 13, 2020 at 1:25 PM Peter Elderson  wrote:

> Nederland, Germany and Belgium also have walking routes, horse routes,
> inline-skating routes, canoe routes, motorboat routes. Also a myriad of
> node networks for all the modalities, some completely developed and
> covering the country (cycling node networks), some almost nation-wide but
> locally or regionally maintained (walking node networks), some in the early
> stages but spreading rapidly, also to other countries (Austria, France,
> Spain).
> The lXn, rXn, nXn, iXn system, combined with network:type=node_network,
> operator, and ref, , covers all recreational routes, in many countries with
> very different systems of administration and maintenance.
>
> If there is a conflict between the use of those routes and the highway
> road routes coding system, that would be a problem requiring a solution.
> Perceived inconsistency  between clearly different uses of the route
> relation iis not.
>
> I think this recreational route network coding has earned its place.
> Still, if an actual problem arises, I would be happy to help solve it. I
> know some people think the network=XXn system is principally flawed and
> should never have been approved, but I have yet to see one actual problem
> and it appears to do the job around the world, for recreational routes of
> all scopes and modalities, even though countries have very different
> administration and maintenance systems from completely central to
> distributed and chaotic, and different for most modalities.
>
> Best, Peter Elderson
>
>
> Op ma 13 jul. 2020 om 18:51 schreef Volker Schmidt :
>
>>
>>
>>
>> I am not saying get rid of the network tag, I am saying we should be
>>> consistent.  In the above case, if  network=UK (instead of network=ncn),
>>> one would know it is national. First because the UK is a nation and there
>>> is no smaller jurisdiction that follows "UK" in the tag, and because there
>>> would be cycle routes all over the UK where network=UK.
>>>
>>
>>
>> Numbering in the UK reflects the "importance" of a route:
>> National routes carry two-digit numbers
>> Regional routes carry three-digit numbers
>> Local cycle routes are less consistently labelled.
>> OSM, born in the UK  has inherited this approach
>>
>> The UK national bicycle network is managed by Sustrans - see
>> https://www.sustrans.org.uk/national-cycle-network
>>
>> Similarly tiered systems exist in the Netherlands and Germany.
>>
>> In Italy there is a similar approach, that mirrors the administrative
>> organisation of the country: National routes connect several regions.
>> Regional routes connect severela provinces and local routes are typically
>> within a single province.
>>
>> Volker (Italy)
>>
>>
>>
>>
>>
>>
>> 
>>  Virus-free.
>> www.avast.com
>> 
>> <#m_-2347637413674922412_m_-5475564013638110848_m_3447769538172802524_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Intermittent highways?

[Paul Johnson]

On Tue, Jul 14, 2020 at 11:23 AM John Sturdy  wrote:

> I've been adding some detail to a site that is used annually for a
> festival (not happening this year because of Covid-19), where there are
> paths in the same place year after year, but the paths are not there when
> the festival is not happening, although increased wear on the ground around
> them is probably visible much of the time.
>

I think you're looking for conditional access.  For example, every year in
the fall, 3rd Street next to the BOK Center is regularly closed to motor
vehicles and converted to a festival space complete with ice skating rink.
https://www.openstreetmap.org/way/355519818
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag minor commercial roads?

[Paul Johnson]

On Thu, Jul 16, 2020 at 12:17 PM Matthew Woehlke 
wrote:

> I'm wondering what, if anything, I should do with
> https://www.openstreetmap.org/way/351516889. It doesn't seem to meet the
> definition of a highway=residential, but I'm not convinced it is a lowly
> highway=service, either, but I also can't easily demonstrate it is
> highway=tertiary.
>
> How should I classify this?
>

Unclassified?  It's the de-facto step down from tertiary.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] narrow=yes, vs lanes=1, vs width

[Paul Johnson]

On Mon, Jul 27, 2020 at 8:37 AM Rob Savoye  wrote:

>   The question is how to tag the change in the road. Usually it becomes
> "smoothness=very_bad", etc... The question is since it's now more of a
> track used by jeeps, should it be narrow=yes, still lanes=1, or should I
> use width=2m ? To me, lanes= seems to apply more to non 4wd_only tracks.
> They're also usually narrower than the single lane highway too. The
> width of the "highway" is important if you're trying to figure out what
> size fire truck to bring to the wildland fire...
>

highway=track.  There's no lanes, so leave that tag off.  Never heard of
narrow=yes before.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

[Paul Johnson]

On Mon, Jul 27, 2020 at 10:18 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Date: Jul 27, 2020, 15:54
> From: ba...@ursamundi.org
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] narrow=yes, vs lanes=1, vs width
>
>
>
> On Mon, Jul 27, 2020 at 8:37 AM Rob Savoye  wrote:
>
>   The question is how to tag the change in the road. Usually it becomes
> "smoothness=very_bad", etc... The question is since it's now more of a
> track used by jeeps, should it be narrow=yes, still lanes=1, or should I
> use width=2m ? To me, lanes= seems to apply more to non 4wd_only tracks.
> They're also usually narrower than the single lane highway too. The
> width of the "highway" is important if you're trying to figure out what
> size fire truck to bring to the wildland fire...
>
>
> highway=track.  There's no lanes, so leave that tag off.  Never heard of
> narrow=yes before.
>
> highway=track appears to be incorrect here (but may be still correct if it
> is leading to
> only vacation huts)
>

3 and 4 digit forest service roads?  They're there exclusively there for
the benefit of forestry (namely logging, replanting and fire suppression).
If they happen to help someone else get where they're going, great, but
that's not what they're built and maintained for.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

[Paul Johnson]

I'd go with highway=track and tracktype=*, surface=* and smoothness=* tags
as necessary.  Given how inconsistent the 3 and especially 4 digit US
forest service roads tend to be, I'd expect tracktype and smoothness are
underutilized despite their relative importance on those roads.

A big hint:  There's three types of USFS shields in use for the same series
of networks.  Each forest has its own network.  The 5 sided shields with 1
or 2 digit numbers are paved highways, usually two or three lanes and
traversable at a decent clip.  For 3 and 4 digit roads, it's usually just a
brown rectangular placard with the number by itself.  If the placard has a
horizontal orientation (read from left to right), then it's intended to be
passable by most vehicles but may or may not be paved.  If the placard has
a vertical orientation (read from top down), then don't count on your car
being able to make it, you'll probably need something with ground clearance
and 4WD if it's traversable at all with a motor vehicle.

On Mon, Jul 27, 2020 at 11:46 AM Rob Savoye  wrote:

> On 7/27/20 9:18 AM, Mateusz Konieczny via Tagging wrote:
>
> > highway=track appears to be incorrect here (but may be still correct if
> > it is leading to only vacation huts)
>
>   It's a residential "track" to the vacation houses, often usually only
> used in the summer or for ski trips. After the last building it
> degenerates into a worse track. While changing
> highway/smoothness/tracktype/surface at that transition spot helps, they
> also often get much narrower.
>
> - rob -
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

[Paul Johnson]

On Mon, Jul 27, 2020 at 12:21 PM Rob Savoye  wrote:

>   Personally though, what the USFS uses to determine that difference
> doesn't seem consistent, and over many years, the road conditions change
> drastically due to erosion. I prefer to go there in a high-clearance
> vehicle or UTV and decide after driving it.
>

Right, always a good idea (especially with the 4-digit roads).  Just trying
to give some insight as to the forest service's thought process.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

[Paul Johnson]

On Mon, Jul 27, 2020 at 2:56 PM Rob Savoye  wrote:

> On 7/27/20 1:04 PM, Martin Koppenhoefer wrote:
> >> highway=track appears to be incorrect here (but maybe still correct
> >> if it is leading to only vacation huts)
> >> these would be highway=service not track.
>
>   I assume if the highway has no name, it'd be highway=service, but if
> it has a county name, like "Lost Gulch Road" too, wouldn't it then be
> highway=residential? Is there a difference if it's vacation cabins, or
> seasonal or full-time houses ?
>

I don't think so.  The typical named forest service road isn't typically
better or worse than the unnamed ones that only go by their ref.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

[Paul Johnson]

On Tue, Jul 28, 2020 at 5:52 AM Martin Koppenhoefer 
wrote:

>
>
> Am Di., 28. Juli 2020 um 11:35 Uhr schrieb Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org>:
>
>>
>> I treat these like this: the public part (if any) up to the property as
>> residential (eventually as service) and the part on private grounds as
>> service+driveway. Never use the driveway tag on public ways
>>
>> Why? Driveway may be public both as in
>> "available to use by general public"
>> and "constructed on land owned by
>> government or other public entity" or
>> both at the same time.
>>
>
>
> citation needed...
>

The turnaround on Larch Mountain Road, on Larch Mountain, Oregon.  Hood NF
15 becomes Hood NF 1500-021 for a moderately sized one-way trailhead
driveway.

Camp Baldwin Road, Camp Baldwin, Oregon.  I believe the main entrance is
Hood NF 4450 and the road has been impassable through the north side of
camp for decades due to an archery range being in the way.  Looks like Hood
National Forest recently renumbered things so where 4450 used to leave the
north end of the camp before it was built is now 4460-140
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[Paul Johnson]

On Fri, Jul 31, 2020 at 8:53 AM David Marchal via Tagging <
tagging@openstreetmap.org> wrote:

> Hello, there.
>
> I'm wondering, there are destination signs which only apply to some kind
> of vehicles: for HGV, for bicycles, for pedestrians, for vehicles below
> 12t… How would I tag such destinations? The simple way would be to use,
> respectively, destination:hgv=*, destination:bicycle=*, destination:foot=*,
> destination:conditional="* @ weight<12". Am I right to assume these?
>

access=destination, bicycle=destination, foot=destination,
access:conditional=destination @ weight<12
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Paul Johnson]

On Fri, Jul 31, 2020 at 11:24 AM Jmapb  wrote:

> Is it best to simply tag addr:street=NY 214, matching the ref tag of the
> segment and the name tag of the route? This isn't consistent with the
> wiki, which specifically says addr:street should match the *name* of a
> nearby *way*.


I'd go with the official address.  It's not rare to find addresses in the
US where what goes on an envelope doesn't match what the street is actually
called.  Nor is it rare to find the wiki to be wrong, such as is the case
with lanes, where excluding lanes for motorcyclists and bicyclists is in
the wiki but fails on the ground verifiability.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Paul Johnson]

On Fri, Jul 31, 2020 at 2:00 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 31. Jul 2020, at 18:25, Jmapb  wrote:
> >
> > But most of the ways in the route have no valid name. Segments were
> > imported from TIGER with name=State Highway 214 but that's been removed
> > in favor of ref=NY 214.
>
>
> around here we keep both, no need to remove the name if it makes sense.
> State Highway 214 looks like a reasonable name, especially outside of
> builtup areas.
>

Name is only the name.  Names are not refs.  For the above example, ref=NY
214, noname=yes would be the right way.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Paul Johnson]

Given that it's not customary or advisable to reproduce ref in the name
field, kinda think that's not the worst policy for old_ref=* situations
that have no name, as well by extension, but that's a bit more of a grey
area still.

On Fri, Jul 31, 2020 at 2:14 PM Joseph Eisenberg 
wrote:

> I agree.
>
> Proof of this is that a section of road which was formerly US Highway 99,
> but where the highway ref is now on a new bypass, will often by signed as
> “Old Highway 99”, so it’s reasonable to say that the name=* was “Highway
> 99” before.
>
> -Joseph Eisenberg
>
> On Fri, Jul 31, 2020 at 12:01 PM Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 31. Jul 2020, at 18:25, Jmapb  wrote:
>> >
>> > But most of the ways in the route have no valid name. Segments were
>> > imported from TIGER with name=State Highway 214 but that's been removed
>> > in favor of ref=NY 214.
>>
>>
>> around here we keep both, no need to remove the name if it makes sense.
>> State Highway 214 looks like a reasonable name, especially outside of
>> builtup areas.
>>
>> Cheers Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Paul Johnson]

So keep State Highway 214 in addr:street=* values, but that doesn't stop
noname=yes and ref=NY 214 being the correct values for the way itself.

On Fri, Jul 31, 2020 at 2:40 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 31. Jul 2020, at 21:31, Paul Johnson  wrote:
> >
> > Name is only the name.  Names are not refs.  For the above example,
> ref=NY 214, noname=yes would be the right way.
>
>
> the authority for names are the local people. I would bet that some of
> them would refer to this particular road as State Highway 214 if they
> should name it in a formal way. NY 214 is a ref, no doubt, and is fine to
> have, but so is State Highway
>
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Paul Johnson]

On Fri, Jul 31, 2020 at 3:16 PM Kevin Kenny  wrote:

> The reductio-ad-absurdum would be to argue that 42nd Street in Manhattan
> should be `noname=yes ref=???` and participate in a route relation with
> `network=US:NY:New York:Street ref=42`. I'm sure that would please strict
> taxonomists, but most people would think it silly to argue that the name of
> the road at the downtown end of Times Square isn't 'Forty-Second Street'.
> If 42nd Street can be a name, why can't County Route 23C?
>


> There are even parallels for 'the road has a name other than the ref, but
> the ref remains the common name' in Manhattan. Sixth Avenue is also named
> Avenue of the Americas. Nowadays, it carries signs for both, but I can
> remember a time when the locals and the subway said 'Sixth Avenue' and the
> street signs said 'Avenue of the Americas', confusing the tourists.  These
> are 'name' and 'alt_name', not 'name' and 'ref'; Sixth Avenue was there
> first. (Also see Seventh Avenue/Fashion Avenue - only in the Garment
> District; Fourth Avenue/Park Avenue South - the segment south of Union
> Square
>

If you're trying to argue that "Sixth Street" is not a name, I'm not
buying.  Especially when you call out that it's absurd to suggest it is.
Or that you don't understand the difference between a name and a ref.  Or
that you don't understand why data consumers may find conflating the two to
be confusing or annoyingly redundant.  Surely you give our intelligence
more credit than that, don't you?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Paul Johnson]

On Fri, Jul 31, 2020 at 5:53 PM Tod Fitch  wrote:

>
>
> > On Jul 31, 2020, at 12:45 PM, Paul Johnson  wrote:
> >
> > So keep State Highway 214 in addr:street=* values, but that doesn't stop
> noname=yes and ref=NY 214 being the correct values for the way itself.
> >
>
> Which will, as I have found by experience, result in OSM QA tools flagging
> you as the last editor of a bunch of addresses with no matching street.


 Sounds like a problem with the QA tool.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Paul Johnson]

On Fri, Jul 31, 2020 at 6:59 PM Clifford Snow 
wrote:

>
>
> On Fri, Jul 31, 2020 at 11:54 AM Kevin Kenny 
> wrote:
>
>>
>>
>> The nearest problem case to me is Ahkwesáhsne, a territory of
>> the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy that straddles
>> the US-Canadian border, and whose government is recognized by neither
>> state. The political situation there has deteriorated into shootings as
>> recently as 1990, and sabre-rattling among US, Canadian and Akwesáhsro:non
>> persons as recently as 2009. The disputes usually stem from one or the
>> other large nation deciding to deny the Kanien'kehá free pratique to travel
>> and trade within their own nation, requiring customs and imposts every time
>> the US-Canadian border is crossed.
>>
>> Kevin,
> Has this disputed territory been map in OSM? I went looking for it but
> struck out. Just the name Ahkwesáhsne returned zero results.
>

I attempted to do so but was not able to proceed because of conflicting
information relying on dubious sources.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Paul Johnson]

I do not, which was a big problem with that.  I like mapping
weird boundaries like that, so I tried to take it on, but it seems there's
somewhat conflicting information between the tribe, US and Canada on this.
I strongly suspect we're going to need to find an Ahkwesáhsnean that knows
the boundaries well to get a solid cut on this and I'm not entirely sure
how to reach out.

On Fri, Jul 31, 2020 at 9:52 PM Clifford Snow 
wrote:

> Paul,
> Do you have any website or contact info for the tribe? There are a number
> of websites but not sure exactly which one. Although it be nice to get them
> all added.
>
> Clifford
>
> On Fri, Jul 31, 2020 at 7:17 PM Paul Johnson  wrote:
>
>>
>>
>> On Fri, Jul 31, 2020 at 6:59 PM Clifford Snow 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jul 31, 2020 at 11:54 AM Kevin Kenny 
>>> wrote:
>>>
>>>>
>>>>
>>>> The nearest problem case to me is Ahkwesáhsne, a territory of
>>>> the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy that straddles
>>>> the US-Canadian border, and whose government is recognized by neither
>>>> state. The political situation there has deteriorated into shootings as
>>>> recently as 1990, and sabre-rattling among US, Canadian and Akwesáhsro:non
>>>> persons as recently as 2009. The disputes usually stem from one or the
>>>> other large nation deciding to deny the Kanien'kehá free pratique to travel
>>>> and trade within their own nation, requiring customs and imposts every time
>>>> the US-Canadian border is crossed.
>>>>
>>>> Kevin,
>>> Has this disputed territory been map in OSM? I went looking for it but
>>> struck out. Just the name Ahkwesáhsne returned zero results.
>>>
>>
>> I attempted to do so but was not able to proceed because of conflicting
>> information relying on dubious sources.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Paul Johnson]

On Sat, Aug 1, 2020 at 12:19 AM Shawn K. Quinn  wrote:

> On 7/31/20 14:29, Paul Johnson wrote:
> > Name is only the name.  Names are not refs.  For the above example,
> > ref=NY 214, noname=yes would be the right way.
>
> How about the stretch of FM 1960 from I-45 or so going east into Humble?
> Addresses on it are " FM 1960 East", though I think it used to be
> signed as "Humble-Huffman Road" even though nobody puts that in the
> addresses anymore. I currently have name=FM 1960 East alongside ref=FM
> 1960 (and maybe an alt_name=* too). (For those outside of Texas, FM or
> RM is like a lower class of state highway called Farm-/Ranch-To-Market
> Roads.)
>

For the way:

name=Humble-Huffman Road
ref=FM 1960

For the address:
addr:street=FM 1960 East

I'm on the side that name=* should match what's in addr:street=*, even
> if there's some duplicity, but maybe there should be some other tag to
> say perhaps the name shouldn't be rendered on (most) visual maps and/or
> read out separately from the ref in navigation software.
>

Problem is, that does not necessarily match the ground truth.  In reality,
a lot of addresses have a street name that radically departs from what the
street is signposted as, particularly if the street is part of a
numbered route.  It's common because there's only so much you can cram on
an envelope and it's often shorter and easier to scrawl out "Hwy 12"
instead of the street name than whatever the highway department named it.

Plus, existing schemes of *not* reproducing the ref in the name already
solves the problem.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Paul Johnson]

On Sat, Aug 1, 2020 at 3:09 PM Clay Smalley  wrote:

> Chiming in as another settler. I really wish we had more Natives active on
> OSM contributing their cultural knowledge. What could we be doing different
> in the future to welcome and engage them in our community?
>

Outreach to tribal GIS offices where they exist couldn't hurt.  The
standard map rendering native areas, particularly when most don't (or in
Oklahoma's case, most are *egregiously* incomplete, often only including
the Osage Nation) definitely is a nice start and I'm glad we're to that.
At least in the north american context, having a separate tag for
indigenous lands seems a little strange compared to filing it under the
administrative boundary, admin_level system, but I can live with it.

On Sat, Aug 1, 2020 at 12:28 PM Kevin Kenny  wrote:
>
>> Both the US and Canada consider the river to be the US-Canada boundary,
>> and that the reservations are their separate dependencies. The Canadians
>> recognize the Six Nations as domestic dependent nations, and they enjoy
>> limited sovereignty on their own lands.
>>
>
> I think what you've said here hints at the answer. The US and Canada are
> UN member states with international recognition, each with an autonomous
> region under indigenous governance. The tribal governments themselves may
> dispute this, which is fair. Perhaps one day they might have an
> internationally recognized sovereign state with defined borders. But on the
> ground as of 2020, there are no such states, only subnational autonomous
> regions.
>

Well, there *was* Bolivia until last month, but Elon Musk helped finance a
coup so he could continue using the country as a cheap source of lithium
for car batteries.


> So I think the current tagging makes sense. Though I wonder if places like
> these qualify as disputed territory. After all, the US and Canada have a
> nation-to-nation relationship with each tribal government.
>

I don't believe that it counts as a disputed territory.  I also think
taking the US and Canada's claim of the tribe having two distinct
reservations with a shared boundary congruent with the US/Canada
international boundary is not substantiated by the ground truth.  It's a
single contiguous area, not two adjoining ones.  It happens to have the
US/Canada boundary going through it, and AFAICT, nobody's disputing that.
Just that this single contiguous tribal area happens to straddle that line.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Paul Johnson]

On Sat, Aug 1, 2020 at 8:09 PM Kevin Kenny  wrote:

>
>
> On Sat, Aug 1, 2020 at 5:29 PM Paul Johnson  wrote:
>
>> On Sat, Aug 1, 2020 at 3:09 PM Clay Smalley 
>> wrote:
>>
>>> Chiming in as another settler. I really wish we had more Natives active
>>> on OSM contributing their cultural knowledge. What could we be doing
>>> different in the future to welcome and engage them in our community?
>>>
>>
>> Outreach to tribal GIS offices where they exist couldn't hurt.  The
>> standard map rendering native areas, particularly when most don't (or in
>> Oklahoma's case, most are *egregiously* incomplete, often only including
>> the Osage Nation) definitely is a nice start and I'm glad we're to that.
>> At least in the north american context, having a separate tag for
>> indigenous lands seems a little strange compared to filing it under the
>> administrative boundary, admin_level system, but I can live with it.
>>
>
> It depends on the jurisdiction.  The non-Federal Schaghticoke reservation
> in Connecticut is simply part of Kent Township; there's a tribal government
> of sorts but it's not recognized by the BIA, and so there isn't really an
> admin_level that would fit.
>
> On the other hand, all of the Indian Reservations in New York are not part
> of either Towns or Cities, and so would slot in nicely at admin_level=7.
> The sole inconsistency that designation would introduce is that the city of
> Salamanca is entirely within the Allegany reservation. (Salamanca, and
> several smaller communities, have significant non-Haudenosaunee populations
> and stand on reservation land that is leased from the Seneca Nation.)
>

That's kind of my point.  In Oklahoma, there's at least 3 tribes that would
fall at admin_level=3, with the rest falling at 5 with a few at 4, all
depending on how their 19th century treaties were called, based on recent
Supreme Court rulings.

Not going to say "I told you so" but, anyone who's been on the OSM mailing
lists for the last 11 years and seen my points about American indigenous
land, well, thanks to Oklahoma v McGill, well, I told you so...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Paul Johnson]

On Sat, Aug 1, 2020 at 9:21 PM Clifford Snow 
wrote:

> If you look at eastern Oklahoma, about 90%, Paul - correct me if I'm
> wrong, is boundary=aboriginal_lands. Tulsa is pretty much completely inside
> of two different reservations.
>

Three, actually.  I live in the Muscogee Nation, now.  Last time indigenous
lands came up, I lived on my own tribe's land, within the same city.  My
tribe ceded land to the Osage Nation in the 19th Century because the US was
going to screw them out of everything and we were "gifted" with almost as
much land as the Navajo despite being a fraction of their size.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Paul Johnson]

CW: Politics, rightfully being denied the world because where I live is an
idiot.

Clarification: I'm Cherokee, Choctaw and Scottish, and I'm barred from
entering Choctaw and Scottish territory due to COVID19, and even without
the pandemic, it's harder for me to travel now (seriously, violate anything
remotely resembling UKIP lasciviously and involuntarily with a rusty,
tetanus-carrying fencepost for that; looking at you, UK Tories, US
Republicans, UKIP folks, and all other white nationalist enabling party
members in the US and UK specifically; really super appreciate being
marginalized *even more* by your direct actions, keep up the good work!  I
super love having a passport only valid in 3 countries worldwide, counting
my own, counting a country that super-hates everyone from my continent
anyway!  I love questioning why I should even bother having passport as a
result!).

On Sun, Aug 2, 2020 at 1:37 AM Paul Johnson  wrote:

>
>
> On Sat, Aug 1, 2020 at 9:21 PM Clifford Snow 
> wrote:
>
>> If you look at eastern Oklahoma, about 90%, Paul - correct me if I'm
>> wrong, is boundary=aboriginal_lands. Tulsa is pretty much completely inside
>> of two different reservations.
>>
>
> Three, actually.  I live in the Muscogee Nation, now.  Last time
> indigenous lands came up, I lived on my own tribe's land, within the same
> city.  My tribe ceded land to the Osage Nation in the 19th Century because
> the US was going to screw them out of everything and we were "gifted" with
> almost as much land as the Navajo despite being a fraction of their size.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Paul Johnson]

Also, seriously, no offense to Croatia, the only place in the world not
hostile to Americans that US passports are still accepted.  We don't
deserve that gesture, but I appreciate the self-sacrificing move if only to
not make us follow entirely in North Korea's footsteps.

On Sun, Aug 2, 2020 at 1:52 AM Paul Johnson  wrote:

> CW: Politics, rightfully being denied the world because where I live is an
> idiot.
>
> Clarification: I'm Cherokee, Choctaw and Scottish, and I'm barred from
> entering Choctaw and Scottish territory due to COVID19, and even without
> the pandemic, it's harder for me to travel now (seriously, violate anything
> remotely resembling UKIP lasciviously and involuntarily with a rusty,
> tetanus-carrying fencepost for that; looking at you, UK Tories, US
> Republicans, UKIP folks, and all other white nationalist enabling party
> members in the US and UK specifically; really super appreciate being
> marginalized *even more* by your direct actions, keep up the good work!
> I super love having a passport only valid in 3 countries worldwide,
> counting my own, counting a country that super-hates everyone from my
> continent anyway!  I love questioning why I should even bother having
> passport as a result!).
>
> On Sun, Aug 2, 2020 at 1:37 AM Paul Johnson  wrote:
>
>>
>>
>> On Sat, Aug 1, 2020 at 9:21 PM Clifford Snow 
>> wrote:
>>
>>> If you look at eastern Oklahoma, about 90%, Paul - correct me if I'm
>>> wrong, is boundary=aboriginal_lands. Tulsa is pretty much completely inside
>>> of two different reservations.
>>>
>>
>> Three, actually.  I live in the Muscogee Nation, now.  Last time
>> indigenous lands came up, I lived on my own tribe's land, within the same
>> city.  My tribe ceded land to the Osage Nation in the 19th Century because
>> the US was going to screw them out of everything and we were "gifted" with
>> almost as much land as the Navajo despite being a fraction of their size.
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Paul Johnson]

On Mon, Aug 3, 2020, 15:29 Jmapb  wrote:

>
> ...Regardless, if this general approach is considered valid and
> workable, then I'd like to propose the following answer to my original
> question:
>
>   * Q) How should `addr:street` be tagged for an address along an
> unnamed way which is part of a numbered road-type route relation?
>   * A) Check the way for alternative name tags. The official postal
> version of the street name may be tagged as `official_name`; if so
> that's a good value for `addr:street`. If the way has other name tags --
> such as `alt_name`, `local_name`, `old_name`, or a language-specific
> name -- those values may be used. It's also possible to use the value of
> the way's `ref` tag, which should match the name of the route relation.


Name is only the name, so most route relations wouldn't have a name.

Since the number of different variations on how one might address something
when the street name is on a numbered route, seems like it's on the data
consumer to fuzzy match appropriately to match an imperfect hit.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[Paul Johnson]

On Wed, Aug 5, 2020 at 3:45 PM Mike Thompson  wrote:

> Hello,
>
> If:
> access=no
> foot=yes
>
> Does this mean that all access except foot travel is prohibited, or is it
> an error?
>

Correct, only pedestrians are allowed.


> If:
> access=yes
> bicycle=no
>
> Does this mean that all access except bicycle travel is allowed, or is an
> error?
>

Correct, everything but bicycles allowed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[Paul Johnson]

On Fri, Aug 7, 2020 at 6:56 AM Simon Poole  wrote:

> This is why access=yes is useless on highway objects as it is not clear if
> it overrides implicit access restrictions or not.
>

I don't see what's not clear about access=* overriding *all* access not
explicitly set.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Paul Johnson]

On Fri, Aug 7, 2020 at 3:27 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> amenity=parking + vehicle=no + electric_scooter=yes
> seems like a terrible idea to me
>

Why?  That's actually pretty good.  amenity=parking is for motor vehicle
parking, electric scooters are a part of that.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Paul Johnson]

On Fri, Aug 7, 2020 at 12:00 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Aug 7, 2020, 18:05 by ba...@ursamundi.org:
>
> On Fri, Aug 7, 2020 at 3:27 AM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
> amenity=parking + vehicle=no + electric_scooter=yes
> seems like a terrible idea to me
>
>
> Why?  That's actually pretty good.  amenity=parking is for motor vehicle
> parking, electric scooters are a part of that.
>
> Mostly because it will break all current users of amenity=parking and at
> least for me place to place
> electric scooter is not the same object as a car parking (in the same way
> as bicycle parking
> is not the same object as a car parking).
>

I feel like a data consumer unable to deal with access tagging is already
broken in advance.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Paul Johnson]

On Sat, Aug 8, 2020 at 6:13 AM Jan Michel  wrote:

> On 07.08.20 23:36, Martin Koppenhoefer wrote:
> >> On 7. Aug 2020, at 19:12, Paul Johnson  wrote:
> >> I feel like a data consumer unable to deal with access tagging is
> already broken in advance.
> > although we already use access like tags for parkings it should be noted
> that being allowed to access is different to being allowed to park, in
> general.
>
> The only use of an amenity=parking is to park there, so there is no
> other access that we have to consider. The situation may be different
> for ways and streets on the parking lot, but these are tagged separately
> anyhow. If the whole area is also used for other purposes (like street
> markets), then this is tagged on a spearate object with separate access
> tags.
>

Which honestly makes me surprised we have two separate amenities for
parking already, since amenity=parking, access=no, bicycle=designated would
be equivalent to amenity=bicycle_parking, and would make it easier to
describe unusual parking situations (like a parking area that only allowed
bicycles and buses to park) more intuitively.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] VANDALISM !

[Paul Johnson]

On Fri, Aug 21, 2020 at 8:36 PM Clay Smalley  wrote:

> For those who aren't following, the DWG recently decided on a two-day ban
> for the person who posted this, for the exact behavior they're exhibiting
> right now: https://www.openstreetmap.org/user_blocks/3850
>
> jdd 3, please take a break. You have better things to do.
>
> I look forward to when you demonstrate the ability to communicate
> collaboratively.
>

I feel like now is a good time to remind folks that the wiki should be
descriptive of how things are actually mapped, not strictly proscriptive.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Hands Off !, respect my (our) space

[Paul Johnson]

On Mon, Aug 24, 2020 at 9:50 AM 80hnhtv4agou--- via Talk-us <
talk...@openstreetmap.org> wrote:

> In ID, on your profile page is, Other nearby users, and the home location,
> map
>
> the point is other locals based on my (our) edits know where we (I) live,
> but come on
>
> don’t edit the building i (we) live in !
>

 That's not the way OSM works.  Have you considered taking a break and
unwinding for a while?  There's already a steep learning curve for this
project, it doesn't really need to be exacerbated by gatekeeping.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Best practices regarding implied tags

[Paul Johnson]

On Wed, Sep 16, 2020 at 5:20 PM François Lacombe 
wrote:

> Is that completely wrong or mappers could eventually add implied tags if
> they want to?
> The proposal currently states they are optional and it won't raise an
> error if mappers add them beside mandatory tags.
>

No, it's not wrong to add implied tags explicitly.  It's actually
encouraged in some cases where the implicit tag is not consumable by
automated system (such as the "none" default for turn:lanes tends to be
ambiguous between "you can't turn from this lane" and "you can't use this
lane" and "there's an implicit but unspecified implication that isn't
painted on the ground"), or access defaults (such as in the US where
bicycle=* and foot=* varies a lot on highway=motorway)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Best practices regarding implied tags

[Paul Johnson]

On Sun, Sep 20, 2020 at 11:58 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> The previous responses are focusing on the benefit of adding explicit tags
> in situations where the current tagging is ambiguous.
>
> Certainly there is a benefit of adding "oneway=no" on all two-way roads
> and "oneway=yes" on motorways to make the situation explicit.
>
> But the original question was about whether or not we should add
> "man_made=utility_pole" + "utility=power" to current power poles.
>

Well, does narrow it down from a neighborhood pole that might have cable
television or carry the PSTN.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=services on bicycle routes?

[Paul Johnson]

On Fri, Oct 9, 2020 at 3:06 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> For me it sounds sort-of similar (the same definition, just swap "motor
> vehicle" with "bicycle",
> or use "vehicle" to cover both ) but with drastically different
> functionality.
>
> Similarly like "parking" and "bicycle parking" or "motorway" and
> "cycleway".
>

 Eeeh, motorway and cycleway make sense because they're definitely two
fairly different beasts, but for amenities and parking, motor_vehicle=no,
bicycle=designated seems like a better idea in retrospect.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=services on bicycle routes?

[Paul Johnson]

On Fri, Oct 9, 2020 at 12:38 PM Mateusz Konieczny 
wrote:

>
> 9 paź 2020, 15:33 od ba...@ursamundi.org:
>
> On Fri, Oct 9, 2020 at 3:06 AM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
> For me it sounds sort-of similar (the same definition, just swap "motor
> vehicle" with "bicycle",
> or use "vehicle" to cover both ) but with drastically different
> functionality.
>
> Similarly like "parking" and "bicycle parking" or "motorway" and
> "cycleway".
>
>
>  Eeeh, motorway and cycleway make sense because they're definitely two
> fairly different beasts, but for amenities and parking, motor_vehicle=no,
> bicycle=designated seems like a better idea in retrospect.
>
> I guess that it depends on personal
> preferences.
>
> I really dislike need to enter multiple tags
> to specify basic type (yes I like
> highway=bus_stop)
>

I mean, sure, but it's also not like highway=services are intrinsically and
inherently motorist oriented, either.  Not sure how many don't cater to
motorists, but I don't see a reason to make a tag for the same thing but
doesn't allow motor vehicles...

Presets are your friend to reduce input fatigue.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Paul Johnson]

On Sat, Oct 24, 2020 at 6:40 AM Supaplex  wrote:

> Hey all,
>
> I would like to invite you to discuss a proposal for "parking =
> street_side" for areas suitable or designated for parking, which are
> directly adjacent to the carriageway of a road and can be reached directly
> from the roadway without having to use an access way:
> https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side
>
> The proposed tagging can be used on separate parking areas as well as with
> the parking:lane-scheme. It aims not only to differentiate such
> street-accompanying parking areas from others, especially
> "parking=surface", but also addresses a contradiction in the current use of
> the amenity=parking and parking:lane-scheme, which I would like to mention
> briefly at this point: the use of "layby"/"lay_by".
>
> The value "layby" was originally intended for forms of resting places, as
> they seem to be especially common in rural areas of Great Britain, Ireland
> or the US: short-stop rest-areas along through-traffic roads intended for
> breaks during a car-trip (see Wikipedia for a definition:
> https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with
> "amenity=parking" this key is also used in this sense (and mostly in Great
> Britain).
>
> Within the parking:lane-schema, however, the value "lay_by" (written with
> an underscore) has gained acceptance. According to the Wiki, this value is
> defined identically to the layby's mentioned above. Its actual use,
> however, differs from this and includes mainly street-side parking, as we
> address them in our proposal.
>

How does this work out when the parking lane is not the curb lane?  This
arrangement is increasingly common in North America, where the parking
isn't at the side of the road, one or more bicycle lanes are.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Paul Johnson]

On Wed, Nov 18, 2020 at 6:16 AM ael via Tagging 
wrote:

> Let's encourage people to use the source tag properly rather than cause
> further decay. Or come up with a better solution, which is definitely
> not a changeset comment.
>

source=* by itself on a way, relation or node is not useful.
source:keyname=* can help give hint on where something came from, but
ultimately, source=* works best as a changeset tag.  Every major editor
supports and encourages this.   The history browser in JOSM and osmcha.org
work well.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping bicycle-only turn lanes

[Paul Johnson]

On Tue, Dec 8, 2020 at 4:09 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Mapper in Poland run into a tricky case and asked for help.
>
> I am forwarding this a bit weird case.
>
> Photo is at
>
> https://commons.wikimedia.org/wiki/File:Krak%C3%B3w_Brodzi%C5%84skiego_(5).jpg
> and depicts
>
> - contraflow bicycle lane
> - bicycle-only left turn lane (signed left turn)
> - general purpose lane (unsigned turn)
>
> How this should be tagged?
>
> Following is my idea but...
>
> highway, name, lit=yes, surface=asphalt etc
> oneway=yes
> oneway:biycle=no
> lanes=1 (as bicycle lanes are not counted)
> vehicle:lanes:forward=no|yes
> bicycle:lanes:forward=designated|yes
> turn:bicycle:lanes:forward=left|
> turn:lanes:forward=|
> vehicle:lanes:backward=no
> bicycle:lanes:backward=designated
> cycleway:left=lane
> cycleway:right= - there is left turn lane only, so cycleway:right=lane
> would be
> not entirely correct but there is a left turn lane, cycleway:right would
> be worse
>

I've been saying for a while now that it's time we fix the tagging problems
with bicycle and motorcycle lanes by *actually including them as lanes*,
because it cleanly handles exactly this kind of situation concisely and
cleanly.  They're still lanes, just a reserved kind of lane like a carpool
lane or HOV lane.  JOSM already handles this with its lane tagging features
beautifully.  Any data consumers that can deal with lane access (which, if
they're not, this is *already* a bug, because HOV and bus lanes are things,
too) will be able to handle it without problems.

cycleway=lane
lanes=3
lanes:forward=2
lanes:backward=1
access:lanes:forward=no|yes
bicycle:lanes:forward=designated|yes
turn:lanes:forward=left|
access:lanes:backward=no
bicycle:lanes:backward=designated

Or we can just keep trying to pretend bicycle lanes aren't actually lanes
and try to figure out how to fix something while simultaneously keeping it
permanently broken because the original lanes proposal only considered
private motorists.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping bicycle-only turn lanes

[Paul Johnson]

On Sat, Dec 12, 2020 at 5:25 AM Jan Michel  wrote:

> Hi,
> where do you see a problem here? The current situation might not be
> perfect, but it is usable as it is. The only thing to keep in mind is
> that the number of "lanes" does not need to match the number of entries
> in the "XY:lanes" tags.
>

That disagrees with literally every lane editing and validation tool in
existence at this time.


> On the other hand, the "lanes" tag has some real problems, e.g.
> lanes = 2
> lanes:psv = 1
> lanes:hov = 1
> Is there any lane for regular traffic or not?
>

That shouldn't be relevant to whether or not a lane counts as a lane


> In my opinion the "lanes" tag is just a rough estimate for the width and
> capacity of a road -


You're actually describing the width=* tag, not the lanes=* tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping bicycle-only turn lanes

[Paul Johnson]

On Sat, Dec 12, 2020 at 8:34 AM Jan Michel  wrote:

> On 12.12.20 14:25, Paul Johnson wrote:
> > On Sat, Dec 12, 2020 at 5:25 AM Jan Michel
> >  > <mailto:j...@mueschelsoft.de>> wrote:
> >
> > Hi,
> > where do you see a problem here? The current situation might not be
> > perfect, but it is usable as it is. The only thing to keep in mind is
> > that the number of "lanes" does not need to match the number of
> entries
> > in the "XY:lanes" tags.
> >
> >
> > That disagrees with literally every lane editing and validation tool in
> > existence at this time.
>
> Please check for example this way:
>
> https://www.openstreetmap.org/way/406235586
>
> It perfectly validates in all tools I tried - JOSM, OSMI, Keepright...
> Rendering in the lane attribute style in JOSM is fine as well.
>
> Even the examples in the Wiki show exactly this:
>
> https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles
>
> It was mentioned in the original proposal for the :lanes suffix 8 years
> ago.
>
> So, it *agrees* "with literally every lane editing and validation tool
> in existence" as well as documentation.
>

Sure, if you manually torque tag it to match the incorrect documentation.
As soon as you open the lane editor, it rightly corrects it to lanes=5,
since you have 2 lanes in one way and 3 in the other.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping bicycle-only turn lanes

[Paul Johnson]

On Sat, Dec 12, 2020 at 10:46 AM Jan Michel  wrote:

> On 12.12.20 17:25, Paul Johnson wrote:
>
> > Sure, if you manually torque tag it to match the incorrect
> > documentation.  As soon as you open the lane editor, it rightly corrects
> > it to lanes=5, since you have 2 lanes in one way and 3 in the other.
>
> The "incorrect documentation" was voted on and it was approved.
>

I'm pretty sure it was done without consideration for reserved lanes as
lane access tagging wasn't something yet available.  Now it is, and it's
time to reconsider that.


> Setting tags according to documentation is hardly "torquing tags".

Which "lane editor" do you refer to? If any tool does this, it needs
> to be fixed.
>

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

Re: [Tagging] Mapping bicycle-only turn lanes

[Paul Johnson]

On Sat, Dec 12, 2020 at 11:22 AM Jan Michel  wrote:

> On 12.12.20 17:47, Paul Johnson wrote:
> > On Sat, Dec 12, 2020 at 10:46 AM Jan Michel
> >  > <mailto:j...@mueschelsoft.de>> wrote:
> >
> > On 12.12.20 17:25, Paul Johnson wrote:
> >
> >  > Sure, if you manually torque tag it to match the incorrect
> >  > documentation.  As soon as you open the lane editor, it rightly
> > corrects
> >  > it to lanes=5, since you have 2 lanes in one way and 3 in the
> other.
> >
> > The "incorrect documentation" was voted on and it was approved.
> >
> >
> > I'm pretty sure it was done without consideration for reserved lanes as
> > lane access tagging wasn't something yet available.  Now it is, and it's
> > time to reconsider that.
>
> I'm refering to the proposal of exactly this: the :lanes extension. It
> was clearly and unambiguously taken into account:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag


That specific anchor says it's completely sidestepping the issue while
highlighting the shortcoming of lanes=* as it stands now.  We need to fix
lanes=* to mean all lanes.  This isn't a hard change to make, but it is a
necessary one to disambiguate lane tagging.

Which means any lane editor that sees the turn:lanes or access:lanes tag is
going to count that and go "OK, there's at least this many lanes" and fix
the count.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping bicycle-only turn lanes

[Paul Johnson]

On Sat, Dec 12, 2020 at 4:37 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 12, 2020, 18:27 by ba...@ursamundi.org:
>
>
>
> On Sat, Dec 12, 2020 at 11:22 AM Jan Michel  wrote:
>
> On 12.12.20 17:47, Paul Johnson wrote:
> > On Sat, Dec 12, 2020 at 10:46 AM Jan Michel
> >  > <mailto:j...@mueschelsoft.de>> wrote:
> >
> > On 12.12.20 17:25, Paul Johnson wrote:
> >
> >  > Sure, if you manually torque tag it to match the incorrect
> >  > documentation.  As soon as you open the lane editor, it rightly
> > corrects
> >  > it to lanes=5, since you have 2 lanes in one way and 3 in the
> other.
> >
> > The "incorrect documentation" was voted on and it was approved.
> >
> >
> > I'm pretty sure it was done without consideration for reserved lanes as
> > lane access tagging wasn't something yet available.  Now it is, and it's
> > time to reconsider that.
>
> I'm refering to the proposal of exactly this: the :lanes extension. It
> was clearly and unambiguously taken into account:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag
>
>
> That specific anchor says it's completely sidestepping the issue while
> highlighting the shortcoming of lanes=* as it stands now.  We need to fix
> lanes=* to mean all lanes.  This isn't a hard change to make
>
> It would redefine widely used tag.
>

So what?  How are we going to improve if we're not willing to correct
choices that are objectively bad in retrospect?  Especially when fixing the
problem makes lane tagging more consistent for all lane types and easier
for new people to understand and map in the long term?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping bicycle-only turn lanes

[Paul Johnson]

On Sat, Dec 12, 2020 at 5:04 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 12. Dec 2020, at 23:43, Paul Johnson  wrote:
> >
> > So what?  How are we going to improve if we're not willing to correct
> choices that are objectively bad in retrospect?  Especially when fixing the
> problem makes lane tagging more consistent for all lane types and easier
> for new people to understand and map in the long term
>
>
> use a different key for the different definition. Promote it and see if
> others join you.
>

This complicates things for new mappers, who are invariably going to come
to the same conclusion of "what do you mean "lanes" doesn't literally mean
lanes?"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] destination:ref with direction?

[Paul Johnson]

On Wed, Dec 16, 2020 at 7:20 AM Skyler Hawthorne  wrote:

> Note the last sentence. If the destination:ref must be the same as the ref
> it is going to, then this would be I 787, or else all the ways along the
> entire I 787 route should have their ref tags changed to indicate direction
> as well.
>

Wouldn't it make more sense, and isn't it already more common, for
destination tags to contain the information on the destination signs, which
*do* differentiate direction?  This ends up as an important distinction
particularly at freeway interchanges, where, say, going southbound, the
ramp to westbound is a left exit instead and eastbound is a right exit,
opposite driver expectation.

I feel like this is another example of "the wiki was written by someone
with inadequate information."
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] destination:ref with direction?

[Paul Johnson]

On Wed, Dec 16, 2020 at 9:34 AM Tom Pfeifer  wrote:

> Both tagging and wiki develop, hopefully forward. In this case,
> Key:destination:ref redirects
> onto an old 2012 proposal, I'm probably going to resolve that soon with
> describing the current practice.
>

Thank you!  If only we could be this nimble on long standing things like
sunsetting ref=* on ways in favor of routes (one of the things that
relations were introduced to fix, as routes and their ways are usually
distinct entities) and fixing lanes=* to actually mean what it says...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] destination:ref with direction?

[Paul Johnson]

On Wed, Dec 16, 2020 at 10:57 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Re: "If only we could be this nimble on long standing things like
> sunsetting ref=* on ways in favor of routes"
>
> Handling ref on routes and ways at the same time requires some more
> complicated processing, and for a long time osm2pgsql did not provide a
> standard way to do this in a consistent manner, until earlier this year. It
> should soon be possible, see
> https://github.com/openstreetmap/osm2pgsql/releases/tag/1.3.0 and
> implementation issues at
> https://github.com/gravitystorm/openstreetmap-carto/issues/596 and
> https://github.com/gravitystorm/openstreetmap-carto/issues/4112 and
>

Well, this is happy news!  Glad to hear it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Continuous shoulder rumble strips (CSRS)

[Paul Johnson]

On Sun, Dec 20, 2020 at 10:27 AM Jeremy Harris  wrote:

> On 20/12/2020 16:07, Volker Schmidt wrote:
> > Is there a tagging scheme for these bicycle  killers
> > ?
> > I have encountered them on freeways and other major roads that allow
> > cyclists, in the western States of the USA.
>
> How about
>
> cycleway = shoulder
> shoulder:barrier = rumble_strip
>

I'm pretty sure a hard shoulder isn't actually a cycleway.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Continuous shoulder rumble strips (CSRS)

[Paul Johnson]

On Sun, Dec 20, 2020 at 4:00 PM Volker Schmidt  wrote:

> The OSM wiki page Traffic_calming defines
>
>- traffic_calming=rumble_strip
>
>
> as a structure that crosses the road. It also says explicitly:
> " Do not confuse with longitudinally placed rumble strips to alert drivers
> that they are leaving their lane, which are generally not mapped by OSM.
> (See rumble strips .)"
>
> Regarding the legal aspect of riding on the hard shoulder. I don't know
> the general rules in the US States, but I rode several hundred km on
> freeway hard shoulders in the western US that were explicitly signed as
> "cyclist use hard shoulder". If necessary I can check with my friends of
> Adventure Cycling Association - they are running a campaign to improve the
> situation regarding the danger posed by longitudinal rumbling strips in the
> US.
>

Bicycles *can* use hard shoulders, but this doesn't make the shoulder a
cycleway.  And shoulders that are open to bicycles and have been built or
rebuilt in the last decade or so will have gaps in the rumble strip
specifically to make it safer for bicycle traffic to get on or off the
shoulder safely.  There's usually 40-60 feet of rumble strip followed by a
10-15 foot long gap in a repeating pattern.  Pennsylvania has been
experimenting with buffered bike lanes, putting a rumble strip in the
buffer, but AFAICT, this is the only state that does this due to being the
only place with experimental approval to use a rumble strip on a bike lane.

But for just a generic hard shoulder on a freeway or highway?  cycleway=*
wouldn't apply at all.  Where signed as above where using the hard shoulder
is compulsory, then "no" would be a good value for all lanes in the
bicycle:lanes=* key along with bicycle=yes.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

[Paul Johnson]

On Thu, Oct 13, 2022 at 8:07 AM Davidoskky via Tagging <
tagging@openstreetmap.org> wrote:

> On 13/10/22 10:15, Warin wrote:
> > I see no point in depreciating anything at the moment .. 'we' need a
> > solution first before even thinking of depreciation.
>
> I do agree and appreciate this approach. A solution for tagging
> man_made=drinking_fountain already exists, that is fountain=bubbler.
>

Though, and I'm not entirely sure if the post made it to the list or not
since it had a picture attached to it, as previously mentioned, this isn't
ideal by a long stretch. Bubblers run continuously by design, and shoot
straight up, so they're also continuously washing themselves.  Drinking
fountains are switch or knob operated and shoot at an angle.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[Paul Johnson]

On Sun, Aug 18, 2019 at 10:16 AM 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". I usually use the common
> name as the 'name' tag, and the USFS designation as the 'alt_name' tag.
> I kindof would like to include the county name as well. I do see a lot
> of roads use 'name_1', but that gets flagged often by validation. So my
> question is, how to I tag all three road names appropriately ?
>

refs aren't names, they're refs.  ref=CR 2 and ref=FS 729.2B are
appropriate.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[Paul Johnson]

On Sun, Aug 18, 2019 at 10:24 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> F Street and 1st Street (usually written out as First Street, though
> this depends on the local standards) are a common name, which goes in
> the name field.
>

It can also be regionally dependent.  Oklahoma got a lot of "East 820 Road"
type names, but in reality it should be ref=CR E820 instead.   TIGER is the
most notorious source for this bogosity, and the counties themselves aren't
super consistent themselves, so you'll see some with the five point blue
county signs, some that use standard street blades and list the road
numbers, and some that literally paint the route numbers on the pavement at
each intersection, regional knowledge is required to get the context right,
especially since you'll get some that TIGER imported with like:

name=East 820 Road
name_1=Cemetery Road
name_2=River Road.

Rearrange the multiple values randomly.  It's pretty obvious to tell which
is going to be the county road number.  Which name it is gets a little
tricker; sometimes it was originally one then it changed to another,
sometimes it's none of those besides the county road number, sometimes it's
the county road number and another, fourth value for the name from a more
recent renaming.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Forward/backward routes

[Paul Johnson]

On Mon, Aug 19, 2019, 08:20 Kevin Kenny  wrote:

> On Mon, Aug 19, 2019 at 6:34 AM Peter Elderson 
> wrote:
> > Keeping linear main route and alteratives separate is actually quite
> straightforward and much less work than creating and maintaining routes
> with roles. Especially when the forward/backward roles do not indicate the
> direction of travel, as is the case with bicycle routes.
>
> The 'forward' and 'backward' roles are well defined. At least two
> editors that I've used understand them. JOSM appears to sort them
> correctly. (It does stumble a bit in the special case where a
> route=road ends at junction among dual carriageways, because it cannot
> find a single endpoint.)  We seem to have this problem mostly solved.
>
> I disagree with the 'much less work' when you're maintaining a route
> that's hundreds of km long, follows dedicated trails or rural roads
> most of the way, but once in a while enters a city and splits because
> of one-way streets. Maintaining separate 'forward' and 'backward'
> relations for the whole thing would be quite annoying.
>

Depends.  I prefer to split to separate forward and backward relations when
the number of members gets to be extremely large or when either or both
ends of a route is not single carriageway, because it gets to be a real
pain in the butt to validate and maintain otherwise.

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

Re: [Tagging] Forward/backward routes

[Paul Johnson]

On Mon, Aug 19, 2019 at 6:23 PM Peter Elderson  wrote:

> Well, the simple version I got from bicycle route mappers is: members in
> the main direction have no roles. The fact that there is a role tells you
> it’s a way for the opposite direction, and then forward tells you the
> opposite travel direction goes against the mapped direction of that member
> way, and the backward role tells you the opposite travel direction goes
> with the mapped direction of the way.
>

If the way is traversable as part of the route in both directions, then
this is correct.  If the route only applies to one direction, then you do
need to specify forward or backward.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Forward/backward routes

[Paul Johnson]

On Mon, Aug 19, 2019 at 7:29 PM Peter Elderson  wrote:

>
> Op 20 aug. 2019 om 01:44 heeft Paul Johnson  het
> volgende geschreven:
>
> On Mon, Aug 19, 2019 at 6:23 PM Peter Elderson 
> wrote:
>
>> Well, the simple version I got from bicycle route mappers is: members in
>> the main direction have no roles. The fact that there is a role tells you
>> it’s a way for the opposite direction, and then forward tells you the
>> opposite travel direction goes against the mapped direction of that member
>> way, and the backward role tells you the opposite travel direction goes
>> with the mapped direction of the way.
>>
>
> If the way is traversable as part of the route in both directions, then
> this is correct.  If the route only applies to one direction, then you do
> need to specify forward or backward.
>
>
> Then, the roles forward and backward may both apply to ways in both travel
> directions? And then there is traffic direction, which is also not the same
> as mapped direction, and may be different for different transport modes...
>

If it applies in both directions, then no role is necessary.  This is how
routes can work regardless of which way the way faces or even it's oneway
status if various modes can go against the oneway.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] bear box in campground ?

[Paul Johnson]

On Wed, Aug 21, 2019 at 4:04 PM Tom Pfeifer  wrote:

> On 21.08.2019 19:44, Rob Savoye wrote:
> >Many western state campgrounds have metal bear proof food storage
> > boxes in each campsite, but not all of them. At certain times of the
> > year this can be important. :-) Around here the bears will destroy your
> > car if there is food left inside. I see zero instances of this type of
> > data, at least not in Colorado. My guess would 'amenity='bear_box' ?
> > (looking at amenity=bbq as an example)
>
> The question remains if tagging the boxes would give bears an advantage as
> they could exploit the
> knowledge and focus on sites without such boxes?
>

Probably not.  I'm not a bear but I play one now and then!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] bear box in campground ?

[Paul Johnson]

On Wed, Aug 21, 2019 at 5:20 PM Rob Savoye  wrote:

> On 8/21/19 4:16 PM, Graeme Fitzpatrick wrote:
>
> > We don't have that problem!, but are the bear boxes at each individual
> > site / pitch, or is there one / "x" for the entire campground?
>
>   Bear boxes are in every campsite, and hold about a week's worth of
> food. They're big enough you can put in a decent size cooler plus
> supplies A campground sized one would be huge!


They're not always every campsite, they're sometimes entire campgrounds or
sections of a campground, to ensure the food is far enough away from all
campers that any bears willing to take on the challenge are not going to be
an immediate threat to humans and vice versa.  Yellowstone National Park
and Banff National Park come to mind as having campgrounds with banks of
bear boxes.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] bear box in campground ?

[Paul Johnson]

On Wed, Aug 21, 2019 at 7:23 PM Warin <61sundow...@gmail.com> wrote:

> Is there a requirement to tag these 'animal resistant boxes'? Would a more
> universal tag be better?
>

I've generally heard these referred to as "bear boxes" regardless of the
species they're intended to guard against.  Granted, my exposure to such
facilities is limited and I am bear-biased.


> I am surprised raccoons are not a problem in northern America.
>

They are, but unlike bears (especially black bears), raccoons haven't
figured out how to open car doors from the outside yet.  Probably owing to
their rather short stature being unable to reach the door handle.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] bear box in campground ?

[Paul Johnson]

On Wed, Aug 21, 2019 at 7:53 PM Warin <61sundow...@gmail.com> wrote:

> On 22/08/19 10:25, Paul Johnson wrote:
>
> On Wed, Aug 21, 2019 at 7:23 PM Warin <61sundow...@gmail.com> wrote:
>
>> Is there a requirement to tag these 'animal resistant boxes'? Would a
>> more universal tag be better?
>>
>
> I've generally heard these referred to as "bear boxes" regardless of the
> species they're intended to guard against.  Granted, my exposure to such
> facilities is limited and I am bear-biased.
>
>
> American English? Fortunately the UK does not seem to suffer from this
> issue, so there is no British English example we can use.
>

Well, of course, they hunted their bears to extinction and turned 'em into
hats.  I think Canadian trappers are now the current source.


> For someone who is not familiar with the term 'bear box' it may sound like
> bears are stored in there.
> "Food storage box" might be better?
>

Fair point.  Food storage box would just mean any kind of camp staple box
at a semipermanent encampment, though, and most staple boxes are just
basically resistance against weather and vermin, typically raised off the
ground about waist high on the low side with a lid that flips out as a food
preparation surface, but wouldn't survive initial contact with a bear
interested in its contents.  Common at locations where backpackers
typically travel in groups of around half a dozen and stay encamped for
several days at a shot in order to facilitate a single common kitchen.

Quick Google search suggests "staple box" is not particularly known outside
of Parks Canada, Scouts Canada and Scouts BSA circles, though, with kitchen
box being slightly more common in North America and "chuck box uk" actually
being the first autocomplete when you start typing "chuck box" in Google.
Chuck box seems to also be the most unambiguous and british term available.

So, for any such box, perhaps amenity=chuck_box and if it's purpose built
against some kind of specific threat to its contents, then hardened=yes?

I'm not married to the terminology, but I am ready to buy in.

> I am surprised raccoons are not a problem in northern America.
>>
>
> They are, but unlike bears (especially black bears), raccoons haven't
> figured out how to open car doors from the outside yet.  Probably owing to
> their rather short stature being unable to reach the door handle.
>
>
> If they team together they can form a pyramid for the reach, only need to
> figure out the handle then.
> Can they do zippers? Raiding tents and backpacks then becomes possible.
>

Can confirm that raccoons don't bother with zippers, they just go through.
Learned the hard way at Cape Foulweather State Park to tree packs with food
when my pack got raided the first campout I had in the Scouts.  Only had to
ruin my grandfather's US Army pack he brought back from World War II, which
had additionally survived an extended backpacking trip across Afghanistan
my mother took when it was under Soviet control in the process (I learned
how to restore it after that, and ended up getting a more modern pack
better suited for backpacking).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] bear box in campground ?

[Paul Johnson]

On Fri, Aug 23, 2019 at 1:12 PM Paul Allen  wrote:

> On Fri, 23 Aug 2019 at 18:43, Dave Swarthout 
> wrote:
>
>>
>> Still, if we want to allow for easy expansion of the tagging scheme then
>> using waste_basket=bear-proof, for example, would help such future
>> expansion.
>>
>
> How about bear_proof=yes which could be applied to food storage containers
> and waste
> containers?  Ummm, we'd probably also need vermin_proof=yes for mice/rat
> proof
> containers.
>

This is why I offered the "hardened=yes" suggestion above.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Turn lanes separated by road markings

[Paul Johnson]

On Fri, Sep 6, 2019 at 2:14 PM Markus  wrote:

> Hello everyone
>
> I'm unsure how to map the following situation:
>
> There are two lanes approaching a roundabout, both with different
> destinations. The lanes are divided by a solid line (and later a panted
> triangle with chevrons) for about 100 m before they are separated
> physically:
>
> https://www.openstreetmap.org/way/430073056
>
> Do we have a relation for storing the information that the left lane
> continues on [way 394112487](https://www.openstreetmap.org/way/394112487)
> and the right lane on [way 290130794](
> https://www.openstreetmap.org/way/290130794)? This information is
> important in order that routers don't announce too late (i.e. when the
> lanes can't be changed anymore) which lane one has to take.
>
> Or is turn:lanes + change:lanes enough? (And what if there were no turn
> lane markings?)
>

Consider putting the split at the theoretical gore and making the right
turn sliproad placement=transition from the theoretical gore to the
bullnose.  Example: https://www.openstreetmap.org/way/397356496
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Johnson]

On Wed, Sep 11, 2019 at 7:59 AM Paul Allen  wrote:

>
> Anyone who thinks the preceding paragraph is off-topic because it's about
> Wikimedia should try to recall all the times on this list when somebody has
> insisted that rules is rules, even when the outcome of following those
> rules is sub-optimal.
>

Like the wiki saying lanes=* not counting all the lanes.  Never mind every
tool ever that consumes, validates or generates this data *does* include
all the lanes and there's zero reasons not to, and fixing omissions is as
easy as a roulette project searching against all ways with lane tagging and
cycleway=*...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bus Routes PTv2

[Paul Johnson]

On Thu, Sep 26, 2019 at 6:57 AM Michal Fabík  wrote:

>
>
> على ٢٦‏/٩‏/٢٠١٩ ‫١:٣٦ م، كتب James:
> > If you have a bus route that doubles back on itself, do you have to
> > add the way twice to the relation or add it once and let the router
> > figure out that it's already in the relation?
>
> I added it twice on a few occasions. JOSM was complaining but it's
> working fine when I display the route in OsmAnd or use it in navigation.
> Not sure about other consumers. I might do some more thorough testing
> now that you mention it.
>

I think the PT Assistant plugin updates the validator to deal with this.
If not you can tell it to ignore that error on that relation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] railway crossings with cycleways

[Paul Johnson]

On Fri, Oct 4, 2019 at 7:58 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
>
> The wiki defines railway=level_crossing as a crossing of rails and a road,
> while railway=crossing is for a pedestrian crossing of railway tracks. What
> about cycleways?
>
> https://wiki.openstreetmap.org/wiki/Tag%3Arailway%3Dlevel_crossing
>
> https://wiki.openstreetmap.org/wiki/Tag:railway%3Dcrossing
>

I'm strongly inclined to consider a cycleway a road, not a footway.  My
thinking on this is that the Federal Highway Administration has considered
bicycle facilities as a roadway since at least 2000 (the earliest copy of
the MUTCD I could find online), and some states like Oregon and California
since at least the 1970s.  Since the 1990s, I've also noticed cycleways
moving from more footway style crossings in the 1990s to, in more recent
years, crossings more or fully consistent with what you would expect on
roads that are open to motor vehicles.  I'd call this a level crossing
(sorry for potato quality, I had to take it from a panorama I took).
https://i.imgur.com/a5roXn1.png  Photo is looking southbound toward
https://www.openstreetmap.org/node/932401569
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Guard booth building type

[Paul Johnson]

On Mon, Oct 7, 2019 at 2:59 AM Joseph Eisenberg 
wrote:

> “Booth” implies that one wall is missing (open).
>

I thought that was an adirondack?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Divided highways, and not so divided highways, one way or two

[Paul Johnson]

On Thu, Oct 10, 2019 at 1:38 AM Frederik Ramm  wrote:

> Personally I believe that "physical division => separate ways; no
> physical division => shared way" is the standard in OSM, or perhaps at
> least the "rule of thumb". But (since people in the German discussion
> have more or less claimed that the world is going to end if local
> mappers are allowed to treat this differently) I'd like to hear from
> mappers in other countries how rigidly this standard is applied. Is it
> something where local mappers have some freedom of judgment (like when
> choosing which highway=* category to apply to a road) or do you have
> strict standards and definitions?
>

So, single carriage freeway?  In the US, that'd be a single way,
highway=trunk, oneway=no.

About the only time I map it otherwise is where a single carriageway
results in spurious directions due to the angles required to make it come
together (like the one block of South Lewis Avenue between 51st Street and
Skelly Drive in Tulsa, where the distance between the end of the median and
the center of the intersection results in a nearly right angle if it were
to be mapped more strictly). Or at exit ramps (where I start a
placement=transition segment even with the start of the theoretical gore
and ends centered on the ramp through lanes, preventing consumers from
giving the instruction too soon as happens extending the ramp vector
straight line to the motorway or too late when going as close to the
physical bullnose as possible).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Divided highways, and not so divided highways, one way or two

[Paul Johnson]

On Thu, Oct 10, 2019 at 5:22 AM Warin <61sundow...@gmail.com> wrote:

> On 10/10/19 20:46, Martin Koppenhoefer wrote:
>
> Am Do., 10. Okt. 2019 um 08:40 Uhr schrieb Frederik Ramm <
> frede...@remote.org>:
>
>> The original mapper claims that using two separate oneway=yes ways is
>> clearer and easier, as it does away with the need for turn restrictions
>> at junctions.
>
>
>
>
> this is an interesting aspect: why do we need turn restrictions, wouldn't
> it be sufficient to tell the routing engine that there is a line that
> cannot be crossed (and add a tag for interruptions to this on the junction
> nodes where you can cross), and we could save a lot of turn restriction
> relations which would be already implied?
>
> I recall this was suggested many years ago, but for some reason it did not
> fly. Maybe it is because it was too complicated to find out under which
> circumstances (in which jurisdictions) white lines had which meaning? Maybe
> we should not map the lines physically, but according to their legal
> meaning, something like (shorter tags would be chosen): divider that cannot
> be crossed (legally), divider that can be crossed legally, divider that can
> be crossed but only for turning left not for u-turns, etc.
>
>
> Allowing for different diving on different sides of the road?
>
> Centre cannot be crossed (all)
>
> Centre cannot be crossed for U turns (turn offs allowed)
>
> Centre cannot be crossed for turns (U turns allowed)
>
> Centre cannot be crossed for turn offs (U turns, turn ons allowed)
>
> Centre cannot be crossed for turn ons (U turns , turn offs allowed)
>
>
>
> centre
> =no_crossing/no_u_crossing/no_turn_crossing/no_off_crossing/no_on_crossing/yes_crossing/???
>
> Will need further though, but the above provides for either side of the
> road driving.
>

Something that I wish routing engines would be better about:  Whether or
not to allow U-turns.  Because I seriously doubt all 3,700+ intersections
in Oregon that don't allow U-turns (literally every traffic light that
doesn't have a "U Turns OK" sign per Oregon state law), and I know not all
of the 831 signalized intersections in Tulsa (no U turn allowed at traffic
signals, it's never posted otherwise, per city code) are tagged with No U
Turn restrictions.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Divided highways, and not so divided highways, one way or two

[Paul Johnson]

On Fri, Oct 11, 2019 at 5:38 AM Snusmumriken 
wrote:

> On Fri, 2019-10-11 at 11:21 +0200, Martin Koppenhoefer wrote:
> >
> >
> > Am Fr., 11. Okt. 2019 um 11:10 Uhr schrieb Snusmumriken <
> > snusmumriken.map...@runbox.com>:
> > > It is up to the driver. I think he can ignore most of the traffic
> > > laws
> > > in the cause of getting as fast and as safe to where he needs to
> > > go. So
> > > he would use his own judgment and not so much what a routing engine
> > > tells him what he can do.
> >
> >
> >
> > you are missing the point: when the emergency vehicle gets the call,
> > the routing engine will suggest a route to approach the place of
> > action from where it is now, and depending on the osm data (and other
> > data like traffic congestion, unaccessible roads, etc.) it may
> > suggest different routes. Of course you can dismiss this in general
> > and say: "the driver will know where to go" or "will use his own
> > judgement", i.e. would not use OSM data at all, but this is not the
> > reality, in reality, OSM is used more and more in emergency
> > scenarios. There are companies dedicated to provide OSM-data-based
> > infrastructure for use by emergency services. I have seen it.
>
>
> Thanks for clearing that out. I still think it is better to map for the
> 99.99% of drivers who need to follow the law strictly. Special tagging
> for different emergency vehicles could be applied.
>
> Just to be clear, I'm not advocating that legal separation MUST lead to
> way separation. Just that a rule that wouldn't allow it would be a very
> bad rule. What makes most sense based upon the ground truth should be
> followed.
>

I think you're asking for a new tag, or adding turn restrictions, not
physical separation.  It's pretty well established that two lines is two
roadways, for which crossing over is only really going to happen where
another way is crossing between the two, not "you can't cross this line on
the pavement".  It's not like the rest of the world doesn't have this
problem, the US frequently has flush medians (
https://i.imgur.com/st58ROv.png) that indicate that you can't turn across
them or use it like a lane.  About the only time these don't get mapped as
a single way is if the median is of a geometry to deal with two closely
adjacent intersections that the only reason there's not another curbed
island there is to deal with vehicle offtracking.  Or more rarely because
it gets a fire station driveway over the median, but then the emergency gap
gets tagged as such.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecating mini_roundabout

[Paul Johnson]

On Wed, Oct 23, 2019 at 3:27 AM Florian Lohoff  wrote:

> i just saw a changeset of someone makeing a mini_roundabout
> from a junction=roundabout. I have never used mini_roundabout
> as non of the routing/nav engines i tried actually supported it
> when i did.
>

Probably because a mini-roundabout is basically one where you imagine the
island there, the island isn't physically present (other than maybe a
cushion in the middle of the road to give the island some tactility without
being unyielding to wayward vehicles).  Basically an indication to turn
around oncoming traffic instead of cutting off the corner.

Instead of making it some special type of roundabout with seperate
> tagging i'd vote for deprecating the mini_roundabout and adding
> a tag making the area of the junction=roundabout be an area which is
> driveable. e.g. why not area=yes on the junction=roundabout.
>

You'd first have to make mini-roundabouts not be a thing in the ground
truth for that to be particularly reasonable.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecating mini_roundabout

[Paul Johnson]

On Wed, Oct 23, 2019 at 5:06 AM Florian Lohoff  wrote:

> On Wed, Oct 23, 2019 at 12:00:13PM +0200, Tom Pfeifer wrote:
> > On 23.10.2019 11:35, Florian Lohoff wrote:
> > > > These are a very common feature, it does seem odd that routers are
> not supporting them.
> > >
> > > 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.
> >
> > Could you explain what the preprocessing is needed for, and why you need
> to
> > replace it in the routing algorithm.
> >
> > From my perspective nothing is needed. The routing engine recognises from
> > which way you come and where to leave, and, since the feature is so small
> > and clear, it can give instructions like at a normal junction, just using
> > the tag to describe the junction:
> > "At the mini-roundabout [turn right|go straight|turn left]".
>
> You would expect (as you see a roundabout sign) to get instructions to
> take the n.th exit.
>

At a mini roundabout?  I mean, for all five of 'em we have in the US so far
(three of which are blocks apart from each other in a city near me,
basically the same thing as the UK version but turns the opposite direction
and has a decorative brickwork or orange island instead of a white one),
no, not really, I'd just expect to be told which way to turn and that it
*is* a mini roundabout.  The only thing I might do differently than a
regular junction would be a straight through movement, have it pipe up to
say "at the mini roundabout, continue straight on."  This largely to tell
me the two things I need to know offhand at such a junction:  Turns work
backwards than normal and all four ways yield to people in the
intersection, otherwise roll it, so I can expect people to stop but can't
count on it if I get there first.


> The roundabout change which triggered this mail is MUCH larger - And you
> physically can go straight but there is a small curb - so cars will use
> the circular road, trailers will possible use the curbed center with the
> last axles.
>

Could we get a link to this roundabout?  Seems like a potentially difficult
call, mostly because the only difference between a painted on median and an
all-"truck apron" median is basically like going over a driveway curb cut
and not a physical barrier.


> > Basically the mini-roundabout is effectively more about who has priority,
> > and here all incoming roads have to 'give way'. Similar a four-side
> "stop"
> > sign in the US. I have used them in Britain and they are often just a
> bucket
> > of white paint poured in the middle of a junction.
>
> A mini_roundabout has the same rules as normal roundabout from what i
> look at the definition. The only difference is that its physically
> traversable.
>

This differs from an all-way stop, which is just bad engineering for stupid
people by lazy traffic controllers.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecating mini_roundabout

[Paul Johnson]

On Wed, Oct 23, 2019 at 5:31 AM Robert Skedgell  wrote:

> On 23/10/2019 11:14, Florian Lohoff wrote:
> > On Wed, Oct 23, 2019 at 11:55:04AM +0200, Colin Smale wrote:
> >> I would suggest it is not necessary to replace the simple node with a
> >> circular way. I think it is perfectly acceptable if it is considered
> >> as a simple turn instead of negotiating a roundabout, from a routing
> >> perspective. An instruction to turn right at the junction would not be
> >> improved by an instruction to take the third exit. If the navigator
> >> knows that a junction is a mini roundabout, an instruction to turn
> >> right at the (mini) roundabout would probably be optimal.
> >
> > What happens when you have 7 exits or even more? There is no left/right
> > ...
> >
> > https://osmcha.mapbox.com/changesets/75857317
> >
>
> 7 exits seems somewhat unlikely at a mini roundabout, at least as
> understood from the UK-centric usage (meaning TSRGD diagram 1003.4).
>

Meanwhile the osmcha example appears to be a 5 way roundabout-type
junction, but I don't have the clarity in that aerial view to tell if it's
traversable or not.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecating mini_roundabout

[Paul Johnson]

On Wed, Oct 23, 2019 at 7:54 AM Florian Lohoff  wrote:

> On Wed, Oct 23, 2019 at 12:42:27PM +, Philip Barnes wrote:
> > It is not just a British thing, I have encountered many when driving in
> France.
> > The rules and usage are the same as in the UK.
> > The other rule that makes them different to other roundabouts is that
> you should not use them to turn around, do U turns.
>
> So what is the difference then?
>
> What i know learned:
>
> - You may traverse the center
>

That's the only hard and fast distinction between mini and regular
roundabouts.


> - No more than 4 exits as left/right/straight on wont work
>

I'm sure there's probably some more-way mini-roundabouts somewhere, just as
I've been through intersections that probably should have been quite a
large roundabout but instead ended up as an 8-way traffic control spaghetti
bowl of turn restrictions, physical islands, priority signage and traffic
lights.  So I wouldn't consider this as a defining or exclusionary
characteristic one way or another.


> - You dont expect nav aids to be "2nd exit etc" but a "turn left at" as
>   the navaids are like a junction.
>

Right, because it, effectively, is a mundane junction, just being smarter
about it than an all-way stop and more likely to get pedestrians safely
across the junction than an uncontrolled junction.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecating mini_roundabout

[Paul Johnson]

On Wed, Oct 23, 2019 at 4:31 PM Paul Allen  wrote:

> On Wed, 23 Oct 2019 at 22:10, Paul Johnson  wrote:
>
>>
>> Meanwhile the osmcha example appears to be a 5 way roundabout-type
>> junction, but I don't have the clarity in that aerial view to tell if it's
>> traversable or not.
>>
>
> I went to the osmcha example and opened it in iD with Bing imagery.  It
> looks too large
> for a mini roundabout.  Three of the four roads have split lanes, which
> makes it
> incompatible with a mini roundabout.  And there are some Mapillary photo
> overlays which
> show the central island to be raised with a wall (tall kerb?) around the
> edge and some
> large bushes in the centre.
>

OK, I'm looking at it in these images now:

https://www.mapillary.com/app/?focus=photo&pKey=wnh2yPXi1HakCH5-dILZHw&lat=51.81508205831051&lng=8.849023785442114&z=17
https://www.mapillary.com/app/?focus=photo&pKey=QPacIZqNSt0x4CasddMBKg&lat=51.81481744674556&lng=8.849143013905326&z=17

>From the ground, this is pretty unambiguously a mini roundabout to my eyes,
albeit a somewhat large one.  Just eyeballing it about the same size as the
ones they recently installed in the next town over from me:
https://www.newson6.com/story/40932988/walkability-project-starts-in-okmulgee
(relevant screen grab if that link doesn't work for you:
https://i.imgur.com/6aL1aZV.png, the plan shown says "Ø 16.00'", meaning
"diameter 16 feet" (~4.88m).  The important part is that the median is not
physical.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecating mini_roundabout

[Paul Johnson]

On Thu, Oct 24, 2019 at 1:22 AM Frederik Ramm  wrote:

> The roundabout in the Mapillary images that Paul Johnson posted seems to
> be one with a traversable centre. At the same time, I would not expect
> my satnav to ask me to "turn left" here, but rather to take the nth exit
> at the roundabout...
>

I'm wondering if this is something best fixed on the consumer end of
things, such as if a mini roundabout has more than 4 exits, indicate which
exit as the diameter is probably large enough to necessitate that.

Or if this should be mapped as a ring, tagged junction=mini_roundabout, so
that consumers can tell large vehicles can effectively treat it as an area.

Out of these two ideas, I think the former makes more sense.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecating mini_roundabout

[Paul Johnson]

On Thu, Oct 24, 2019 at 7:20 AM Paul Allen  wrote:

>
> Necessary, but not sufficient.  It doesn't just have to be physically
> treaversable, it has
> to be legally traversable.
>

Eeeh, I think that's a bit of a grey area, like stopping on yellow lights.
Can you be written up for traversing a mini-roundabout island or running a
yellow light?  At least most places I've encountered, pretty clearly yes.
Is it likely?  Only if the cop thinks you picked the more dangerous option.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecating mini_roundabout

[Paul Johnson]

On Thu, Oct 24, 2019 at 7:55 AM Paul Allen  wrote:

> On Thu, 24 Oct 2019 at 13:30, Paul Johnson  wrote:
>
>> On Thu, Oct 24, 2019 at 7:20 AM Paul Allen  wrote:
>>
>>>
>>> Necessary, but not sufficient.  It doesn't just have to be physically
>>> treaversable, it has
>>> to be legally traversable.
>>>
>>
>> Eeeh, I think that's a bit of a grey area, like stopping on yellow lights.
>>
>
> Yes, but there are rigidly defined areas of doubt and uncertainty (at
> least in the UK):
> "All vehicles MUST pass round the central markings except large vehicles
> which are
> physically incapable of doing so."   UK mini roundabouts are signed as
> such, so while
> there may be doubt and uncertainty about how large the vehicle is and the
> necessity
> of going straight across, there's no doubt whether it is a mini roundabout
> or not.
>
> Does the example roundabout have signage defining the central island as
> legally traversable?
> Does the unbroken white line around it indicate vehicles may not cross
> it?  What do the
> traffic regulations say about roundabouts in general?  Is this a real
> roundabout built on the
> cheap and the island happens to be physically traversable but not legally
> so or do the
> regulations say "If you can physically drive across a roundabout then you
> may do so if
> your vehicle is too large to go around"?
>
> That particular example is tough to decide just from imagery.  It's a
> fairly tight circle.  But
> those split lanes make me shudder when I think of vehicles going straight
> across.  I'd
> hate to map it as a mini roundabout if legally it isn't and then some
> router happily tells
> a driver to drive straight across; or to map it as a roundabout when
> legally it isn't and
> the router tells the driver to do a 360.  There might be legal
> consequences if OSM
> adopts a cavalier attitude to these things.  Traffic regulations are even
> more important than
> physical appearances.
>

I hate to be a stick in the mud, but whether or not it's legally
traversable doesn't seem to have much bearing on whether or not it's
physically traversable.  It's kinda like mapping a flush median in this
case, it's not a seperate way so just a node indicating that there's a mini
roundabout would be appropriate similar to how we don't map divided single
carriageways with a flush median as two seperate ways.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Billboard or something else

[Paul Johnson]

On Wed, Oct 30, 2019, 05:55 Martin Koppenhoefer 
wrote:

>
> Am Mi., 30. Okt. 2019 um 11:02 Uhr schrieb Warin <61sundow...@gmail.com>:
>
>> > these aren’t traffic signs, a common, although underspecified tag is
>> man_made=gantry (subtagging the type of gantry could make sense)
>> >
>> The gantry is the support structure.
>>
>>
>
> I am aware of this
>
>
>
>> The sign can display various messages - so variable message fits.
>>
>
>
> +1
>
>
>> Traffic sign also fits - the travelling time to another place reflects
>> the traffic density, and vehicle crashes are traffic warnings ..
>>
>
>
> I agree this is more complicated than what I thought, because according to
> the Vienna Convention on traffic, Annexe 1, information signs are a kind of
> traffic sign.
>

Heck, Oregon has replaced a number of overhead signs with video panels.
When not displaying incidental information, they show the original sign
they replaced, though with some added flair.  Last time I was up in Oregon,
on OR 217 a number of speed limit signs had been replaced with video
displays showing a speed limit and advised speed, and signs displaying
distance to next exit were replaced with video displays that were cycling
the miles distance display to also show kilometers (or meters for distances
of 1500m or less) and average travel times.

I think we're seeing the future with this, and the future is boring.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Billboard or something else

[Paul Johnson]

On Wed, Oct 30, 2019, 11:06 Jonathon Rossi  wrote:

> On Wed, Oct 30, 2019 at 11:19 PM Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>> > Il giorno 30 ott 2019, alle ore 13:09, Jonathon Rossi <
>> j...@jonorossi.com> ha scritto:
>> >
>> > I didn't say these signs had to display messages that must be obeyed
>> just that they often do.
>>
>> what I meant was that we might want to distinguish between those that
>> show information and those that show traffic signs to which you must obey.
>>
>
> Okay, might be useful, but how does a mapper know what a road authority
> will do with a variable message sign? If it has only been observed with
> travel time messages and other informational messages, then how do you
> verify it won't be used for more in the 1% of cases, and does it actually
> matter?
>
> I'd be inclined to have all big matrix panels tagged
> traffic_sign=variable_message, with Variable Speed Limit Signs and Lane Use
> Signals different traffic sign types, maybe traffic_sign=variable_speed and
> traffic_sign=lane_control (I've not checked taginfo to see what people are
> already using) which would allow navigation apps to notify a driver about a
> variable speed limit zone (or does that belong on the highway?), however
> this is getting out of scope of Graeme's original question.
>

And it gets just insane when you consider the possibilities Oregon DOT has
with its variable displays, since something that's normally displaying the
next three exits and which lane is exit only might be pink incident
response signs, white speed limit signs and lane control signals the next
time you pass the same sign an hour later.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic Signs (was: Re: Is there a good way to indicate "pushing bicycle not allowed here"?)

[Paul Johnson]

On Thu, Nov 7, 2019 at 7:02 AM Andy Townsend  wrote:

> My experience of the US is much less, but what I would say is that
> signage there is more likely to be just text, and that text may be
> complicated.  Parking signs are an example of this (and a bit of a trope
> there - see e.g.
> http://www.mikeontraffic.com/wp-content/uploads/2014/04/parking_regs.gif
> ).
>

In the US, the situation is improving.  Restriction signs are mostly all
pictographs, so word legends are going away as signs hit the end of their
functional life.

The default per FHWA is that a way is open to all modes of travel except
when otherwise posted, be it a cycleway to a freeway and everything in
between.  In practice, some states actually subscribe to this (the west
coast states operate this way in terms of access), but others have weird
rules you just have to know and don't appear anywhere except in the state
laws (getting more rare but still happens; like in Oklahoma where
pedestrians are bicycles are prohibited due to a minimum posted speed
limit, but you have no way of knowing there's a minimum speed limit until
you've been on the road for some time...).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Service road - Can it be a driveway if serving multiple houses?

[Paul Johnson]

On Tue, Nov 5, 2019 at 7:50 AM Dave F via Tagging 
wrote:

> Hi
>
> In the UK, Amazon Logistics are adding useful data from their GPS'd
> delivery vehicles. Mainly highway=service as the last part of their
> journey to a destination.
>
> However, one of their contributors removed service=driveway from a
> highway=service road. In the changeset comments they said it was because
> it served multiple residential properties.
>

 Weird.  In the US, this happens somewhat regularly, and usually for some
variation of a few reasons.


   - A landlocked lot has an easement on an adjacent lot for a driveway.
   The owner of the adjacent lot has their own driveway off the easement to
   minimize landuse dedicated to the movement and storage of vehicles.
   - A flag lot, where the "pole" passes one or more lots that the
   neighboring landowners are getting easement from the flag lot owner to
   limit the overall landuse among all landowners dedicated to driveways.

Usually the more complicated the flag lot/landlocked lot situation is, the
more likely the affected landowners are going to work with each other on
easement to just limit the amount of land everyone loses to driveways.  For
example here in Oklahoma, in situations where there's a landlocked lot
between a landowner with frontage and a flag lot, the typical arrangement
is for the flag lot to have a driveway, and the two other lots to have
easement (even though the frontage lot has, well, frontage), with the
frontage and landlocked lots sharing a wide driveway off the flag lot
driveway.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Changeset 62867521

[Paul Johnson]

On Thu, Nov 7, 2019 at 7:30 PM Mike Thompson  wrote:

> Hello,
>
> User dvdhns are having a friendly discussion regarding this changeset:
> https://www.openstreetmap.org/changeset/62867521#map=16/40.3021/-105.6436
>
> They have some good reasons for adding "(off trail)" to the end of the
> name to the "Fire Trail", but I don't think they override the rule that we
> should only use the name tag for the name [0].  Note that in any event, it
> is not really "off trail", it is a well defined trail, but is not an
> official trail according to the Park Service, thus in OSM tagging it is
> "informal" [1].  Perhaps some others in the community could weigh in on
> this issue.
>

It's a trail just for firefighting and rescue to access, but closed to all
others, correct?

highway=footway
access=no
emergency=yes
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

[Paul Johnson]

On Mon, Nov 11, 2019 at 2:41 AM Martin Koppenhoefer 
wrote:

> Am Mo., 11. Nov. 2019 um 09:28 Uhr schrieb Jan Michel  >:
>
>> I don't really like the idea to introduce both 'electric_bicycle' as a
>> generic term and 'pedelec', 'speed_pedelec' as more narrow tags in case
>> we need to be specific.
>>
>
>
> if the vehicle class is treated exactly like another one (e.g. pedelec
> like a bicycle), I agree there is no need to add an extra key for it, on
> the contrary you should not do it (don't tag your local legislation). If
> there are differences, we should have a key for every class that makes a
> difference (this is how we usually do it with access-tags).
>

Be aware that it's pretty typical in North America for pedelecs to be
considered as motor vehicles and excluded from bicycle facilities as such
when using their motor.  We have the Chinese pump-and-dump rental trash
scooter model to thank for this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - park_drive

[Paul Johnson]

On Thu, Dec 5, 2019, 04:09 Martin Scholtes  wrote:

> Hello,
>
> I would like to inform you that I have made a suggestion about park and
> drive. This resulted from a discussion in the OSM DE Telegram Chat.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/park_drive
> Definition: Information that can be taken on this parking lot to form a
> carpool.
>
> I would be pleased about suggestions.
>

I'm thinking this should be a subtag of park and ride ragging already
existing.  There's quite a few Park and Ride lots in places that don't
confer exclusive use of transit, and usually if you see a Park and Ride lot
in the rural midwestern US, there's a good chance it is exclusively for for
carpooling commuters.

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

Re: [Tagging] [Talk-us] Trunk VS primary,

[Paul Johnson]

On Thu, Dec 19, 2019 at 1:19 PM Martijn van Exel  wrote:

> I actually like your suggestion that highway=trunk does not add much value
> to the U.S. map, Eric.
> We love to add detail / granularity to OSM so much, it can become hard to
> envisage taking some away.
> Not saying we should abolish trunk right here and now, but something I'd
> consider as one outcome.
>

I'd like to see a lot more left up to the data consumer and more regional
values to be widely acceptable.  For example, instead of trying to smash
the entire planet into the UK's prescribed values and trying to come up
with equivalences, use the terminology each country uses.  So, for example,
in the US, instead of motorway, trunk, primary, secondary, tertiary,
perhaps something more like freeway, expressway, major/minor_principal
(just having this would fix a *lot* of problems with Texas and Missouri and
their extensive secondary systems), major/minor_collector...the US just has
a way more complex view of how highways work.

Or at least some more serious consideration given to the proposal at
https://wiki.openstreetmap.org/wiki/User:UltimateRiff/HFCS (but perhaps
with "other principal arterials" as primary and a new "highway=quartinary".

Much like moving route refs to highway relations (freeing the ref=* tag on
highways for situations where the road and the route have different refs),
leaving the mental gymnastics up to an algorithm and leaving less confusion
to the mapper is getting to be long overdue.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Paul Johnson]

On Fri, Dec 20, 2019 at 1:07 AM Mateusz Konieczny 
wrote:

>
> 20 Dec 2019, 01:25 by ba...@ursamundi.org:
>
> So, for example, in the US, instead of motorway, trunk, primary,
> secondary, tertiary, perhaps something more like freeway, expressway,
> major/minor_principal (just having this would fix a *lot* of problems with
> Texas and Missouri and their extensive secondary systems),
> major/minor_collector...the US just has a way more complex view of how
> highways work.
>
> Or at least some more serious consideration given to the proposal at
> https://wiki.openstreetmap.org/wiki/User:UltimateRiff/HFCS (but perhaps
> with "other principal arterials" as primary and a new "highway=quartinary".
>
> Fitting thing like road classification
> into UK system is irritating at times.
>
> But idea of each country with separate tags
> for roads is simply a bad idea.
>

Could you expand on this?  Being able to speak each country's highway
lingua franca would make it a lot easier for OSM to become the Rosetta
Stone of maps simply from ease of classification.


> This info is probably worth recording,
> but legal status should go into a separate tag.
>

Legal status of roads in the US isn't quite as clearcut as it is in the UK,
where the highway=* tag is literally equal to that country's legal
classification, plus private roads with significant public passage and/or
reach.  Off the top of my head we have 1 country, 2 states, 34 tribes, 77
counties and 597 towns, plus MacQuarie Group Australia running the
turnpikes and the Boy Scouts of America, Phillips 66, ConocoPhillips, or
some combination of the three, and potentially scores more private
entities, operating extensive networks of publicly accessible roads and
highways in Oklahoma.  And I generally consider myself lucky I have it
*this* straightforward in the US.

Texas likely has similar situations but throw in the fact that they have 7
different state highway systems before you get into at least 3 more
(regional? state? private? unclear...) competing turnpike networks,
sometimes running side by side on the same right of way (consider TX 121
with the George Bush Turnpike operated by the North Texas Transportation
Agency running down the median).

Simply starting with the HFCS and expanding from that (particularly on the
freeway/expressway distinction, and having more levels between secondary
and unclassified) would be a fantastic boon to dealing with this mess in a
more concise fashion as it changes highway=* tagging from almost entirely
subjective to subjective but within a limited range.  Establish wiki pages
describing how each region works and let the consumers sort it out from
there.

At an absolute minimum, we really need to establish values lower than
tertiary yet above unclassified, and we definitely do need to make the
freeway/expressway distinction.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Paul Johnson]

On Fri, Dec 20, 2019 at 4:41 PM Mateusz Konieczny 
wrote:

>
>
>
> 20 Dec 2019, 23:04 by graemefi...@gmail.com:
>
>
>
>
> On Fri, 20 Dec 2019 at 19:18, Martin Koppenhoefer 
> wrote:
>
>
>
> > On 20. Dec 2019, at 04:02, Graeme Fitzpatrick 
> wrote:
> >
> > that [/the/] (one & only) road servicing an area is dirt, if you're
> lucky, 2 lanes wide, but is used constantly by heavy traffic (semi-trailers
> with 3 o4 4 trailers on the back).
> >
> > How do we tie that into the nice neat Motorway > Primary > Secondary etc
> arrangement?
>
>
> lanes=2
> surface=unpaved
>
>
> Thanks, Martin :-)
>
> But would they still count as either =trunk or =primary?
>
> While they're of high local importance, they're definitely not
> high-performance & they don't link major population centres either?
>
> Main road linking villages (even unpaved
> and unmaintained) is
> highway=unclassified (yes, confusing name
> is confusing).
>

The British idea of "unclassified" maps nicely in Alaska to borough roads
(I would generally assume to be paved or at least graded if not graded and
graveled), since the usable space on U roads in the UK is substantially
smaller than tertiary and lanes are typically not present, or even singular
despite two way travel.


> Maybe this fits here?
>

Eeeh, maybe, but a long stretch.  In the US, it's generally established
that state highways are highway=secondary, even if unpaved, in the lower 48
and Hawaii.  Though the "unpaved" part has been obsolete since AR 220 went
from surface=dirt (it wasn't even graveled) to surface=asphalt, 4 years ago
in two weeks in the lower 48 and Hawaii.  Alaska is currently the only
state, territory or posession of the US that has unpaved state highways and
the last of the same that will ever have unpaved highways in the Eisenhower
Interstate Defense Highway System (despite having no signed network US:I
routes presently).  With that context, AK 2 fits pretty obviously as
highway=secondary.  Based on my look just now, looks like that's a good fit
saved for portions within Fairbanks metro, which would be a good
highway=trunk segment.  There are no portions that I see as rising to
highway=motorway, despite being presently mapped as such in some parts of
Fairbanks.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Paul Johnson]

On Fri, Dec 20, 2019 at 5:22 PM Graeme Fitzpatrick 
wrote:

> While =primary refers to "A major highway linking large towns, in
> developed countries normally with 2 lanes. In areas with worse
> infrastructure road quality may be far worse"
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dprimary
>

Well, that more or less does it, doesn't it?  Homer, Alaska is almost
exactly a statistically average American city in terms of size, anything
larger than that would be a moderately large city with Juneau, Fairbanks
qualifying as moderately major and Anchorage as quite large.  Keep in mind,
the average US city is only about 5000 people.


> If the only way of getting from A to B is along a particular road, it's
>> very important.
>>
>
> In some of the cases that I'm thinking of, these are the only roads, so
> yes, very important.
>

In which case secondary is going to show up adequately while not
overstating its stature as an even more major road than it is.


> Do we need to broaden our classes of construction/legality somewhat to
>> encompass
>> standards in countries outside the UK?  Probably.  Are the values for the
>> highway key
>> UK-centric and somewhat misleading?  Sure.
>>
>
> Thank you!
>
>
>> Should we map dirt tracks between Hell's Bumhole and Arse-end Of Nowhere
>> as motorways because they're the only
>> way of getting from one place to the other?  No, no, a thousand times no.
>>
>
> & yes, yes, a thousand times yes, :-) I agree that they shouldn't be
> =motorways, BUT, they should be either =trunk or =primary, because, in this
> area, they are the main road, & so are of vital importance
>

But, it's largely been established in the US that highway=trunk is a
special case to mean limited access expressway or controlled access single
carriageway, and primary being either an extremely major locally
significant road or a longer road of national importance.  AK2 might fit
primary for most of its length, and definitely fits trunk for it's
Fairbanks dual-carriageway segment, but I think a stronger case is made
with trunk for the Fairbanks dual carriageway and secondary for the rest.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Paul Johnson]

On Fri, Dec 20, 2019 at 6:57 PM Joseph Eisenberg 
wrote:

> > Being able to speak each country's highway lingua franca would make it a
> lot easier for OSM to become the Rosetta Stone of maps simply from ease of
> classification.
>
> That would mean using "jalan=provinsi" instead of "highway=primary" in
> Indonesia, so any global map service (like opencyclemap.org) would
> need to interpret all these tags from different languages. If you
> limit this to just official languages there would be several hundred
> to translate, but there are over 1500 languages with a written
> language currently: I don't see why we would limit things to just
> official languages.
>

I'm not arguing in favor of a change in language for key name.  But the
local broadly accepted classification terminology (preferably in English
for consistency sake) for the value.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Trunk VS primary,

[Paul Johnson]

On Fri, Dec 20, 2019 at 7:22 PM Jarek Piórkowski 
wrote:

> On Fri, 20 Dec 2019 at 20:16, Paul Johnson  wrote:
> > On Fri, Dec 20, 2019 at 6:57 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
> >> > Being able to speak each country's highway lingua franca would make
> it a lot easier for OSM to become the Rosetta Stone of maps simply from
> ease of classification.
> >>
> >> That would mean using "jalan=provinsi" instead of "highway=primary" in
> >> Indonesia, so any global map service (like opencyclemap.org) would
> >> need to interpret all these tags from different languages. If you
> >> limit this to just official languages there would be several hundred
> >> to translate, but there are over 1500 languages with a written
> >> language currently: I don't see why we would limit things to just
> >> official languages.
> >
> >
> > I'm not arguing in favor of a change in language for key name.  But the
> local broadly accepted classification terminology (preferably in English
> for consistency sake) for the value.
>
> Why in English? Bundesstraße is a broadly accepted classification
> terminology, so is autostrada. If you want to do things for
> consistency sake, there are the accepted OSM-British-English names.
>

What I'm saying is highway=bundesstraße could be acceptable, but
straße=bundestraße wouldn't be.  Mostly so way type objects with highway=*
are still potentially routable.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging