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] 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]

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] 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] 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] 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] 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] 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 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] 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] 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 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 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 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 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 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] 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] 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] 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] 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] 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] 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] [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] [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] 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] 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 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] 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] 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] 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] 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] 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]

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]

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 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] 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]

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] 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] 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] 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]

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]

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]

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]

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] 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] 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] 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 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]

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 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] 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] 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] 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] 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] 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]

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]

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]

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 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] 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] 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] oneway=yes on motorways

[Paul Johnson]

On Tue, May 26, 2020 at 12:34 PM Steve Doerr 
wrote:

> I would think that oneway=yes or oneway=-1 was required on motorways in
> order to identify the direction of one-way travel. For roundabouts, it must
> be easier provided data consumers know the national rules.
>
Seems pretty easy to tag it anyway and remove all doubt.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] oneway=yes on motorways

[Paul Johnson]

On Tue, May 26, 2020 at 3:22 AM Jean-Marc Liotier  wrote:

> On 5/26/20 5:44 AM, Paul Johnson wrote:
>
>
> It can't hurt to specify oneway=yes. I have noticed that the JOSM style
>> that shows lane counts and lane use will sometimes not show ways
>> properly if oneway=yes isn't there, but that's probably a bug in the
>> style more than an indictment of implying oneway=yes.
>>
>
> I'm on the side of "team tag explicitly" on this.  If anything, it gives
> validators more to work with if you start doing something weird.
>
> Isn't that what oneway=no is for ?
>
Or literally either value.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] oneway=yes on motorways

[Paul Johnson]

On Sun, May 24, 2020, 18:51 Shawn K. Quinn  wrote:

> On 5/24/20 15:26, Volker Schmidt wrote:
> > I just noticed an apparent contradiction regarding the use of the oneway
> > tag between the wiki pages key:oneway
> >  and motorway
> >  .
> > The former states:
> > "Some tags (such as junction
> > =roundabout
> > , highway
> > =motorway
> >  and others)
> > imply oneway=yes and therefore the oneway tag is optional,
> > the latter states:
> > "These ways should all point direction of travel and be tagged with
> > oneway =yes"
> > 
> >
> > What is the agreed standard, if any?
>
> It can't hurt to specify oneway=yes. I have noticed that the JOSM style
> that shows lane counts and lane use will sometimes not show ways
> properly if oneway=yes isn't there, but that's probably a bug in the
> style more than an indictment of implying oneway=yes.
>

I'm on the side of "team tag explicitly" on this.  If anything, it gives
validators more to work with if you start doing something weird.

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

Re: [Tagging] relations & paths

[Paul Johnson]

On Thu, May 14, 2020 at 5:48 AM Steve Doerr  wrote:

> On 14/05/2020 09:31, Jo wrote:
>
>
>
> On Wed, May 13, 2020, 17:44 Jmapb  wrote:
>
>> Regarding the original question -- in what circumstances are
>> single-member walking/hiking/biking route relations a good mapping practice
>> -- what would be your answer?
>>
>
> Always
>
>
> Doesn't that violate
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element ?
>

No.  The route traverses the way, it's not the way.  You know what does
violate one feature, one element?  Putting highway route numbers on the way
instead of exclusively in the relation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relations & paths

[Paul Johnson]

On Wed, May 13, 2020 at 10:43 AM Jmapb  wrote:

> On 5/13/2020 10:12 AM, Paul Johnson wrote:
>
>
> We've had relations for over a decade now, IIRC.  It's time to stop
> treating this basic primitive as entity-non-grata.  If tools *still* can't
> deal with this, this is on the tools and their developers now.
>
> Sure. Regarding the original question -- in what circumstances are
> single-member walking/hiking/biking route relations a good mapping practice
> -- what would be your answer?
>

Is it part of a network?  Is it signed as part of a network?  OK 166 was a
single member relation until I did lane tagging on it and had to split that
way a couple times.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relations & paths

[Paul Johnson]

On Wed, May 13, 2020 at 9:23 AM brad  wrote:

> It isn't part of a route, it's the whole route.


 I think that's a difference without a distinction in this case.  Data
consumers still need to know the route is there.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relations & paths

[Paul Johnson]

On Wed, May 13, 2020 at 9:06 AM Jmapb  wrote:

> On 5/12/2020 10:58 PM, Paul Johnson wrote:
>
> On Tue, May 12, 2020 at 9:37 PM brad  wrote:
>
>> OK, but it seems redundant to me.   A trail/path get tagged as a path.
>> There's a trailhead and a sign, it gets a tagged with a name.   Why does
>> it need to be a route also?
>>
>
> Same reason all 0.11 miles of I 95 in Washington DC is part of a route.
> It's part of a route.
>
> Yes but that's *part* of a route, a route relation with many other
> members. Brad's asking about single-member route relations.
>
And so is that 50-51 segment in the Dutch cycle network. Even if it's  a
particularly short one.

> Finally there's the issue of software and rendering support. Waymarked
> Trails, as Kevin mentioned, only supports route relations. I believe other
> hiking map renderers work similarly. Of course this is not how OSM is
> "supposed" to work -- structuring data for a particular renderer or
> software -- but nonetheless it is a factor in how people map.
>
We've had relations for over a decade now, IIRC.  It's time to stop
treating this basic primitive as entity-non-grata.  If tools *still* can't
deal with this, this is on the tools and their developers now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relations & paths

[Paul Johnson]

On Tue, May 12, 2020 at 9:37 PM brad  wrote:

> OK, but it seems redundant to me.   A trail/path get tagged as a path.
> There's a trailhead and a sign, it gets a tagged with a name.   Why does
> it need to be a route also?
>

Same reason all 0.11 miles of I 95 in Washington DC is part of a route.
It's part of a route.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] contact:google_plus status discardable ?

[Paul Johnson]

I think that's a distinction without a difference right now.  Given that I
can check my Google+ right now (yes, mine still works) but it's *now* as
dead as people used to claim it was before.

On Mon, Apr 13, 2020 at 5:49 PM Phake Nick  wrote:

> Google Plus for Corporate is still functional.
>
> 在 2020年4月14日週二 06:25，Marc M.  寫道：
>
>> Hello,
>>
>> the service was shutdown on 2 avril 2019
>> can we set the status as discardable ?
>>
>> Regards,
>> Marc
>>
>> ___
>> 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] Can highway=cycleway be limited to MTB?

[Paul Johnson]

On Thu, Apr 2, 2020 at 3:10 AM Andrew Harvey 
wrote:

> My view based on current usage, reading of the wiki and general opinion is
> that highway=cycleway is meant for any path that is either
> designed/intended for bicycles or specifically designated (signposted) for
> bicycles, irrespective of if it's an urban track or mountain biking track.
>
> So a mountain bike track and an urban cycle track should both be tagged
> with highway=cycleway as the primary tag. surface= and smoothness= can help
> for both to help guide users on which kind of bicycle the track is suitable
> for, and mtb:scale=/mtb:scale:imba= are used to indicate this is a
> designated mountain biking track.
>
> highway=path is specifically for a general use / unspecified path, which a
> mountain biking track may be if it's informal/shared, but purpose built and
> signposted mountain bike tracks don't fall into that category.
>
> A similar thing applies to hiking tracks, sometimes they are designated
> walking paths so use highway=footway + surface + sac_scale, but sometimes
> they are just an unmarked or mixed use path so are highway=path + surface +
> sac_scale.
>

This is also my read on it.  But we also need more than just
highway=path/cycleway and sometimes footway for bicycle facilities, there's
a bigger hierarchy than this.  Also seen a lot of situations where
highway=cycleway_link would be handy.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names that aren’t names

[Paul Johnson]

On Sat, Mar 28, 2020 at 5:45 PM Kevin Kenny  wrote:

> On Sat, Mar 28, 2020 at 5:57 PM Richard Fairhurst 
> wrote:
>
> > Sure. NCN 4 is called "NCN 4" in the same sense that the M4 is called the
> > "M4". That's fine - plenty of people refer to it that way. But OSM
> > convention, dating back 15ish years, is that in situations like this, you
> > put the number in the ref alone. The M4 just has ref=M4, not name=M4.
>
> We Yanks follow that convention for route _relations_, where we can
> identify the network. Otherwise, it really doesn't work for us,  It's
> entirely possible to have intersections between two routes with the
> same number that belong to different networks. (Yes, it's confusing,
> but we are used to identifying routes as "Interstate 95", "US 9", "New
> York 20", "County Road 84",  even in speaking.)  For us to leave
> that out would be like you saying the 4 or the 180 for the M4 or the
> A180.
>

Doesn't really work for most of Europe, either.  I get that European Truck
Simulator 2 and American Truck Simulator are highly stylized
representations of both regions, but in both cases, it's pretty obvious the
only places within the scope of those games that "*doesn't*" have this
problem is the UK and Arizona.  Except they still do, because bus, bicycle
and foot routes still run over the same ways as motorist routes...


> You convinced me that refs are not names, so I've been working in my
> local area of killing off the use of the ref as the name, even in
> cases where the road has no other name: 'ref="CR 104" noname=yes' in
> preference to 'ref="CR 104" name="County Road 104"').  But as long as
> we suffer with refs on ways, we need at least to make the refs useful.
>

Most of Oklahoma and parts of Kansas also have the variation "E0104 Road"
which is really "CR E0104"...this one's going to be hard to crush since
there's slightly higher than one county road per mile on average on a state
that has extents of 478 miles east to west and 231 north to south, with
numbers *usually* but not always consistent across counties.  It goes
sideways in Osage County, the panhandle and the mountainous counties where
they get put in pretty much wherever terrain will allow, and there's 77
counties, so, probably somewhere between 25,000 and 50,000 county roads
that need to be updated.


> (That gets tricky when one jurisdiction's road crosses over into
> another jurisdiction.  About half of NY 120A
> https://www.openstreetmap.org/relation/407958 is in Connecticut but
> it's signed and maintained as a New York state highway.)
>

Nice thing is relations don't care.  Which is handy because Oklahoma has a
couple routes that go into Texas, and both Oklahoma and Arkansas, and
Oregon and Washington have routes that go into each other (Oklahoma and
Arkansas having a road that's dual signed as an Oklahoma and Arkansas state
highway; largely as a result of the road roughly following the state line
but the line didn't care about terrain and roads obviously do).


> I fully understand the difficulty with rendering only from route
> relations. I maintain a renderer that does it.  It still needs some
> serious programming if it is to scale to handle minutely updates
> against the planet.  The project has, to put it mildly, less than my
> highest priority, since Paul and Sarah have quite sternly discouraged
> me from pursuing the approach that I took to the problem. The issue is
> that the rendering servers are already grievously overloaded, and any
> new functionality such as this needs to come at essentially zero cost
> at render time, and only negligible cost at the time of minutely
> updates. I've not been clever enough to meet that challenge, and while
> new ideas might come to me, I've so far come up empty.
>
>
 Which Paul?  I'm on Team Relation here.  It's been 13 years, relations
really need to be treated like any other primative.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names that aren’t names

[Paul Johnson]

On Sat, Mar 28, 2020 at 5:29 PM Peter Neale via Tagging <
tagging@openstreetmap.org> wrote:

> Like Dave, I am not sure that I see a huge issue with a name and a
> reference duplicating each other (or at least overlapping).
>
> Names and References are essentially doing the same job; they identify
> "things"; they are proper nouns.
>
> We probably expect a name to be a word (or words) and a reference to be an
> alphanumeric string that is not a word (or words), but that is not always
> the case.  That big mountain is called "K2"; that is its name.
>
> Clearly, there are many cases where name and reference are different and
> are both required - e.g.Name: Watling Street; Ref: A5.  (Mind you,
> perhaps "A5" should be the name of a route relation, which includes a
> stretch of road called "Watling Street", so that may be a poor example)
>

A better example would be areas that have both "state highways" and "state
routes" as unique concepts.  Like for example, in Oregon, every last road
in the state highway inventory has a ref.  All of them.  Not all of them
are part of state routes, however.  Top of the head example would be
Interstate Avenue in Portland, which is part of State Highway 1W but no
longer part of 99W (longtimers will remember this and generally use
Interstate as if it were 99W though).  But the highway number belongs to
the road, not the route.  Pennsylvania has something similar going on,
particularly with the 4-digit state highways.

Moving all, and I do mean *all*, tags that belong to the route to a route
relation would be the best way to model this (and one of the things that
was being tossed around back when I joined in the prep for API 0.5).

In other cases names may include words and numbers (e.g. I don't think that
> National Cycle Network Route 51 has any other name).  One could then say
> that "NCN 51" is an abbreviated name and not a reference.  AFAIK, there is
> not an accepted tag for an abbreviated name,  so (I assume) mappers have
> used the ref= tag for this (after all it looks like a reference), which
> gives us:  name=National Cycle Network Route 51; ref=NCN 51.
>

route=bicycle
network=ncn
ref=51
noname=yes

Route relations really are that easy.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names that aren’t names

[Paul Johnson]

On Sat, Mar 28, 2020 at 3:39 PM Peter Elderson  wrote:

>
> Richard Fairhurst::
>
>> If you need somewhere for a mapper-facing route description (and I can
>> see that you need that for “part United Kingdom 5”), then I guess the
>> obvious place to put that is the note= tag. But let’s keep it out of the
>> name tag; and let’s have a concerted effort to remove them from existing
>> name tags.
>
>
> I was under the impression the note=* tag is for mapper's notes about the
> object.
> I would think the best tag for a descriptive text would be the
> description=* tag.
>
> Question about the ref=* tag: should a ref be something visible along the
> route?
>

Generally, and that's one of the reasons relations were introduced as a
primitive in API 0.5 13 years ago.  Because multiplexed routes are a thing,
not only between the same network but within multiple networks (such as a
way that has a bus route, a county and a state bike route, is part of a US
historic highway, and a current state highway), and ref=* on a way to
describe a specific kind of route that traverses it makes very little sense.

Can we please kill ref=* on way already?  Please?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names that aren’t names

[Paul Johnson]

On Sat, Mar 28, 2020 at 2:30 PM Andrew Hain 
wrote:

> Proposal for QA tools: flag anything with the same number in the name and
> ref.
>

So much this.   I see this a lot and had to fix a bit of that when I was
doing I 405 work.  "Interstate 405" is *not* a name and shouldn't be
there...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names that aren’t names

[Paul Johnson]

On Sat, Mar 28, 2020 at 1:18 PM Richard Fairhurst 
wrote:

> A modest proposal: let’s use the name= tag in route relations for route
> names. Let’s use the ref= tag for route numbers. If it doesn’t have a name,
> it shouldn’t have a name= tag. Same as we do everywhere else.
>

I'm OK with this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to match multiple destinations and destination:ref?

[Paul Johnson]

On Thu, Feb 13, 2020 at 9:07 AM António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

> Hi there.
>
> I've stumbled with a problem for which I couldn't find a satisfactory
> answer.
> Say I have a destination sign in a motorway junction exit with 4
> destinations, but only the second one has a ref. How do we match the
> right destination with its ref?


Is there a user story that requires that level of accuracy?  In the US,
typically signage doesn't get *that* specific.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?&In-Reply-To=<88cad950-d9cc-3c2e-9015-a54d7206a...@gmx.com>

[Paul Johnson]

On Mon, Feb 10, 2020 at 8:41 AM Marc Gemis  wrote:

> On Mon, Feb 10, 2020 at 3:26 PM Paul Johnson  wrote:
> >
> > On Mon, Feb 10, 2020 at 3:36 AM Florimond Berthoux <
> florimond.berth...@gmail.com> wrote:
> >>
> >> Le lun. 10 févr. 2020 à 09:49, AndreasTUHU  a
> écrit :
> >>>
> >>> I agree that 'surface' tag should be mandatory but in Hungary 54
> percent of the mixed foot-cycle-ways misses this tag.
> >>> Additionally, the 20 percent of foot-cycle-ways has no 'segregated'
> tag. Not ideal conditions for converting mixed cycleways to path :)
> >>
> >>
> >> I don’t understand, for me a mixed cycleway has no sense, if it’s mixed
> well it is a path segregated or not.
> >
> >
> > It's common in North America.  Sometimes it even switches between a path
> and a cycleway.  Galloping Goose Cycleway and Trail in Canada's a fantastic
> example of both.
> >
> > 1. Cycleway that allows pedestrians:
> https://en.wikipedia.org/wiki/Galloping_Goose_Regional_Trail#/media/File:Galloping_Goose_Regional_Trail,_Saanich,_British_Columbia,_Canada_17.jpg
>
> Curious to understand why this is a cycleway and not an asphalted path.
>

Primary purpose as indicated by the presence of dedicated lanes and signage
specifically for cyclists.  Busier parts also include ◊ 🚲 ↑ and signs
reminding pedestrians to walk near the edge.  Oklahoma and Oregon do
something similar but often omit the "bike lane" markings and instead ask
pedestrians to walk on the right half, preferably near the edge.

Similar to tertiary roads that allow pedestrians but lack sidewalks.  It
still has lanes, pedestrians are allowed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?&In-Reply-To=<88cad950-d9cc-3c2e-9015-a54d7206a...@gmx.com>

[Paul Johnson]

On Mon, Feb 10, 2020 at 3:36 AM Florimond Berthoux <
florimond.berth...@gmail.com> wrote:

> Le lun. 10 févr. 2020 à 09:49, AndreasTUHU  a écrit :
>
>> I agree that 'surface' tag should be mandatory but in Hungary 54 percent
>> of the mixed foot-cycle-ways misses this tag.
>> Additionally, the 20 percent of foot-cycle-ways has no 'segregated' tag.
>> Not ideal conditions for converting mixed cycleways to path :)
>>
>
> I don’t understand, for me a mixed cycleway has no sense, if it’s mixed
> well it is a path segregated or not.
>

It's common in North America.  Sometimes it even switches between a path
and a cycleway.  Galloping Goose Cycleway and Trail in Canada's a fantastic
example of both.

1. Cycleway that allows pedestrians:
https://en.wikipedia.org/wiki/Galloping_Goose_Regional_Trail#/media/File:Galloping_Goose_Regional_Trail,_Saanich,_British_Columbia,_Canada_17.jpg

2. A path segment of the same in a more rural area:
https://en.wikipedia.org/wiki/Galloping_Goose_Regional_Trail#/media/File:Galloping_Goose_Trail._INFO_IN_PANORAMIO_DESCRIPTION_-_panoramio.jpg

3. Keep going further out and it becomes a track (with obvious evidence
doubletracked vehicles, like maintenance trucks, do use it, but probably
not open to most motor vehicles):
https://en.wikipedia.org/wiki/Galloping_Goose_Regional_Trail#/media/File:Galloping_Goose_Trail_-_a_restored_train_station_near_the_Sooke_Potholes.jpg
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road names and refs

[Paul Johnson]

On Thu, Jan 30, 2020 at 3:15 PM Kevin Kenny  wrote:

> On Thu, Jan 30, 2020 at 2:50 PM Richard Fairhurst 
> wrote:
> > Honestly, there is, and it's as Paul and I have described - you put the
> ref
> > in the ref tag and leave the name tag blank. This is how it has been in
> OSM
> > since pretty much day one. If a newbie in Europe puts a ref in the name
> tag,
> > it gets stomped on pretty quickly.
> >
> > The reason it might seem otherwise in the States is that the TIGER import
> > didn't populate the ref tag, just the name tag, and a lot of the TIGER
> > import still hasn't been cleared up. So there's a bunch of TIGER-derived
> > roads which have things like "name=County Road 23" (or Township Road, or
> "Co
> > Rd", or many other variations).
>
> OK, I'll add that to the things I look for. As I said, I'd been
> retaining it only when it's the only name, and I never added any new
> ways with that, merely refrained from repairing that case.
>
> It's encouraging that in this particular discussion, that's the only
> detail you guys say I got wrong. 'ref' tag on the way for the
> renderer; road route relation with detailed network and ref; never an
> alt_name or name_1, etc. with a route reference.
>
> Oh, and a further corner case: Are we agreed that something like "Old
> Route 7" has become a name?  It's no longer a ref, because Route 7 is
> now elsewhere. It appears on street signs like any other name, not on
> a reference banner, and it's the 'addr:street' of the houses on it.
>

Eeeh, I'd generally suggest tagging that as noname=yes old_ref=US 7 (if the
old route was a US route) to retain more information.  Signing is pretty
similar, too, some places will leave the old shields up and change the
banner from a cardinal to OLD until the signs wear out as a wayfinder for
folks with outdated maps.  Much of the midwest, on nameless roads that have
routes, just put something like "SH 33" or "Hwy 412" on the finger signs as
a low-budget solution to posting a proper, potentially multicolor, die-cut,
screen-printed shield and a double-ended arrow as is MUTCD standard for
such a case.  addr:street still goes with however the post finds it.  It
helps to know the local context quite a bit when trying to sort out how
local authorities cheaped out on posting standard signs.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road names and refs

[Paul Johnson]

On Thu, Jan 30, 2020 at 12:38 PM Kevin Kenny 
wrote:

> On Thu, Jan 30, 2020 at 12:58 PM Paul Johnson  wrote:
> > No, no.  I'm not proposing addr:street on ways at all, only on things
> that actually have an address.  What I am saying is that noname=yes should
> be a trigger to validators that they can't depend on the way to handle
> address validation.  Just saying that name=County Road 34, ref=CR 34 is
> wrong; noname=yes; ref=CR 34 is the way to go.
>
> OK, and that's where we disagree - one important _suggestion_ that a
> validator can make is to point out that there's no similarly-named way
> anywhere nearby. At least once I've done the house numbers for a whole
> street without remembering to change the name of the street from the
> previous one I was working on, and I was glad that the validator
> caught it before I uploaded!
>
> (If you're now going to tell me "don't make mistakes like that!" my
> reply is, "Good luck with that one!")
>
> I think we can both agree that in practice there is no clear consensus
> on what to do in the specific case where a road has a reference but no
> other name. (That is intended as an entirely neutral statement - not
> "Kevin's right" or "Paul's right")


I disagree.  The wiki had it pretty clearly documented that names aren't
refs longer than I've been in the project.  People putting refs as names is
a more recent, value detracting, invention.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road names and refs

[Paul Johnson]

On Thu, Jan 30, 2020 at 11:46 AM Kevin Kenny 
wrote:

> On Thu, Jan 30, 2020 at 12:09 PM Paul Johnson  wrote:
> > addr:street= should be tagged anyway, and that's where you can put your
> "County Route 34".  Attempting to infer this based off the nearest street
> should be a last resort because, at least in the US, it's not uncommon for
> what the street's actually named and signed to be radically different than
> the postal address's street name for simplicity or brevity's sake.
>
> I do that, too, when I do address points or building footprints. I
> don't propose importing my county's address points (because of data
> quality issues) or its building footprints (because of licensing
> issues) so that happens manually on a catch-as-catch-can basis. If
> you're proposing 'addr:street' on the way, that's fraught with another
> set of issues - but I don't think that's what you're proposing.
>

No, no.  I'm not proposing addr:street on ways at all, only on things that
actually have an address.  What I am saying is that noname=yes should be a
trigger to validators that they can't depend on the way to handle address
validation.  Just saying that name=County Road 34, ref=CR 34 is wrong;
noname=yes; ref=CR 34 is the way to go.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road names and refs

[Paul Johnson]

On Thu, Jan 30, 2020 at 10:49 AM Kevin Kenny 
wrote:

> On Thu, Jan 30, 2020 at 10:09 AM Kevin Kenny 
> wrote:
> >> (1) The `name=*` field gets the road's actual name. If the road's only
> >> name is 'County Route 12' (New York consistently uses 'Route' rather
> >> than 'Road' for these), to the extent that `addr:street=*` will show
> >> that for the name, then `name=*` gets that name. (Yes I know that
> >> there are mappers who would prefer `noname=yes` in that situation, but
> >> address validation has an easier time with the way I do it.)
>
> On Thu, Jan 30, 2020 at 11:20 AM Paul Johnson  wrote:
> > Please stop.  This gets very annoying for data consumers (especially
> your average joe just using a satnav).  Fix your validation process instead.
>
> I knew you were going to say that. The sentiment seems to run about
> equally between 'fix the navigation software not to read the ref
> twice,' and 'fix software that recognizes street addresses to deal
> with the fact that an address of '2367 County Route 34' might need to
> be translated to a ref=*'.
>

addr:street= should be tagged anyway, and that's where you can put your
"County Route 34".  Attempting to infer this based off the nearest street
should be a last resort because, at least in the US, it's not uncommon for
what the street's actually named and signed to be *radically* different
than the postal address's street name for simplicity or brevity's sake.

This solves both problems.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road names and refs

[Paul Johnson]

On Thu, Jan 30, 2020 at 10:09 AM Kevin Kenny 
wrote:

> On Thu, Jan 30, 2020 at 9:51 AM Jarek Piórkowski 
> wrote:
> >
> > On Thu, 30 Jan 2020 at 09:38, Rob Savoye  wrote:
> > > On 1/30/20 2:08 AM, Richard Fairhurst wrote:
> > > > "County Road 12" is a ref. It is not a name. People often refer to
> roads by
> > > > their ref. That's fine. I will say "I'm taking the A3400 to
> Stratford"
> > >
> > >   I'm wondering if "CR 12" or "County Road 12" (the abbreviation
> > > expanded) was the proper value for a ref. If the abbreviation is fine
> > > for the ref, should it then have a name that is expanded ? The wiki
> > > isn't clear.
> >
> > One solution I've seen advanced is that the ref in that case is just
> > 12. But that rather raises more new questions than it answers, because
> > while no one says "I'm going to take the Highways England A3400" or
> > "the British A3400", people do say "I'm going to take County Road
> > 12"...
>
> What I do:
>
> (1) The `name=*` field gets the road's actual name. If the road's only
> name is 'County Route 12' (New York consistently uses 'Route' rather
> than 'Road' for these), to the extent that `addr:street=*` will show
> that for the name, then `name=*` gets that name. (Yes I know that
> there are mappers who would prefer `noname=yes` in that situation, but
> address validation has an easier time with the way I do it.)
>

Please stop.  This gets very annoying for data consumers (especially your
average joe just using a satnav).  Fix your validation process instead.


> (3) In the US, there are so many coincidences among numbered routes
> that they're hard to work with unless you use `route=road` relations.
> Moreover, there are a number of cases where one jurisdiction's route
> crosses over into another jurisdiction's territory, but the owning
> juristiction still maintains and numbers it. There are New York State
> highways with portions in at least Connecticut, New Jersey and
> Pennsylvania. Only a route relation can identify the state on NY 120A
> https://www.openstreetmap.org/way/108702747 where it's a New York
> State highway on Connecticut soil.
> (Note that its postal address is also Purchase, New York, and not
> Fairfield, Connecticut, since its mail is delivered from the other
> side of the state line. Confusion abounds.)
>

Ultimately this is the way forward, worldwide.  ref on ways is a stupid way
to describe routes and ultimately it's beyond time to kill that dinosaur
(not to mention, precludes the way from having it's own ref, which every
state-owned road in Oregon and Pennsylvania at a minimum, does).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road names and refs

[Paul Johnson]

On Thu, Jan 30, 2020 at 8:38 AM Rob Savoye  wrote:

> On 1/30/20 2:08 AM, Richard Fairhurst wrote:
>
> > You asked this back in August and the answers still apply:
>
>   That was as slightly different question about multiple names, and yes,
> still applies.
>
> > "County Road 12" is a ref. It is not a name. People often refer to roads
> by
> > their ref. That's fine. I will say "I'm taking the A3400 to Stratford"
>
>   I'm wondering if "CR 12" or "County Road 12" (the abbreviation
> expanded) was the proper value for a ref. If the abbreviation is fine
> for the ref, should it then have a name that is expanded ? The wiki
> isn't clear.
>

ref=CR 12 would be the correct value.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road names and refs

[Paul Johnson]

On Wed, Jan 29, 2020 at 5:02 PM Shawn K. Quinn  wrote:

> On 1/29/20 16:17, Paul Johnson wrote:
> > On Wed, Jan 29, 2020 at 4:07 PM Joseph Eisenberg
> > mailto:joseph.eisenb...@gmail.com>> wrote:
> > In my hometown, the main road was California highway 96, so “ref=CA
> > 96” but we called it “Highway 96” so “name=Highway 96”.
> >
> >
> > I think you're confusing name=* with addr:street=* in that case, Joseph.
>
> JOSM has a mode where it renders highway=* with a color based on the
> name=* and nearby addresses with color based on addr:street=*. This is
> useful for finding misspelled and abbreviated road names either in the
> address or on the road itself. I've always thought name=* was to refer
> to the name of the road as used in addresses, usually indicated on
> street signs. Have I missed something?


The name is only the name, it is not a ref or old_ref.  This has even been
in the wiki and normal practice for longer than I was even aware of the
Names page.  https://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only

For street names as they appear in addresses, see addr:street instead.
It's not uncommon at all for what gets put on the envelope is different
than what's on the sign, or the value of addr:street= to not even be a
street name but a highway number or even some internal route to whatever
state postal system is present (such as RFD and RR addresses in the US).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road names and refs

[Paul Johnson]

On Wed, Jan 29, 2020 at 4:07 PM Joseph Eisenberg 
wrote:

> > should 'ref' be 'CR 12', and then "name='County Road 12'"
>
> Sure, if local addresses say “123 County Road 12” and local people say “I
> live on County Road 12”.
>
> If the name is “Old County Road 12”, that would clearly be a name, not a
> ref.
>
> In my hometown, the main road was California highway 96, so “ref=CA 96”
> but we called it “Highway 96” so “name=Highway 96”.
>

I think you're confusing name=* with addr:street=* in that case, Joseph.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road names and refs

[Paul Johnson]

On Wed, Jan 29, 2020 at 1:29 PM Rob Savoye  wrote:

>  I was wondering about tagging roads properly. Previously it was
> mentioned to use 'ref' for county roads, ie... "ref='CR 12'", but as the
> road sign says "County Road 12", I was wondering about the proper way to
> tag this. Should 'CR' be expanded in the 'ref' to "County Road", or
> should 'ref' be 'CR 12', and then "name='County Road 12'" ? This also
> applies to state Forest Service roads as well that lack a name tag. I'm
> working on cleaning up some ancient crap from the TIGER import...
>

 Both of these would be noname=yes and ref=*
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Paul Johnson]

On Tue, Jan 28, 2020 at 7:08 PM Jarek Piórkowski 
wrote:

> On Tue, 28 Jan 2020 at 19:55, Paul Johnson  wrote:
> >
> >
> >
> > On Tue, Jan 28, 2020 at 6:51 PM Jarek Piórkowski 
> wrote:
> >>
> >> On Tue, 28 Jan 2020 at 19:45, Paul Johnson  wrote:
> >> > On Tue, Jan 28, 2020 at 6:14 PM Yaro Shkvorets 
> wrote:
> >> >> That passage should be rewritten. That's certainly not the common
> practice.
> >> >> I personally tag `highway=cycleway` where bikes significantly
> outnumber foot traffic, `highway=footway` where foot traffic significantly
> outnumbers bikes, `highway=path` for the rest.
> >> >> If you need to explicitly disallow bikes or foot you use access tags.
> >> >
> >> > This seems a little iffy.  I mean, footway is obvious, is it designed
> for people on foot, and too narrow for oncoming bikes to meet?  Footway.
> City sidewalk?  Footway.  A path through a park?  Probably a path
> (especially if it's multiuse), unless it's really narrow, then footway.
> Has lanes but isn't a street?  Cycleway.
> >>
> >> Around Toronto I've generally seen (and also tagged myself), for
> >> routes through a park, footway if it's paved or otherwise major, path
> >> if it's unpaved or overgrown or status uncertain. So I interpret
> >> highway=footway to be "higher grade" than highway=path - the opposite
> >> of your interpretation, I fear...
> >
> > Not higher grade, just not as specialized in its design purpose and what
> other use modes will not find their needs particularly addressed if it's
> allowed at all.  In a venn diagram of bridleway, cycleway and footway, path
> is in the middle.
>
> Hm, that's not how I think about it. In my mental map: bridleway
> doesn't exist (as a big-city mapper); path is something for people but
> nothing major; footway is usually paved with a lot of pedestrians on
> it and if not a sidewalk maybe bikes but not majority; cycleway is
> usually paved with relatively a lot of bicycles on it (can be unpaved
> if out in nature).
>

As previously mentioned, a lot of places (the US and possibly Canada in
particular) have a lot of places that use "multiuse path" and "bicycle
oriented facility" somewhat interchangeably, hence why I tend to make the
distinguishing factor between the two being on whether or not it has
lanes.  So, part of the confusion is general official apathy of such
facilities, and it basically an afterthought chapter in the Manual on
Uniform Traffic Control Devices and Standard Highway Signs and Markings.

Bridleways only come to mind from the only place I've ever seen them,
which, weirdly enough, would be in Los Angeles and its suburbs.  North end
of the San Fernando Valley and going from roughly Pasadena to Indio (this
one also has adjacent foot and cycleways as part of the same right of way!)
has quite a few.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Paul Johnson]

On Tue, Jan 28, 2020 at 6:51 PM Jarek Piórkowski 
wrote:

> On Tue, 28 Jan 2020 at 19:45, Paul Johnson  wrote:
> > On Tue, Jan 28, 2020 at 6:14 PM Yaro Shkvorets 
> wrote:
> >> That passage should be rewritten. That's certainly not the common
> practice.
> >> I personally tag `highway=cycleway` where bikes significantly outnumber
> foot traffic, `highway=footway` where foot traffic significantly outnumbers
> bikes, `highway=path` for the rest.
> >> If you need to explicitly disallow bikes or foot you use access tags.
> >
> > This seems a little iffy.  I mean, footway is obvious, is it designed
> for people on foot, and too narrow for oncoming bikes to meet?  Footway.
> City sidewalk?  Footway.  A path through a park?  Probably a path
> (especially if it's multiuse), unless it's really narrow, then footway.
> Has lanes but isn't a street?  Cycleway.
>
> Around Toronto I've generally seen (and also tagged myself), for
> routes through a park, footway if it's paved or otherwise major, path
> if it's unpaved or overgrown or status uncertain. So I interpret
> highway=footway to be "higher grade" than highway=path - the opposite
> of your interpretation, I fear...
>

Not higher grade, just not as specialized in its design purpose and what
other use modes will not find their needs particularly addressed if it's
allowed at all.  In a venn diagram of bridleway, cycleway and footway, path
is in the middle.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Paul Johnson]

On Tue, Jan 28, 2020 at 6:14 PM Yaro Shkvorets  wrote:

> That passage should be rewritten. That's certainly not the common practice.
> I personally tag `highway=cycleway` where bikes significantly outnumber
> foot traffic, `highway=footway` where foot traffic significantly outnumbers
> bikes, `highway=path` for the rest.
> If you need to explicitly disallow bikes or foot you use access tags.
>

This seems a little iffy.  I mean, footway is obvious, is it designed for
people on foot, and too narrow for oncoming bikes to meet?  Footway.  City
sidewalk?  Footway.  A path through a park?  Probably a path (especially if
it's multiuse), unless it's really narrow, then footway.  Has lanes but
isn't a street?  Cycleway.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Disputed territory mapped as a country

[Paul Johnson]

On Mon, Jan 27, 2020 at 11:41 PM Shawn K. Quinn 
wrote:

> On 1/27/20 18:31, Greg Troxel wrote:
> > Martin Koppenhoefer  writes:
> >
> >> Mateusz, offlist deliberately.
> >
> > While we're at it, could the list admins fix the BROKEN REPLY-TO?
>
> I have working "Reply" and "Reply List" features. I don't see what's
> broken.


The list is quashing whatever's in reply-to and replacing it with it's own
value.  Reply-to is supposed to be a user-set, not machine-set, field.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Paul Johnson]

On Mon, Jan 27, 2020 at 2:16 PM Mike Thompson  wrote:

>
>
> On Mon, Jan 27, 2020 at 10:39 AM Kevin Kenny 
> wrote:
> >
> > On Mon, Jan 27, 2020 at 12:00 PM Paul Johnson 
> wrote:
> > >  Not exactly helping is that the US tends to also confuse form and
> access, calling things "multipurpose paths" even when they are clearly
> purpose built for a specific mode and possibly even do have specific mode
> restrictions.
> >
> > True enough.  Still, there are a lot of rail-trails and the like where
> > foot, bicycle, and XC ski travel were all contemplated from the moment
> > that the trail was paved. There are also a bunch of recreational
> > trails near me that I'd be hard put to identify whether foot or MTB is
> > the 'primary' use.  And farther out in the sticks, there are a bunch
> > of old carriage roads that were redesignated footways and have
> > subsequently been opened to MTB travel as well. (Some of these are
> > grown to trees to the point where I don't feel comfortable labeling
> > them with `highway=track`.)
> Here is an example of a major trail in the area where I live:
> https://www.openstreetmap.org/way/385367054 which someone has tagged as a
> cycleway.  I have biked, walked and ran this trail many different times
> over the years and I have no indication that it was built for a specific
> purpose.  On a typical day I would say that non cyclists outnumber cyclist.
> I also just visited the websites for the various entities that manage the
> trail, and there is no indication I could find that it was built for a
> single purpose.  It is a general recreation trail.  I suspect the
> "cycleway" tag was used so that it would show up in some cycling specific
> renderer... but I can't say that for sure.
>

Possibly old version of the way had lanes and signage, which got deleted in
a more recent rebuild?  Or just bad tagging?  Either way, looking at it in
id's default imagery I'd say that definitely looks like a path to me now,
barring any on the ground knowledge.  Though the width and turn radii on
curves tends to make me think they wanted it to be a cycleway but then
either chickened out or downgraded it at the last minute.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Paul Johnson]

On Mon, Jan 27, 2020 at 10:41 AM Mike Thompson  wrote:

> Also, in the parts of the US where I have lived there have generally only
> been "multipurpose" paths/trails (a few exceptions).
>

 Not exactly helping is that the US tends to also confuse form and access,
calling things "multipurpose paths" even when they are *clearly* purpose
built for a specific mode and possibly even do have specific mode
restrictions.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Paul Johnson]

On Mon, Jan 27, 2020 at 9:37 AM Jmapb  wrote:

> Hi all, just noticed this passage on the cycleway=* wiki page (
> https://wiki.openstreetmap.org/wiki/Key:cycleway ):
>
> > For mapping a separate path (on a separate way) dedicated to cycling
> > traffic use highway=cycleway. Foot traffic is restricted on these paths.
> >
> >   *  Do not use highway=cycleway on paths for both cyclist and foot
> > traffic (such as shared paths). Instead use highway=path with
> > bicycle=designated and foot=designated. Add also segregated=yes or
> > segregated=no) as applicable.
> >* For paths where cycling is not permissible use highway=footway.
> > If cycling is permissible even if it is not signed but legally
> > permissible on a path, use highway=path (and a combination of the
> > segregated key and designated tag as applicable) and not highway=footway.
>
> (This was added by wiki user Aaronsta last May, with no change
> description.)
>
> Does anyone know if there was a discussion, here or elsewhere, that led
> to this change?
>
> My own impression over the years has been that mappers use
> highway=cycleway on anything that primarily for bicycle traffic, and add
> access keys for any other permitted traffic. Similarly for
> highway=footway. So "highway=cycleway + foot=yes" and "highway=footway +
> bicycle=designated" are quite common. Is there a general consensus that
> these are better mapped as highway=path?
>

No, this is also my take.  In North America, I'm generally inclined to go
with highway=cycleway if it has formally marked lanes and highway=path if
it doesn't, and explicitly tag access on both.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC free_water

[Paul Johnson]

I'm not sure what European Water Project is doing to break threading, but
could you kindly not do that?  Most likely this is caused by replying to an
undigested digest, in which you really should be going with individual
delivery or using procmail to split the digest into individual messages
before replying.

On Fri, Jan 17, 2020 at 2:48 PM European Water Project <
europeanwaterproj...@gmail.com> wrote:

> 3. Re: RFC free_water (Alessandro Sarretta)
>
>  Francois, Florimond, Alessandro,
>
> First, thanks to all of you for taking so much time to reflect on this
> subject which is core to our project.
>
> I see three concepts that need to be described.
>
> 1. Is there free water available ?
> 2. For whom is it free ? if it is the case that there is free water
> available
> 3. If it is free for everyone, can you bring your own container ?.
>
> Here are some alternatives which seem to be getting traction for each of
> the three concepts. I have removed free_water as it doesn't seem to be
> getting consensus.
>
> After feedback, I will update the draft proposal.
>
> For 1.
> charge:water=
> drinking_water:fee=yes/no
> tap_water:free=yes/no/customers
>
>
> For 2.
> access:water = 
> tap_water=yes/no/customers
> drinking_water:access=yes/no/customers
>
> For 3.
> container:water = 
> tap_water:container=*
>
> Best regards,
>
> Stuart
>
>
>>
>>
>> Message: 3
>> Date: Fri, 17 Jan 2020 20:25:28 +0100
>> From: Alessandro Sarretta 
>> To: tagging@openstreetmap.org
>> Subject: Re: [Tagging] RFC free_water
>> Message-ID: <9665c5e1-9a9b-e388-bff6-56366974b...@gmail.com>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> Hi,
>>
>> On 17/01/20 12:08, European Water Project wrote:
>> >
>> >  2. Re: RFC free_water (François Lacombe)
>> >
>> >
>> > I see your point and agree it would be preferable to develop a more
>> > generalize nomenclature, but also think it is important to choose
>> > something that is understandable to a newbie.
>> >
>> > If we chose charge:water
>> > <
>> https://wiki.openstreetmap.org/w/index.php?title=Key:charge:water&action=edit&redlink=1>=free
>>
>> > <
>> https://wiki.openstreetmap.org/w/index.php?title=Tag:charge:water%3Dfree&action=edit&redlink=1>we
>>
>> > would need to differentiate when the water is free to anyone (yes in
>> > OSM speak) or just paying customers (customers in OSM speak).
>> >
>> > We could use :
>> > charge:water
>> > <
>> https://wiki.openstreetmap.org/w/index.php?title=Key:charge:water&action=edit&redlink=1>=>
>> > <
>> https://wiki.openstreetmap.org/w/index.php?title=Tag:charge:water%3Dfree&action=edit&redlink=1
>> >/fee>
>> > access = 
>> > container = 
>> >
>> > In the above, European Water Project would only include cafés, bars,
>> > etc. with
>> > charge:water
>> > <
>> https://wiki.openstreetmap.org/w/index.php?title=Key:charge:water&action=edit&redlink=1>=free
>>
>> > <
>> https://wiki.openstreetmap.org/w/index.php?title=Tag:charge:water%3Dfree&action=edit&redlink=1
>> >
>> > access = yes
>> > container = bring_own
>>
>> If you use the tag /access/ alone, it could refer to the "main" feature
>> (the bar or restaurant...).
>>
>> And water is probably too general... I try suggesting to use
>> /tap_water/, that should clearly state that is not bottle water :-)
>>
>> So it could be:
>>
>>   * tap_water=yes/no/customers
>>   * tap_water:free=yes/no/customers
>>   * tap_water:container=*
>>
>> This way it seems to me you should be able to cover all the
>> possibilities clearly.
>>
>> m2c
>>
>> Ale
>>
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstreetmap.org/pipermail/tagging/attachments/20200117/b7f56b29/attachment.htm
>> >
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> --
>>
>> End of Tagging Digest, Vol 124, Issue 120
>> *
>>
> ___
> 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] recreational vs functional routes

[Paul Johnson]

On Tue, Jan 7, 2020 at 1:23 PM joost schouppe 
wrote:

> Especially for car routes, I haven't seen any way to tag touristic routes
> for driving cars, like the Turist Veger in Norway or the Route des Cols in
> France. It is also of specific interest for cycling. For example, in
> Belgium we have a very dense "node network" for cycling for fun, but those
> routes aren't exactly interesting for commuting. On the other hand, we have
> "cycle highways" which can be boring and focus on actually getting
> somewhere.
>

Sounds like a job for route relations.  Also a good reason why moving route
refs off ways and make them exclusively relation-based is a good idea we
really need to strongly consider.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Cycle boxes for two-stage left turns

[Paul Johnson]

On Mon, Dec 16, 2019 at 7:06 PM Jarek Piórkowski 
wrote:

> Hello,
>
> I'm looking for a way to tag designated areas where cyclists wait to
> safely make a far turn (in right-hand-drive regions, a left turn).
> I'll call them "left turn boxes" for short though pointers to a better
> name would be welcome!
>

Since it's basically a short, mode-restricted turn lane, why not tag it as
such?  turn:lanes=whatever|left, access:lanes=whatever|no,
bicycle:lanes=whatever|designated?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] depreciate recycling:metal in favor of recycling:scrap_metal

[Paul Johnson]

On Tue, Dec 31, 2019 at 10:50 AM Mateusz Konieczny 
wrote:

> There is no useful difference
> therefore it is pointless to have two
> separate tags for that.
>

Domestic refuse metals like metal packaging from consumer products (think
like, food and beverage cans), something that you can typically drop off at
your average grocery store parking lot recycling center.  As opposed to
scrap metal, which is pretty much everything from car hulks to household
appliances to copper wiring and plumbing, etc...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Paul Johnson]

On Thu, Dec 26, 2019 at 12:50 PM Erkin Alp Güney 
wrote:

> No, that is highway=road. highway=unclassified is one grade above that.
>

highway=road tends to be most typically used to indicate that there is a
traversable path of unknown quality, or a temporary road in a construction
zone.   These tend to be aggressively reclassified or removed as surveys
happen or temporary roads get removed after they're no longer needed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging