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

2020-10-09 Thread 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?

2020-10-09 Thread 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

2020-09-20 Thread 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

2020-09-16 Thread 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

2020-08-24 Thread 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 !

2020-08-21 Thread 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

2020-08-08 Thread 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

2020-08-07 Thread 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

2020-08-07 Thread 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

2020-08-07 Thread 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

2020-08-05 Thread 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

2020-08-03 Thread 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?

2020-08-02 Thread 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?

2020-08-02 Thread 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?

2020-08-02 Thread 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?

2020-08-02 Thread 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?

2020-08-01 Thread 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

2020-08-01 Thread 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?

2020-07-31 Thread 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?

2020-07-31 Thread 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

2020-07-31 Thread 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

2020-07-31 Thread 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

2020-07-31 Thread 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

2020-07-31 Thread 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

2020-07-31 Thread 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

2020-07-31 Thread 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…)

2020-07-31 Thread 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

2020-07-28 Thread 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

2020-07-27 Thread 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

2020-07-27 Thread 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

2020-07-27 Thread 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

2020-07-27 Thread 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

2020-07-27 Thread 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?

2020-07-16 Thread 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?

2020-07-14 Thread 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

2020-07-13 Thread 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

2020-07-13 Thread 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

2020-07-13 Thread 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

2020-07-13 Thread 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

2020-07-12 Thread 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

2020-07-12 Thread 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?

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

2020-06-10 Thread 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

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

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

2020-05-25 Thread 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

2020-05-14 Thread 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

2020-05-13 Thread 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

2020-05-13 Thread 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

2020-05-13 Thread 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

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

2020-04-13 Thread 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?

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

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

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

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

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

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

2020-02-13 Thread 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?=<88cad950-d9cc-3c2e-9015-a54d7206a...@gmx.com>

2020-02-10 Thread 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?=<88cad950-d9cc-3c2e-9015-a54d7206a...@gmx.com>

2020-02-10 Thread 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

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

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

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

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

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

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

2020-01-29 Thread 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

2020-01-29 Thread 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

2020-01-29 Thread 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?

2020-01-28 Thread 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?

2020-01-28 Thread 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?

2020-01-28 Thread 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

2020-01-27 Thread 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?

2020-01-27 Thread 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?

2020-01-27 Thread 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?

2020-01-27 Thread 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

2020-01-17 Thread 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=edit=1>=free
>>
>> > <
>> https://wiki.openstreetmap.org/w/index.php?title=Tag:charge:water%3Dfree=edit=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=edit=1>=>
>> > <
>> https://wiki.openstreetmap.org/w/index.php?title=Tag:charge:water%3Dfree=edit=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=edit=1>=free
>>
>> > <
>> https://wiki.openstreetmap.org/w/index.php?title=Tag:charge:water%3Dfree=edit=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

2020-01-08 Thread 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

2020-01-08 Thread 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

2020-01-05 Thread 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,

2019-12-26 Thread 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


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

2019-12-21 Thread Paul Johnson
On Sat, Dec 21, 2019 at 3:48 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 21. Dec 2019, at 01:10, Joseph Eisenberg 
> wrote:
> >
> > Unfortunately, the road classification system in parts of Continental
> > Europe was different, so mappers in some major countries, including
> > Germany and France, chose to use highway=trunk as synonym for
> > "motorroad" (somewhat similar to a U.S.A. "expressway"), with other
> > major roads tagged as highway=primary.
>
>
> actually not, the motorroad tag was introduced by the Germans (AFAIK) to
> express a typical access situation on many trunks but also some primaries
> (motorway like access), so that trunk (motorway like physical construction)
> and access could be tagged orthogonally. There are also some trunks that
> permit slower traffic in Germany.
>

I would also consider a "super two" or similar undivided design to be a
trunk.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2019-12-21 Thread Paul Johnson
On Sat, Dec 21, 2019 at 6:37 AM Jarek Piórkowski 
wrote:

> On Fri, 20 Dec 2019 at 22:30, Paul Johnson  wrote:
> >> > What I'm saying is highway=bundesstraße could be acceptable, but
> straße=bundestraße wouldn't be.  Mostly so way type objects with highway=*
> are still potentially routable.
> >>
> >> How do you propose these "potential routable" fallback routers to
> >> handle highway=Bürgersteig (a sidewalk) vs highway=Fahrradstraße (a
> >> local street where bicycles have priority)?
> >
> > Same way I already consider highway=motorway:  Tag for access.
> Assumptions are OKish, but at least in north america, motorway and trunk
> (aka freeways and expressways) are ambiguous for non-motorized modes.  Most
> states allow nonmotorized modes on motorways, but 15 don't, and about 30
> allow it when not otherwise posted, so foot=no, bicycle=no is *NOT* a safe
> assumption for freeways.  Especailly the farther west you go; for example,
> in British Columbia, Washington and Oregon (where I grew up), a motorway is
> probably safer for cyclists than your average city street with bicycle
> lanes (no oncoming traffic, parking on the pavement is not permitted at
> all, roughly 4.5m wide hard shoulders, 80-110km/h speed limits but that's
> 3m from anybody walking or cycling, versus no sidewalks, 1.5-2m wide
> bicycle lanes and 60-90 km/h surface street speed limits, with both the
> speed limits and bicycle lanes being next to never respected in the
> northwest).
>
> Tagging exceptions is fine, but tagging every highway=footway aka
> highway=chodnik with vehicle=no is going to be a bit silly I would
> think.
>
> You might know, but just to mention: the British Columbia comment is
> not accurate in most of Lower Mainland (that one bit of Upper Levels
> Highway notwithstanding). So if we are adding access tags to
> distinguish urban vs rural realities, what's wrong with
> highway=motorway as the base tag?
>
> >> How will a router know
> >> which highways can be used by trucks, buses, pedestrians, other than
> >> with a giant lookup table?
> >
> > highway=* is a good start, which is why I'm in favor of "lower is
> better" with the exiting system.
>
> I'm sorry, I'm missing some context to understand this (or was this
> meant to be "existing"?). To be more explicit, how would a router know
> not to send trucks on highway=Fahrradstraße?
>
> >> And if you do have a giant lookup table,
> >> wouldn't be easier to have it in editors rather than in every single
> >> data consumer?
> >
> > Not really.  UK concepts are entirely foreign to all but roadgeeks in
> North America, and, judging by AARoads and NE2's history, not even then.
>
> Sorry, I meant "editors" as in software, not as in humans. You specify
> the road as "Oregon freeway", and JOSM/rapiD/whatever editor add tags
> highway=motorway + bicycle=yes.
>

Under state law, except where bicycle=no, it appears Oregon is actually
foot=yes, bicycle=designated on all state-operated highways these days,
with the entire state highway system (or it's bicycle bypasses instead
where present) being part of that state's RCN.  Not that this says anything
about actual ridability in Oregon, since most state highways outside of
urban centers do not have bicycle lanes or hard shoulders except for
freeways.  I'm glad that Osmand has "allow motorways" as an option in
bicycle mode, as, if you have the endurance required inherent (emergency
stopping only, even for cyclists, despite potentially extreme distances
between exits; barring physical barriers or mechanical issues preventing
it, you must keep moving) as, especially in western Oregon and the Portland
area specifically, the freeway is probably your best, if not only, bet.

I'd be down for something similar to that.  I'm really not in favor of
using trunk for anything other than expressways though, mostly because
there's an upward creep problem in US tagging already and expressways are a
special case for driving anyway.

Would also be nice if there was an *actually easy* scheme for handling
presets that deal with complicated rules to explicitly tag regional
situations.  Like, for example, you're editing a highway in Oklahoma that
has minspeed=* set, bicycle=no and foot=no automatically get added.  If
that way is part of a bicycle route relation, then it gets
bicycle=designated added automatically, instead.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2019-12-20 Thread Paul Johnson
On Fri, Dec 20, 2019 at 7:47 PM Jarek Piórkowski 
wrote:

> On Fri, 20 Dec 2019 at 20:26, Paul Johnson  wrote:
> >> > I'm not arguing in favor of a change in language for key name.  But
> the local broadly accepted classification terminology (preferably in
> English for consistency sake) for the value.
> >>
> >> Why in English? Bundesstraße is a broadly accepted classification
> >> terminology, so is autostrada. If you want to do things for
> >> consistency sake, there are the accepted OSM-British-English names.
> >
> >
> > What I'm saying is highway=bundesstraße could be acceptable, but
> straße=bundestraße wouldn't be.  Mostly so way type objects with highway=*
> are still potentially routable.
>
> How do you propose these "potential routable" fallback routers to
> handle highway=Bürgersteig (a sidewalk) vs highway=Fahrradstraße (a
> local street where bicycles have priority)?


Same way I already consider highway=motorway:  Tag for access.  Assumptions
are OKish, but at least in north america, motorway and trunk (aka freeways
and expressways) are ambiguous for non-motorized modes.  Most states allow
nonmotorized modes on motorways, but 15 don't, and about 30 allow it when
not otherwise posted, so foot=no, bicycle=no is *NOT* a safe assumption for
freeways.  Especailly the farther west you go; for example, in British
Columbia, Washington and Oregon (where I grew up), a motorway is probably
safer for cyclists than your average city street with bicycle lanes (no
oncoming traffic, parking on the pavement is not permitted at all, roughly
4.5m wide hard shoulders, 80-110km/h speed limits but that's 3m from
anybody walking or cycling, versus no sidewalks, 1.5-2m wide bicycle lanes
and 60-90 km/h surface street speed limits, with both the speed limits and
bicycle lanes being next to never respected in the northwest).


> How will a router know
> which highways can be used by trucks, buses, pedestrians, other than
> with a giant lookup table?


highway=* is a good start, which is why I'm in favor of "lower is better"
with the exiting system.


> And if you do have a giant lookup table,
> wouldn't be easier to have it in editors rather than in every single
> data consumer?
>

Not really.  UK concepts are entirely foreign to all but roadgeeks in North
America, and, judging by AARoads and NE2's history, not even then.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2019-12-20 Thread Paul Johnson
On Fri, Dec 20, 2019 at 7:22 PM Jarek Piórkowski 
wrote:

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

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


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

2019-12-20 Thread Paul Johnson
On Fri, Dec 20, 2019 at 6:57 PM Joseph Eisenberg 
wrote:

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

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


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

2019-12-20 Thread Paul Johnson
On Fri, Dec 20, 2019 at 5:22 PM Graeme Fitzpatrick 
wrote:

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

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


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

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


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

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


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

2019-12-20 Thread Paul Johnson
On Fri, Dec 20, 2019 at 4:41 PM Mateusz Konieczny 
wrote:

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

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


> Maybe this fits here?
>

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


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

2019-12-20 Thread Paul Johnson
On Fri, Dec 20, 2019 at 1:07 AM Mateusz Konieczny 
wrote:

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

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


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

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

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

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

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


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

2019-12-19 Thread Paul Johnson
On Thu, Dec 19, 2019 at 1:19 PM Martijn van Exel  wrote:

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

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

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

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


Re: [Tagging] Feature Proposal - RFC - park_drive

2019-12-06 Thread Paul Johnson
On Thu, Dec 5, 2019, 04:09 Martin Scholtes  wrote:

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

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

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


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

2019-11-11 Thread Paul Johnson
On Mon, Nov 11, 2019 at 2:41 AM Martin Koppenhoefer 
wrote:

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

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


Re: [Tagging] Changeset 62867521

2019-11-08 Thread Paul Johnson
On Thu, Nov 7, 2019 at 7:30 PM Mike Thompson  wrote:

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

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

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


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

2019-11-08 Thread Paul Johnson
On Tue, Nov 5, 2019 at 7:50 AM Dave F via Tagging 
wrote:

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

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


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

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


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

2019-11-08 Thread Paul Johnson
On Thu, Nov 7, 2019 at 7:02 AM Andy Townsend  wrote:

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

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

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


Re: [Tagging] Billboard or something else

2019-10-30 Thread Paul Johnson
On Wed, Oct 30, 2019, 11:06 Jonathon Rossi  wrote:

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

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


Re: [Tagging] Billboard or something else

2019-10-30 Thread Paul Johnson
On Wed, Oct 30, 2019, 05:55 Martin Koppenhoefer 
wrote:

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

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

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


Re: [Tagging] Deprecating mini_roundabout

2019-10-24 Thread Paul Johnson
On Thu, Oct 24, 2019 at 7:55 AM Paul Allen  wrote:

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

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


Re: [Tagging] Deprecating mini_roundabout

2019-10-24 Thread Paul Johnson
On Thu, Oct 24, 2019 at 7:20 AM Paul Allen  wrote:

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

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


  1   2   3   4   5   6   7   8   9   10   >