Re: [OSM-talk] Should we be mapping transformers and powerlines?

[Paul Johnson]

Ever been lost someplace where that's the only obvious set of fixed
landmarks?

On Wed, Jan 18, 2023 at 9:16 PM john whelan  wrote:

> Perhaps you could expand on the benefits of mapping them?
>
> Thanks John
>
> On Wed, Jan 18, 2023, 10:09 PM stevea,  wrote:
>
>> I'd like to say "oh, please..." because this seems a bit harsh.  But I
>> understand that people can be sensitive.
>>
>> But this is OSM and I'd like to believe we live in a world that is more
>> free rather than less free.  What's next, do we stop mapping pre-school or
>> kindergartens because they have children?
>>
>> Criminals are going to use maps, yes, that is going to happen.  We
>> mappers ourselves are not criminals for mapping.
>>
>> Map.  Map well.  Criminals will be criminals.  While there are book
>> banning people, librarians are not criminals.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-transit] Several stations in a stop_area

[Paul Johnson]

On Sat, Jan 22, 2022 at 6:38 AM Alexey Z via Talk-transit <
talk-transit@openstreetmap.org> wrote:

>
> Hello.
>
> Let me raise a question/appeal about stop_area relation. PTv2 is very
> disputable and imperfect, so I tried to touch a narrow and practical aspect
> to solve a specific problem. I really hope for your help to make the OSM PT
> data truly useful for data consumers.
>
> This is the description of the problem with pictures:
>
> https://wiki.openstreetmap.org/wiki/Talk:Tag:public_transport%3Dstop_area#Several_stations_in_a_stop_area
>
> This is the problematic stop_area:
> https://www.openstreetmap.org/relation/7672142
>

I'm generally inclined to believe Trimet (who had been developing transit
data feeds for at least a decade before their data format became the GTFS
standard) more or less knows what they're doing with a resource they
created, and PT2 is largely based on that.  Within that context, can you
give the cliff notes on what your proposal is that is substantively
different?
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[Paul Johnson]

On Mon, Dec 14, 2020 at 1:51 PM ipswichmapper--- via talk <
talk@openstreetmap.org> wrote:

> You are right. If updating to mailman 3 will take monrhs of work it is
> probably not worth trying to make any changes right now.
>

Recurring OpenStreetMap theme:  If fixing something takes absolutely any
effort at all, then it's not worth doing, even if the effort already is
underway.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] FLOSS alt? | Re: reddit AMA with some OSMF Board members. 15:00Z 9 Nov

[Paul Johnson]

On Fri, Oct 30, 2020 at 5:03 AM Rory McCann  wrote:

> On Fri, 30 Oct 2020, at 10:04 AM, Martin Koppenhoefer wrote:
> > Rory, I am absolutely sure there was no bad intent in the choice of
> > format and platform, but given where this discussion went so fast, I
> > believe the setting should be reconsidered, evaluating the possibility
> > of choosing an open platform.
>
> Hmm, I do want to support open channels. Do you have an idea of an
> alternative?
>

I may be biased, but how about the fediverse?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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: [OSM-talk] Big Blue Button download

[Paul Johnson]

On Thu, Sep 17, 2020 at 1:41 PM Rory McCann  wrote:

> On Thu, 17 Sep 2020, at 8:21 PM, Clifford Snow wrote:
> > Can you confirm that we can leave the recordings on the server and are
> > able to link to the recordings for other sites, like the wiki?
>
> No, you can't rely on it like that. We only have limited storage space.
> Alas, we cannot offer a video hosting service like this. You should use a
> proper service for that.
>
> I merely said that AFAIK, *these* videos hadn't been explicitly deleted.
>

Isn't the default in BBB for it to automatically delete recordings after
two weeks?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Paul Johnson]

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

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

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

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

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: [OSM-talk] This needs to be voted upon. (was: Re: Separating all metadata from coordinates in OSM into a wikibase instance)

[Paul Johnson]

On Mon, Aug 10, 2020 at 1:03 AM Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

> Before going to vote it would need to demonstrate some sort of clear
> benefit and
> consensus that it is reasonable.
>

For this, as well as my take on this
, is why I'm
also a hard no on this.  This is a solution looking for a problem that will
only create a bigger series of problems.  We already have bigger problems,
like making lanes=* actually pass on the ground verifiability in situations
where there's bicycle or motorcycle lanes.  Or killing ref=* on ways as a
method of describing road routes in favor of relations.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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: [OSM-talk] Proper use of route relations?

[Paul Johnson]

On Sat, Aug 1, 2020 at 11:24 AM Mike Thompson  wrote:

> I have come across a number of examples[0] of route relations where all
> the trails in a given park have been put into a single relation.  Is this a
> recommended use for route relations?
>

Nope.  It's wrong.  Each route should have its own relation.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Paul Johnson]

Doesn't OpenStreetCam have similar corporate ownership problems, with the
additional problematic aspect that the toolchain's been neglected since
Telenav cut 'em loose?

On Thu, Jun 18, 2020 at 6:23 PM Niels Elgaard Larsen 
wrote:

> Paul Johnson:
> > Great.  How's this affect those of us who trust Facebook about as far as
> we can throw it?
>
>
> Use openstreetcam
>
>
> Start downloading all you images from Mapillary, if you did not keep a
> copy-
>
>
> But I think most important, use existing Mapillary photos to improve OSM
> with speed
> limits, surfaces, lit, etc.
>
>
>
>
> >
> > On Thu, Jun 18, 2020 at 5:37 PM Sérgio V.  > <mailto:svo...@hotmail.com>> wrote:
> >
> >
> https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6
> >
> >
> > - - - - - - - - - - - - - - - -
> >
> > Sérgio - http://www.openstreetmap.org/user/smaprs
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org <mailto:talk@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
>
> --
> Niels Elgaard Larsen
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Paul Johnson]

Great.  How's this affect those of us who trust Facebook about as far as we
can throw it?

On Thu, Jun 18, 2020 at 5:37 PM Sérgio V.  wrote:

>
> https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Talk-us] fake, edit, fake map.

[Paul Johnson]

Yeah, there's plenty that's wrong with Amazon's mapping (like basically
just straight out importing GPX from Amazon trucks and not bothering to
check for completeness or alignment at all, something I routinely see).
But armchair mapping in and of itself isn't the problem.


On Tue, Jun 16, 2020 at 12:54 PM Hauke Stieler 
wrote:

> I made edits from 2000km away from where I live. But I was there on
> vacation. It's possible that these editors were there, even if they
> aren't locals ;)
>
> Just be happy about good edits in your region and talk to them if you
> have something to discuss.
>
> Hauke
>
> On 16.06.20 19:24, 80hnhtv4agou--- via talk wrote:
> > i am trying to make a point here about editors that are 100 of miles
> away.
> >
> >
> >
> > Tuesday, June 16, 2020 12:20 PM -05:00 from Clay Smalley
> > :
> >
> > Not sure what it is you're trying to point out here. Have you
> > started a conversation with the person who made that edit?
> >
> > On Tue, Jun 16, 2020 at 9:11 AM 80hnhtv4agou--- via Talk-us
> >  > >
> > wrote:
> >
> > Added a service road.
> >
> > Edited about  hours ago by
> >
> > Version #1 · Changeset #86698283
> >
> >
> > https://imgur.com/gallery/k6Zjnqm
> >
> >
> >
> >
> > ___
> > Talk-us mailing list
> > talk...@openstreetmap.org
> >  e.mail.ru/compose/?mailto=mailto%3atalk%2...@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk-us
> >
> > ___
> > Talk-us mailing list
> > talk...@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-us
> >
> >
> >
> >
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Large cadastral polygons

[Paul Johnson]

On Fri, Jun 12, 2020 at 6:32 PM Warin <61sundow...@gmail.com> wrote:

> On 13/6/20 1:37 am, Paul Johnson wrote:
>
> On Fri, Jun 12, 2020 at 10:28 AM Florian Lohoff  wrote:
>
>> On Fri, Jun 12, 2020 at 02:14:15PM +0200, Mateusz Konieczny via talk
>> wrote:
>> >
>> >
>> >
>> > Jun 12, 2020, 13:59 by f...@zz.de:
>> >
>> > > Changeset envelopes which span more than 100s of km² are broken.
>> > >
>> > Except cases where you edit/delete already created huge objects or you
>> create
>> > huge object that actually should be created.
>> >
>>
>> These types of objects should be pretty exceptional. I try to split
>> landuses to sub 1km² because i also feel the pain for
>> rendering tiles. As soon as someone touches those areas you invalidate
>> tons of tiles. So breaking this down also benefits us long term
>> concerning workload on the tile servers.
>>
>
> Not just that, but cadastral type tags probably shouldn't be spanning
> large areas to start with.  If your landuse or landcover polygon is
> crossing an unclassified or higher highway, you're probably making a big
> mistake.  landuse=residential is NOT a substitute for place=neighborhood
> (something I see a lot).
>
>
> Hummm.. the following military areas are used as a rocket test firing
> area. Spiting them up into 1 km square areas would be a lot of work! Total
> area is approximately 122,188 km².
>

Odds are that's a single parcel.  Nobody's expecting that to get broken
up.  But when you have landuse=residential spanning entire city districts,
or entire towns and crossing other landuses like retail, commericial,
industrial, highway and railway, that's clearly a misuse.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?

[Paul Johnson]

On Fri, Jun 12, 2020 at 10:31 AM Florian Lohoff  wrote:

> On Fri, Jun 12, 2020 at 03:45:17PM +0200, Frederik Ramm wrote:
> > Hi,
> >
> > On 12.06.20 15:22, Dave F via talk wrote:
> > > There is a lot of negativity about large changsets, but assessment of
> > > them should be based on quality, not quantity.
> >
> > Yes, we're not discussing a popup that says "You dumbass, why did you
> > create a world-spanning changeset?" ;)
> >
> > The way in which editors deal with that would likely differ; in JOSM it
> > might be a popup that says "are you sure?" and in ID it might be a
> > floating warning somewhere.
>
> I'd rather let josm not download additional data in some distant
> spot as long as you have unpushed changes.
>

There's some legitimate edge cases for doing this, but I'd say slightly
more often than not when I do this, it's because I was on the wrong layer
and didn't expect to.  A warning that you're not on the layer you think you
are if there's another data layer that's closer that isn't the active layer
would help.

This isn't unique to JOSM, though.  This is *easily* doable with iD as well
(as evidenced by watching OSMCha with a bbox edged on Oklahoma's maximum
extents, Amazon Logistics does this a good 3-4 times a day every day with
changesets spanning the continent).  And I've done it in Vespucci by
accident.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Large cadastral polygons

[Paul Johnson]

On Fri, Jun 12, 2020 at 10:28 AM Florian Lohoff  wrote:

> On Fri, Jun 12, 2020 at 02:14:15PM +0200, Mateusz Konieczny via talk wrote:
> >
> >
> >
> > Jun 12, 2020, 13:59 by f...@zz.de:
> >
> > > Changeset envelopes which span more than 100s of km² are broken.
> > >
> > Except cases where you edit/delete already created huge objects or you
> create
> > huge object that actually should be created.
> >
>
> These types of objects should be pretty exceptional. I try to split
> landuses to sub 1km² because i also feel the pain for
> rendering tiles. As soon as someone touches those areas you invalidate
> tons of tiles. So breaking this down also benefits us long term
> concerning workload on the tile servers.
>

Not just that, but cadastral type tags probably shouldn't be spanning large
areas to start with.  If your landuse or landcover polygon is crossing an
unclassified or higher highway, you're probably making a big mistake.
landuse=residential is NOT a substitute for place=neighborhood (something I
see a lot).

If you have reasonably high resolution (like, at least Esri Clarity in the
midwest) imagery available, it's often possible to see lot stakes and
fenceposts on property boundaries...that seems like a reasonable edge for a
landuse polygon.  Also makes it easier to deal with landuse changes in the
future, as lots rarely change shape, more commonly get subdivided or
consolidated; that's a trivial change.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?

[Paul Johnson]

On Fri, Jun 12, 2020 at 6:07 AM Frederik Ramm  wrote:

> I wonder if it would be feasible or desirable for editors to warn users
> if they are at risk of creating country/world-spanning changesets.
> Something like "you have unsaved edits more than 500km away from where
> you are editing at the moment, please upload those before you continue"
> or so.
>

I don't see why it would be unfeasible.  I do see it being desirable.
Maybe dial it back to about 50km though, changesets spanning more than 3 or
4 kilometers without having a fairly tight and obvious scope are a pain to
QA.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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: [OSM-talk] CyclOSM Lite a new cycling infrastructure map layer

[Paul Johnson]

On Tue, May 26, 2020 at 10:22 AM James  wrote:

> and if pedestrians are allowed on it:
>
> highway=path
> segregated=no
>

Maybe.  If it clearly has lanes marked out, I tend to consider this a
cycleway even if there's no sidewalk as it was clearly built for bicycles a
forethought with minimal, if any, consideration for pedestrians in such a
case.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

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

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: [OSM-talk] Taking a break and a call for help

[Paul Johnson]

On Sat, Mar 21, 2020 at 11:37 AM Jmapb  wrote:

> I try to keep an eye on them and fix the errors and the most egregious
> road geometry. When I leave changeset comments, they generally reply,
> but there are so many of them that it feels like trying to cook rice one
> grain at a time.


Very much this.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

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

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

Re: [OSM-talk] Flashing school speed limit sign

[Paul Johnson]

On Wed, Mar 11, 2020 at 9:59 PM Andrew Harvey 
wrote:

>
>
> On Thu, 12 Mar 2020 at 12:51, Paul Johnson  wrote:
>
>> On Wed, Mar 11, 2020 at 8:23 PM Jack Armstrong 
>> wrote:
>>
>>> How would this be tagged? I can't seem to find anything about this on
>>> the wiki. Perhaps I'm just not looking in the right place. Thanks.
>>>
>>
>> The sign itself would be highway=traffic_sign, traffic_sign=maxpseed,
>> maxspeed=traffic_signals.  For the school zone on the way, that would be
>> maxspeed=* (whatever the maxspeed is normally when it's not in effect),
>> and maxspeed:variable=school_zone.
>>
>
> That looks good but how would you mark the variable speed as 20mph? I've
> seen people use something along the lines of `maxspeed:conditional=80 @
> wet` to indicate the lower speed for maxspeed:variable=weather, so
> something similar could be used here.
>

To my knowledge, there's no way to accurately represent that at this time.
Nor could data consumers reasonably use that information, as far as I can
tell.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Flashing school speed limit sign

[Paul Johnson]

On Wed, Mar 11, 2020 at 8:23 PM Jack Armstrong 
wrote:

> How would this be tagged? I can't seem to find anything about this on the
> wiki. Perhaps I'm just not looking in the right place. Thanks.
>

The sign itself would be highway=traffic_sign, traffic_sign=maxpseed,
maxspeed=traffic_signals.  For the school zone on the way, that would be
maxspeed=* (whatever the maxspeed is normally when it's not in effect), and
maxspeed:variable=school_zone.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[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: [OSM-talk] Interstate naming in the United States

[Paul Johnson]

On Thu, Mar 5, 2020 at 10:32 AM Jack Armstrong 
wrote:

> I'm not an expert in the field of naming U.S. interstate highways. I'd
> like some opinions from others with more experience with this.
>
> A new OSM user has just "named" Interstate 25 (I-25) as the "CanAm
> Highway".
>

It's been a while since I've been on I 25, but at least as of then, I never
saw anything referring to it as such.


> As a native Coloradan, I can say I've never heard anyone refer to I-25 as
> the CanAm Highway. There is a Wikipedia page on the name. This highway
> might also be referred to as the PanAmerican Highway, but again, nobody in
> this region refers to it as such.
>

If it enjoys any kind of status beyond an informal collection of routes in
the US and Canada, I'm not aware of it.


> I suppose almost all U.S. interstate highways could be "named" the Dwight
> D. Eisenhower Interstate Highway. A few years ago a user "named" I-70 and
> I-25 in Colorado as the "Dwight D. Eisenhower Highway", which I deleted
> explaining to the user this was not how Coloradans referred to these
> interstates.
>

You're conflating the name of single roads with the name of the route
system of which they are members.  The name of a route doesn't necessarily,
and often is completely unrelated, to the names of the ways that are
members.  The name of the network (in this case, the network is officially
called "Dwight D. Eisenhower National System of Interstate and Defense
Highways") tends to be even further removed from what individual roads are
actually named.  I think there is a tunnel in that network, within
Colorado, named for Eisenhower, though.


> Before I (gently) approach the new user, what is the best way for this
> name to be tagged? I assume a relation is not the best answer. I would
> think alt_name, alt_name_1, alt_name_2, etc., is the best method?
>

For the pan-am/can-am, within the US, I question ground truth veracity, but
open to other opinions.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Web editors and lane rendering

[Paul Johnson]

On Tue, Feb 18, 2020 at 10:45 PM Mateusz Konieczny 
wrote:

>
>
> 19 Feb 2020, 05:27 by ba...@ursamundi.org:
>
> Could we get some lane editing/rendering in these editors to cut down on
> this kind of unintentionally erratic mapping?
>
> Not sure whatever Potlatch is still developed,
>

I would hope it is if it's still considered an available selection on the
website; if not, maybe it's time to retire that option.


> but have you checked whatever some simple form
> of displaying this tags is already requested for iD?
>

It's definitely not.  Here's what JOSM and what ID shows over the Bing
imagery at the same junction (I 405 at CA 22): https://imgur.com/a/j5Kz7PF
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Web editors and lane rendering

[Paul Johnson]

 I'm working on editing I 405 in Los Angeles, California for lane guidance,
and at almost 150 miles not counting ramps, it's a big effort to go
through, so it's taken enough time that others are editing around where I
started.  No big deal, I'm fine with that, *except...*

I'm consistently noticing users of Potlatch and Id are ignoring
placement=*, lanes=* and turn:lanes=* tags, reconnecting ramps I already
adjusted and tagged to connect much farther down in a place that disagrees
with what's going on in the lane tagging (and this will result in incorrect
guidance).

I'm curious if there's any reason that id and Potlatch don't render lanes
and placement tags.  I suspect the fact that they're not made obvious to
the user is the reason why mappers using these editors are seeming to
ignore something made quite obvious in JOSM.  Could we get some lane
editing/rendering in these editors to cut down on this kind of
unintentionally erratic mapping?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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: [OSM-talk] Teaching cyclists how to contribute to OSM

[Paul Johnson]

On Sun, Jan 19, 2020 at 6:28 PM john whelan  wrote:

> Locally in Ottawa many paths are multiuse there is a path many kilometers
> long along the Ottawa river that has a line marked down the center and is
> very much used by cyclists but according to NCC who own the path it is
> multi-use not bicycles only so is mapped highway=path.  Most City of Ottawa
> paths are the same, bicycles are permitted but they are not cycleways.
>

Generally speaking I'd consider that highway=cycleway, foot=yes.  Same with
the variation that has lanes but no sidewalks and clearly has pedestrians
walking on it in the Mapillary.  I'd consider it highway=path if it didn't
have lanes, even if it did have vehicle-oriented signage (consider the
older portions of the Westside Regional Trail in Oregon where it's
technically too narrow to have lanes.  Oregon-specific thing: Oregon allows
bicycle lanes to be 1.2m wide if the lane is adjacent only to another
bicycle lane in the same direction or a shoulder; if the bicycle lane is
adjacent to a lane that allows motor vehicles, or is adjacent to any kind
of lane in the opposite direction, then the minimum allowable lane width is
1.82m.  A lot of older MUPs in Oregon are ~3.0m wide, owing to when Oregon
considered all bicycle lanes to be 1.52m minimum, whereas newer MUPs mapped
as cycleways are 3.66m wide minimum.

This paragraph is Oregon-specific geekery and skippable. Springwater
Corridor in Gresham was widened to accomodate 4 lanes and the edge to edge
width is about 6.1m across, with the original intention to be the inside
lanes being about 1.82m wide and the shoulder lanes being 1.2m wide.  End
result, they didn't bother to mark any lanes (consistent with the Portland
segment of the cycleway, which is too narrow to have lanes, and as such the
lane markings haven't been maintained in over 20 years since the rules
changed, as the Springwater Corridor is too narrow to meet code in
Portland), effectively making it a two lane cycleway with 3 meter wide
lanes.  Only other places in Oregon where multiple same-direction bike
lanes come into play off the top of my head would be the Hawthorne Bridge
westbound (where there's a second, narrower bike lane against the curb for
slower cyclists on a hard climb on a street that frequently sees 30,000+
cyclists a day) and the Bush Pasture Parkway (deceptively named).  It's a 5
lane (formerly 8 lane) cycleway (the two middle lanes were converted to a
flush median since I moved away, but when they do soapbox races, my
understanding is they add a spraychalk stripe down the median) on a steep
hill and doesn't really go anywhere, and primarily exists as a soapbox
derby dragstrip (it's on a steep hill), but the city striped it as a
cycleway in order to be able to justify the tax expense.  On the other
hand, they're seriously future proof for when McColloch Stadium is
primarily accessed by bicycle!


> I worked with City of Ottawa bicycle specialist on this starting on why
> one path in a park was marked as a bicycle path whilst another in the same
> park of identical width was not.  Eventually we arrived at all paths except
> those that are marked no bicycles are multiuse paths ie bicycles are
> permitted.
>

Generally speaking on footway and cycleway, I will explicitly tag the most
common unusual mode.  So, footways that allow bicycles will get bicycle=yes
and cycleways that allow pedestrians will get foot=yes.  I tend to focus a
lot on intent on deciding on footway/path/cycleway.  If it's a true MUP
(like, say, Willamette Greenway in Portland), I'd tag that as highway=path
and bicycle=designated, foot=designated.

If it's a MUP but it's clear the intent was to favor cyclists (ie, formal
lanes, bicycle-specific signage, etc, but it allows pedestrians), then I'd
tag it as highway=cycleway, lanes=*, turn:lanes=* as appropriate,
foot=yes.  Examples would be the Creek Turnpike Trail in Tulsa, Liberty
Parkway Trail in Broken Arrow, Westside Regional Trail in Washington
County, Oregon, and others.

More rare in North America is a cycleway that doesn't allow pedestrians.
Examples would be the Riverparks Westbank and Eastbank cycleways in Tulsa
in specific segments, where foot=no is explicitly (redundantly) tagged.
Where these trails have pedestrian and bicycle facilities on the same
roadway but marked out, then highway=cycleway, segregated=yes,
foot=designated, bicycle=designated is appropriate (such as between the
Arkansas River and River Spirit Casino.

I might suggest Ottawa mappers take a look at the Riverparks Eastbank Trail
and Creek Turnpike Trails as examples.


> Multiuse means skateboards, wheelchairs, skis  etc.  We had 25 cms of snow
> today and many paths are not ploughed.  There aren't many conventional
> bicycles that can use the paths under these conditions.
>

Fortunately Tulsa tends to lack this problem, with cycleways generally
being plowed, often before surface streets are.
___
talk mailing list

Re: [OSM-talk] Teaching cyclists how to contribute to OSM

[Paul Johnson]

On Sat, Jan 18, 2020 at 5:06 PM James  wrote:

> Bike advocacy group in Ottawa created this:
>
>
> https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide/blob/master/README.md
>
> as well as a crowd sourced map like the one for winter bike trails that
> allows a user to submit if a path is winter maintained or not, it will then
> update OSM in the back end: maps.bikeottawa.ca
>

Did notice an error.  It's suggesting a cycleway with a sidewalk be tagged
as highway=path instead of highway=cycleway.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tag:man_made=embankment

[Paul Johnson]

On Wed, Jan 15, 2020 at 10:28 AM 80hnhtv4agou--- via talk <
talk@openstreetmap.org> wrote:

> What does this mean ?
>
> “should be tagged on a way drawn with the *lower side on right side* of
> way direction”
>

The downhill side of the embankment is to the right of the way.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Too subjective & problematic Re: no-go-areas

[Paul Johnson]

On Mon, Jan 13, 2020 at 6:34 PM Joseph Eisenberg 
wrote:

> In the USA a postal code is not actually an area, but a set of
> addresses. Often they are all in one area, but sometimes the area is
> not clearly defined. This is partially why postal codes are usually
> just added to the POI directly in the USA. Trying to make a sensible
> set of areas or boundaries will not work for all USPS postal codes.
>

For mailing addresses, yes.  For street addresses, maybe.  The Census does
have areas for their ZIP codes.  Whether a particular area uses Census or
Postal zips depends on whether or not they're served by the USPS directly
(and there's decent chunks that don't).  Edge case is super edge, though,
and the de-facto way of dealing with this is to just use the ZIP observed
on the address marker or ask someone who lives/works there what the ZIP is
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Too subjective & problematic Re: no-go-areas

[Paul Johnson]

On Sun, Jan 12, 2020 at 11:49 AM Mateusz Konieczny 
wrote:

>
>
>
> 12 Jan 2020, 18:39 by snusmumriken.map...@runbox.com:
>
> On Sun, 2020-01-12 at 08:35 -0600, Paul Johnson wrote:
>
>
>
> On Sun, Jan 12, 2020 at 1:47 AM Snusmumriken <
> snusmumriken.map...@runbox.com> wrote:
> > On Sat, 2020-01-11 at 21:22 +0100, Martin Trautmann via talk wrote:
> > > On 20-01-02 12:23, pangoSE wrote:
> > >
> > > > A map cannot solve a lack of general awareness when visiting a
> > > > new/unknown place. Going to the mountains to hike can also be
> > > > dangerous
> > > > if you are not well prepared. This is of course not marked on
> > the
> > > > map!
> > >
> > > I agree that I don't know any non-subjective way how to identify
> > such
> > > an
> > > area.
> >
> > Well, one could rely on authority, e.g. if a national police
> > authority
> > designated certain areas as high risk.
>
> Yeah, that's not really going to work, either. Just look at
> Portland. Most arrests happen in poor, black neighborhoods, but
> you're most likely to get hurt or killed in a suburban white area.
> Besides, if you really want to go that route, just composite their
> data as a layer over OpenStreetMap in Leaflet. There's no reason
> whatsoever to include it in OpenStreetMap's database.
>
>
> I understand that it would politically sensitive, but from a data-model
> point of view it doesn't really differ from postcode areas (under the
> assumption that there's an authority that designates some areas as
> high-risk areas)
>
> There is a single authority assigning
> postal codes.
>

Well, two in the US.


> Also, in general people are not disputing postal codes.
>

The US Census Bureau and the Postal Service, but that's their problem to
sort out; just putting city and state will still get your mail there and
it's specific enough to wayfind.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Too subjective & problematic Re: no-go-areas

[Paul Johnson]

On Sun, Jan 12, 2020 at 1:47 AM Snusmumriken 
wrote:

> On Sat, 2020-01-11 at 21:22 +0100, Martin Trautmann via talk wrote:
> > On 20-01-02 12:23, pangoSE wrote:
> >
> > > A map cannot solve a lack of general awareness when visiting a
> > > new/unknown place. Going to the mountains to hike can also be
> > > dangerous
> > > if you are not well prepared. This is of course not marked on the
> > > map!
> >
> > I agree that I don't know any non-subjective way how to identify such
> > an
> > area.
>
> Well, one could rely on authority, e.g. if a national police authority
> designated certain areas as high risk.
>

Yeah, that's not really going to work, either.  Just look at Portland.
Most arrests happen in poor, black neighborhoods, but you're most likely to
get hurt or killed in a suburban white area.  Besides, if you really want
to go that route, just composite their data as a layer over OpenStreetMap
in Leaflet.  There's no reason whatsoever to include it in OpenStreetMap's
database.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Too subjective & problematic Re: no-go-areas

[Paul Johnson]

On Sat, Jan 11, 2020 at 2:25 PM Martin Trautmann via talk <
talk@openstreetmap.org> wrote:

> On 20-01-02 12:23, pangoSE wrote:
>
> > A map cannot solve a lack of general awareness when visiting a
> > new/unknown place. Going to the mountains to hike can also be dangerous
> > if you are not well prepared. This is of course not marked on the map!
>
> I agree that I don't know any non-subjective way how to identify such an
> area.
>

OK, too subjective for OSM then.


> But a good map is for people who do NOT know this area.
> People who know about neither need a map nor a warning.
>

Not our problem, we map the objective.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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: [OSM-talk] no-go-areas

[Paul Johnson]

On Tue, Dec 31, 2019 at 12:10 PM Mark Wagner  wrote:

> On Tue, 31 Dec 2019 16:14:30 +0100
> Martin Trautmann  wrote:
>
> > hi all,
> >
> > did you read about the Suisse tourist couple which was shot because
> > they got lost in a Brasilian favela?
> >
> > NZZ (Neue Zürcher Zeitung) from Tuesday 31.12.2019. ("Schweizer
> > Ehepaar bei Irrfahrt duch Favela in Brasilien
> > angeschossen")
> >
> > Other examples are e.g. Mafia areas within Kosovo - or name your own
> > home town no-go area.
> >
> > Is there any option to mark certain areas in order to bypass routing
> > whenever possible?
> >
>
> The problem is that most of these "no-go" areas are subjective, both in
> boundary and in level of danger.  If you ask a half-dozen people, you
> might get a half-dozen responses ranging from "I go there all the time"
> to "The police don't patrol in less than platoon strength".
>

Yeah, I get this same impression.  This has the potential to rear its head
in a really classist, and varying ranges of racist, ways as well.  For
example, go post on Reddit on any given city's subreddit, and ask "I'm
moving to ___, what parts of town should I avoid?"  Fair warning, try this
for a city you're familiar with, and be prepared to die a little inside
with the answers you get.

Personally, I'm more likely to consider middle-class suburbia a no-go area
because large parking lots make it easy for car prowlers no matter how many
police are on the streets, transit coverage tends to be iffy before morning
and after evening peak commuter hours, and 5+-lane-wide boulevards tend to
be not-safe-for-life if you need to traverse them without using a car.
Your mileage may vary.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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