Re: [Talk-us] Recent Trunk road edits

[Paul Johnson]

On Mon, Sep 28, 2020 at 11:07 AM Matthew Woehlke 
wrote:

> On 28/09/2020 11.42, Jack Burke wrote:
> > I'm willing to bet that most OSM editors who drive on either of those two
> > will think "this is a great freeway, just with occasional traffic
> signals."
>
> That's an oxymoron. Freeways are, by definition, limited access (no
> crossing intersections, period) and do not have (permanent¹) signs or
> signals to halt traffic. IMNSHO, if it has traffic lights, stop signs,
> or the possibility of vehicles suddenly driving *across* the way, it
> isn't a freeway.


True, but highway=trunk can mean either expressways (think like freeways
that have some or all at-grade intersections; note that having
freeway-style ramps in between junctions doesn't make it a
highway=motorway), or single-carriageway freeways.  In both cases, they
tend to get built as an incremental case to building a full motorway, but
are not yet motorways.

That's not to say there aren't non-interstate highways that meet these
> definitions.
>
> But... is it a highway=trunk? *I* don't see where the wiki excludes the
> possibility. (It does, however, seem to me that only *actual* interstate
> freeways should be highway=motorway in the US.)
>

That's not true at all...heck, not all sections of Interstates qualify for
highway=motorway, there's at least a couple dozen spots where this is true,
like pretty much any customs checkpoint, the transitions to where an
interstate ends and it continues as another kind of highway past the last
exit before a junction,


> Related: if it's I-## or I-###, shouldn't it be a highway=motorway,
> period? (Unless those, for some reason, are ever *not* freeways?)
>

No.  Very much not, in fact.  Network and classification are, relative to
the UK, quite disconnected.  Most of the Interstate network that is
bannered as Detour (more common in disaster prone areas where getting
around a freeway closure isn't obvious and yet happens frequently enough to
have permanently signposted detour routes for such occasions) or Business
tends to be trunk at most (I can think of a couple places where a Business
Interstate runs down expressway sections that used to be US 66) but usually
is *extremely* not a freeway (usually boulevards and two lane roads).  Get
up to Alaska and mainline interstates aren't freeways and usually aren't
even signposted (I'd be surprised if anything outside Fairbanks and
Anchorage warrants higher than a secondary tag realistically, but the US
loves to creep everything upwards, overstating connectivity).  Some cities
operate full blown freeways, some interstates are gravel barely-a-road.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

[Paul Johnson]

On Mon, Sep 28, 2020 at 10:42 AM Jack Burke  wrote:

>
>
> On Monday, September 28, 2020, Paul Johnson  wrote:
>
>> On Sun, Sep 27, 2020 at 8:35 PM Jack Burke  wrote:
>>
>>> Recently, someone has taken it on himself to downgrade most (all?)
>>> highway=trunk roads in the eastern U.S. to just primary.  The odd
>>> thing is that the very wiki page he cites as his reason fully supports
>>> keeping them as trunk.  Many of them I'm personally familiar with, and
>>> even absent the wiki's definition, they actually make more sense as
>>> trunk from a driving perspective.
>>
>>
>> The wiki's pretty inconsistent but the generally accepted standard is
>> "it'd be a motorway if it didn't have intersections" or "it'd be a motorway
>> if it was dual carriageway".  I think some context would help.
>>
>
> How about a pair of highways that "would be motorways if they didn't have
> intersections" for context?
>
> Georgia 400 is a grade-separated, divided, high-speed freeway from its
> southern endpoint at I 85, all the way to where it meets GA 369 near Coal
> Mountain, 37 miles later. From there, it's an at-grade, divided, high-speed
> (mostly 65mph, with short sections of 55mph in denser areas) highway with
> extremely long straight sections and other sections with high-speed curves,
> until it ends at GA 60 just outside Dahlonega, 16 miles past Coal Mountain.
>

Yeah, not looking very hard at this so don't know if I missed any at-grade
intersections looking at Maxar/Mapbox. I'd call that a motorway pretty
solidly from I 85 to GA 306 and a trunk north of that to GA 60.  Looks like
it turns into GA 115 at GA 60, didn't trace that further but I'd call GA 60
a secondary.


> GA 515 begins life where I 575 ends, at Ball Ground. From there, it is a
> grade-separated, divided, high-speed (mostly 65mph, with a few sections of
> 55mph, and a couple of 45mph when it passes through Ellijay and Blue Ridge)
> freeway that travels north to Blue Ridge, almost at the Tennessee border,
> where it arcs eastward and continues to Blairsville.  That's 63 miles of
> divided high-speed goodness. There it finally becomes an undivided highway
> that continues on to Young Harris, "ending" a few miles past there. GA 515
> was upgraded to its dual-carriageway status about 30 years ago as part of
> the Appalachian development highway program.
>

Looking at the same imagery as above, yeah, I'd call I 575 a trunk north of
Howell Bridge Road and GA 515 a trunk from I 575 until the south end of
Blue Ridge, where the single carriageway through town is primary (it stops
being an expressway and becomes a boulevard for a bit), and then picks back
up as trunk on the north end of town before going primary again at
Blairsville.


> All of these, and others, were highway=trunk until floridaeditor decided
> to downgrade them (and challenge anyone to change them back)
>

So far it seems like floridaeditor is the exact opposite of NE2 (who
smashed everything in network=US:US to highway=trunk even if it's not an
expressway or super-two freeway, something we're *still* cleaning up
particularly in the midwest and Texas).  Given NE2 was also in Flordia, I
wouldn't rule out it's the same person.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

[Paul Johnson]

On Sun, Sep 27, 2020 at 8:35 PM Jack Burke  wrote:

> Recently, someone has taken it on himself to downgrade most (all?)
> highway=trunk roads in the eastern U.S. to just primary.  The odd
> thing is that the very wiki page he cites as his reason fully supports
> keeping them as trunk.  Many of them I'm personally familiar with, and
> even absent the wiki's definition, they actually make more sense as
> trunk from a driving perspective.


The wiki's pretty inconsistent but the generally accepted standard is "it'd
be a motorway if it didn't have intersections" or "it'd be a motorway if it
was dual carriageway".  I think some context would help.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] While we're fixing things in iterations

[Paul Johnson]

On Fri, Sep 25, 2020 at 11:49 AM Volker Schmidt  wrote:

> (this comment is only regardinbg the "lanes" part of the thread)
>
> Date: Thu, 24 Sep 2020 09:30:15 -0500
>> From: Paul Johnson 
>> To: OpenStreetMap talk-us list 
>> Subject: Re: [Talk-us] While we're fixing things in iterations
>>
>
>
>> > > Can we finally fix two other longstanding problems, then?
>> > >
>> > > 1. The wiki being incorrect about not counting bicycle lanes.
>
> The wiki is correctly reflecting the practice in many places, for example
> in Italy. Almost all users here count the car lanes and not bicycle, foot,
> combined foot-cycle lanes.
> If there are different  approaches prevalent in other places, then at
> worst the wiki is incomplete by not listing diverging approaches.
>
>> > >That's
>> > > not reflective of how validators deal with lanes, how data consumers
>> > > like Osmand or Magic Earth deal with lanes,
>
> Can you point more precisely where Osmand and Magic Earth differ from the
> wiki.
>

They actually treat all lanes as lanes when all lanes are mapped.  They're
automatically providing incorrect lane guidance when tagged to the wiki, as
the wiki specifically asks people to omit lanes.


> or how ground truth works.
>>
> Ground truth depends on how you define lanes.
> If you count bike lanes this
> <https://www.mapillary.com/map/im/5ZIOO4PlfSIhbmfveSXnnw> is a 4-lane
> road, if not it's a two-lane road.
>

It's a 4 lane road.  That's how lanes works in the real world.


> > > The whole "but you can't fit a motor vehicle down it" argument is
>> > > facile, that's what access:lanes=* and width:lanes=* is for.
>>
> In this argument you forget that hundreds of thousends of roads have been
> inserted in the OSM database using the wiki definition.
>

Just because it's time consuming to fix doesn't mean we shouldn't bother
fixing it.  Or we'd have just thrown in the towel after the OBDL
relicensing.


> > I agree that width is a poor argument for the status quo, especially
>> > given the common practice (in California, anyways) of bike lanes that
>> > double as right turn lanes for cars.
>>
> As far as I know (rom riding a lot ib California, we are not talking about
> bike lanes, but, at best, about shared lanes.
> Example: bike lane
> <https://www.mapillary.com/map/im/5ZIOO4PlfSIhbmfveSXnnw> disappers, and 
> becomes
> (unsigned) shared lane
> <https://www.mapillary.com/map/im/fXPRLaU0nxEtRp_93TYhgw>.
>

It didn't disappear so much as it became motor_vehicle=yes.  Probably a
good situation where mode:turn:lanes (ie, bicycle:turn:lanes,
motor_vehicle:turn:lanes) may need to come into existence.

> Apparently some mappers
>> > only count through lanes but exclude turn lanes.
>>
> That seems fine to me especially if the turn lanes are short (ike  in the
> above example in LA.
>

Except this breaks data consumers from being able to provide accurate lane
guidance.


> The editor won't solve the problem of existing mapping.
>

Maproulette can help organize fixing this.


> Hopefully when id gets
>> lane tools, it does the same thing JOSM does in this regard.
>>
>
>
>> > I'm pretty sure existing routers would have no problem with including
>> > bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=*
>> > are both present. So I think a reasonable migration path would be to use
>> > the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the
>> > non-auto-centric approach you're advocating.
>>
>
> There is no migration path. I would, from my European perspective at
> least, stick with the present usage and not count any bike/pedestrian
> lane/horse lanes.
>
> The number of lanes is a rough indication for the capacity for motor
> vehicles of a road.
>

"Fuck accuracy, fuck ground truth" --you.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Thu, Sep 24, 2020 at 8:32 AM Brian Stromberg 
wrote:

> This contradicts the OSM wiki but seems like the only way to avoid
> confusion.
>

Much like sport=american_football vs sport=soccer, this makes sense.  Maybe
it's time to retire place=suburb as a tag due to its ambiguity?


> The only reason I can think of to use 'suburb' as a tag in the context of
> the United States would be if a tag indicating 'central city' or something
> similar was introduced.
>

Ostensibly, that's what place=city was supposed to be, but not helping OSM
would be that some places have cities and towns of different legal
importance (Oklahoma), or "it's a city or it's not a city" with no room for
nuance (Oregon).  Not making things any easier is how lopsided populations
are in the US, a midsize municipality is about 5500 people.  Once you get
to about 90,000, you're in the top 2% largest anything in the US.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] While we're fixing things in iterations

[Paul Johnson]

On Thu, Sep 24, 2020 at 3:55 AM Minh Nguyen 
wrote:

> Vào lúc 10:45 2020-09-23, Paul Johnson đã viết:
> > Can we finally fix two other longstanding problems, then?
> >
> > 1. The wiki being incorrect about not counting bicycle lanes.  That's
> > not reflective of how validators deal with lanes, how data consumers
> > like Osmand or Magic Earth deal with lanes, or how ground truth works.
> > The whole "but you can't fit a motor vehicle down it" argument is
> > facile, that's what access:lanes=* and width:lanes=* is for.
>
> I agree that width is a poor argument for the status quo, especially
> given the common practice (in California, anyways) of bike lanes that
> double as right turn lanes for cars.
>
> For what it's worth, the lanes=* documentation has long included a
> passage recommending that data consumers treat lanes=* as a minimum
> value rather than a reliable exact lane count. Apparently some mappers
> only count through lanes but exclude turn lanes.
>

Fortunately, editors will automatically fix this and make lanes=* be the
total of lanes:forward=*, lanes:backward=* and lanes:both_ways=*, so this
is something that isn't hard to solve long term.  Hopefully when id gets
lane tools, it does the same thing JOSM does in this regard.


> I'm pretty sure existing routers would have no problem with including
> bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=*
> are both present. So I think a reasonable migration path would be to use
> the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the
> non-auto-centric approach you're advocating.
>

There's no need.  We already have access:lanes=* for this.  Lanes are
lanes, regardless of access, and it takes a very narrowly motorist-centric
view in order to break this already fairly universally implemented
assumption.


> > 2. Tagging route information on ways.  It's about a decade too long at
> > this point for ref=* on a way to be completely disconnected from the
> > entity the tag applies to:  That's why route relations exist.  Biggest
> > problem child on this at the moment:  OSM's own tilesets.  Let's drop
> > rendering for ref=* on ways and just render the route relations already,
> > this and multipolygons are why relations came to exist in the first
> place.
>
> I'm as excited about route relations as anyone, especially because route
> relations are required for more nuanced route shield selection in
> renderers and routers. But for all the problems route relations solve,
> there are still some unresolved issues:
>
> * Even once rendered maps display pictioral route shields [2], there
> will still be situations where plain text is more appropriate, just as
> on the ground. It isn't always obvious how to transform a particular
> network=* value into a human-readable ref prefix to display in prose or
> read aloud during turn-by-turn navigation. Signposted ref prefixes can
> be pretty idiosyncratic, like "CC" for network=US:NV:Clark. I'm slowly
> building up Wikidata's coverage of signposted road networks and linking
> it to OSM Wiki data items, to make it easier for data consumers to look
> up the human-readable ref prefix on demand [3] or export a lookup table
> like [4] to hard-code. Incidentally, I've also proposed a road name
> formatter property at Wikidata [5], so that data consumers can expand
> network=US:NV:Clark to "Clark County Route", but it hasn't gotten much
> traction yet.
>

Honestly it isn't that hard to include modifier=* for bannered routes (ie,
Business, Bypass, Truck, Express, etc) and match against network on that to
get a good starting place without having to look up the whole thing.  So,
for example, (using NA as an abbreviation for the fictional state of
Nebrahoma), US:NA:Nebrahoma with no modifier would be easy to assume
"County Route".  US:NA:Nebrahoma:Nebrahoma City would be "City Route",
US:NA:Business with modifier=Business would be "State Business Route"...


> * A way's ref=* key is an ordered list, whereas there's no explicit
> ordering of a way's membership in multiple route relations. (A relation
> explicitly contains its members but not the other way around.) A data
> consumer either has to hard-code some heuristics that may not always be
> accurate [3] or infer the order from the way refs, as OSRM does. [6]
> There's a parallel situation with route numbers associated with a bus
> stop. The route_ref=* key on the stop node makes the order explicit,
> since some agencies don't sort the routes numerically on signage.
>

Perhaps we can get some insight from Osmand.


> * The destination:ref=* key uses the same prefixed syntax as way refs.
> No structured alternative has been formally proposed, but
> des

Re: [Talk-us] While we're fixing things in iterations

[Paul Johnson]

On Wed, Sep 23, 2020 at 6:22 PM Andy Townsend  wrote:

> On 24/09/2020 00:00, Paul Johnson wrote:
>
>
>
> On Wed, Sep 23, 2020 at 5:56 PM Andy Townsend  wrote:
>
>>
>> On 23/09/2020 23:01, Paul Johnson wrote:
>>
>>
>>
>> On Wed, Sep 23, 2020 at 4:37 PM stevea  wrote:
>>
>>> Paul Johnson  wrote:
>>>
>> > 2. Tagging route information on ways.  It's about a decade too long at
>>> this point for ref=* on a way to be completely disconnected from the entity
>>> the tag applies to:  That's why route relations exist.  Biggest problem
>>> child on this at the moment:  OSM's own tilesets.  Let's drop rendering for
>>> ref=* on ways and just render the route relations already, this and
>>> multipolygons are why relations came to exist in the first place.
>>>
>>> Yes, 100% agreement.  I think this is simply pure inertia (the kind that
>>> says "broken process") on the part of renderers.
>>>
>>> Can anybody (renderer authors included, maybe even especially) are
>>> welcome to offer reasons why "the old machinery" remains in place?  Are
>>> there legacy use cases that remain unclear to the wider community?  Please
>>> tell us here, if so.
>>>
>> The US is unusual in that it doesn't have a single ref per section of
>> road.  Most places in OSM map what they see on the ground, and the current
>> OSM Carto rendering works just fine for them
>>
> Right up until there's more than one kind of route on the way.
>
> No-one's disputing that this is a major problem for mappers in the US -
> I'm just saying that it's really not a major problem in most other places.
> That doesn't make it any less of a problem in the US but does help to
> explain why people elsewhere seem not to see it as a problem.
>
I don't mean just route=road, literally any other route.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] While we're fixing things in iterations

[Paul Johnson]

On Wed, Sep 23, 2020 at 5:56 PM Andy Townsend  wrote:

>
> On 23/09/2020 23:01, Paul Johnson wrote:
>
>
>
> On Wed, Sep 23, 2020 at 4:37 PM stevea  wrote:
>
>> Paul Johnson  wrote:
>>
> > 2. Tagging route information on ways.  It's about a decade too long at
>> this point for ref=* on a way to be completely disconnected from the entity
>> the tag applies to:  That's why route relations exist.  Biggest problem
>> child on this at the moment:  OSM's own tilesets.  Let's drop rendering for
>> ref=* on ways and just render the route relations already, this and
>> multipolygons are why relations came to exist in the first place.
>>
>> Yes, 100% agreement.  I think this is simply pure inertia (the kind that
>> says "broken process") on the part of renderers.
>>
>> Can anybody (renderer authors included, maybe even especially) are
>> welcome to offer reasons why "the old machinery" remains in place?  Are
>> there legacy use cases that remain unclear to the wider community?  Please
>> tell us here, if so.
>>
> The US is unusual in that it doesn't have a single ref per section of
> road.  Most places in OSM map what they see on the ground, and the current
> OSM Carto rendering works just fine for them
>
Right up until there's more than one kind of route on the way.

> It's not strictly a Mapnik problem.  It's certainly possible to render
> information from relations in Mapnik (I've done it, for different sorts of
> relations, and written diary entries about it).  There are a couple of
> tricky bits* though:
>
>1. You'd need to derive the shields from the ref and the road itself
>from the way, and you're going to get some edge cases where they "don't
>seem to match".
>2. I expect that it would be _really_ difficult to render refs from
>relations in the one country where that's needed and refs from ways in the
>other 190-odd.  The OSM style is a global style, and that means that local
>edge cases (which is what the US is here) can't get the "special-case
>handling" that might be nice.
>
> There's no reason the rest of the world shouldn't be mapping routes this
way.  For the reason I gave above.

>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] While we're fixing things in iterations

[Paul Johnson]

On Wed, Sep 23, 2020 at 4:37 PM stevea  wrote:

> Paul Johnson  wrote:
> > Can we finally fix two other longstanding problems, then?
> >
> > 1. The wiki being incorrect about not counting bicycle lanes.  That's
> not reflective of how validators deal with lanes, how data consumers like
> Osmand or Magic Earth deal with lanes, or how ground truth works.  The
> whole "but you can't fit a motor vehicle down it" argument is facile,
> that's what access:lanes=* and width:lanes=* is for.
>
> If it truly is the wiki that needs fixing, I'm all for fixing the wiki
> here.  Is there some reason the relatively low bar of making a change to
> the wiki hasn't been done yet?
>

Proscriptivists end up changing it back and screaming that their word is
gospel, so everyone's just given up at this point.


> > 2. Tagging route information on ways.  It's about a decade too long at
> this point for ref=* on a way to be completely disconnected from the entity
> the tag applies to:  That's why route relations exist.  Biggest problem
> child on this at the moment:  OSM's own tilesets.  Let's drop rendering for
> ref=* on ways and just render the route relations already, this and
> multipolygons are why relations came to exist in the first place.
>
> Yes, 100% agreement.  I think this is simply pure inertia (the kind that
> says "broken process") on the part of renderers.
>
> Can anybody (renderer authors included, maybe even especially) are welcome
> to offer reasons why "the old machinery" remains in place?  Are there
> legacy use cases that remain unclear to the wider community?  Please tell
> us here, if so.
>
> While I still find murky and mysterious exactly "how" to effect change in
> renderers (who you gonna call?), my two best efforts along these lines are
> to "tag well" and "wiki well."  (And that can include a great deal of
> discussion and consensus building on its own, no doubt).  Eventually, (and
> I've discovered it can take years), renderers do catch up.
>

To be clear, I don't want to throw any humans under the bus on this, since
the Carto folks really do make an elegant style for Mapnik.  Though if this
is a Mapnik issue that's preventing this, maybe it's time to either fix
Mapnik or consider alternatives?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] While we're fixing things in iterations

[Paul Johnson]

On Wed, Sep 23, 2020 at 11:34 AM stevea  wrote:

> > Exactly.  My rule of thumb is if you're thinking about putting a name on
> it, and it's not a shopping center, apartment complex or similar large but
> contiguous landuse, then landuse=* probably isn't what your polygon should
> be.
>
> At least initially, it MIGHT be.  Let's acknowledge that and while we can
> absorb complaints about it, I won't redact such data, it being a first
> draft at completion (similar to TIGER roads and rail).  We'll take decades
> to clean that up, as OSM is a long-term project.  Let's acknowledge that,
> too:  "the map is never 'done.'"
>

Can we finally fix two other longstanding problems, then?

1. The wiki being incorrect about not counting bicycle lanes.  That's not
reflective of how validators deal with lanes, how data consumers like
Osmand or Magic Earth deal with lanes, or how ground truth works.  The
whole "but you can't fit a motor vehicle down it" argument is facile,
that's what access:lanes=* and width:lanes=* is for.

2. Tagging route information on ways.  It's about a decade too long at this
point for ref=* on a way to be completely disconnected from the entity the
tag applies to:  That's why route relations exist.  Biggest problem child
on this at the moment:  OSM's own tilesets.  Let's drop rendering for ref=*
on ways and just render the route relations already, this and multipolygons
are why relations came to exist in the first place.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Tue, Sep 22, 2020 at 9:27 PM stevea  wrote:

> On Sep 22, 2020, at 7:05 PM, Clifford Snow 
> wrote:
> > For example, in Seattle I lived in the Wallingford Neighborhood. Seattle
> has defined boundaries for each of the neighborhoods. In other areas,
> neighborhoods are roughly defined by people living there. In those cases
> using a place= tag makes more sense.
>
> Clifford:  One more thing.  Several summers ago, I lived at / house sat at
> my sister's house in the Magnolia suburb of Seattle.  I believe I mapped
> fairly well the little "village downtown" there (it was walking distance,
> as a nice suburb or neighborhood might be) as a hobby after I fed her cats,
> I'd have to check OSM data history I think summer of 2012.
>
> But you'll notice that suburbs (not Neighborhoods, as you call them) of
> Seattle are tagged in OSM as place=suburb.  (And it wasn't simply me who
> has done that, I think I only did it once or twice for Magnolia and maybe
> Ballard).  In a larger city like Seattle, this seems about right.  I don't
> like disagreeing with a friend like you about where you have lived (and all
> I did was feed my sister's cat for a few weeks, and I do love Seattle) but
> I think the jury is in about Seattle suburbs in OSM, and they are tagged
> suburb.  Does Wallingford or Ballard or Magnolia get called a neighborhood
> in local vernacular?  Sure, I don't doubt it:  you just did so yourself!
> But in OSM tagging, which is I think what we're trying to better agree
> upon, I think the tagging of place=suburb on these is correct.
>

In terms of Seattle, I don't think Ballard or Magnolia are a suburb.
They're more of a neighborhood, both subordinate to Seattle.  Mercer Island
or Bellvue are more suburbs as they're their own cities but really wouldn't
matter or properly stand on their own without Seattle being in the
immediate vicinity.  Note that place=city, place=neighborhood and
place=suburb are all extant tags in common use already.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Tue, Sep 22, 2020 at 8:56 PM stevea  wrote:

> If you MUST tag place=neighbourhood (note the u) see if you agree with me
> that this tag makes most sense in a hierarchy where place=suburb (and
> perhaps quarter, if applicable, is/are above) also exist(s).  I'm not
> strictly saying I believe that place=neighbourhood CANNOT exist without
> place=suburb, but it makes me wrinkle my brow a bit at it not fitting as
> well as a landuse=residential (multi)polygon might rather generically and
> innocently (without any hierarchy required) fit in.
>

Landuse=residential fits better for the lots within a place, not as a
substitute for it.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Tue, Sep 22, 2020 at 8:36 PM Mike N  wrote:

> On 9/22/2020 9:26 PM, Paul Johnson wrote:
> > The extra hamlet nodes are import remainders that haven't yet
> been
> > converted to landuse areas.   The general landuse zones for that area
> > have been identified, but do not exactly correspond to the named
> > subdivisions.   As I get a chance to survey, I divide the landuse
> into
> > subdivisions and convert the node to a named area for the
> subdivision.
> >
> >
> > Please don't expand these as landuse, please expand them as
> > place=neighborhood instead.  Landuse polygons should be congruent to the
> > actual land use.
>
> That's a good point: the subdivisions often contain one or more landuse
> basins, clusters of trees, etc.   I've been thinking of them as one big
> blob, but it seem correct on a more micromap level to mark them as
> place=, and identify the smaller landuse areas (which are sometimes all
> residential).
>

Exactly.  My rule of thumb is if you're thinking about putting a name on
it, and it's not a shopping center, apartment complex or similar large but
contiguous landuse, then landuse=* probably isn't what your polygon should
be.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Tue, Sep 22, 2020 at 8:20 PM Mike N  wrote:

> On 9/22/2020 8:56 PM, Karson Sommer wrote:
> >
> > Looking around the area of the edit, there is a lot of stuff from my
> > perspective that seems fishy. There are a bunch of place=hamlet nodes? I
> > certainly don't see anything that should be tagged as a hamlet, they all
> > look like place=neighborhood to me. Each of these nodes should be mapped
> > onto an explicit residential area.
>
>The extra hamlet nodes are import remainders that haven't yet been
> converted to landuse areas.   The general landuse zones for that area
> have been identified, but do not exactly correspond to the named
> subdivisions.   As I get a chance to survey, I divide the landuse into
> subdivisions and convert the node to a named area for the subdivision.
>

Please don't expand these as landuse, please expand them as
place=neighborhood instead.  Landuse polygons should be congruent to the
actual land use.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Tue, Sep 22, 2020 at 7:14 PM Mike N  wrote:

> Thoughts on use of place=neighborhood for subdivisions?
> https://www.openstreetmap.org/changeset/91255294
>
>Note that there are many thousands already tagged this way (5000 plus
> in a section of the southeast alone).


 I'd consider a subdivision place=neighborhood and give it a boundary.  One
of the few examples where a boundary is cut and clear on the ground even.

landuse=* isn't the right thing for this, it's not interchangeable with
place=* or boundary=*...
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Paul Johnson]

On Mon, Aug 24, 2020 at 9:50 AM 80hnhtv4agou--- via Talk-us <
talk-us@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.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] VANDALISM !

[Paul Johnson]

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

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

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

Re: [Talk-us] changeset: 89516909

[Paul Johnson]

On Mon, Aug 17, 2020 at 4:02 PM 80hnhtv4agou--- via Talk-us <
talk-us@openstreetmap.org> wrote:

> can somebody who knows how to use Tiger data fix this ?
>

Fix what??
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Cycleway Crossings

[Paul Johnson]

On Fri, Aug 7, 2020 at 3:44 PM Volker Schmidt  wrote:

>
> There are many different OSM tagging "dialects" to describe the details of
> a foot-cycle-way crossing a road.
> I looked up the situation of the example on Mapillary. From that it looks
> as if the specific path is a combined foot cycle way  (yellow diamond sign
> with a bicycle and a pedestrian side by side).
>

That sign means both cyclists and pedestrians may be present.  Generally
whether it's a cycleway that lacks sidewalks, or if it's a path, is the
presence of pavement markings.  The latter is foot=yes, highway=cycleway if
it allows pedestrians but doesn't have a specific foot route.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Cycleway Crossings

[Paul Johnson]

On Fri, Aug 7, 2020 at 12:49 PM Natfoot  wrote:

> here is my example and location specific response
> https://www.openstreetmap.org/way/663362208
>

I'd probably call that highway=path, bicycle=designated, foot=yes based off
what I'm seeing in the aerial photography.  I seem to recall it was striped
out as a cycleway at one point and it's possible the lane and edgelines
wore off; if this is the case, then highway=cycleway, foot=yes would be the
correct set of tags for that short collection that got dinged to
highway=footway.  I will say that highway=footway is definitely
inappropriate in this one.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Cycleway Crossings

[Paul Johnson]

On Fri, Aug 7, 2020 at 6:11 AM Doug Peterson <
dougpeter...@dpeters2.dyndns.org> wrote:

> I have noticed in my area where some people have been adding crossings to
> a designated cycleway (named and signed as a bike trail). The crossings are
> fine. It is that the crossing is then been changed to a footway.
>

Can we get an example?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest refs/names

[Paul Johnson]

I'd be inclined to include "Road" on that.

On Thu, Jul 30, 2020 at 5:06 PM  wrote:

>
> County Road 14, Boundary County ID. TIGER name is "Camp Nine Road",
> joins with a forest road labelled in the US Forest Roads Overlay as just
> "Camp Nine".
>
> Around 48.7993305N 116.2837172W
>
> Mark.
>
> On 2020/07/30 8:12, Paul Johnson wrote:
> > Could we get some examples of what you mean?
> >
> > On Wed, Jul 29, 2020 at 5:26 PM  > <mailto:tj-osmw...@lowsnr.net>> wrote:
> >
> > That seems sensible. What about the general case (i.e. no continuity
> > with a county road?) - to add "road" or not?
> >
> > On 2020/07/30 7:09, Paul Johnson wrote:
> > > I'd generally include the whole name including "Road" in that case.
> > >
> > > On Wed, Jul 29, 2020 at 5:03 PM  > <mailto:tj-osmw...@lowsnr.net>
> > > <mailto:tj-osmw...@lowsnr.net <mailto:tj-osmw...@lowsnr.net>>>
> wrote:
> > >
> > > Quick question for clarification.
> > >
> > > The US Forest Roads overlay in JOSM shows the name of forest
> roads
> > > without "Road"; e.g. "Burton Creek B". Should the suffix
> > "road" be added
> > > or is it redundant and a waste of bytes? (Sometimes there may
> be
> > > continuity from, say, a County Road with e.g. "Burton Creek
> Road",
> > > though.)
> > >
> > > Mark.
> > >
> > > On 2020/07/30 2:55, Paul Johnson wrote:
> > > > Alright, I think we have a consensus forming.  Someone want
> > to update
> > > > the wiki?
> > > >
> > > > On Wed, Jul 29, 2020 at 12:30 PM Evin Fairchild
> > > mailto:evindf...@gmail.com>
> > <mailto:evindf...@gmail.com <mailto:evindf...@gmail.com>>
> > > > <mailto:evindf...@gmail.com <mailto:evindf...@gmail.com>
> > <mailto:evindf...@gmail.com <mailto:evindf...@gmail.com>>>> wrote:
> > > >
> > > > I'm also in favor of this change. It's a route number,
> > so it only
> > > > should be in the ref tag. This will make Forest service
> > roads more
> > > > consistent with other numbered routes. Even though most,
> if
> > > not all,
> > > > Forest service roads don't have a name but just a
> number, I
> > > still am
> > > > in favor of this. I was a bit surprised that the wiki was
> > > saying to
> > > > keep the road number in the name.
> > > >
> > > > In fact, the names that most of these forest service
> > roads have
> > > > don't even match common parlance. Most people refer to
> > them as
> > > > "Forest Service Road XX" whereas the TIGER import called
> > them
> > > > "National Forest Development Road XX," which might be
> > the official
> > > > name, but not the most common name.
> > > >
> > > > -Evin
> > > >
> > > >
> > > > On Wed, Jul 29, 2020, 6:47 AM Mike Thompson
> > > mailto:miketh...@gmail.com>
> > <mailto:miketh...@gmail.com <mailto:miketh...@gmail.com>>
> > > > <mailto:miketh...@gmail.com <mailto:miketh...@gmail.com>
> > <mailto:miketh...@gmail.com <mailto:miketh...@gmail.com>>>> wrote:
> > > >
> > > >
> > > >
> > > > On Tue, Jul 28, 2020 at 1:33 PM Paul Johnson
> > > > mailto:ba...@ursamundi.org>
> > <mailto:ba...@ursamundi.org <mailto:ba...@ursamundi.org>>
> > > <mailto:ba...@ursamundi.org <mailto:ba...@ursamundi.org>
> > <mailto:ba...@ursamundi.org <mailto:ba...@ursamundi.org>>>> wrote:
> > > >
> > > >
> > > >
> > > > Could we get the US Road Tagging page updated to
> > reflect
> > > > common name practice instead of encouraging the
> > > duplication
>

Re: [Talk-us] National Forest refs/names

[Paul Johnson]

Could we get some examples of what you mean?

On Wed, Jul 29, 2020 at 5:26 PM  wrote:

> That seems sensible. What about the general case (i.e. no continuity
> with a county road?) - to add "road" or not?
>
> On 2020/07/30 7:09, Paul Johnson wrote:
> > I'd generally include the whole name including "Road" in that case.
> >
> > On Wed, Jul 29, 2020 at 5:03 PM  > <mailto:tj-osmw...@lowsnr.net>> wrote:
> >
> > Quick question for clarification.
> >
> > The US Forest Roads overlay in JOSM shows the name of forest roads
> > without "Road"; e.g. "Burton Creek B". Should the suffix "road" be
> added
> > or is it redundant and a waste of bytes? (Sometimes there may be
> >     continuity from, say, a County Road with e.g. "Burton Creek Road",
> > though.)
> >
> > Mark.
> >
> > On 2020/07/30 2:55, Paul Johnson wrote:
> > > Alright, I think we have a consensus forming.  Someone want to
> update
> > > the wiki?
> > >
> > > On Wed, Jul 29, 2020 at 12:30 PM Evin Fairchild
> > mailto:evindf...@gmail.com>
> > > <mailto:evindf...@gmail.com <mailto:evindf...@gmail.com>>> wrote:
> > >
> > > I'm also in favor of this change. It's a route number, so it
> only
> > > should be in the ref tag. This will make Forest service roads
> more
> > > consistent with other numbered routes. Even though most, if
> > not all,
> > > Forest service roads don't have a name but just a number, I
> > still am
> > > in favor of this. I was a bit surprised that the wiki was
> > saying to
> > > keep the road number in the name.
> > >
> > > In fact, the names that most of these forest service roads have
> > > don't even match common parlance. Most people refer to them as
> > > "Forest Service Road XX" whereas the TIGER import called them
> > > "National Forest Development Road XX," which might be the
> official
> > > name, but not the most common name.
> > >
> > > -Evin
> > >
> > >
> > > On Wed, Jul 29, 2020, 6:47 AM Mike Thompson
> > mailto:miketh...@gmail.com>
> > > <mailto:miketh...@gmail.com <mailto:miketh...@gmail.com>>>
> wrote:
> > >
> > >
> > >
> > > On Tue, Jul 28, 2020 at 1:33 PM Paul Johnson
> > > mailto:ba...@ursamundi.org>
> > <mailto:ba...@ursamundi.org <mailto:ba...@ursamundi.org>>> wrote:
> > >
> > >
> > >
> > > Could we get the US Road Tagging page updated to
> reflect
> > > common name practice instead of encouraging the
> > duplication
> > > of the ref in the name?  Or is that going to spark
> drama?
> > >
> > > I am in favor of the change.  The name tag should be for
> the
> > > name only.
> > >
> > > Mike
> > >
> > > ___
> > > Talk-us mailing list
> > > Talk-us@openstreetmap.org
> > <mailto:Talk-us@openstreetmap.org> <mailto:Talk-us@openstreetmap.org
> > <mailto:Talk-us@openstreetmap.org>>
> > > https://lists.openstreetmap.org/listinfo/talk-us
> > >
> > >
> > > ___
> > > Talk-us mailing list
> > > Talk-us@openstreetmap.org <mailto:Talk-us@openstreetmap.org>
> > > https://lists.openstreetmap.org/listinfo/talk-us
> > >
> >
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org <mailto:Talk-us@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk-us
> >
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
> >
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest refs/names

[Paul Johnson]

I'd generally include the whole name including "Road" in that case.

On Wed, Jul 29, 2020 at 5:03 PM  wrote:

> Quick question for clarification.
>
> The US Forest Roads overlay in JOSM shows the name of forest roads
> without "Road"; e.g. "Burton Creek B". Should the suffix "road" be added
> or is it redundant and a waste of bytes? (Sometimes there may be
> continuity from, say, a County Road with e.g. "Burton Creek Road", though.)
>
> Mark.
>
> On 2020/07/30 2:55, Paul Johnson wrote:
> > Alright, I think we have a consensus forming.  Someone want to update
> > the wiki?
> >
> > On Wed, Jul 29, 2020 at 12:30 PM Evin Fairchild  > <mailto:evindf...@gmail.com>> wrote:
> >
> > I'm also in favor of this change. It's a route number, so it only
> > should be in the ref tag. This will make Forest service roads more
> > consistent with other numbered routes. Even though most, if not all,
> > Forest service roads don't have a name but just a number, I still am
> > in favor of this. I was a bit surprised that the wiki was saying to
> > keep the road number in the name.
> >
> > In fact, the names that most of these forest service roads have
> > don't even match common parlance. Most people refer to them as
> > "Forest Service Road XX" whereas the TIGER import called them
> > "National Forest Development Road XX," which might be the official
> > name, but not the most common name.
> >
> > -Evin
> >
> >
> > On Wed, Jul 29, 2020, 6:47 AM Mike Thompson  > <mailto:miketh...@gmail.com>> wrote:
> >
> >
> >
> > On Tue, Jul 28, 2020 at 1:33 PM Paul Johnson
> > mailto:ba...@ursamundi.org>> wrote:
> >
> >
> >
> > Could we get the US Road Tagging page updated to reflect
> > common name practice instead of encouraging the duplication
> > of the ref in the name?  Or is that going to spark drama?
> >
> > I am in favor of the change.  The name tag should be for the
> > name only.
> >
> > Mike
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org <mailto:Talk-us@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk-us
> >
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
> >
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest refs/names

[Paul Johnson]

Alright, I think we have a consensus forming.  Someone want to update the
wiki?

On Wed, Jul 29, 2020 at 12:30 PM Evin Fairchild  wrote:

> I'm also in favor of this change. It's a route number, so it only should
> be in the ref tag. This will make Forest service roads more consistent with
> other numbered routes. Even though most, if not all, Forest service roads
> don't have a name but just a number, I still am in favor of this. I was a
> bit surprised that the wiki was saying to keep the road number in the name.
>
> In fact, the names that most of these forest service roads have don't even
> match common parlance. Most people refer to them as "Forest Service Road
> XX" whereas the TIGER import called them "National Forest Development Road
> XX," which might be the official name, but not the most common name.
>
> -Evin
>
>
> On Wed, Jul 29, 2020, 6:47 AM Mike Thompson  wrote:
>
>>
>>
>> On Tue, Jul 28, 2020 at 1:33 PM Paul Johnson  wrote:
>>
>>>
>>>
>>> Could we get the US Road Tagging page updated to reflect common name
>>> practice instead of encouraging the duplication of the ref in the name?  Or
>>> is that going to spark drama?
>>>
>> I am in favor of the change.  The name tag should be for the name only.
>>
>> Mike
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] National Forest refs/names

[Paul Johnson]

In  https://www.openstreetmap.org/changeset/59418875, seems we've hit on
some inconsistency in the documentation.
https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Tagging_Forest_Roads
suggests
that the ref should go in the name for national forest roads, when this is
directly contradicted by the common use of name, which is that the name is
only the name, as outlined at
https://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only

Also specifically about that road in that changeset, name=Dufur Valley Road
got moved to alt_name, though I can confirm firsthand that the addresses
along it are Dufur Valley Road and it's signed as such at least at the east
end.

Could we get the US Road Tagging page updated to reflect common name
practice instead of encouraging the duplication of the ref in the name?  Or
is that going to spark drama?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries

[Paul Johnson]

On Fri, Jun 26, 2020 at 9:31 AM Bradley White 
wrote:

> > We were doing great there, then I think my (admonishment?  might be too
> strong) way of expressing "owned and operated by the USFS" is technically,
> accurately stated as "owned by the People, managed / operated specifically
> by the USFS."  If you can agree with me there, I think we can get even
> closer.
>
> In most county assessor records, the name on the "title" of USFS owned
> land is "United States of America", "United States Forest Service", or
> some variant. The federal government owns the land, and manages the
> land resource as well as US citizens' legal right to access the land
> (barring conservation necessities that limit access to certain users
> or any public at all).
>
> > A USFS NF is a "virtual" multipolygon (not one in OSM, we can get to
> that later) of three kinds of things:
> >
> > 1) An "outer" (but not the biggest one) which is "the enclosing land
> which USFS manages, except for inholdings, below,"
> > 2) Zero to many "inner" polygons, representing inholdings (and with the
> usual "hole" semantic of exclusion from 1), above and
> > 3) An even LARGER and ENCLOSING of 1) "outer" which Congress declares is
> the geographic extent to which USFS may or might "have influence to someday
> manage."
>
> Sort of. Administratively, the USFS operates 9 regions containing 154
> "national forests", with each forest being subdivided by a number of
> ranger districts. The federal government also owns large swaths of
> land across the country. These parcels are then managed by whichever
> national forest (and ranger district) they happen to be located in.
> There isn't necessarily an "outer" way enclosing the land that the
> USFS manages, there is just a sum of US-owned parcels that fall within
> a certain NF boundary that represents the actual land managed by the
> USFS. In OSM practice, this is often a very complicated multipolygon
> with multiple 'outer' members, which is usually required in order to
> avoid self-intersecting rings.


If you really want to up the difficulty, the east slope of the Cascades
extending east quite some distance has checkerboards of alternating
sections that are National Forest and BLM range with the occasional private
property thrown in for maximum confusion.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS Roads - name and ref

[Paul Johnson]

On Sat, Jun 6, 2020 at 4:15 PM Bob Gambrel  wrote:

> Paul's in depth answer of my question was very helpful. Luckily I am not
> concentrating on road/highway routes. I like the concept of:
>
> We should be moving forward towards
> all routes being tagged in a route relation so we can phase out route
> attributes on ways, freeing those up for *the way's attributes.*
>
> That intuitively makes sense. It seems to me that most routes these days
> are really a collection of ways (collected by the route relation).
>

This was *literally* a reason relations became a thing in API 0.5.  Though
the design problem being solved was mostly "The UK has Sustrans and MOT
routes and existing ref=* can't deal with both", not that "EU routes also
cross through the UK" and "the US has three national networks, at least 70
state networks, over 200 indian networks, and nearly 4000 county networks
for highways, not counting the potential for nearly the same number of the
same for cyclists".  Not a problem yet but wouldn't surprise me, especially
now that a lot of places are moving bicycle infrastructure from "nice to
have if we have money left over" to "no hurry, 20 years ago is fine" thanks
to COVID19, that we might need to make route=bicycle relations have the
same network=* tags as route=road, down the line.


> I explained this to some city planners, newer to OSM than I was, with
> three examples (an Interstate that actually includes a Ferry, clearly not
> part of a single paved way, a bus route traversing many different streets,
> and the MRT (Miss. River Trail) which consists of streets, highways, bike
> paths, ...)
>

There's an Interstate that traverses a ferry??  I knew of two drawbridges
and six traffic signals but a ferry's a new one on me.  But yeah, routes
are frequently highway=* agnostic within the limits of the type of vehicle
that the route is intended for, for the most part (granted, Historic Route
66 has at least one staircase in it now).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS Roads - name and ref

[Paul Johnson]

On Sat, Jun 6, 2020 at 3:46 PM Bob Gambrel  wrote:

> Paul Johnson says
>
> Ultimately consider adding a route relation with network=US:NSFR:Forest
> Name:FH/FR as well so we can finally kill off route tagging on things that
> are not routes.
>
>
> I am not doing any mapping for forest roads, but the above caught my eye.
> I am doing a lot of bike path/trail mapping as well as mapping cycle
> routes. I understand the idea of adding a route relation. What confuses me
> a little above is:
>
>  so we can finally kill off route tagging on things that
> are not routes.
>
> I think you might be saying that there are ways that seem to have a route
> name in the name field and they shouldn't. Instead they should have the way
> be part of a relation that has the name of the route.
>

Route name and route ref.  Pennsylvania and Oregon (at a minimum) have
state highways and state routes, that are not always (particularly on older
roads) the same.  Oregon, for example, has a lot of state highways, *all of
which are numbered*, that have no state route, and most of the 20 or so
oldest routes now traverse multiple different highways, with only routes
created after about 2000 having the same highway and route number
consistently and no plans to retcon.  Right now, practice is to ignore the
ref (even if no route traverses it) that the state actually uses for the
way, and instead ref=* gets tagged with the route that traverses over it
(or leave it off if there is no route).  This isn't orthogonal, *at all*,
with how anything else is tagged.  The ref=* on the way in this case, is
not an attribute that belongs to the way.  It belongs to the route.  I get
*why* it's that way, but the introduction of relations as a basic primitive
10 years ago obsoleted this practice.  We should be moving forward towards
all routes being tagged in a route relation so we can phase out route
attributes on ways, freeing those up for *the way's attributes.*

Please be patient if I am using some wrong terms above. Still learning
> the OSM lingo. I am really just trying to understand the last part of what
> you said. (Especially if you think it might apply to cycle routes too)
>

No problem.  The takeaway is, yes, go ahead and use the existing ref=*
practice on the way, but please also create the route relation if it
doesn't exist yet.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS Roads - name and ref

[Paul Johnson]

On Sat, Jun 6, 2020 at 3:24 PM brad  wrote:

> On 6/6/20 9:24 AM, Paul Johnson wrote:
>
> On Sat, Jun 6, 2020 at 8:24 AM Mike Thompson  wrote:
>
>> ref:
>> The wiki states that these should be ref=FR + . In
>> practice:
>> * ref:usfs=FS + 
>> * ref=FS + 
>> Most of the changesets that added a "ref:usfs" tag include a very helpful
>> comment that this issue was discussed on the tagging list at sometime in
>> the past and that this was the consensus, e.g. [2].  If this continues to
>> be the consensus, can we change the wiki?
>>
>>
> ref=FS 
>
> Ultimately consider adding a route relation with network=US:NSFR:Forest
> Name:FH/FR as well so we can finally kill off route tagging on things that
> are not routes.  Not sure we really need the FH/FR distinction, however,
> since within the same forest, they're all the same network: The 2 digit
> routes are major, the 3 digits are minor (like parking lots and
> campgrounds) and the 4 digits are usually only usable by log trucks and
> 4x4s.  Trails are another matter.
>
> I prefer ref=FS xxx   too.   I think the tagging discussion that suggested
> ref:usfs was using that for the route relation.
>

 Why would that even be necessary to have a ref:usfs subkey on a route
relation, though?  It's already in the NFSR network.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS Roads - name and ref

[Paul Johnson]

On Sat, Jun 6, 2020 at 8:24 AM Mike Thompson  wrote:

> ref:
> The wiki states that these should be ref=FR + . In
> practice:
> * ref:usfs=FS + 
> * ref=FS + 
> Most of the changesets that added a "ref:usfs" tag include a very helpful
> comment that this issue was discussed on the tagging list at sometime in
> the past and that this was the consensus, e.g. [2].  If this continues to
> be the consensus, can we change the wiki?
>
>
ref=FS 

Ultimately consider adding a route relation with network=US:NSFR:Forest
Name:FH/FR as well so we can finally kill off route tagging on things that
are not routes.  Not sure we really need the FH/FR distinction, however,
since within the same forest, they're all the same network: The 2 digit
routes are major, the 3 digits are minor (like parking lots and
campgrounds) and the 4 digits are usually only usable by log trucks and
4x4s.  Trails are another matter.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USGS Topos, "Draw", "Gulch", etc.

[Paul Johnson]

On Mon, Jun 1, 2020 at 12:57 PM Mike Thompson  wrote:

> Do the names on the USGS Topo Maps that end in "Draw", "Gulch", and
> similar terms refer to a stream, or a valley?  I have always assumed a
> stream, and applied the name to waterway=stream in OSM, but perhaps that is
> not correct.
>

Could be a canyon, or the stream at the bottom of it.  Context is king when
it comes to the names we gave things in the US.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [OSM-talk] Taking a break and a call for help

[Paul Johnson]

On Sat, Mar 21, 2020 at 3:59 PM Greg Troxel  wrote:

> Dave F via talk  writes:
>
> > In my area, AL are adding legitimate data which helps improve the
> > quality of the OSM database. I believe they make the same amount of
> > errors as any other contributors, including experienced ones.
> >
> > Unsure why he thinks OSMF should be keeping an eye on contributors
> > purely because they're paid.
> > I doubt Paul, when he started his first *paid* job was an expert at
> > it, & never made a mistake.
> >
> > It sounds like Paul's got his knickers in a twist over something other
> > than poor quality data.
>
> This really seems unfair.
>
> When someone maps for OSM because they want to, they have goals and a
> typically a good attitude about community norms.
>
> When someone is a a paid mapper, their goals come from the person who is
> paying them, and they don't necessarily care about the overall health of
> OSM.
>

This is accurate.  I don't consider it unreasonable to expect a paid mapper
to have a higher level of professionalism and due care than the
volunteers.  So, I will say, I am *definitely not* holding the Amazon
Logistics mappers to the same standard I hold other volunteers.  I hold
them to *a much higher standard*.


> Really these edits are not so different from mechanical
> edits, and I think the organizers need to own the responsibilility for
> high quality, and the standard should be quite a bit better than normal
> hand mapping norms.
>

 I honestly don't think we could get worse results than Amazon Logistics is
contributing now if we outsourced map editing to Amazon Mechanical Turk for
a penny an edit.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [OSM-talk] Taking a break and a call for help

[Paul Johnson]

On Sat, Mar 21, 2020 at 9:36 AM Dave F  wrote:

> In my area, AL are adding legitimate data which helps improve the quality
> of the OSM database. I believe they make the same amount of errors as any
> other contributors, including experienced ones.
>
> Unsure why he thinks OSMF should be keeping an eye on contributors purely
> because they're paid.
> I doubt Paul, when he started his first *paid* job was an expert at it, &
> never made a mistake.
>

My first job, oddly enough, was with the Boy Scouts of America.  A
situation directly analogous to OSM.  I was a Scout for about a decade
before I found myself on payroll.  Not to say I didn't make mistakes as an
employee (I was 14), but I found myself on payroll because I rose to that
level, not because some third party decided I should start scattergun
efforts.  Anybody paid to contribute to OSM *must* be capable of setting
the example, as far as I'm concerned.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Taking a break and a call for help

[Paul Johnson]

On Fri, Mar 20, 2020 at 6:07 PM Paul Johnson  wrote:

> 3) Amazon Logistics and a revolving door team of one-edit-and-done spam
> accounts keeps throwing paid contributions into Oklahoma that are of poorly
> aligned, largely fictional and low quality.  I'm stuck cleaning up in a
> neglected part of North America some particularly low quality edits with
> limited resources and little ability to find more.  I hope other
> contributors can help keep abreast and I hope OSM Foundation can help keep
> paid contributors to account.  I don't think it's unreasonable to think
> that paid mapper should be contributing *far* higher quality data than
> your average volunteer first time mapper, and I think OSM needs to have a
> serious conversation about minimum qualifications for paid mapping that I
> simply don't have the time or energy for at this point.  Dealing with this
> (and staying abreast extensive OkTrans highway modernization efforts
> lately) have been a major part of my editing (and while OkTrans is
> unavoidable, Amazon is inexcusable).
>

More constructively, let me deconstruct what I think needs to happen with
Amazon Logistics generally (and can be constructively generalized to any
other large fleet entities that might consider contributing to OSM):
Strongly consider contributing GPX traces from their fleet exclusively
first, since covering ground with trucks is what they do best.  Let the
volunteers do the lifting on the cartography if they're not going to hire
people who are already familiar and involved to do the actual mapping.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Taking a break and a call for help

[Paul Johnson]

So, you all know at this point that I've been heavily invested in editing
OSM and contributing to my maximum activity, less as a need to help a
charity and more of an obligation to the public to do the most good with
the short time I have on this planet.  However, I've had a few events come
up that are more or less killing my ability to keep up.

I'm taking a step back from being the primary editor in the Oklahoma region
until this passes.

3) Amazon Logistics and a revolving door team of one-edit-and-done spam
accounts keeps throwing paid contributions into Oklahoma that are of poorly
aligned, largely fictional and low quality.  I'm stuck cleaning up in a
neglected part of North America some particularly low quality edits with
limited resources and little ability to find more.  I hope other
contributors can help keep abreast and I hope OSM Foundation can help keep
paid contributors to account.  I don't think it's unreasonable to think
that paid mapper should be contributing *far* higher quality data than your
average volunteer first time mapper, and I think OSM needs to have a
serious conversation about minimum qualifications for paid mapping that I
simply don't have the time or energy for at this point.  Dealing with this
(and staying abreast extensive OkTrans highway modernization efforts
lately) have been a major part of my editing (and while OkTrans is
unavoidable, Amazon is inexcusable).

2) My truck was stolen last night
, along with the
dashcams I use for Mapillary, essentially making long range surveying
impossible and imperiling my survival since, if for nothing else, I need to
hit Costco for restocking my pantry and storeroom.  As such, I had to call
off work and spent most of the day today dealing with the police today.

1) I work in the IT department of a major regional hospital on the front
lines of the COVID-19 response in the US.  My vacation at the end of next
month, and my weekends for the next two months, have been cancelled, and
I'm expected to work 8+ hours a day, 7 days a week to help keep things up
and running so the medical staff don't have to think about the computers.

I really hope OSMF and the DWG takes a good, hard and critical look at
dealing with the low quality edits from Amazon and spammers while I deal
with acquiring another (or, best case, my stolen) pickup and dealing with
my professional life.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Updating opening_hours for COVID-19.

[Paul Johnson]

On Thu, Mar 19, 2020 at 8:50 AM Shawn K. Quinn  wrote:

> On 3/13/20 15:36, Eric Christensen via Talk-us wrote:
> > I've been updating the opening_hours for businesses and services as I
> > hear about them closing or changing their hours of operation for
> > COVID-19.  I'm also adding a note in the description with any
> > information the source is providing.
> >
> > Seems like a good idea to keep people updated to what's open and what's
> not.
> >
> > I wonder if anyone else is also doing this as well?
>
> Bad idea since these are emergency changes and unlikely to be permanent.
> I am putting in the "normal" hours where they are known, with the
> understanding that people should know locations will be changing their
> hours because of the situation and OSM's data will by necessity be out
> of date for this item.
>

Perhaps have an end date for the temporary hours in case it gets overlooked
when this is all over.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] I 405 in southern California lanecheck complete

[Paul Johnson]

Just completed a roughly two month long process of checking the entire
length of I 405 in both directions in lane-level detail.  This was inspired
from exceptionally bad lane guidance on what is the busiest freeway in
America and competes for busiest in the world on my last trip to Los
Angeles back in December.

This took a lot longer than editing ~73 centerline miles of freeway should
have, even given the complexity, largely because of a couple key factors:

Lane access, placement and turns are not particularly well represented in
key editors.  This leads to a lot of unintentionally introduced noise when
someone else, well intentioned, comes in and tries to edit behind you,
actually reducing detail and introducing inaccuracies that won't be easily
spotted without these important elements being visualized readily in the
editor.

Placement tags get to be even more important where a ramp joins or leaves
its parent, as this lets the navigation system (or, hey, even Teslas now)
where to expect the the painted gore to split a lane from the rest of the
road and where the real ramp starts.

Likewise, change:lanes seems to not appear in many people's editors and is
*extremely* important given miles-long restrictions on changing lanes (into
and out of HOV lanes in particular).

Some of these well intentioned edits were *very* large and were actually
easier and faster to revert and clean up with an explaination than try to
conflate.  This really highlights the importance of smaller changesets on a
cohesive theme in a limited area (something I could probably work on a bit
myself), particularly in extremely complex areas.

Right now, JOSM has a turn lane editor plugin, but no access editor.  A
*lot* of this had to be banged out manually.

Some editors make it really easy to break relations without being noticed
(particularly route and enforcement).

Anyrate, feel free to take a look.  I really hope editor support,
particularly for lanes and lane access, greatly improves because not
highlighting and making it easy to maintain the integrity of these elements
really is important to best give consumers anything resembling consistent
navigation where it's needed the most.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Tagging historic US routes

[Paul Johnson]

Try network=US:US:Historic on your route relation.  Might not render, but
you can at least give renderers *something* for renderers to latch onto if
they want that information. ref=US Historic xx seems to be the way tagging
for that if you want to go that route.  I recommend, until we can finally
kill the route-tagging-on-way "ref=*" legacy method, to implement both,
since it makes it more obvious if the ref=* tagging gets munged later.

On Thu, Mar 5, 2020 at 7:46 PM Tod Fitch  wrote:

> This weekend I drove part of AZ-79 and noticed that Arizona has now put up
> some “Historic US 80” signage. On the sections of highway I drove, every
> occurrence of a AZ-79 route marker now also has a historic US-80 route
> marker. (Back in the day that highway was dual signed as US-80 and US-89
> but I guess nobody cares about having historic US-89 markers at present.)
>
> I was in a rental car and eventually figured out how to get Apple CarPlay
> setup so I could use the OSM based Maps.me app to show the roads I was on.
> In doing so I saw that Maps.me was showing the road with dual highway
> shields: A AZ shield with 79 and a US shield with 80. Since US-80 was
> decommissioned a long time ago (at least in Arizona and California) this
> seems wrong so I thought I’d look at the tagging.
>
> The tagging is on a route relation [1], at least I don’t see tagging on
> the individual way segments that would render as “US 80”.
>
> How should this be tagged?
>
> Casting about for examples of what to do, it seems that the Lincoln
> Highway [2] relation is quite different. And US 66 in California has no
> historic route relation at all, just the current county road route [3].
>
> There is a German page on the wiki about “route=historic” [4]. My reading
> of a machine translation of it implies that instead of “route=road” the
> historic US 80 relation should have “route=historic” and “historic=road”.
>
> Suggestions?
>
>
> [1] https://www.openstreetmap.org/relation/9230611
> [2] https://www.openstreetmap.org/relation/3958115
> [3] https://www.openstreetmap.org/way/205719338
> [4] https://wiki.openstreetmap.org/wiki/Tag:route%3Dhistoric
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Mapping for emergency services

[Paul Johnson]

On Mon, Feb 3, 2020 at 8:58 AM Mike Thompson  wrote:

> Mike,
>
> That is a very compelling story.  Thanks to you and the other OSM folks
> involved for making it happen and to you for writing the diary entry.  I
> have often thought that OSM would be a great resource emergency responders
> because in some areas it contains data that no one else has, but generally
> the reaction that I have gotten when I have suggested this to such
> officials was "we have our own data", "we have already invested in xyz
> system" (sunk cost fallacy), or "how can we trust OSM?".  The exception was
> a search and rescue group that used OSM to help locate missing people in
> the back country because OSM contains trails that no other source has.
>
> Is this being publicised outside of the OSM community?  There are probably
> associations for fire fighters and other emergency response professionals
> and perhaps someone from the FD involved could speak about this project at
> one of their conferences to get agencies in other parts of the country (or
> world) interested.
>

I've been to a few furry conventions in Oklahoma where firefighters have
attended and cartography has come up.  Oddly enough, for the rural
firefighters?  Osmand with Microsoft Earth imagery as the background is
their most popular pick because it works brilliantly offline and we have
better map data than the state itself does.  The E911 system (where
available) spits 'em a set of coordinates, so punch that in and go.  Hit
the destination distance button to cache in the imagery around where
they're going in case the exact driveway or building hasn't been mapped
yet.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] When is your doctor a clinic?

[Paul Johnson]

On Thu, Jan 23, 2020 at 3:30 PM Frederik Ramm  wrote:

> Hi,
>
> hunting down spam in OSM I often stumble over medical establishments in
> the US that have maximum-length description tags exhorting just how
> beatiful your smile will be after your visit to that dentist, etc.; I
> also find many objects that sound like a simple doctor's practice but
> are entered as "amenity=clinic", e.g.
>
> https://www.openstreetmap.org/node/4574659098


This happens a lot, i question the sources especially the georeferencing
(which probably means "looked up address on Google, copied lat and long
into OSM") to the point I delete on sight when I see edits similar to
Revision 1 of that node.  I might clean it up I've independently also
spotted the business and can do it better justice.  Just a quick look over
user 42TEAM's edit history suggests just another database spammer (usually
of the variety that just has a username of the same name as the business
that's being added).


> Especially in the US, when do you use amenity=doctors and when
> amenity=clinic - is this essentially self-determined by the business, or
> are there criteria that you as a mapper apply to select which to use?
>

There may be a disconnect with what the US (or that spammer) means.  Could
I get a clarification on the difference between "doctors" and "clinic" as
you understand it?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS trail/road/route numbers

[Paul Johnson]

On Tue, Jan 7, 2020 at 3:15 PM Tod Fitch  wrote:

> In my area there seems to be a mix of how the US Forest Service route
> numbers are tagged on roads and trails. The main variations seem to be:
>
> name=“Forest Route 9N24”
> name=“FR 9N24”
> alt_name=“Forest Route 9N24”
> alt_name=“FR 9N24”
> ref=“FR 9N24”
> ref=“9N24”
>

Well, name should only be the name.  So the first four are wrong, refs are
not names.


> Things I’ve seen in the wiki that might pertain cover “National Forest
> Trails” [1] which seems to want a tag of “route_no” or “trail_no”. That
> just seems wrong.
>
> And in the United States roads tagging [2] which seems to prefer tagging
> like:
>
> ref=“NFR 9N24”
>
> Which I don’t recall seeing in my area.
>
> What should the preferred tagging be? My inclination would be to migrate
> the tagging in my area toward that listed on the US road tagging page (e.g.
> ref=“NFR 9N24”) even though my preference (for printed map display
> purposes) would be to simply use ref=“9N24”.
>

I'd go with ref=NF 9N24 and strongly consider making a route relation for
it.  Ideally, this would all be moot and it'd just be a refless, nameless
way with the route being on the relation alone (same could be said of
roads) but for some reason people don't want to kill the dinosaur on that
still.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] User in Florida changing several motorways to trunk

[Paul Johnson]

On Wed, Jan 8, 2020 at 8:22 AM James Mast  wrote:

> As for restoring the 'motorway' roads, I've honestly just been manually
> fixing them.  Sure, takes longer, but allows me to catch the 'Emergency
> U-Turn' crossovers that are improperly tagged as a '_link', and fix them at
> the same time.  I've cleared & restored the proper motorway/motorway_link
> tags on FL-414, FL-429, FL-451, & FL-453 manually so far.  Leaves FL-408,
> FL-417, FL-528, and a few non-state roads around Walt Disney World.  But
> those routes are some pretty long ones, and will take some time to fix
> since they have several exits along them.
>

Not a bad time to doublecheck lane tagging and capture that detail, too.
I'm working through that on I 405 in LA right now, which somehow still had
mostly barely-improved-since-TIGER data.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alt_names on counties

[Paul Johnson]

On Thu, Dec 26, 2019 at 12:55 PM Kevin Kenny 
wrote:

> On Thu, Dec 26, 2019 at 1:11 PM stevea  wrote:
> > The myriad variations of "name" (alt, loc, nat, old, reg, official,
> sorting, int...) show how complex this is.  The issues go back many years
> and will likely continue well into the future, indeed many participants in
> this/these thread(s) are authors of our wiki's name page.
> >
> > Better documenting, continuing dialog, consensus-style agreement,
> changing data in the map to reflect our well- or better-documented
> conventions:  all of these get us closer to perfection.  Although I think
> everybody agrees, perfection is nigh on impossible, as "the map is never
> 'done.'"
> >
> > "Do our best."  If there is contention, discuss it.  If there is
> misunderstanding or disagreement, discuss it.  If there is agreement,
> document it and use it in the map and even write code that depends on it.
> We get there, we will better get there as we continue to do these things.
>
> Exactly. There is a plethora of name variations in the database
> because there is a plethora of names in the field.
>
> I joke that in New York City, most of the freeways have three names:
> the highway number, which is on the signs but nobody ever uses it in
> speaking, the name of the highway (e.g., "Jackie Robinson Parkway",
> "Avenue of the Americas", "Robert F. Kennedy Bridge") that's on all
> the signs (but the locals don't remember the name!), and the name that
> the locals call it (e.g., "Interborough Parkway", "Sixth Avenue",
> "Triboro Bridge") which isn't on the signs. (Not quite true - New York
> gave up some years ago and posted signs reading  both Sixth Avenue and
> Avenue of the Americas, but give me some poetic license here.)
>

I'll have to reiterate that "the name is not the reference", and highway
numbers are best reserved not for the name, but for the ref=* (or even
better yet, the route=road relation), except for addressing.  For example,
US 412/US 59 in Siloam Springs, AR really shouldn't have a name (but at the
time of this writing is tagged name=Highway 412 West/East).  This is wrong,
should be noname=yes instead.  Now, to use a random car wash on the road as
a handy example, *that* is where this localism should appear, with that
building being tagged as addr:housenumber=1402 and addr:street=Highway 412
West.  This comes up a *lot*, given that the US Postal Service needs to
have a canonical name for any particular street with mail delivery, even if
the street has no name, even if the street is absurdly long.  A good
example of this in action would be addresses on a road that was renamed
after two police officers, with their full titles and expanded names, but
the postal service rejected that with the address names still being "New
Sapulpa Road".  Or another example where a nameless road passes the Farm
Credit of Western Oklahoma branch in Guymon, the road has no name and
ref=US 64;US 412;OK 3;OK 136, but the bank branch has addr:street=North
Highway 64.  The Karlsruhe address schema handles these complex situations
*flawlessly*.

The situation is similar to ZIP codes provided by the US Census versus ZIP
codes provided by the US Postal Service, with in both cases, the USPS
having it's own specific reality that is a result of trivializing
complicated situations to provide specific georeferencing within their
service network.  Yes, I'm aware E911 also has addressing that often
doesn't perfectly reflect the street situation but given that it was
modeled after the USPS system *and* covers areas the USPS doesn't (filling
in the Census ZIP where the USPS doesn't have ZIPs), I'm lumping it into
the USPS for purposes of this discussion.


> Back to counties, specifically:
>
> Three of the five counties that make up New York City absolutely need
> alt_names.  The Borough of Manhattan is New York County; the Borough
> of Brooklyn is Kings County, and the Borough of Staten Island is
> Richmond County. Both sets of names are official - the county courts
> still go by the county names, while the executive branch of the city
> government uses the borough names.
>

+1
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alt_names on counties

[Paul Johnson]

On Thu, Dec 26, 2019 at 12:09 PM stevea  wrote:

> The myriad variations of "name" (alt, loc, nat, old, reg, official,
> sorting, int...) show how complex this is.  The issues go back many years
> and will likely continue well into the future, indeed many participants in
> this/these thread(s) are authors of our wiki's name page.
>
> Better documenting, continuing dialog, consensus-style agreement, changing
> data in the map to reflect our well- or better-documented conventions:  all
> of these get us closer to perfection.  Although I think everybody agrees,
> perfection is nigh on impossible, as "the map is never 'done.'"
>
> "Do our best."  If there is contention, discuss it.  If there is
> misunderstanding or disagreement, discuss it.  If there is agreement,
> document it and use it in the map and even write code that depends on it.
> We get there, we will better get there as we continue to do these things.
>

I wish it was even this straightforward.  Liberty Parkway in Broken Arrow,
OK being a great example.  The city calls it Creek Turnpike, the OTA calls
the route that traverses the length of it Creek Turnpike, the state
legislature officially renamed it Liberty Parkway.  To me, this speaks
loudly to calling it name=Liberty Parkway, loc_name=Creek Turnpike,
especially since when you're on it, it's signed as Liberty Parkway and the
only signs that still say Creek Turnpike are posted by the City of Broken
Arrow at the surface street end of ramps.  DWG went with how it's tagged
now, essentially erasing ground truth, something that I'm not satisfied
with but respect (especially given that data consumers will call out
"Continue for ___ kilometers/miles on Creek Turnpike" when passing a big
green sign that says LIBERTY PARKWAY after a confusing interchange).
Meanwhile in the same interchange at the cycleway level, Creek Turnpike
Trail, Liberty Parkway Trail and Mingo Valley Trail meet a three-way "y"
shaped intersection, and in a case of local amnesia, Broken Arrow won't
acknowledge Liberty Parkway's name, even though they themselves sign the
cycleway as Liberty Parkway Trail and even say they did that because it
runs frontage to Liberty Parkway, and that Liberty Parkway Trail name
persists for the entire length of the Liberty Parkway it runs adjacent to...

This speaks more to how stupidly complicated naming is in Oklahoma than
anything, but even on sections with easily five or six equally valid names
for the same road, it's not even that obvious to locals which should get
prime billing and some will go a long way to argue against the ground
truth.  See above again, Liberty Parkway.

I really wish Oklahoma would adopt Oregon's lead and have the concept of
honorific naming (Oklahoma does not), and post unique signs for the
honorific names instead of officially legally renaming stuff.  That'd at
least narrow it down to name:*= namespaces (where the * is mercifully
limited to various translations of the same name, like name=Bear Street,
name:en=Bear Street, name:mus=Nokose Yusten (lit. Bear Trail), or (slightly
more controversial but in practice the right call, given the vernacular
language is English and the official language is Cherokee in Tahlequah),
name=Muskogee Avenue, name:en=Muskogee Avenue, name:chr=ᎫᏐ ᎦᎳᏅᏛ (lit. Creek
Road) going from memory and my Cherokee is terrible, so apologies if I
slaughtered that).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alt_names on counties

[Paul Johnson]

On Thu, Dec 26, 2019 at 1:07 PM Kevin Kenny  wrote:

> On Thu, Dec 26, 2019 at 1:01 PM Paul Johnson  wrote:
> > Did you mean to use "old_name" instead of "alt_name"?
>
> When the locals keep using an old name for decades, without regard for
> official signage to the contrary, at what point does an old_name
> become promoted to an alt_name?
>

Good question.  There's still a lot of Portlanders who use "Union Avenue"
to refer to "Martin Luther King, Jr. Boulevard", for reasons obvious to
anyone familiar with Portland's least cheerful open secret, though it does
provide a useful lifecycle example for straightforward ones.

1989: MLK Jr. Blvd signs go up.  name=Northeast Martin Luther King, Junior
Boulevard, alt_name=Northeast Union Avenue
1994: Union Avenue signs start getting removed in select portions.
name=Northeast Martin Luther King, Junior Boulevard, old_name=Northeast
Union Avenue in selected portions.
200x: Last Union Avenue signs come down.  name=Northeast Martin Luther
King, Junior Boulevard, old_name=Northeast Union Avenue for entire segment.

Note this doesn't very well map cleanly to places that have a short memory
on names, like Oklahoma, where it's pretty routine to have, 6 to 8 times a
year, actual states of emergency declared to rename roads shotgun style,
randomly, with exceptionally long names on exceptionally short segments.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alt_names on counties

[Paul Johnson]

On Thu, Dec 26, 2019 at 12:56 AM Greg Morgan  wrote:

> Please don't remove the alt_name tags.  They are useful and not that much
> of a distraction or an error  For example, a new freeway was just renamed
> for a congress person that helped with many AZ transportation projects.  I
> added the alt_name tag so that the South Mountain Freeway can still be
> found in a search.
>

Did you mean to use "old_name" instead of "alt_name"?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[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.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Paul Johnson]

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

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

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

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Paul Johnson]

On Fri, Dec 20, 2019 at 7:18 PM Clifford Snow 
wrote:

> I've reached out to a couple of the nearby reservations, one with a small
> parcel of off reservation land trust, the other with only a small
> reservation but a very large off reservation land trust. I don't expect
> answers until possibly after the new year. Unlike Oklahoma, Washington
> reservations are pretty straight forward. The Yakama Nation has a large
> disputed area but I'm inclined to show it as reservation land. I haven't
> updated it yet because the borders are tied up in multiple relations that
> need undoing.
>

Well, that's mostly fortunate.  The disputed area and definitely Fort
Simcoe would be potentially sore spots to look out for and look into more
if reasonable.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Paul Johnson]

(Conversational quoting, please)

On Fri, Dec 20, 2019 at 6:42 PM David Bartecchi 
wrote:

> All of these concerns must be weighed against the fact that the current
> absence of Native lands in OSM only contributes to the erasure Native
> Americans and their lands from the American collective conscience.
>

Agreed.

I did think ahead on this enough to use the protected lands key when
tagging the areas I have mapped so far, as this is probably the most
neutral method available right now that doesn't break the renderers.  Not
good enough for government work (we'd need a lot more research into treaty
status and way more admin values to make those value judgements as
administrative areas), but good enough to at least be a starting point for
well established areas.

My more immediate concern than "not erasing people" is "not assigning areas
to people in ways that are ambiguous, irrelevant or potentially perceived
as hostile".  I'm not the person to take the lead on navigating that one.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Paul Johnson]

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

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

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

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

[Paul Johnson]

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

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

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


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

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

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

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

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

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Paul Johnson]

Content warning: Aboriginal abuse mention

On Fri, Dec 20, 2019 at 2:08 PM Clifford Snow 
wrote:

> I do have Washington State tribal lands available [1]  as a background
> layer for JOSM. There is also a vector tile layer [2] of the same
> background available for iD users.
>
> The data contains the name in english and the land type of Disputed Area,
> Off-Reservation Trust Land, Reservation, and Tribal Headquarters. Only 4
> disputed areas but 60 Off-Reservation areas. Some people include
> Off-Reservation in tribal lands while others do not. My sense is that they
> should be tagged as boundary=aboriginal_lands. I'd like to hear the opinion
> of the group.
>

The TLDR: I, personally, have not been including trust lands in Oklahoma,
for pragmatic reasons.  The situation is complicated, painful to many, and
politically loaded on a level where I don't think OSM should sort out trust
lands yet.

I'm aware of several dozen trust exclaves, but they all fall into one of
three categories.

   1. The exclave is presently unclaimed or claimed but no longer occupied
   by multiple tribes, and thus the status is ambiguous other than it's within
   BIA jurisdiction.  Most Oklahoma exclaves fall into this category, and it's
   really complicated.
   2. The exclave is claimed by one tribe but it's ability to establish a
   presence and primary jurisdiction is in question.  There's an exclave in
   Boise, OK where one of the tribes (not sure which, but pretty sure not
   mine) presently has plans to open a travel center and casino, however, this
   exclave is hundreds of kilometers from their jurisdictional area and
   whether or not they can even claim the exclave is nebulous.  It's
   effectively tribal terra nullius.
   3. The Chilocco Indian Residential School.  This one gets super touchy.
   The school, which closed in 1980, has sat abandoned and uncared for since,
   yet can't be torn down without considerable red tape since the site is on
   the National Historic Register.  The school is currently assigned to five
   additional tribes in the immediate region, and they cooperatively ran a
   rehabilitation center for the school's victims at the site in the 1990s and
   2000s, but the rehab facility has also sat abandoned since at least 2011
   with no plans for the site, and the whole enclave currently is off limits
   to everyone, very intermittently used as a training ground for federal
   police agencies, further rubbing sandpaper into unhealed wounds for many.
   No surprise, the original school that operated for 98 years is widely
   criticized for most of its existence, and especially in its final decade of
   operation, for being little more than a concentration camp for indian
   children as part of the US's plan for Americanization of indians. As far as
   I can tell, abuse at the school was institutionalized, frequent and
   persistent enough it's hard not to imagine it wasn't by design.  It might
   as well be scorched earth.

Add this into the fact that not all of Oklahoma's tribes (or even the
relevant tribes that potentially have claim to these parcels) get along
with each other.  Add that Governor Stitt has been talking about cancelling
state compacts with the tribes this month, and we're actually seeing nearly
unprecedented intertribal unity and cooperation right now (weird how a
common threat does that).

All that said, my read on the situation?  Trying to sort out the trust
lands in Oklahoma is politically shaky at best for OSM, and it wouldn't
surprise me if similar situations are present in other states.  Offhand,
Pennsylvania, Oregon and Kansas all have federal indian schools presently
in operation (Army War College in Carlisle, Chemawa in Salem, and Haskell
Indian College in Haskell respectively).  Washington State had one as well
(Fort Simcoe), and presently has a far darker and ongoing relations with
the tribes in that state most readily comparable Canada's Highway of Tears,
but more widespread.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk VS primary,

[Paul Johnson]

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

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

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

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

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

Re: [Talk-us] Trunk VS primary,

[Paul Johnson]

On Thu, Dec 19, 2019 at 5:13 AM Mike N  wrote:

> On 12/17/2019 10:19 PM, Evin Fairchild wrote:
> > some US routes are more important than others and lumping them all as
> > primary doesn???t make any sense;
>
> The arguments here about relative importance of parallel routes makes
> sense.
>
>Some massive changes such as in
> https://www.openstreetmap.org/changeset/78620805 are raising roads which
> have no other major choices, but are apparently just because they are
> the most important.
>

This smashing everything to the highest possible value I would generally
consider to be an undiscussed and problematic mechanical edit.  Going with
the lowest level that fits feels a bit more correct (think "minimum
effective dose" from medicine, for example), does give routers more
information where there's lots of routes available, and humans more of an
idea what kind of road they're going to encounter at a glance.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Preliminary Import/Organized Mapping Effort Idea

[Paul Johnson]

On Thu, Dec 19, 2019 at 3:03 PM Mike Thompson  wrote:

> > I've avoided BIA because their data doesn't seem accurate
> We have gotten some additional feedback off list also suggesting that the
> BIA data may not be as accurate as some other sources.  Perhaps we should
> create a wiki page listing every reservation, its boundary status in OSM,
> and the known sources of data.  Mappers can then "sign up" to work on
> individual reservation boundaries (by adding their name to the wiki page),
> manually comparing the various sources, researching the most correct
> representation, and of course editing OSM to reflect their findings
> just thinking out loud here.--
>

I'm feeling this a lot more than the MapRoulette idea.  Especially if we
can get local participants involved.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

On Tue, Dec 17, 2019 at 3:05 PM Greg Troxel  wrote:

> Tod Fitch  writes:
>
> > My reading of the wiki indicates that for the United States a trunk is
> “a high speed Arterial Divided highway that is partially grade separated.”
> [1]
> >
> > What is the problem with having the main road between
> regions/cities/towns being “primary”? Do you like the rendering of trunk
> better?
> >
> > For myself if I planned a driving trip and was expecting a trunk road
> I’d sure be surprised to find areas that are undivided and apparently, from
> other responses in this thread, unpaved in sections.
>
> Agreed.  To me trunk means:
>
>   paved
>   divided
>   very few at grade intersections or driveways (one every few miles is ok)
>

I'm also willing to include single-carriageway (ie, undivided) freeways,
reserving motorway for something identical to substantially typical
Interstate standard fare.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk VS primary,

[Paul Johnson]

On Tue, Dec 17, 2019 at 7:24 AM Mike N  wrote:

>
>I think many of the trunk VS motorway VS primary conflicts come from
> 2 points of view:  on the one hand, people like to zoom out and see a
> coherent network of interconnected roads.


In which case, rendering based on network on the route relations would be
more appropriate.


>In the end, this would suffer from the same connectivity issue:
> should the US highway remain a trunk as it reduces to 2 lanes and drops
> to 30mph passing through a tourist area?   Would that tend to draw GPS
> navigation routes from nearby faster, parallel streets?


No.  What usually causes this is a regional speed limit where the local
speed is not yet known to OSM and/or priority signage hasn't been mapped
yet that obviate staying on the highway as the best route to the renderer
based on ground truth.


> Or would it
> look like an ugly gap in the trunk road if it switched to primary in
> that tourist area?
>

Depends on if you're rendering based on class or based on network.


>As an aside, I sense that the tendency to upgrade results in all OSM
> streets being promoted by one level, resulting in a compression at the
> top end and less class distinction at those levels.
>

This tends to be the case.  Seems like based on the AK2 conversation, this
is a prolific problem in northern Canada, where roads are uncommon in
general.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

On Mon, Dec 16, 2019 at 7:17 PM Eric H. Christensen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, December 16, 2019 7:35 PM, Tod Fitch 
> wrote:
>
> > My reading of the wiki indicates that for the United States a trunk is
> “a high speed Arterial Divided highway that is partially grade separated.”
> [1]
> >
> > What is the problem with having the main road between
> regions/cities/towns being “primary”? Do you like the rendering of trunk
> better?
> >
> > For myself if I planned a driving trip and was expecting a trunk road
> I’d sure be surprised to find areas that are undivided and apparently, from
> other responses in this thread, unpaved in sections.
> >
> > [1]
> https://wiki.openstreetmap.org/wiki/United_States/Road_classification#Trunk
>
> I haven't seen that wiki page before.  Looking at the trunk page[0], the
> highway need not be divided and the U.S.-specific portion says "Surface
> expressway: A relatively high-speed divided road (at least 40 MPH with a
> barrier or median separating each direction of traffic), with a limited
> amount of intersections and driveways; or a major intercity highway. This
> includes many U.S. Highways (that do not parallel an Interstate) and some
> state highways.".  To me that meets the requirement for AK-2.
>

For a single carriageway road?  Seems like it's going the long way around
describing the southern loop of the Duncan Bypass
 or the entire
length of the Chicasaw Turnpike
.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

On Mon, Dec 16, 2019 at 10:29 PM Michael Patrick 
wrote:

>   > secondary in most cases for the state
>> highways and primary for the US ones.
>>
>
>  At least for the U.S., the Interstate vs. State Route distinction has
> more to do with funding than  carrying capacity and physical attributes. We
> have several State Routes that are definitely expressways:
> https://www.windy.com/-Webcams/United-States/Washington/Seattle/SR-at-MP-:-Des-Moines-Memorial-Dr/webcams/1459260132?47.545,-122.306,13
>

That looks more like a freeway (an expressway is a freeway with
intersections or a mix of ramps and intersections).


> Although they are few, there are still portions of the Interstate that are
> not expressways:
>
> https://en.wikipedia.org/wiki/List_of_gaps_in_Interstate_Highways#Undivided_and_narrow_freeways
>

Yeah, I 5 at either end past the last exit, for example.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

On Mon, Dec 16, 2019 at 6:47 PM Joseph Eisenberg 
wrote:

> Alaska is not attached to the rest of the USA, so consistency with the
> Yukon Territory and British Columbia is equally important.
>
> In the western USA, highway=trunk is not limited to expressways like it is
> in Germany and France
>
> On the West Coast, several important State highways are tagged as trunks
> even though they are not full expressways, because they are the main road
> for a large region. For example, see US 199, US 101, CA 99 and CA 299 on
> this map of far Northern California:
>

Are we sure that's not leftover tagging from before NE2 torqued things on a
continental level?  101 in parts of California I could potentially see, and
maybe parts of 99 where the freeway is ending in central california but the
other examples probably should be secondary in most cases for the state
highways and primary for the US ones.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

Please strongly consider splitting digests into constituent messages with
procmail or your MUA, or switch to the non-digest version to preserve
threading.

On Mon, Dec 16, 2019 at 6:35 PM Anthony Costanzo 
wrote:

>
> All of AK 2 between Fairbanks and the Canadian border is paved. I can
> vouch for this personally.
>

OK, so that's kinda putting more weight on the "primary" idea.  Is most of
it a single carriageway freeway or a dual carriageway expressway?  It's
been a long time since I've been there but i can't imagine it being more
than your typical middle-of-nowhere two-lane uncontrolled single
carriageway today.  If that's the case, I feel like primary is the highest
it should be, and we should be considering more whether or not such a road
rises to primary instead of secondary (the lowest it should be, given it's
part of the primary state highway network in Alaska).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

On Mon, Dec 16, 2019 at 6:26 PM Joseph Eisenberg 
wrote:

> Trunks are rarely expressways in remote parts of the world. In Britain,
> where this tag started, many highway=trunk roads are not expressways or
> motorroads.
>

Are we not trying to remain internally consistent with the rest of the US?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

On Mon, Dec 16, 2019 at 6:18 PM Joseph Eisenberg 
wrote:

> I would use highway=trunk the whole way for consistency. In Canada the
> connecting highway is also highway=trunk. This makes sense because AK 2 is
> linking Fairbanks, the largest city in this part of Alaska, with All the
> cities in Canada and the lower 48 States.
>

That's kind of my thinking as to why it should be primary instead of
secondary (as typical for the US for state highways).  Almost all of it's
not even paved, it'd be a hard stretch to call it an expressway (trunk).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

On Mon, Dec 16, 2019 at 5:35 PM Eric H. Christensen via Talk-us <
talk-us@openstreetmap.org> wrote:

> I've noticed that there is some mixed tagging of the Alaska Highway AK-2
> from the Canadian border through Delta Junction to where it becomes a
> divided highway just south and east of Fairbanks at Eielson Air Force
> Base.  Some of the non-divided portions are tagged as trunk while the other
> (majority) is tagged as primary.  The definitions of these two tags are
> similar enough in the U.S. to almost be interchangeable.  Being that this
> highway links many villages with Canada and the City of Fairbanks and the
> speed limit is 65 MPH, I would lean towards this highway being tagged as
> trunk.  By the same definition, I'd probably argue the same for the
> Richardson Highway AK-4.
>

I'd personally go for primary in the segments that don't rise to being a
single carriageway freeway or a dual carriageway with infrequent
intersections or a mix of intersections and ramps.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Thu, Aug 29, 2019 at 6:40 AM Joseph Eisenberg 
wrote:

> That's probably not relevant for anywhere in the USA (even in Alaska
> the main highways between cities are paved... right?) but it's a
> reminder that we can certainly choose to do things in a way that makes
> sense for mapping the USA; we don't have to use the British or German
> standards.
>

The larger cities in southern Alaska.  Most are gravel, including a paper
interstate.  I think Alaska's the last state to still have gravel state
highways.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Wed, Aug 28, 2019 at 11:41 PM Bradley White 
wrote:

> > For example, US Hwy 101 is the main route connecting the cities (e.g.
> > Eureka) and towns along the coast of northern California. Right now
> > only some segments are tagged as highway=trunk. I would like to
> > upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
> > leaves 101 and heads to I-5, at Crescent City.
>
> I did this a year or two ago, then changed it back following the
> previous time this discussion came up last year. Someone else has
> recently changed it back to trunk in its entirety as you describe (as
> well as US 395, CA 70); I explained in a changeset comment that the
> "major intercity highway where no motorway exists" definition (per
> Highway:International_equivalence) is contentious and not commonly
> used, but that I have no plans on reverting their changes.
>

Also language introduced by NE2 when he changed the wiki to justify his own
national mass edit on the US highways.


> Caltrans doesn't appear to have "divided" as a requirement for an
> expressway build, or even necessarily a freeway (See:(California)
> State Highway Map 2005; David Rumsey Map Collection) - these terms are
> used to describe the level of access control on a given highway. US
> 101 through Redwood Ntl Park is signed with "Freeway Entrance" and is
> fully access controlled, but is an undivided 4-lane road. Many 2-lane,
> undivided roads are considered expressways in California, for example:



>

- Vasco Road connecting Antioch & Livermore
> - Portions of CA 4 west of Angels Camp
> - CA 108 east of Sonora (fully access controlled 2-lane road)
>
> Once you know what to look for - reduced access to adjacent
> properties, smoothed road geometry (esp. when bypassing old highways),
> hard shoulders, usually 65 mph - they aren't too hard to differentiate
> from conventional 2-lane highways with no access control. Where these
> are obvious I generally tag them as trunk roads as opposed to primary.
> Specifically in the case of CA 108, I reject that a fully access
> controlled two-lane road is anything less than a trunk, if we have
> decided to use 'trunk' to mean 'expressway'. California doesn't use
> AASHTO definitions so I won't either.
>

I think that generally fits what would be tagged as a trunk as well (fully
access controlled but single carriageway and AASHTO's definition).


> Reno, NV has a couple urban arteries that straddle the divide between
> trunk and primary (specifically: McCarran Blvd/NV 659, Pyramid Hwy/NV
> 445 north of McCarran, Veterans Pkwy, foothills portion of Mt. Rose
> Hwy/NV 431). These roads carry traffic at speeds higher than other
> nearby arteries (45-55 mph as opposed to 40 mph). They are built to
> the highest level of access control specified by Washoe RTC -
> generally no direct access to properties, except for retail/commercial
> areas (where access is quite frequent), or rural areas where no other
> roads provide access to properties. They range from undivided w/
> center turn lane to divided with concrete jersey barriers & headlight
> blinders (similar to a freeway). The majority of these roadways have
> bike lanes, and many have sidewalks. They are quite similar to San
> Jose's expressway system, except for a lack of grade-separated
> interchanges. Are these primary, or trunk? I don't really know. They
> currently sit at an awkward mix of trunk and primary depending on how
> definitively myself and others think they are "expressways" or not.
>

I'd probably consider those as expressways.


> I don't deny that "divided highway with partial control of access" is
> a rigorous definition, with which it is certainly possible to tag
> unambiguously with. I just question whether it is a good choice in the
> US to use 'trunk' to mean 'expressway' in the same way that 'motorway'
> means 'freeway', when the US has a formal freeway system, but lacks a
> formal expressway system. Most other countries that also lack a formal
> expressway system do not use the trunk/expressway definition (UK,
> Canada, etc). In my area, sticking strictly to "divided highway with
> partial control of access" means very few highways at all will see
> 'trunk' tagging. Certainly, this reflects what's on the ground here if
> we use this definition - but why use a definition that either has to
> be used ambiguously or seldom at all?
>
> I support orthogonalizing expressways & trunk by using
> 'expressway=yes/no' for access control (maybe
> access_control=full/partial/no?), 'highway=trunk' to mean non-freeway
> road with national-level importance, and using 'oneway' to denote
> whether a highway is divided or not. Then let rendering decide how to
> draw the road from there. Want to see formal expressways drawn
> separately? 'Expressway=yes' & 'oneway=yes'. Want a more general view
> of the most important US highways? 'Highway=trunk'.
>

Feels like conflating expressways and primaries.
___

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Wed, Aug 28, 2019 at 9:15 PM stevea  wrote:

>
> > Eeeeh, that's gonna be a hard sell for the most part, most Oklahoma
> expressways are built like this as are parts of Interstate freeways, with
> the only real difference between the two being at-grade intersections and
> limited driveways (as opposed to getting to install driveways virtually
> anywhere you want on it).  Indian Nation Turnpike is a great example of
> this.  Save for being fully controlled access from the get-go meriting a
> motorway tag, it's of substantially the same design and in about the same
> condition as the expressway portions of 66.
> https://openstreetcam.org/details/1119877/3443/track-info
>
> So, trunk is wrong?  Your link appears to display an old road, re-paved
> many times, but I wouldn't call it a bad road, maybe intermediate or good.
>

Well, on the INT it would be, it's tagged as motorway because it's
controlled and limited access with dual carriageway.  The section of 66
we're talking about is trunk because it's only semi controlled and only
loosely limited access.


> > When there's more driveways, it either narrows and becomes a boulevard
> (like US 75 does for a couple kilometers in Okmulgee,
> https://openstreetcam.org/details/1119877/803/track-info;
>
> If but for the driveway, that looks like trunk, but the driveway makes me
> say primary or secondary.
>

Expressways tend to have more rules on how you can connect a driveway up to
one and how frequently they appear, not that driveways are banned nearly
entirely.  They're not anywhere near as common as you might get with a
primary, and driveways are usually but not always grouped together where
they meet the highway compared to what you'd normally expect on a primary.


> > or US 64 does entering Muskogee,
> https://openstreetcam.org/details/1366842/204/track-info)
>
> Nice example of a similar (to above) transitioning to / from "median
> divided road" to "simply double-yellow line divided" (no median).  I don't
> think this is trunk, again, depending on daily traffic and speeds, I'd say
> primary or secondary here, but not trunk.
>

Obviously I disagree.  ODOT might just take up the road and convert it down
to a boulevard later (especially if the impending bordering incipient
expressway revolt starting to take root in places like Muskogee take deeper
root), but that would be pretty typical of an inline transition at the end
of an expressway pretty much anywhere in the midwest.  If all you need to
do beyond severing driveways is add an overpass and ramps to make it a
freeway, you're probably looking at a trunk, it's not always controllable
how things organically develop around edges of towns.  Another good example
is about a mile west where US 69 goes into Muskogee.  It used to be a solid
expressway down to McAlester, but over the course of the 2000s they started
adding grade separated ramps, and this decade they spent severing driveways
and at-grade crossings from Wainright Road to the south end of OK 113
making that 75 km stretch a motorway.

I get the frustration.  There's a lot of Oklahoma that looks weird because
of the expressways seemingly scattergunned across the state.  But, that's a
reflection of reality.  And that reality is a bit of the root cause of the
pushback the public's giving ODOT on new expressways and freeways now,
because there's so much unnecessary capacity that was built up without any
coherent plan or clear justification for building it, often while
overlooking more pressing needs like maintaining what already exists,
bordering on absurdity.


> > or frontages are added to wrangle driveway traffic with connections to
> and from the expressway and the frontage being closer in frequency to what
> you would get for driveways in somewhat rural expressways (for example, the
> George Nigh Expressway in McAlester,
> https://openstreetcam.org/details/48220/5369/track-info),
>
> Here, driveways make me want to hold my nose at trunk (though it otherwise
> looks like one), so again, primary if speeds and ADT #s (daily average
> traffic counts) warrant it, otherwise, secondary.  (Though, large
> 18-wheelers / semis hauling discourages me from saying secondary).
>

That's where things get a little sticky, sure.  ODOT built most of the
expressways and all of the turnpikes with aspirations that Oklahoma would
be as populated as California and often rammed through expressways on that
assumption.  There's just a lot of examples where ODOT tried to kill a fly
with a cruise missile and missed.  AADT on the examples I've given in
Muskogee and McAlester so far are all at least 1.

US 69 examples are 15000 on the motorway portions and in McAlester where
it's an expressway with frontage roads, it's about 20100.  In Muskogee,
where US 69 passes through as a single carriageway primary street, it's
about 22000, getting significantly more traffic than the turnpike a couple
kilometers east.  Plans to build a freeway bypass through the neighborhoods
on the west 

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Wed, Aug 28, 2019 at 9:05 PM Joseph Eisenberg 
wrote:

> I don't have any local knowledge about old route 66 in OK, but I'd
> like to address the use of highway=trunk in general.
>
> I'm in favor of using a secondary tags like motorroad=yes and
> expressway=yes, along with other details like lanes=, surface=,
> maxspeed=, etc, to specify expressways, rather than using
> highway=trunk for this.
>

Ideally I'd prefer we started using tags that actually reflect what people
call things in this country and have a lookup table on the wiki someplace
for national equivalence, ie, highway=expressway, highway=freeway, etc,
since the US tends to have more levels and nuance than the relatively easy
"A/B/C/M/U" grading the British have officially that carries over there.
We don't really have motorroad as a well defined thing here, either, even
about 3/5ths of the states allow pedestrians and bicycles on most
freeways.  Using trunks for expressways does give a pretty well defined
expectation of what you're going to be experiencing as it's used now.

Like the distinctions between primary/secondary/tertiary, trunk was
> originally intended to describe the role of a road in the network.
> While most trunk highways are divided and have more than 1 lane in
> each direction in densely-populated areas, it's quite normal for to
> have narrower roads as the main route between 2 cities, in
> sparsely-populated parts of the country.
>

Well, literally the official designation of the highway, before the project
jumped outside the UK.


> For example, US Hwy 101 is the main route connecting the cities (e.g.
> Eureka) and towns along the coast of northern California. Right now
> only some segments are tagged as highway=trunk. I would like to
> upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
> leaves 101 and heads to I-5, at Crescent City.
>

I'm not sure that's really worth revisiting so much; seems for the US as we
have it now.  NE2 nationally torque-tagged everything in network=US:US as
trunk and that seems to have broken the already established trunk.


> The segments that are divided and wider can be tagged expressway=yes,
> lanes=4, maxspeed=, etc, so if people want to render these differently
> they can (routers are probably more interested in the number of
> intersections, traffic signals, lanes, maxspeed, and surface, so the
> expressway=* tag isn't really needed).
>

I think it'd honestly be easier to get everyone to agree that it's time for
lanes=* to include all lanes, not just lanes of a minimum width accessible
to a pretty narrow selection of vehicles than redefine highway=trunk in
North America at this point.  Certainly a lot less subjective.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Wed, Aug 28, 2019 at 9:10 AM Kevin Kenny  wrote:

> 'Historic US 66' is a bannered and numbered route because of its
> history, not because of its current importance to the road system. The
> constituent ways should be tagged as whatever they are currently in
> the road network. In many places, 'Historic US 66' no longer follows
> the historic route of the road because the road is no longer passable
> or no longer has good connections to the highway network. For example,
> from Flagstaff, Arizona to the New Mexico state line (except for brief
> detours through Winslow and Holbrook) the bannered 'Historic Route 66'
> is highway=motorway because the construction of I-40 obliterated or
> disconnected the old route.  (I don't know whether I-40 actually bears
> the signage anywhere.)
>

It does, sporadically, as of the last time I was that far west on 66.  And
there's also places like in Tulsa where there's multiple old alignments,
all of which are signed as Historic 66.  In order of mundane to strange,
would be its final alignment on what's now I 44, a couple major section
line boulevards across north Tulsa, an otherwise fairly anonymous two lane
road running between flood control ponds in a residential neighborhood,
what's now a quiet light industrial and residential street about a block
from where America's first yield sign once stood, and a staircase.

There are places where the old road exists on the ground and bears the
> name, but are not bannered because a road fails to connect or is no
> longer reliably passable to low-clearance automobiles. The route can
> be followed for some distance east and west of Exit 303, for instance.
> It's at most an 'unclassified' road and connects mostly to tracks. At
> the east end of that run, there's no crossing of I-40, and the road
> simply turns right onto another track. On the other side of the
> freeway, the pavement resumes, but in Petrified Forest it's
> unmaintained and has deteriorated to where it is neither safe nor
> lawful to drive. East of there, it's a track at best, and again ends
> at a freeway crossing without an interchange.  On the far side, it's a
> minor rural road (County Road 7385)
> https://www.openstreetmap.org/way/16792461, then crosses the freeway
> at McCarrell and becomes the freeway frontage road in Chambers. If
> memory serves, some of the tracks that remain in use are no longer
> public rights-of-way, and neither the ranchers nor the Navajo Nation
> welcome visitors on them.
>

Pueblo Laguna still has Indian Road L66, but they've intentionally removed
the pavement, and the signage along the road telling you not to take
pictures and that they do not want visitors makes it pretty clear that
you're merely tolerated so long as you're minding your own business, taking
only memories and leaving only tire tracks in the dust (though I think this
might be in New Mexico...I was conserving the food and water I had on hand
in case I got stuck and was taking the trip solo in a borderline overloaded
car after having emptied a storage unit, so I wasn't exactly traveling
under ideal conditions, L66 was easily the worst-maintained portion I was
willing to risk).


> In western Arizona, from Kingman to Seligman, the historic way is in
> service, is bannered 'AZ 66' and is at least 'secondary'.


About the only other classification I could see for that is primary, and
that's only because of it's relative historical value as a through route
that people come from around the world to drive, and (deep memory dive on
this) it's set up with permanent turnable/foldable signs to work as I 40
Detour in emergencies on the freeway.  ADOT bought the rights to Burma
Shave's branding just to maintain their own Burma Shave signs along that
section (amusingly, these are retroreflective metal signs made to roughly
the same physical specs as the standard MUTCD signs along the road).


> East of
> Seligman, it exists as Crookson Road and 'Old US 66, but diminishes to
> a track and disappears at a corner where it crosses neither I-40 nor
> the Phoenix spur of the Santa Fe. Between there are Flagstaff, there
> are fragmentary tracks, and some, such as
> https://www.openstreetmap.org/way/16792461 are entirely isolated from
> the road network. West of Kingman, it's County Road 10, and at least
> it used to be challenging to drive because it was a narrow and badly
> deteriorated road in mountainous terrain. The only community on the
> route is Oatman, which has enjoyed something of a resurgence as a
> tourist destination, "come see the ghost town where wild burros roam
> the streets." I'd say it's probably 'tertiary' because in that desert,
> it doesn't take much to make a road important.
>

It's still pretty rough and it's still a twisty drive, with the speed limit
being 15 MPH in places, IIRC.  Speed limit enforced by burro.  Wanted to
see the fire station for their restored, roofless firetrucks, but the
closest I could legally get to it was a block away because apparently 

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Wed, Aug 28, 2019 at 7:04 AM stevea  wrote:

> Hi Paul, Hi Volker, Hi talk-us:
>
> The topic begs the question as to what such (usually very) old,
> poor-condition (where they ARE poor) roads should be tagged (we limit
> ourselves to US roads here because this is talk-us), and at what
> granularity.  (Volker COULD do detailed tagging, but I hear loud and clear
> he prefers high-granularity tagging, as do I, though we all recognize how
> tedious this can be).  And "old 66" is a quintessential example, many
> segments are a century old or older:  it is known as "the Mother road" by
> many.  BTW, many public agencies under the umbrella of Southern California
> Association of Governments are working on developing USBR 66 in California
> for cyclists (the route number choice is no coincidence as some alignments
> follow the old Mother road).  This was actually in OSM as an early proposed
> route, but was removed to conform to USBRS proposed route conventions.
> If/as USBR 66 turns into a Caltrans (DOT) route proposal to AASHTO, OSM
> will re-enter these data.  It makes sense to pay close attention to the
> underlying infrastructure tagging (tertiary, surface, smoothness...) as we
> do so since these are important to cyclists.
>

So, the segment in question given in the example to me (I don't think the
response was intended only for me, so I'm not quoting the whole thing) is
https://www.openstreetmap.org/way/14678570/.  OpenStreetCam has footage
from November 2018 on it at
https://openstreetcam.org/details/1305935/3747/track-info, showing it's a
pretty typical Oklahoma expressway, 55 MPH speed limit for most of it,
slowing towards its eastern end, and is currently a part of OK 66.

I think a better argument for downgrading from trunk exists in Southern
California if it hasn't been downgraded already.  There's some decent
chunks east of Indio in San Bernardino County off the top of my head that
were clearly constructed as trunks, have since left Caltrans inventory and
are now county roads, and SB County has just let one side of the road rot
off, running both directions undivided on the other (usually the former
westbound-only carriageway, from memory, as last I drove it I was going
eastbound, the center divider was on my right, and it looked like the other
side hadn't been usable for at least a decade with weeds and huge cracks
growing out of the abandoned carriageway).

A case can be made for highway=trunk (for connectivity reasons) yet I do
> resonate with "secondary at best" for such old, poor roads.  Tagging
> highway=trunk is about as high a classification as the very best portions
> of this road will ever get, and only on its highest-speed segments which
> are divided.  This implies highway=tertiary (MAYBE secondary) where the
> road is NOT dual carriageway, as highway=trunk in the USA means "with a
> barrier or median separating each direction of traffic" (truly dual
> carriageway).  Yes, it is appropriate to tag highway=secondary on some
> segments, I believe these to be in the minority compared to tertiary (which
> likely makes up the majority of what remains of this route in many states).
>

I could see secondary or tertiary for the non-expressway portions (though
most of it is state highway, so that would be secondary at lowest for the
parts that are currently part of state highways).  But it does have among
the longest portions of still-extant expressway portions, mostly still in
the state highway inventory here in Oklahoma.


> I also say including a surface=* tag is important, so is a smoothness=*
> tag (though that has its controversies) where this is known or meets /
> falls below value intermediate (or so).
>

I think it's important to disconnect the idea of surface=* and smoothness=*
from highway=* in most cases.  If surface and smoothness factored into it,
that really opens up I 5 in Portland until relatively recently (like,
before about 2013) to question it's motorway status, as it's 50 and 55 MPH
speed limits being way too fast without damaging tires on the potholes or
hydroplaning the ruts.

Let's agree that simply tagging highway=trunk is often incorrect when dual
> carriageways of highway=tertiary with accurate surface=* (and sure,
> smoothness=*) tags would be much more accurate and preferred.
>

Eeeeh, that's gonna be a hard sell for the most part, most Oklahoma
expressways are built like this as are parts of Interstate freeways, with
the only real difference between the two being at-grade intersections and
limited driveways (as opposed to getting to install driveways virtually
anywhere you want on it).  Indian Nation Turnpike is a great example of
this.  Save for being fully controlled access from the get-go meriting a
motorway tag, it's of substantially the same design and in about the same
condition as the expressway portions of 66.
https://openstreetcam.org/details/1119877/3443/track-info

When there's more driveways, it either narrows and becomes a boulevard
(like US 75 does for 

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Tue, Aug 27, 2019 at 11:27 AM Volker Schmidt  wrote:

> going over my Mapillary photos of Route 66 I just noticed that long
> stretches of the Historic 66 are mapped in OK as highway=trunk as soon as
> they have separate carriageways for the two directions. Many of these
> stretches are at best secondary roads, often with poor road surface and
> with plenty of intersections and driveways connected to them.
>

I'm familiar with and traveled the entire length of 66 in Oklahoma a few
times.  Got an example?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Oklahoma getting first mini-roundabout

[Paul Johnson]

Just saw this in my newsfeeds this morning, looks like the number of
mini-roundabouts in Oklahoma is about to tick from 0 to 1.

https://www.newson6.com/story/40932988/walkability-project-starts-in-okmulgee
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] What is the meaning of hgv:national_network=yes/terminal_access?

[Paul Johnson]

On Mon, Aug 5, 2019 at 8:07 AM Joseph Eisenberg 
wrote:

> hgv:national_network=terminal_access means > "a road which can carry
> cargo trucks and has an adequate turn-around facility at the end"
>
> Great, that's helpful. So it sounds like this tag is a synonym for
> hgv=destination or hgv=yes?
>

Well, I'd say more like hgv=designated
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Careful, "st" can mean "stone" in some places | Re: Typical maxweight signs in USA? (editor developmnent question)

[Paul Johnson]

On Thu, Jun 27, 2019 at 1:59 AM Rory McCann  wrote:

> On 25/06/2019 20:01, Mateusz Konieczny wrote:
> > 25 Jun 2019, 17:47 by pe...@dobratz.us:
> >> Reading this page, I see the potential ambiguity extends deeper than
> >> I realized (short ton, metric ton, long ton)
> >> https://en.wikipedia.org/wiki/Tonne
> >
> > AFAIK all cases of "t" in USA on max weight signs means "short ton".
> >
> > Taggable by adding "st" unit or by converting to pounds, and adding
> > "lbs" unit.
> > First seems to be superior as puts lower burden on mappers and it allows
> > to directly map what is signed.
> > See https://wiki.openstreetmap.org/wiki/Key:maxweight#Usage
>
> FYI "st" is used in Britain & Ireland to mean a "stone" ( 14 pounds i.e.
> 6.35029318 kg ). People in UK & Ireland can refer to their weight as "X
> stone", or "I've lost half a stone on my diet" (but kg is common too).
>
> If you use "st" in an OSM tag value for weight, a not very bright data
> consumer might interpret that as stone. Maybe we can side-step that
> problem by picking a better suffix?
>
> What about "uston" (maxweight=8 uston)?
>
> Are there other regions which use “ton/tonne/...” on signs which
> *aren't* the US ton? If so, we could just say “t” means “us short ton”.
>

Older signs, TON means US tons.  Newer signs, T means legacy US, t means
standard (metric) tons.   Texas went kinda the other way redefining their
standards in standard measure, but posting strangely specific legacy weight
limits, like bridges that say "WEIGHT LIMIT 22046 POUNDS" instead of
"WEIGHT LIMIT 10t" with the 10t in a circle.

Hopefully some sanity can be restored to this country and this whole thing
will be moot in the next decade...
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Need someone in the south to review an edit

[Paul Johnson]

On Sat, Jun 15, 2019 at 11:07 AM Frederik Ramm  wrote:

> Not following the organised editing guidelines is not a rule violation
> in itself, but if not following the guidelines leads to bona fide
> mappers like yourself saying "most of my dedicated mapping time is now
> spent dealing with SEO spam and low quality brand location data." then
> this is clearly a case where the guidelines need to be enforced, and I'm
> more than happy to block any and all organised mapping teams who
> willfully disregard the guidelines and cause trouble down the line
> because of that.
>

How are we handling the operation behind the zillion throwaway accounts,
where they make a new account for each client, edit one time, then
disappear, never replying to comments or direct messages?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Need someone in the south to review an edit

[Paul Johnson]

On Sat, Jun 15, 2019 at 7:45 AM Frederik Ramm  wrote:

> Hi,
>
> On 6/14/19 10:27 PM, Rihards wrote:
> > I zoomed in on one location, and the node was, judging by the imagery,
> > on a street (literally). I hope Brandify does not set locations from
> > Google address searches.
>
> I did that a few days ago when investigating this large deletion, and
> also found that many of the objects are bang in the middle of roads.
> Which means at the very least that their location has not been visually
> inspected by the uploader.
>

I'm not against companies for hire mapping, but...do we have any guidelines
actually requiring them to accurately geocode what they're bringing?  Kind
of feel like most of my dedicated mapping time is now spent dealing with
SEO spam and low quality brand location data.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Need someone in the south to review an edit

[Paul Johnson]

Aaah, OK.  Would have been nice if Brandify Tran replied to changeset
comments.

On Fri, Jun 14, 2019, 10:01 Micah Cochran  wrote:

>
>> One of the following changeset comments suggests the deletions in this
>> changeset are to remove duplicates added by mistake previously.
>>
>>
> I checked the a few local locations of the business (Athens, Alabama).
> There are still nodes/ways for the "Express Oil Change" locations, which
> would seem to suggest that it was just correcting duplicates (as Shawn
> pointed out).
>
> The business is still in business, I think I drove by one this week.
>
> Micah Cochran
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Need someone in the south to review an edit

[Paul Johnson]

Brandify put up a rather suspicious mass deletion
 recently.  I suspect that
one of their customers stopped paying/had a term contract that expired and
Brandify mass-deleted the entire chain.  But it is possible that the chain
went out of business and their website is still active.  Could I get
someone in the south to take a look at this and see if locations near you
that was deleted closed?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] What's protecting the map?

[Paul Johnson]

On Sun, Jun 9, 2019 at 1:23 PM Nuno Caldeira 
wrote:

> But what happens if the Foundation is taken over by people with commercial
> interests?
>
>- You still own the rights to any data you contribute, not the
>Foundation. In the new Contributor Terms, you license the Foundation to
>publish the data for others to use and ONLY under a free and open license
>
>
This got me thinking, particularly considering the license change a few
years ago and what a fiasco that was.  What's protecting the map here?
What's to stop a prolific contributor from taking their ball and going
home, to the overall detriment of the map?

To be clear, this *is not something I am going to to*.  For the sake of
playing Devil's advocate, what is to stop me from, after nearly a decade,
taking my data and going home?  This would leave a roughly 400 kilometer
wide hole centered in Tulsa, some serious breakage in metro Portland and
thousands of pockmarks around the world.  If I were to pull out and take my
data with me, it would swiss cheese the map.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Paul Johnson]

On Wed, Apr 24, 2019, 18:35 Greg Troxel  wrote:

> I think the entire "national_park" tag is unfortunate, as it wraps up a
> lot of concepts that vary by country, and makes people understand things
> when they don't.  In the US, it should mean "preserve the land while
> allowing access and enjoyment", there is a notion that the place is
> relatively distinguished, and it doesn't really have a connotation of
> size.
>

I agree, the national_park tag is rather unfortunate, some other tag should
be used to connote state or national parks in an easily distinguishable
fashion while not making it excessively difficult to find parks in
general.  With the existing national park tag, I'd use it for national (US
and indian tribal), but not state parks.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Fwd: trail tagging

[Paul Johnson]

Accidentally sent this as a private reply but did so unintentionally.

-- Forwarded message -
From: Paul Johnson 
Date: Fri, Apr 19, 2019 at 7:54 PM
Subject: Re: [Talk-us] trail tagging
To: Tod Fitch 




On Fri, Apr 19, 2019 at 10:26 AM Tod Fitch  wrote:

> On Apr 19, 2019, at 7:28 AM, brad  wrote:
>
> Everywhere I've been in the US or Canada a dirt 'way' too narrow for a 4
> wheel vehicle is called a trail, path, or single track.   For the most part
> they are appropriately (IMO) tagged as path.   Unfortunately the wiki says
> this for highway:path (the highlighting is mine):
>
> *A non-specific path. **Use highway=footway
> <https://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway> for paths
> mainly for walkers, highway=cycleway
> <https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway> for one also
> usable by cyclists, highway=bridleway
> <https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbridleway> for ones
> available to horse riders as well as walkers **and **highway=track
> <https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrack>** for ones
> which is passable by agriculture or similar vehicles.*
>
> I think it makes no sense to call a dirt path, open to more than 1 user
> group, anything other than a path.Since about 98% of the trail tagging
> that I've seen seems to agree, Is there consensus on this?   Perhaps if the
> international group likes the description as is, a clarification on the US
> road tagging wiki page?
> https://wiki.openstreetmap.org/wiki/United_States_roads_tagging
>
>
> From my experience in the western US, I concur with you.
>
> I personally use footway if it is a hard surfaced way that is restricted
> to foot traffic. One of my mental check points is: can it be used by a
> person in a wheelchair or pushing a stroller? In practice I usually only
> see those in suburban and urban environments though there are a few “nature
> trails” or “discovery trails” specifically designed for handicapped access
> I’ve come across that I’ve tagged as footways.
>

Most sidewalks in America are informal dirt trails next to a paved street.
I wouldn't call those "paths" at all.  They're not suitable (or legal) for
cycles to use, and definitely not suitable for other wheeled travel
(motorized or not).  That would definitely be a footway.  Your average
concrete sidewalk (in the relatively rare places these exist) would also be
footway (but additionally, footway=sidewalk).

Once away from town the ways are almost always too rough or narrow for a
> stroller/wheelchair and they are almost always multiple use with some
> combination of walking, equestrian and/or bicycling use allowed. Those I
> tag as paths.
>

That's (mostly) fair.  Be sure to explicitly tag at least foot and bicycle
values, as path implicitly allows both in most areas (even though this
isn't normally or always the case).  Highway values I definitely support
explicit tagging for foot and bicycle at a minimum are pedestrian, footway,
path, cycleway, trunk and motorway, because at least in North America, all
bets are off on those.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Gated communities

[Paul Johnson]

I like this answer.  Behind the gates I tend to tag as private, but giving
one of the barriers access=destination should be enough for that to be the
default answer for going in, if implemented.

Not really something common in Oklahoma, usually gated communities have
only one way in or out that isn't an emergency access, pedestrian or
bicycle only gate.

On Wed, Mar 20, 2019 at 7:24 PM Evan Derickson 
wrote:

> What about marking the resident-only gates with access=private and the
> guest gate as access=destination?
>
> On Wed, Mar 20, 2019, 16:03 Eric H. Christensen via Talk-us <
> talk-us@openstreetmap.org> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Wednesday, March 20, 2019 6:38 PM, Frederik Ramm 
>> wrote:
>>
>> > Should all roads inside the gated community be access=private?
>>
>> I wouldn't necessarily mark all the roads as private as I think that
>> would hinder the routing engines.
>>
>> > What tags should be applied to (a) the main gate where visitors and
>> > delivery services are expected to report, and (b) resident-only gates?
>>
>> I've mapped a neighborhood like this before and I think I got the routing
>> to work properly by using gates at non-manned areas with access=private and
>> something else at the guard houses with access=designated or something to
>> that affect.  I think that fits the model...
>>
>> Eric "Sparks"
>> -BEGIN PGP SIGNATURE-
>> Version: ProtonMail
>> Comment: https://protonmail.com
>>
>> wsFcBAEBCAAGBQJcksYxAAoJEIB2q94CS7PREZoQALxqnyFgf57KuZ8btd9G
>> Rh/ttSnL2ut/P3JBddk++vM3qvxD0N6dAEQDF5X1mMYvYtwkjJ3JUm5WeFSL
>> MTt3teOV1KIJWb7fk8VsysJUatz3Q3Ksty9fevG1t5W2l+9tkXn6eNzMIL5c
>> Ztdabtgrlx/6I04IpQnPcqAjJUh48g5aQYCitfMQf3A/67/CRt0YnsYEa/79
>> 0WmOUmtxLSDdofwOwi3g6CCma6oWiAttnrCfHLQhqbALSlM9e0+VLGICT2ma
>> c3eV0tzE7qvv6Xw3ngos6uVwsnJ5ppnslBax+ZDyRlc5De0ka+XAep/VWJQc
>> oU5Yd6gYj+7xiP+loFRLQoOR2gPSf1C/nPIVBKiD0tWgiEkPK/zHA8jA6C83
>> a+ZR+BNZ5LXQsSbHGn/4R5jyXBmRSRlsQ3UajVfcaDOteRKsvW2zNQUxQJn/
>> uzCPE6H1ZkuMjNzr2qT4/IT8TXc8Qyx+rZB/q0OiJfFa1QofNOmy9rsXkxzm
>> bDdcH+swBAe6eXz1snM/hYW8HDn0aba/TPYCK5+q5B3D9ynrIH9HktPVcIs9
>> wbt4/+qhBe4bxihA5A2vntZyrQJeHqObiMHvN8a4Zs1AiMvzEw70JAth6uYo
>> 0oNrFCnHC3GZrEHZzyyGK/pjKlcevupEn4NIUZvWO1T6ph3rMLiAr241eSSy
>> xykO
>> =y2bt
>> -END PGP SIGNATURE-
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> --
>
> --
> Evan Derickson
> (360) 402-6494
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Forest Routes

[Paul Johnson]

On Thu, Dec 6, 2018 at 8:06 PM Kevin Broderick 
wrote:

> I don't think that the way to is a reliable indicator of trail vs road.
> Particularly in areas managed for forestry, I believe it's fairly common
> for a disused skid road to be managed and used as a non motorized trail (I
> can think of a few examples around here), which is a distinct situation
> from a road being closed to vehicle traffic without special permission, but
> both cases could be a track with the same access tags.
>

Singletrack versus doubletrack.  The roads are always doubletrack (but
don't always allow vehicles save for forestry and fire), the trails are
always singletrack (and quite typically incapable of passing a doubletrack
vehicle).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Forest Routes

[Paul Johnson]

On Thu, Dec 6, 2018 at 6:42 PM Eric H. Christensen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, November 29, 2018 3:13 PM, Kevin Broderick <
> k...@kevinbroderick.com> wrote:
>
> > Doesn't the Forest Service use FR for "Forest Road" at the reference?
> I'd think that, or NFR to distinguish from state forest roads, would be the
> more appropriate ref, as FS is ambiguous (it doesn't distinguish between a
> forest road and a forest trail).
>
> I think the highway type would be a better way to distinguish between a
> roadway and a trail.
>
>
My thoughts, too.  And the route relation type, since a trail's not going
to be route=road, even if it is the same network.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Paul Johnson]

Sure thing, go back to about the last year of his edits.

On Sun, Dec 2, 2018 at 5:06 PM Evin Fairchild  wrote:

> Can you provide changesets showing where NE2 mass edited motorways in the
> way you're describing?
>
> On Sun, Dec 2, 2018, 3:02 PM Paul Johnson 
>>
>>
>> On Sun, Dec 2, 2018 at 4:58 PM Thomas Silas 
>> wrote:
>>
>>> As for the situation in question: I agree with the vast majority of the
>>> posters both in the changeset and in talk-us. There are countless examples
>>> of the motorway tag extending to the first intersection (or to a visible
>>> change in road geometry, for that matter), but I haven't been able to find
>>> any examples of what Paul is proposing, except for the ones he has edited
>>> himself.
>>>
>>
>> Are there any that don't date back to either the TIGER import or NE2's
>> tag torquing?
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Paul Johnson]

On Sun, Dec 2, 2018 at 5:04 PM Evin Fairchild  wrote:

> You are proving my point once again re misrepresentation of what we're
> saying. It would only be accurate for you to say that we're going against
> federal guidelines is if we were to say that the motorway should continue
> thru the at grade intersection. None of us are saying that!
>

Sure, if the federal guidelines actually said that.  But they exclude all
surface intersections.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Paul Johnson]

On Sun, Dec 2, 2018 at 4:58 PM Thomas Silas  wrote:

> As for the situation in question: I agree with the vast majority of the
> posters both in the changeset and in talk-us. There are countless examples
> of the motorway tag extending to the first intersection (or to a visible
> change in road geometry, for that matter), but I haven't been able to find
> any examples of what Paul is proposing, except for the ones he has edited
> himself.
>

Are there any that don't date back to either the TIGER import or NE2's tag
torquing?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Paul Johnson]

On Sun, Dec 2, 2018 at 4:30 PM Evin Fairchild  wrote:

> Once again, I see you're misrepresenting the discussion and trying to make
> us look like a bunch of idiots for not accepting your way of doing things.
> There's no way you're so dense as to assume that because we pretty much all
> want the motorway designation to extend all the way to the first at grade
> intersection, we think roads with at grade intersections can be classified
> as motorways.
>

 There's no reason to get personally derogatory on this.  Where's the
problem with limiting motorway to what generally meets federal guidelines
on what constitutes a freeway?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Paul Johnson]

On Sun, Dec 2, 2018 at 4:19 PM Adam Franco  wrote:

> I'm not saying that the surface junction itself would still be motorway
> (or even the area of reduced speed approaching it), but once one is far
> enough beyond those limiting features and the speeds and other aspects are
> the same as the rest of the motorway, the roadway is functionally a
> motorway.
>

So where is the argument here?  In this case, the speed limits start
dropping (and in the opposite direction, don't get up to full speed) until
the Apache junction.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Paul Johnson]

The commonly accepted definition of freeways in the US excludes surface
junctions, whereas expressways (trunks) does include intersections.  I
honestly am surprised a group of roadgeeks isn't more attuned to this
distinction.

On Sun, Dec 2, 2018 at 3:15 PM Adam Franco  wrote:

> On Sun, Dec 2, 2018 at 1:36 AM Paul Johnson  wrote:
>
>>
>> On Sun, Dec 2, 2018 at 12:30 AM Bryan Housel  wrote:
>>
>>> I do understand your point, but a dozen or so people on talk-us and the
>>> six or so people on that changeset 64919426
>>>
>>
>> Well, 1 person, an AA roads troll and like 5 sockpuppets.  There's also a
>> number of people in this thread that do agree with me.
>>
>>
>>> discussion all disagree with you.  Is there nothing that would make you
>>> reconsider?
>>>
>>
>> Get the commonly used definition of a freeway changed to include
>> intersections.  Good luck!
>>
>
> Since you are asking for more declaration of support/opposition, I'm a
> relatively disinterested-in-motorways mapper that has been following along
> with this thread. Paul, I think your read of a motorway definition is
> overly rigid and I agree with Richie, Bryan, and the others that a motorway
> classification may continue beyond the last interchange.
>
> If one is traveling past the last interchange one may be traveling in a
> "motorway zone" where high speeds, grade separation of crossing roads, dual
> carriageway, etc all continue to exist. As Richie pointed out, there will
> be some place where "caution freeway ends", "intersection ahead" or slowing
> speed limit signage indicates a transition out of the motorway zone to
> something else. That seems like a vastly more appropriate place to change
> the tagging from motorway to trunk/primary. Choosing the point of the last
> interchange doesn't make sense as there may be many miles on both sides of
> the last interchange where the roadway is functionally the same -- where
> standing and looking at the road it shows all of the characteristics of a
> motorway. It is confusing to think that an at-grade intersection far over
> the horizon would force a long final segment of road to change
> classification.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Paul Johnson]

On Sun, Dec 2, 2018 at 12:30 AM Bryan Housel  wrote:

> On Dec 2, 2018, at 12:42 AM, Paul Johnson  wrote:
>
> On Wed, Nov 28, 2018 at 8:37 PM Bryan Housel  wrote:
>
>> Can’t a motorway* begin or end* at an at-grade intersection though?
>>
>
> No, I don't think so.  It's at least not a freeway traffic pattern on the
> side heading towards the intersection.
>
>
> I do understand your point, but a dozen or so people on talk-us and the
> six or so people on that changeset 64919426
>

Well, 1 person, an AA roads troll and like 5 sockpuppets.  There's also a
number of people in this thread that do agree with me.


> discussion all disagree with you.  Is there nothing that would make you
> reconsider?
>

Get the commonly used definition of a freeway changed to include
intersections.  Good luck!

> What you did by classifying it “trunk” back to the Apache Street
>> interchange just looks weird.
>>
>
> So why should we tag for the renderer?
>
>
> In this case, the renderer is correct, and it’s making your unusual
> tagging preference stand out clearly on the map.
> Would you at least consider tagging the last 500 feet or so as
> motorway_link?
>

It's not a mutual split, though; it's the mainline.  I don't think anybody
would argue link is appropriate in this context.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Paul Johnson]

On Wed, Nov 28, 2018 at 8:37 PM Bryan Housel  wrote:

> Can’t a motorway* begin or end* at an at-grade intersection though?
>

No, I don't think so.  It's at least not a freeway traffic pattern on the
side heading towards the intersection.


> What you did by classifying it “trunk” back to the Apache Street
> interchange just looks weird.
>

So why should we tag for the renderer?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Paul Johnson]

On Sat, Dec 1, 2018 at 11:01 PM  wrote:

> [forwarding this to talk-us, sent privately in error]
>
> -Original Message-
> From: Richie Kennedy 
> Sent: Saturday, December 1, 2018 1:19 PM
> To: Paul Johnson 
> Subject: Re: [Talk-us] Trunk versus motorway
>
>
> > On Nov 29, 2018, at 8:34 PM, Paul Johnson  wrote:
> >
> > Single carriageway grade separated?  Trunk.
>
> Disagree vehemently. I do not believe that a Super-Two should be
> classified differently than its four-lane counterparts
>

They don't even work like regular freeways.  You can't pass, and even if
you can, it's limited by oncoming traffic and onramps.  Freeways are dual
carriageway, fully controlled, grade separated and high speed; anything
that doesn't meet that shouldn't be tagged as motorway.


> > Dual carriageway, at-grade intersections but otherwise freeway like?
> Trunk.
>
> It seems the question in this thread is “Where does a Motorway end and a
> Trunk begin” where there is a stretch containing at-grade intersections
> between two segments that could otherwise qualify as motorway.
>

I generally consider the last junction with another motorway to be a good
place, though the first grade separated junction to be a good compromise.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Trunk versus motorway

[Paul Johnson]

On Thu, Nov 29, 2018 at 8:28 PM OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> In Santa Cruz, there is about 50 meters of highway=trunk between Highway
> 17 (freeway, motorway) and where 17 ends at signalized Ocean Street
> (highway=primary).  At first I was nonplussed about this being so tagged in
> OSM, but as I remembered where the regulatory (therefore, by law) "End
> Freeway" sign is (confirming it today), it actually is tagged correctly.
>
>
Looks like there's a mistake on CA 1 west of CA 17 near there.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk versus motorway

[Paul Johnson]

I'm largely in agreement and this seems like how it's been done in
practice.  Would also apply to WA 500 (which also should be a trunk east of
I 205, if not at least 112th/Gher; with argument supporting 205 being that
112th/Gher is largely only used by way of it's I 205 North exit and
supporting Gher as the break as it doesn't start slowing down until just
before the WA 500 East merge), and until recently, the entire length west
of the traffic light with Fourth Plain.

There's been a long tendency towards escalating highway priority, which
kind of dilutes all of the definitions and overloads secondary, primary,
trunk and motorway, that I've been trying to resist.  Like US 26 from where
it goes single-carriageway east should be primary, same with US 97 north of
Bend Parkway

 and south of Century Drive

until
the Klamath Falls Pilot

and
then again south of Reams Country Club
,
to use some more examples I'm very familiar with on the ground.  About the
least motorway-like thing I'd call a motorway would be Arroyo Seco Parkway
(most ramps are RORO with stop signs and no merge space, really not having
changed much since it was parodied in 1950's Motor Mania
.

Single carriageway grade separated?  Trunk.  Dual carriageway, at-grade
intersections but otherwise freeway like?  Trunk.  Traffic lights?  Trunk.
Fully controlled, fully grade seperated, high speed design?  Motorway.
Random 100km+ stretch of standard interstate-style highway

 (TLDR version
)
that passes a cow pasture whose only frontage is the freeway, accessible
only through a private gate in the freeway fence?  Motorway.

Another set of situations I'm familiar with:  I 5 north of WA 543 (trucks
prohibited, frequently stopped traffic to that point, speed limit gets down
to 10 MPH, passes through several crosswalks, then not long after that and
enters Canada, and doesn't properly continue as freeway again until the 8
Ave interchange on BC 99.  Nearly the mirror situation at the opposite end
of I 5, it and 805 south of the San Ysidro interchange with the Mexican
side currently mapped correctly.  Neither are remotely like, say, taking
Germany's A 6 onto France's A 320 where everything's free flowing, and no
checkpoint and not driving in a park.  A really good edge case would be
between motorway and trunk would be I 5 between OR 99E and WA 14 (traffic
lights for/and a draw bridge, no shoulders, and a blind sharp right turn at
the north end northbound).

On Thu, Nov 29, 2018 at 7:36 PM Greg Troxel  wrote:

> Bryan Housel  writes:
>
> > Can’t a motorway begin or end at an at-grade intersection though?
>
> Certainly, and I think the question is how long does a stretch of road
> that meets motorway specs have to be to be tagged motorway.  The basic
> issue is that "not having at-grade intersections" is not a local
> property of a road, and is really a statement about the road before and
> after where one is talking about.
>
> Assume an infinitely long road, divided, 2 lanes each way.  After a very
> long time of no intersections, assume an at-grade intersection, and call
> this coordinate 0, expressed in km.
>
> Then, assume an another at-grade intersection at 0.100.  After that, at
> 0.110, and so on, with each being 1.1 times the previous.
>
> By the time you get to 500 km between at-grade intersections, the
> intevening roads are surely motorways.  At 100m, they surely are not.
>
> In my view, to be tagged as motorway, the length of qualifying roadway
> has to be long enough so that it feels like it is very long, as opposed
> to a lucky 2 to 3-mile stretch of trunk that happens not to have any
> intersections.
>
> Overall, I would throw out that if a section that meets motorway specs
> isn't at least 10 miles, it's still really nice trunk, and should not be
> tagged motorway.  Maybe 10 is too much and it should be 5 mi, or 10km,
> or maybe it should be 20 or 25 km.   But 1-2 miles is way too short to
> flip back and forth.
>
>
> I have no  idea if this supports or opposes Paul in this case :-)  But
> I'm guessing it supports...
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Forest Routes

[Paul Johnson]

The numbering is consistent only within a single National Forest and
numbers will likely repeat even where multiple national forests are
contiguously adjacent.  The numbers are unique within each individual
forest, though.

On Thu, Nov 29, 2018, 16:21 Tod Fitch 
> > On Nov 29, 2018, at 1:28 PM, Jack Burke  wrote:
> >
> > As Paul said, it depends on the type of road.  In Georgia, the signage
> > has been the brown keystone one for roads that mere mortal cars can
> > drive on:
> > https://www.mapillary.com/map/im/HD_cjbQunrGWEQCViX-Now
> >
> > And the vertical ones with FS on them for people with more advanced
> vehicles:
> > https://www.mapillary.com/map/im/3Il7nk3S4MuMX9jR_SIQnw
> >
> > And, as I said, their IVR map uses NF for all of them....
> >
> > --jack
> >
> > On Thu, Nov 29, 2018 at 3:36 PM Paul Johnson 
> wrote:
> >>
> >> On Thu, Nov 29, 2018, 14:14 Kevin Broderick  wrote:
> >>>
> >>> Doesn't the Forest Service use FR for "Forest Road" at the reference?
> I'd think that, or NFR to distinguish from state forest roads, would be the
> more appropriate ref, as FS is ambiguous (it doesn't distinguish between a
> forest road and a forest trail).
> >>
> >>
> >> Maybe on visitor brochures, but on signage they get keystone shields
> for two digit routes and either a vertical or horizontal rectangle sign
> (depending on whether or not motor vehicles are expected to travel) for
> minor routes, and the numbers all constitute a single network regardless of
> if it's a road or a trail.
> >>
> >> I seem to recall when I lived near a national forest that TIGER and the
> USGS would use Forest Service XX when spelling out major routes, and
> National Forest Development XXX or NFD  on the minors.
> >>
> >> In either case, most people that travel in or near national forests
> regularly will find FS and NFD immediately recognizable.
> >>
>
> Having just been hiking and sightseeing in the Coconino National Forest,
> sightseeing in the Prescott National Forest, frequently hiking in the
> Angeles National Forest and Cleveland National Forest, occasionally hiking
> in the Coronado National Forest as well as volunteering regularly in the
> Los Padres National Forest, my impression is that signage is inconsistent
> between at least different USFS regions and likely between forests within a
> region. For example, the signage I saw in the Red Rock area of the Coconino
> NF last week were just numeric (and pretty visible) while much of the
> signage in the Los Padres is less visible and in the form of 8N05 (might be
> a “W” instead of “N” if a trail/path).
>
> So I think this thread is attempting to establish a higher level of
> consistency in tagging USFS roads (and possibly trails) than the USFS has
> been able to achieve itself. Not to say this is a bad thing, but I expect
> any photos of signage from one forest can be contradicted by photos of
> signage from another.
>
> For roads and trails with a purely numeric forest service ID, I think a
> prefix of “FR” or “FS” in OSM could make sense.
>
> I suspect, however, that purely numeric ID values are likely not unique
> between different forests, or if not forests then between regions. So “FS
> 525” might well exist in two different parts of the country. Is this a
> problem in OSM? Do we wish to guarantee that a search for a specific
> reference value only turn up one route?
>
> The forest service seems to have a unique short alphabetic code for each
> forest (at least within a region) that is displayed on the vehicles (e.g.
> LPF for Los Padres National Forest) which I think they use to keep things
> less confused when resources, especially fire crews, are dispatched to
> other forests. From that point of view those alphabetic codes might be
> useful in also tagging routes/road reference if we desire to have each
> unique USFS road/route have a unique OSM reference value.
>
> Cheers!
>
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Forest Routes

[Paul Johnson]

On Thu, Nov 29, 2018, 14:14 Kevin Broderick  Doesn't the Forest Service use FR for "Forest Road" at the reference? I'd
> think that, or NFR to distinguish from state forest roads, would be the
> more appropriate ref, as FS is ambiguous (it doesn't distinguish between a
> forest road and a forest trail).
>

Maybe on visitor brochures, but on signage they get keystone shields for
two digit routes and either a vertical or horizontal rectangle sign
(depending on whether or not motor vehicles are expected to travel) for
minor routes, and the numbers all constitute a single network regardless of
if it's a road or a trail.

I seem to recall when I lived near a national forest that TIGER and the
USGS would use Forest Service XX when spelling out major routes, and
National Forest Development XXX or NFD  on the minors.

In either case, most people that travel in or near national forests
regularly will find FS and NFD immediately recognizable.

>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Trunk versus motorway

[Paul Johnson]

On Thu, Nov 29, 2018, 00:17 Albert Pundt   or if the road becomes single-carriageway and isn't a super-2 (a
> controlled-access freeway in which only one carriageway is constructed with
> accommodation for the second later).
>

A controlled access single carriageway would also be a trunk, not a
motorway.  Basically motorways should only be things that meet current
Interstate guidelines except maybe for hard shoulders.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us