Re: [Talk-us] Trunk

[Evin Fairchild]

The concept of expressway is not as well known as a freeway. Many people,
especially in places like NYC, might consider expressways and freeways to
be interchangeable terms. Heck, even in Tulsa, you have the Broken Arrow
Expressway, and the Sand Springs Expressway, which, despite being called
expressways, have full access control and no at-grade intersections and no
places where one crosses into oncoming traffic.

Also, as for super-twos, let's not discuss that right now. I'd prefer us to
stick to talking about trunk roads *only*, since that's the topic of this
thread. Let's not go on that tangent, and I'd like to know what you think
about how the standard Mapnik render differentiates between undivided and
divided trunk roads. It's a pretty obvious distinction to me, and you can
*easily* tell the two apart. If anything, I think that that helps us out
here.

On Fri, Oct 13, 2017 at 9:26 PM, Paul Johnson  wrote:

> On Fri, Oct 13, 2017 at 11:00 PM, Evin Fairchild 
> wrote:
>
>> Another thing worth adding is that if we do decide to tag two-lane roads
>> as trunk, you will still be able to tell the undivided two-lane roads apart
>> from the divided four-lane roads, even at zoom 5. I'm sure many of you have
>> noticed if you've looked at Canada at zoom 5, you can see that some of the
>> trunks are thicker than others. If you zoom in more, you'll notice that
>> said thicker roads are divided/ dual carriageway, whereas the thinner ones
>> are undivided roads. Also, the same is true with motorways, so we could
>> theoretically tag super-twos as motorways and still tell them apart from
>> actual Interstate freeways. This has been done extensively in New Brunswick
>> and Nova Scotia, and I quite like it. But we probably shouldn't go down
>> that rabbit hole at this point...
>>
>
> I also disagree with the idea that (at least in the US, though also
> relevant to the rest of North America to a lesser extent) a super-2
> qualifies as a motorway.  I generally consider the minimum requirements for
> motorway as dual carriageway, with each carriageway having a minimum of two
> lanes, barring temporary traffic controls (such as a reduction to one lane
> each way, undivided, very common when a DOT needs to restrict access
> completely to one motorway for routine maintenance or immediately after a
> major disaster; most frequently personally experienced in California,
> Oklahoma and Kansas, and routinely planned for to the extent that permanent
> crossover "X" links are installed regularly in Kansas and Oklahoma).
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Paul Johnson]

On Fri, Oct 13, 2017 at 11:00 PM, Evin Fairchild 
wrote:

> Another thing worth adding is that if we do decide to tag two-lane roads
> as trunk, you will still be able to tell the undivided two-lane roads apart
> from the divided four-lane roads, even at zoom 5. I'm sure many of you have
> noticed if you've looked at Canada at zoom 5, you can see that some of the
> trunks are thicker than others. If you zoom in more, you'll notice that
> said thicker roads are divided/ dual carriageway, whereas the thinner ones
> are undivided roads. Also, the same is true with motorways, so we could
> theoretically tag super-twos as motorways and still tell them apart from
> actual Interstate freeways. This has been done extensively in New Brunswick
> and Nova Scotia, and I quite like it. But we probably shouldn't go down
> that rabbit hole at this point...
>

I also disagree with the idea that (at least in the US, though also
relevant to the rest of North America to a lesser extent) a super-2
qualifies as a motorway.  I generally consider the minimum requirements for
motorway as dual carriageway, with each carriageway having a minimum of two
lanes, barring temporary traffic controls (such as a reduction to one lane
each way, undivided, very common when a DOT needs to restrict access
completely to one motorway for routine maintenance or immediately after a
major disaster; most frequently personally experienced in California,
Oklahoma and Kansas, and routinely planned for to the extent that permanent
crossover "X" links are installed regularly in Kansas and Oklahoma).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Paul Johnson]

On Fri, Oct 13, 2017 at 10:19 PM, Bradley White 
wrote:

> > Message: 4
> > Date: Fri, 13 Oct 2017 21:24:20 -0500
> > From: Paul Johnson 
> > To: OpenStreetMap talk-us list 
> > Subject: Re: [Talk-us] Trunk
> > Message-ID:
> > 

Re: [Talk-us] Trunk

[Evin Fairchild]

Another thing worth adding is that if we do decide to tag two-lane roads as
trunk, you will still be able to tell the undivided two-lane roads apart
from the divided four-lane roads, even at zoom 5. I'm sure many of you have
noticed if you've looked at Canada at zoom 5, you can see that some of the
trunks are thicker than others. If you zoom in more, you'll notice that
said thicker roads are divided/ dual carriageway, whereas the thinner ones
are undivided roads. Also, the same is true with motorways, so we could
theoretically tag super-twos as motorways and still tell them apart from
actual Interstate freeways. This has been done extensively in New Brunswick
and Nova Scotia, and I quite like it. But we probably shouldn't go down
that rabbit hole at this point...

-Evin (Compdude)

On Fri, Oct 13, 2017 at 8:41 PM, Dave Swarthout 
wrote:

> >Can you explain what your goal/desire is for these non-divided highways
> >to be labeled trunk?  Is it about a small-scale render showing them,
> >when if they are primary, Alaska looks empty when it shouldn't?  Some
> >sense of hierarchical views of road networks?  Something else?
>
> @Bradley - I didn't tag them originally and don't particularly care how
> they're tagged. Routing in rural Alaska is pretty simple because there's
> only one way to get from Anchorage to Fairbanks and to Homer, where I live
> LOL. That's why I prefaced my comment by saying I have no stake in the
> outcome of this conversation. I only want to stay tuned in so I can
> understand any changes to our rationale.
>
> Dave
>
> On Sat, Oct 14, 2017 at 10:19 AM, Bradley White 
> wrote:
>
>> > Message: 4
>> > Date: Fri, 13 Oct 2017 21:24:20 -0500
>> > From: Paul Johnson 
>> > To: OpenStreetMap talk-us list 
>> > Subject: Re: [Talk-us] Trunk
>> > Message-ID:
>> > 

Re: [Talk-us] Trunk

[Dave Swarthout]

>Can you explain what your goal/desire is for these non-divided highways
>to be labeled trunk?  Is it about a small-scale render showing them,
>when if they are primary, Alaska looks empty when it shouldn't?  Some
>sense of hierarchical views of road networks?  Something else?

@Bradley - I didn't tag them originally and don't particularly care how
they're tagged. Routing in rural Alaska is pretty simple because there's
only one way to get from Anchorage to Fairbanks and to Homer, where I live
LOL. That's why I prefaced my comment by saying I have no stake in the
outcome of this conversation. I only want to stay tuned in so I can
understand any changes to our rationale.

Dave

On Sat, Oct 14, 2017 at 10:19 AM, Bradley White 
wrote:

> > Message: 4
> > Date: Fri, 13 Oct 2017 21:24:20 -0500
> > From: Paul Johnson 
> > To: OpenStreetMap talk-us list 
> > Subject: Re: [Talk-us] Trunk
> > Message-ID:
> > 

Re: [Talk-us] Trunk

[Bradley White]

> Message: 4
> Date: Fri, 13 Oct 2017 21:24:20 -0500
> From: Paul Johnson 
> To: OpenStreetMap talk-us list 
> Subject: Re: [Talk-us] Trunk
> Message-ID:
> 

Re: [Talk-us] Trunk

[Paul Johnson]

On Fri, Oct 13, 2017 at 9:53 PM, Evin Fairchild  wrote:
>
> Soon after I first joined OSM, NE2 changed a US highway near me from
> primary to trunk which another user quickly reverted, but I actually agreed
> with the change to trunk. The road I'm referring to, BTW, is US 2 in
> Washington. It's mostly just two lanes, (it really could use four lanes,
> particularly between Snohomish and Gold Bar) but it is the second most
> important route over the Cascades in Washington, after I-90. Thus, it ought
> to be a trunk road.
>

The Super2 parts of US 2 were being upgraded to Trunk was valid, but not
the single carriageway, uncontrolled access parts.


> And I still do think that many US highways should be tagged as trunk for
> the most part, except when they parallel a freeway or other road with a
> higher capacity. After all, not every pair of large towns and cities (I'm
> talking anything with a population greater than 25,000 or more) will be
> connected by a freeway or expressway, even if they have traffic counts that
> are close to that of some rural interstates.
>

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

Re: [Talk-us] Low-quality NHD imports

[Clifford Snow]

On Fri, Oct 13, 2017 at 10:34 AM, Christoph Hormann  wrote:

> On Friday 13 October 2017, Kevin Kenny wrote:
> >
> > I remain unconvinced that importing or not importing has had any
> > significant impact on whether people improve the map manually.
>
>
> There are a number of possible measures that could be considered for
> improving old NHD imports:
>
> * removal of unnecessary tags to reduce the baggage mappers would have
> to deal with when working on the data.
> * removal of small unnamed streams which are not necessary for the
> overall river network connectivity in areas where the geometric
> accuracy is poor by current standards (and it is therefore usually
> easier for mappers to newly trace those streams instead of trying to
> improve the inaccurate data)
>


Unnamed streams are helpful to people hiking in the forest areas by giving
a landmark for navigation. From areas I'm familiar with, there are
thousands of unnamed streams. They are unnamed because civilization just
hasn't reached it. For example, we have Logan Creek nearby. If it was in a
national forest it would most likely be unnamed.


* creating maproulette challenges for fixing inaccurate waterway
> classifications - in particular waterways tagged 'waterway=stream' but
> with a name containing 'Creek' or 'River' will often qualify as
> waterway=river.  Same for artificial waterways with 'waterway=ditch'
> but names containing 'Canal' or ther other way round.
>

When I see creek in the name, it implies stream, at least in areas I'm
familiar with, then again that's where I usually map. I'm not sure where
you are from but I never consider telling you how to classify something
just by the name. A Maproulette could be handy if we had NHD classification
differences between what't tagged in OSM and NHD.

* creating maproulette challenges for unconnected waterways.
>

+1


> * adding missing 'intermittent=yes' to waterways in imports where this
> was not properly set based on the feature codes.
>

+1


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

On Oct 13, 2017 7:11 PM, "Bradley White"  wrote:

Lots of words ahead, you have been warned...

I disagree with trying to use the "highway=" tag to describe what
"kind" of road a given way is in the US, except for freeways. The
"highway" key is for importance, or, how prominently a road should
show on the map. We have other tags to describe completely the
physical attributes of a road. If there existed an "if-then" algorithm
to determine how prominently a road should show on the map only from
physical attributes, we wouldn't need this tag at all.

But we do. The U.S. needs this tag because form often does not follow
function. There are many plain-old two-lane roads that are important
enough for cross-country navigation that they should show at low zoom
along with the interstate system. There are also countless high-speed,
high-access-control (no driveways, limited intersections), multi-lane,
divided arteries that do little more than connect suburbs to more
important roads. These roads do NOT need to show at low zoom, despite
being a high-quality road.

Consider instead that we trade off "highway=motorway" with
"highway=1", "highway=trunk" with "highway=2", etc., which represents
only the importance of a road in the network. In the US, it is fair to
take freeways as an entire class to be the most important roads. A
freeway has strict & verifiable physical criteria (aside from a small
fringe set of exceptions), they are signposted and unambiguous, it is
a term well-understood in common vernacular that the average map
consumer would expect to see shown on a map, and they are nearly
always THE most important roads in the area. It is easy to say both
that "this is a freeway" and that "these are the most important kinds
of roads". In fact, this is the case in nearly all developed countries
on the planet. So, we instead define "highway=1" to just be
"highway=motorway" since it is nearly always the same thing.

In Europe, it would also be fair to use "highway=2" to simply
represent expressways as a class. Expressways (in the countries that
have expressway systems) are built to a verifiable design criteria,
are signposted and unambiguous (see:
https://en.wikipedia.org/wiki/Limited-access_road), are something the
average map consumer in the area is both familiar with and would
expect to see on a map, and are nearly always second in importance to
the motorway system. Again, it is easy to say both that "this is an
expressway" and "this is the second most important kind of roads". So,
in countries that have designated expressway systems, they define
"highway=2" to just be "highway=trunk" since it is nearly always the
same thing.

This situation is NOT the case for the majority of the US, and trying
to use this definition is what has been leading to unresolved
confusion about the purpose of the trunk tag. MUTCD gives a definition
of "divided highway with partial control of access". This is rather
vague, and as stated above, means countless unimportant suburban
arteries would now be considered the second most important roads in
the country. Many states haven't even adopted usage of this term at
all. I have seen planning documents of some counties that have
multiple grades of "expressways" depending on intersection distance,
speed limits, etc. Outside of bona-fide urban expressway systems like
the Santa Clara Expressway system, I think it's a nearly meaningless
term.

I have heard two kinds of attempts to describe what constitutes an
expressway and thus a trunk road in the US. The first attempt is the
"it's like a freeway but only kind of" definition. I don't like this
definition because if we're going to trade off an entire class of
importance with an entire class of road design, we should at least be
perfectly clear about what kinds of roads we are talking about, as we
are with freeways. The second attempt is to establish some kind of
verifiable physical criteria: divided, minimum 45 mph speed limit,
limited intersections, maybe has grade-separated interchanges. There
are also many problems with this approach. As discussed above, it
grades swaths of overbuilt roads as being more important that they
actually are. It makes roads that are crucial for navigation but don't
meet an arbitrary checklist difficult to pick out from the sea of
primary roads that the rural US currently exhibits. Furthermore, it
leads to the current situation of random splotches of deep-orange
lines visible at the same level as the interstate system scattered
across the US, which provides absolutely no meaning to the average
US-based map consumer. Being frank, I can't understand at all why
anyone considers the current state of trunk road tagging in rural
parts of the US desirable or useful or illuminating at all.

I propose defining trunk in the US to mean, formally, "The most
important non-motorway roads in the country". An extended definition
for the US follows below:

--
Trunk roads are the 

Re: [Talk-us] Trunk

[Paul Johnson]

On Fri, Oct 13, 2017 at 9:10 PM, Bradley White 
wrote:
>
> This situation is NOT the case for the majority of the US, and trying
> to use this definition is what has been leading to unresolved
> confusion about the purpose of the trunk tag. MUTCD gives a definition
> of "divided highway with partial control of access". This is rather
> vague, and as stated above, means countless unimportant suburban
> arteries would now be considered the second most important roads in
> the country. Many states haven't even adopted usage of this term at
> all. I have seen planning documents of some counties that have
> multiple grades of "expressways" depending on intersection distance,
> speed limits, etc. Outside of bona-fide urban expressway systems like
> the Santa Clara Expressway system, I think it's a nearly meaningless
> term.
>

I would tend to give AASHTO, NACTO and especially USDOT documents to be
authoritative when it comes to defining documents for US transportation,
however, this may be coming from getting into civil engineering in Oregon
where expressways and freeways are using the MUTCD definitions quite
strictly, making the trunk situation more obvious.  Also, hence my
frustration with how WA 500 is being handled in Vancouver; every time
someone updates it to be trunk from I 5 to Fourth Plain, someone updates it
to being a checkerboard of motorway again.  Idiots...


> --
> Trunk roads are the most important non-motorway roads in the country.
> These roads connect major population centers and are crucial to the
> transportation network as a whole, acting as a supplement to the
> interstate system for cross-country travel. They are usually US
> highways, but may be of other designation as well.
>
> In rural areas, these roads often - but not always - are built with
> expressway features (divided carriageway, access control,
> grade-separated interchanges) at some or all portions of the road.
> Often, these roads will circumvent towns along the route, but they may
> also penetrate towns as an important road ("Main Street"s), in which
> case it is to remain trunk.
>
> In urban areas, most expressway systems should be tagged trunk,
> especially if they serve as an important artery through the city not
> already served by a freeway. If a trunk road enters from rural into
> urban, in general it should remain trunk until it connects with a more
> important road (motorway), or passes through the city completely (as
> an exception, cases where the city IS the important destination may
> end the trunk designation at the city). Very minor expressway systems
> that serve small population centers or destinations should NOT be
> tagged as trunk; instead consider using a lower classification of road
> along with "motorroad=".
> --
>

I reject this because it will lead to an overemphasis of relatively smaller
roads.  Including primary at lower zooms might help what you're referring
to as being splotchiness with trunks in rural areas.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Bradley White]

Lots of words ahead, you have been warned...

I disagree with trying to use the "highway=" tag to describe what
"kind" of road a given way is in the US, except for freeways. The
"highway" key is for importance, or, how prominently a road should
show on the map. We have other tags to describe completely the
physical attributes of a road. If there existed an "if-then" algorithm
to determine how prominently a road should show on the map only from
physical attributes, we wouldn't need this tag at all.

But we do. The U.S. needs this tag because form often does not follow
function. There are many plain-old two-lane roads that are important
enough for cross-country navigation that they should show at low zoom
along with the interstate system. There are also countless high-speed,
high-access-control (no driveways, limited intersections), multi-lane,
divided arteries that do little more than connect suburbs to more
important roads. These roads do NOT need to show at low zoom, despite
being a high-quality road.

Consider instead that we trade off "highway=motorway" with
"highway=1", "highway=trunk" with "highway=2", etc., which represents
only the importance of a road in the network. In the US, it is fair to
take freeways as an entire class to be the most important roads. A
freeway has strict & verifiable physical criteria (aside from a small
fringe set of exceptions), they are signposted and unambiguous, it is
a term well-understood in common vernacular that the average map
consumer would expect to see shown on a map, and they are nearly
always THE most important roads in the area. It is easy to say both
that "this is a freeway" and that "these are the most important kinds
of roads". In fact, this is the case in nearly all developed countries
on the planet. So, we instead define "highway=1" to just be
"highway=motorway" since it is nearly always the same thing.

In Europe, it would also be fair to use "highway=2" to simply
represent expressways as a class. Expressways (in the countries that
have expressway systems) are built to a verifiable design criteria,
are signposted and unambiguous (see:
https://en.wikipedia.org/wiki/Limited-access_road), are something the
average map consumer in the area is both familiar with and would
expect to see on a map, and are nearly always second in importance to
the motorway system. Again, it is easy to say both that "this is an
expressway" and "this is the second most important kind of roads". So,
in countries that have designated expressway systems, they define
"highway=2" to just be "highway=trunk" since it is nearly always the
same thing.

This situation is NOT the case for the majority of the US, and trying
to use this definition is what has been leading to unresolved
confusion about the purpose of the trunk tag. MUTCD gives a definition
of "divided highway with partial control of access". This is rather
vague, and as stated above, means countless unimportant suburban
arteries would now be considered the second most important roads in
the country. Many states haven't even adopted usage of this term at
all. I have seen planning documents of some counties that have
multiple grades of "expressways" depending on intersection distance,
speed limits, etc. Outside of bona-fide urban expressway systems like
the Santa Clara Expressway system, I think it's a nearly meaningless
term.

I have heard two kinds of attempts to describe what constitutes an
expressway and thus a trunk road in the US. The first attempt is the
"it's like a freeway but only kind of" definition. I don't like this
definition because if we're going to trade off an entire class of
importance with an entire class of road design, we should at least be
perfectly clear about what kinds of roads we are talking about, as we
are with freeways. The second attempt is to establish some kind of
verifiable physical criteria: divided, minimum 45 mph speed limit,
limited intersections, maybe has grade-separated interchanges. There
are also many problems with this approach. As discussed above, it
grades swaths of overbuilt roads as being more important that they
actually are. It makes roads that are crucial for navigation but don't
meet an arbitrary checklist difficult to pick out from the sea of
primary roads that the rural US currently exhibits. Furthermore, it
leads to the current situation of random splotches of deep-orange
lines visible at the same level as the interstate system scattered
across the US, which provides absolutely no meaning to the average
US-based map consumer. Being frank, I can't understand at all why
anyone considers the current state of trunk road tagging in rural
parts of the US desirable or useful or illuminating at all.

I propose defining trunk in the US to mean, formally, "The most
important non-motorway roads in the country". An extended definition
for the US follows below:

--
Trunk roads are the most important non-motorway roads in the country.
These roads connect major 

Re: [Talk-us] Davis Senior High School, California

[Andy Townsend]

On 12/10/2017 18:45, David Kewley wrote:
I've just now sent an email through the school's portal to Mr. 
Birdsall, asking whether he can help. I live in California, and have 
met folks from Davis, but don't have enough of a personal connection 
to go a more direct route.


David


Thanks for that.  We'll see what happens next...

Best Regards,

Andy


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

Re: [Talk-us] Trunk

[Doug Peterson]

> Date: Fri, 13 Oct 2017 11:59:11 -0600
> From: Martijn van Exel 
> Subject: Re: [Talk-us] Trunk
>
> Hi all,
> 
> I haven't abandoned this thread or thinking about it. It has just taken me
> a while to read through all the diary comments + what is being said in this
> thread. I intend to follow up with another diary post where I try to
> collect this smart crowd's thoughts and suggestions, but it will probably
> not until after State of the Map US that I get to this.
> 
> In the mean time, I decided to test some of the ideas posted here on a real
> case: The part of Michigan SR 10 northwest of the I-696 interchange:
> https://www.openstreetmap.org/relation/252973#map=13/42.5132/-83.3168
> 
> Since 1) this road does not seem to serve an important connecting role in
> the long distance road network 2) the density of abutters and related
> driveway / parking exits I judged a downgrade warranted. Please discuss
> here or on https://www.openstreetmap.org/changeset/52903464 .
> 
> On the topic of tagging for the renderer, two things: 1) A US-specific
> rendering would be really neat 2) Trunk 'appendices' like the one I just
> downgraded do make rendering at low zooms tricky -- you end up with short
> segments that seem to end in nothing.
> 
> Martijn
> 

I'm not arguing the change.  I would point out that the bike lane now masks 
what functioned as basically an entrance / exit lane on the highway.  The 
abutting entrances were not an issue to maintaining highway speed on the road.  
They do not now with the bike lane.  The bike lane is basically treated the 
same way without apparent risk to the bikes as I have never seen one in it.  
That is a comment on what I think of the wisdom of overlaying a bike lane there 
for how the lane has functioned.

Northwestern Highway / M-10 is similar in nature and use to nearby Telegraph 
Road / US-24 which has been tagged as Primary since at least 2009.

Thank you,

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

Re: [Talk-us] Trunk

[Kevin Kenny]

On Fri, Oct 13, 2017 at 8:17 PM, Greg Troxel  wrote:
> Agreed mostly.  But I don't see primary/secondary as having anything to
> do with physical; we more or less defined that as US vs state long ago.

If you read the description on the Wiki, we defined no such thing, we
merely said it was an indication: 'primary' is "A major highway
linking large towns, in developed countries normally with 2 lanes. In
areas with worse infrastructure road quality may be far worse." and
then we say "U.S. Highways are *mostly* primary." (emphasis added).
And that's true largely because they were imported that way from
TIGER, for weal or woe.

Examples: US 6 between Port Jervis and Middletown, NY is really no
longer even primary. In that stretch it isn't the major highway
linking those towns. Interstate 84 now serves that role. US 6 is
maintained there chiefly as a detour route in case I-84 has to be
closed for some reason. I'm also not sure that I'd accord it 'primary'
farther east, between Woodbury and Bear Mountain, because it's
'hgv=no' and has a reduced speed limit in the park.

By contrast, NY 17 is a freeway. (It's signed, "Future I-86" in spots.
I'm not sure what's blocking the designation- it is I-86 farther
west.)  NY 5, on the north side of the Mohawk, is correctly labeled a
'trunk' for most of its length. (It slows down and has stoplights in
the larger towns, but is dual-carriageway with only infrequent
at-grade crossings.) NY 30 is surely at least 'primary'. It's a
bad two-lane road in a lot of places, but it goes through remote and
mountainous parts of the state and is The Big Road in virtually every
community it visits.

Ulster County Road 47 is a primary (or secondary at the very
least), two-lane (uhm, usually)
gravel (or sometimes asphalt) road. It was formerly signed
NY 42 - and there are sections of NY 42 beyond both
ends of it. But the state, some years back, decided that a
road through the mountain range there could not be maintained
to state highway standards and turned it over to the county.
The non-hard-surface sections were downgraded because
they're easier and cheaper to maintain, and with the
well-compacted surface, the road runs surprisingly fast in
summer. (In winter, it's pretty challenging - snow removal leaves
something to be desired, and there's a LOT of snow up
in the pass by Winnisook Lake.) But for the villages of Big
Indian, Oliverea, Frost Valley, Claryville, it's The Highway.

Reading the descriptions on the Wiki, they all are talking about
importance, not size. "Secondary" is defined as "A highway which is
not part of a major route, but nevertheless forming a link in the
national route network." "Trunk" is "Use highway=trunk for high
performance or high importance roads that don't meet the requirement
for motorway." This is the only one that's hedged: "In different
countries, either performance or importance is used as the defining
criterion for trunk."

By contrast, if we want to say, "how big a road is this" for
rendering, we have a collection of attributes that can inform it:
"lanes", "maxspeed", "maxweight", "hgv", single vs dual carriageway,
presence or absence of grade crossings, ...

So in an ideal world, it's less of a stretch to say that "highway=*"
is the "importance" metric (which would determine the map scale at
which the road is relevant), and the bucket of physical attributes
that I mentioned is enough to determine "size" for the symbology.  I
don't know if "maxspeed" by itself is enough for routing, or if other
information is needed there; I generally consider routing to be
Someone Else's Problem.

Nevertheless, we live in a real world in which a TIGER import did
indeed tag roads by administrative level - surely a surrogate for
neither size, nor speed, nor importance, and in which people argue
whether a dual-carriageway county road could possibly be anything
higher than 'tertiary', and tag a dual carriageway as "motorway" with
downgrades to "trunk" for barely the width of each grade crossing. I
don't know what to do to get from the world we live in to a world
where the useful attributes for selection, rendering, and routing are
separable.

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

Re: [Talk-us] Trunk

[Paul Johnson]

On Fri, Oct 13, 2017 at 6:50 PM, Dave Swarthout 
wrote:
>
> I don't really have a stake in the outcome of this discussion but wish to
> again point out that Alaska is a state where "trunk" has been used to
> designate highways that are ordinarily classified as primary but because
> they are in a state with so few roads and in which they are the "only"
> connectors between towns, have been tagged trunk highways. They are
> high-speed, 65 mph in most cases, or I should say, in most sections, but
> have driveways, intersections, and when passing through towns, lower speed
> limits, traffic signals, etc.
>

I wouldn't call those trunks unless they are also an Interstate, and even
that's a pretty weak argument in favor of calling it a trunk.  It shouldn't
make much of any difference in terms of functionality but does give humans
a better idea of what the road is.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Paul Johnson]

On Fri, Oct 13, 2017 at 6:49 PM, Kevin Kenny 
wrote:

> On Fri, Oct 13, 2017 at 7:30 PM, Greg Troxel  wrote:
> > I don't think "important connecting role in the long distance road
> > network" should have anything to do with it.   A regular US highway that
> > is not divided, grade-separated, mostly limited access is still a key
> > interconnecting road, and it's squarely "primary".  Most of US 20 is
> > like this, as I understand it, and all or almost all of the parts I've
> > driven on (MA, WY) are like that.
>
> You're saying basically the same thing I've been saying. But... people
> who do routing and make maps are asking for three things, and
> we separate them only incompletely.
>
> (1) How "important" is this road to the long distance road network?
> If you look at a small-scale map of the state of Maine, you'll virtually
> always see US 1, 1A 2, 201; Maine 6, 11, 16, 161, 205. Maine
> has only the one Interstate (95) plus a loop (295 from Portland to Augusta)
> and a spur (395 into Bangor).
>
> This is what guides the decision to render a road at a given scale.
>

No argument here; I consider trunks and motorways as a special case of
primary.


> (2) What are the road's physical characteristics (access control,
> grade separation, number of lanes, width of shoulders, presence
> or absence of traffic lights and stop signs)?
>
> This is what guides the symbology to use. While Maine 205 is
> an important road in its area, it is NOT rendered as a freeway,
> or even a trunk. It's at best a primary and may even be a secondary,
> and that's how is should be rendered even on a small scale
> map.
>

I generally consider state highways as secondary unless they're quite large
or hit trunk or motorway.


> (3) How fast does traffic ordinarily flow on the road?
>
> This is what (should) guide the routing decision; routing is
> ordinarily done to save the driver's time. It is of key importance
> to navigation systems, but doesn't ordinarily guide rendering.
>

We don't even need to tag for this, as it can be inferred from the GPX
database instead.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Tracking Redaction Review

[Tod Fitch]

I’ve completed adding Tiger 2017 names to the roads in Arizona. And I’ve 
updated your spreadsheet to reflect the completion.

That was a much bigger job than I wanted to do but I just couldn’t stand seeing 
all those roads named “chdr_USA_AZ_name_fixup_required”. I’ve probably made a 
few typographical mistakes but the names will be closer to reality. I only 
touched the geometry in a couple of places and saw many, many places that could 
use some local love. But I am more interested in mapping places I actually 
visit so I’ll leave that to others.

Tod


> On Oct 13, 2017, at 4:29 AM, Max Erickson  wrote:
> 
> I setup a sheet to try to consolidate information about what has been looked 
> at:
> 
> https://docs.google.com/spreadsheets/d/1MbF4BptFvkY_Cp0zh1OKBxt_E9tdXklxRDfMW0baBvU/edit?usp=sharing
> 
> Open to anyway so just fill in a state once it is reviewed. I went
> through the earlier thread and added anything mentioned as done.
> 
> 
> Max
> 



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

Re: [Talk-us] Trunk

[Dave Swarthout]

>I don't think "important connecting role in the long distance road
>network" should have anything to do with it.   A regular US highway that
>is not divided, grade-separated, mostly limited access is still a key
>interconnecting road, and it's squarely "primary".  Most of US 20 is
>like this, as I understand it, and all or almost all of the parts I've
>driven on (MA, WY) are like that.

I don't really have a stake in the outcome of this discussion but wish to
again point out that Alaska is a state where "trunk" has been used to
designate highways that are ordinarily classified as primary but because
they are in a state with so few roads and in which they are the "only"
connectors between towns, have been tagged trunk highways. They are
high-speed, 65 mph in most cases, or I should say, in most sections, but
have driveways, intersections, and when passing through towns, lower speed
limits, traffic signals, etc.

Just an observation on an edge case that is moderately important in our
immense and 99% rural state.

Best,
AlaskaDave

On Sat, Oct 14, 2017 at 6:30 AM, Greg Troxel  wrote:

>
> Martijn van Exel  writes:
>
> > In the mean time, I decided to test some of the ideas posted here on a
> real
> > case: The part of Michigan SR 10 northwest of the I-696 interchange:
> > https://www.openstreetmap.org/relation/252973#map=13/42.5132/-83.3168
> >
> > Since 1) this road does not seem to serve an important connecting role in
> > the long distance road network 2) the density of abutters and related
> > driveway / parking exits I judged a downgrade warranted. Please discuss
> > here or on https://www.openstreetmap.org/changeset/52903464 .
>
> If there are enough abutters and driveways (and use of them) that people
> driving on the road cannot basically act as if there are none, then it
> fails as trunk, so from your description, that sounds good.
>
> I don't think "important connecting role in the long distance road
> network" should have anything to do with it.   A regular US highway that
> is not divided, grade-separated, mostly limited access is still a key
> interconnecting road, and it's squarely "primary".  Most of US 20 is
> like this, as I understand it, and all or almost all of the parts I've
> driven on (MA, WY) are like that.
>
> > On the topic of tagging for the renderer, two things: 1) A US-specific
> > rendering would be really neat 2) Trunk 'appendices' like the one I
> > just downgraded do make rendering at low zooms tricky -- you end up
> > with short segments that seem to end in nothing.
>
> On point 2: Because the evolved rough consensus is about trunk being
> something that would have qualified for primary that also has superior
> physical characteristics, there is no reason to expect that displaying
> trunk but not primary will result in a connected network or a coherent
> map.  Displaying motorway but not trunk will likewise not be connected;
> e.g. parts of MA 2 are trunk and part are motorway (and in Boston and
> Western MA, merely primary).  The signed route is continuous and part of
> the network, but if you start at Alewife you are on motorway (4 lanes
> and traffic moves at 80+ mph) and eventually you get to Erving where
> it's 1 lane each way, double yellow line, and posted 30, having dropped
> to trunk and then had another motorway section.  But it is certainly a long
> distance important route, and if you only render 2 EW routes in MA, it's
> the second one to show after I-90.
>
> My point then, is that choosing to render trunk but not primary is not
> really a thing to do what preserves a sense of networks.  We absolutely
> should not thing about how to use motorway/trunk/primary to make maps
> rendered that way look good.
>
> People may want to render based on ref tag, or some other "how important
> is this route" tag, which could be some combination of how long the road
> is and how far away the next road that goes roughly those places but is
> faster is.  Others have talked about dropping some Interstate sections
> (esp odd 3 digits) at small scales.
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Kevin Kenny]

On Fri, Oct 13, 2017 at 7:30 PM, Greg Troxel  wrote:
> I don't think "important connecting role in the long distance road
> network" should have anything to do with it.   A regular US highway that
> is not divided, grade-separated, mostly limited access is still a key
> interconnecting road, and it's squarely "primary".  Most of US 20 is
> like this, as I understand it, and all or almost all of the parts I've
> driven on (MA, WY) are like that.

You're saying basically the same thing I've been saying. But... people
who do routing and make maps are asking for three things, and
we separate them only incompletely.

(1) How "important" is this road to the long distance road network?
If you look at a small-scale map of the state of Maine, you'll virtually
always see US 1, 1A 2, 201; Maine 6, 11, 16, 161, 205. Maine
has only the one Interstate (95) plus a loop (295 from Portland to Augusta)
and a spur (395 into Bangor).

This is what guides the decision to render a road at a given scale.

(2) What are the road's physical characteristics (access control,
grade separation, number of lanes, width of shoulders, presence
or absence of traffic lights and stop signs)?

This is what guides the symbology to use. While Maine 205 is
an important road in its area, it is NOT rendered as a freeway,
or even a trunk. It's at best a primary and may even be a secondary,
and that's how is should be rendered even on a small scale
map.

(3) How fast does traffic ordinarily flow on the road?

This is what (should) guide the routing decision; routing is
ordinarily done to save the driver's time. It is of key importance
to navigation systems, but doesn't ordinarily guide rendering.


In places with sensibly-designed road networks, these three
concerns are strongly correlated, and a road that scores high
on any axis is likely to score high on the other two. But this
is the US. Using the standing of a road on any of these
three axes as a surrogate for the other two is doomed to
a suboptimal result.

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

Re: [Talk-us] Trunk

[Greg Troxel]

Martijn van Exel  writes:

> In the mean time, I decided to test some of the ideas posted here on a real
> case: The part of Michigan SR 10 northwest of the I-696 interchange:
> https://www.openstreetmap.org/relation/252973#map=13/42.5132/-83.3168
>
> Since 1) this road does not seem to serve an important connecting role in
> the long distance road network 2) the density of abutters and related
> driveway / parking exits I judged a downgrade warranted. Please discuss
> here or on https://www.openstreetmap.org/changeset/52903464 .

If there are enough abutters and driveways (and use of them) that people
driving on the road cannot basically act as if there are none, then it
fails as trunk, so from your description, that sounds good.

I don't think "important connecting role in the long distance road
network" should have anything to do with it.   A regular US highway that
is not divided, grade-separated, mostly limited access is still a key
interconnecting road, and it's squarely "primary".  Most of US 20 is
like this, as I understand it, and all or almost all of the parts I've
driven on (MA, WY) are like that.

> On the topic of tagging for the renderer, two things: 1) A US-specific
> rendering would be really neat 2) Trunk 'appendices' like the one I
> just downgraded do make rendering at low zooms tricky -- you end up
> with short segments that seem to end in nothing.

On point 2: Because the evolved rough consensus is about trunk being
something that would have qualified for primary that also has superior
physical characteristics, there is no reason to expect that displaying
trunk but not primary will result in a connected network or a coherent
map.  Displaying motorway but not trunk will likewise not be connected;
e.g. parts of MA 2 are trunk and part are motorway (and in Boston and
Western MA, merely primary).  The signed route is continuous and part of
the network, but if you start at Alewife you are on motorway (4 lanes
and traffic moves at 80+ mph) and eventually you get to Erving where
it's 1 lane each way, double yellow line, and posted 30, having dropped
to trunk and then had another motorway section.  But it is certainly a long
distance important route, and if you only render 2 EW routes in MA, it's
the second one to show after I-90.

My point then, is that choosing to render trunk but not primary is not
really a thing to do what preserves a sense of networks.  We absolutely
should not thing about how to use motorway/trunk/primary to make maps
rendered that way look good.

People may want to render based on ref tag, or some other "how important
is this route" tag, which could be some combination of how long the road
is and how far away the next road that goes roughly those places but is
faster is.  Others have talked about dropping some Interstate sections
(esp odd 3 digits) at small scales.



signature.asc
Description: PGP signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Low-quality NHD imports

[Kevin Kenny]

On Fri, Oct 13, 2017 at 1:34 PM, Christoph Hormann  wrote:
> There are a number of possible measures that could be considered for
> improving old NHD imports:
>
> * removal of unnecessary tags to reduce the baggage mappers would have
> to deal with when working on the data.
> * removal of small unnamed streams which are not necessary for the
> overall river network connectivity in areas where the geometric
> accuracy is poor by current standards (and it is therefore usually
> easier for mappers to newly trace those streams instead of trying to
> improve the inaccurate data)
> * creating maproulette challenges for fixing inaccurate waterway
> classifications - in particular waterways tagged 'waterway=stream' but
> with a name containing 'Creek' or 'River' will often qualify as
> waterway=river.  Same for artificial waterways with 'waterway=ditch'
> but names containing 'Canal' or ther other way round.
> * creating maproulette challenges for unconnected waterways.
> * adding missing 'intermittent=yes' to waterways in imports where this
> was not properly set based on the feature codes.


I've no argument with any of these (but please keep reachcode!).  They
all seem to be worthy projects. I'm of two minds about maproulette
challenges, only because I've seen some pretty low-quality results
coming out of them.

I have issues only with 'newly trace the streams' in areas with dense
tree cover - even some significant streams bordering on
'waterway=river' can be virtually invisible on the aerial images
around here. A lot of the time if I am tracing a stream, I cross-check
with the 1/3-arc-second (or 1/9-arc-second where I can get it) radar
altimetry and make sure that the streambed appears to be following the
'v's in the contour lines, and I'm not sure I'm actually doing any
better than NHD. Since I'm in an area where NHD is pretty good, I
usually start by importing individual watercourses and then try to
improve the data. (One of my projects for when the snow starts flying
is to make sure that I've brought in enough that the streams that I
added for some specific large-scale rendered maps actually reach
the rivers.)

A definite +1 on the inaccurate waterway classifications. In
particular, anything with an artificial flowline and a drawn riverbank
is a 'river,' whatever the name or the FCode say.  (I've had one
discussion in the past with someone who wanted to downgrade the
Schoharie Creek to 'stream' - apparently the guy couldn't quite grasp
that it has dams, reservoirs, power generation stations, catastrophic
floods from time to time. Despite 'Creek' in the name, it's a
third-order river.)

Oh, and a side question: should we be mapping artificial connections,
and if so, how? It is known, for instance (by accidental
contamination) that the water from one small lake locally flows
underground and exits through caves in a cliff a few km distant, but
not by what route it flows. NHD has an artificial 'connector' flowline
for that purpose, that I've never seen fit to map, having absolutely
no idea how to map it. In other cases of sinks and springs around
here, the connections may not even be known. (Ah, the joys of
glacio-karst terrain.)

For that matter, I also have No Clue what to do about
rapids. "waterway=rapids" is deprecated, and I'm not a canoeist or
kayaker - the "Whitewater Sports" page on the wiki says that if you
don't know the practice on the river in question, don't map it. (I
would have thought that "rapids here" had some utility even in the
absence of further information, but apparently the community
disagrees?)

Then again, that 'whitewater sports' page has some other misleading
stuff: "All rivers with width more than 5 meters has to be draw by
waterway=riverbank or natural=water+water=river in addition to
waterway=river.  I'm sorry, if I can't see the bank in aerials, but
can follow the flow line on elevation maps, I'm still going to map the
stream. Incomplete information is better than a blank map. If we
demand perfection from mappers when information is first being
gathered, that'll scare even more away. I'll agree with "it is
desirable to show the riverbank on rivers more than XX metres wide",
and '5' is probably too small a value for XX - I don't get that sort
of repeatability from GPS, and I'm surely not going to do a plane
table survey of the banks of my local streams!

In short: We agree about good ways to move forward, even if I reserve
judgment on the reasons.

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

Re: [Talk-us] Trunk

[Richard Welty]

On 10/13/17 1:59 PM, Martijn van Exel wrote:
> Hi all,
>
> I haven't abandoned this thread or thinking about it. It has just
> taken me a while to read through all the diary comments + what is
> being said in this thread. I intend to follow up with another diary
> post where I try to collect this smart crowd's thoughts and
> suggestions, but it will probably not until after State of the Map US
> that I get to this. 
>
> In the mean time, I decided to test some of the ideas posted here on a
> real case: The part of Michigan SR 10 northwest of the I-696
> interchange: 
> https://www.openstreetmap.org/relation/252973#map=13/42.5132/-83.3168 
i would concur that this is not a trunk by the conventions that most of
us in the US have
been using for the past several years. too many driveways at the very least.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


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

Re: [Talk-us] Trunk

[Martijn van Exel]

Hi all,

I haven't abandoned this thread or thinking about it. It has just taken me
a while to read through all the diary comments + what is being said in this
thread. I intend to follow up with another diary post where I try to
collect this smart crowd's thoughts and suggestions, but it will probably
not until after State of the Map US that I get to this.

In the mean time, I decided to test some of the ideas posted here on a real
case: The part of Michigan SR 10 northwest of the I-696 interchange:
https://www.openstreetmap.org/relation/252973#map=13/42.5132/-83.3168

Since 1) this road does not seem to serve an important connecting role in
the long distance road network 2) the density of abutters and related
driveway / parking exits I judged a downgrade warranted. Please discuss
here or on https://www.openstreetmap.org/changeset/52903464 .

On the topic of tagging for the renderer, two things: 1) A US-specific
rendering would be really neat 2) Trunk 'appendices' like the one I just
downgraded do make rendering at low zooms tricky -- you end up with short
segments that seem to end in nothing.

Martijn

On Sun, Oct 8, 2017 at 4:33 PM, Greg Troxel  wrote:

>
> Kevin Kenny  writes:
>
> > Perhaps we could reach consensus more easily if we were
> > to first try to agree that the goal is to tag both physical character
> > and regional importance, and recognize that the two serve
> > different needs, and are (in the US) often grossly mismatched?
> > Then the discussion could revolve around the question of what
> > tagging is for physical character, what tagging is for regional
> > significance, and what are objective criteria for assessing
> > significance. (It's somewhat subjective, and therefore
> > contrary to the OSM spirit of "tag what is visible only on the
> > ground", but it's so necessary to getting mapping and routing
> > right that I think we have to grasp that particular bull by
> > the horns.)
>
> I think that would be a great step forward.
>
> The elephant in the room, though, is that the behavior of the default
> render is considered extremely important, and I think a lot of the
> debate is at least somewhat tied to controlling how that comes out.
>
> ___
> 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] Low-quality NHD imports

[Christoph Hormann]

On Friday 13 October 2017, Kevin Kenny wrote:
>
> I remain unconvinced that importing or not importing has had any
> significant impact on whether people improve the map manually.

In case of NHD imports in the US there are certainly significant parts 
of the country where no NHD data has been imported and there is also no 
manual waterbody mapping worth mentioning - which would allow you to 
conclude there are likely also areas of NHD imports where at least so 
far this did not have a negative effect.  But in areas of significant 
interest, in particular popular outdoor destinations, i am pretty sure 
you can observe this - i showed an example from southern Montana where 
the limit of the detailed and accurate manual mapping clearly matches 
the limit of the previous NHD import or in other words:  The mapper 
mapping that clearly did not feel like bringing the NHD data to the 
same level of quality as the manually mapped area.  This is just one 
case and you cannot simple conclude it is the same everywhere else but 
i would not simply dismiss the idea that there is a discouraging effect 
of imports on manual mapping in some cases.

There are a number of possible measures that could be considered for 
improving old NHD imports:

* removal of unnecessary tags to reduce the baggage mappers would have 
to deal with when working on the data.
* removal of small unnamed streams which are not necessary for the 
overall river network connectivity in areas where the geometric 
accuracy is poor by current standards (and it is therefore usually 
easier for mappers to newly trace those streams instead of trying to 
improve the inaccurate data)
* creating maproulette challenges for fixing inaccurate waterway 
classifications - in particular waterways tagged 'waterway=stream' but 
with a name containing 'Creek' or 'River' will often qualify as 
waterway=river.  Same for artificial waterways with 'waterway=ditch' 
but names containing 'Canal' or ther other way round.
* creating maproulette challenges for unconnected waterways.
* adding missing 'intermittent=yes' to waterways in imports where this 
was not properly set based on the feature codes. 

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-us] Low-quality NHD imports

[Kevin Kenny]

On Fri, Oct 13, 2017 at 10:06 AM, Frederik Ramm  wrote:
> I only posted that on the talk list and not here, so for those on
> talk-us who don't read talk and who are familiar with the "imports are
> always bad for the community" discussion, you might want to have a look
> at a scientific paper recently written by Abhishek Nagaraj (UC
> Berkeley-Haas) which finds that:
>
> "... a higher level of information seeding significantly lowered
> follow-on knowledge production and contributor activity on OpenStreetMap
> and was also associated with lower levels of long-term quality."
>
> The paper can be freely downloaded here
> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3044581 and there
> has been a little discussion about it over on the talk list, here:
> https://lists.openstreetmap.org/pipermail/talk/2017-October/079116.html

Interesting. The interesting take-away is that there may be an ideal
level of 'information seeding' so that potential contributors are
initially attracted to the platform (if there's nothing there, there's
no reason to believe that your contribution will ever have value)
and not driven off by a sense that the job is done. The
'inverted U' effect is hypothesized several times in the
paper.

I'm a post-TIGER mapper, so the TIGER import has always
been part of my environment. I know that when I was a beginner,
one thing that quite put me off trying to improve it was
all the noise tags that came with the import. Since at the
time, I had no idea what the purpose of that information
was, much less that it serves no purpose whatsoever, I
was reluctant to edit TIGER ways for fear of breaking
something. In the environment we live in now, we certainly
need some way to encourage new mappers to go ahead and
break things. (I know, this argument is anecdotal, but
I can't even think of how I could set out to test it.)

I also think the balance shifts some in the places where
there simply are never going to be enough mappers.
I could, in theory, lawfully get out in the field and
survey the boundaries of the big parks, for instance.
But the boundaries don't move much, and there aren't
enough people like me with the necessary motivation
and skills. But people relate to parks, and react
badly to an argument that they shouldn't be
on the map unless someone has devoted that
sort of effort. (Someone has. The state surveyor. And
even the state survey may reblaze the bounds only
once or twice a century.) Remember that in my part of
the word, there are even indefinite county boundaries.
County lines that have never been surveyed and
monumented. (It messes up everyone's idea of topology
not to draw lines on the maps, so people do.)

I think the ideal level of imports is greater than zero and less
than TIGER. We'll go on arguing about where the maximum
value is along that curve, and that's a good thing. In the
meantime, we all try to improve the map, and to recruit
mappers - which, we see, are sometimes conflicting goals.

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

Re: [Talk-us] Low-quality NHD imports

[Clifford Snow]

I live in the west coast of the US where manually surveying waterways is
not only difficult, but almost impossible. I can't quantify how much as
been cleaned up, but I do know of efforts to fix problems. For example,
most of the waterways in the Olympic Peninsula were reversed. That's been
fix. (I did a few, but another mapper did just about everything else.) I
regularly improve waterways and waterbodies around me. Just recently I
added names to lakes and lagoons in Island County.

The difficulty in physically mapping waterways is so expensive that our
state and counties have dropped most efforts to map them, instead they use
NHD data. The counties do mapping of salmon stream but doing so requires
hiring companies to fly drones equipped with LIDAR to map the stream. My
own county is even looking at OSM data because we have been improving the
waterways from imagery.

Frederik, I'm not sure what you are suggesting. Too many tags on NHD
imported data, that we should import data, or not enough love is being
given to streams and lakes? I certainly hope you are not suggesting we
revert all the steams and waterbodies.

One study on imports is inciteful, but hardly the last word. I hope to
discuss the report with the author later this month. I have some questions
about his findings and how much we can infer from them.

Best,
Clifford


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Low-quality NHD imports

[Kevin Kenny]

On Fri, Oct 13, 2017 at 4:53 AM, Christoph Hormann  wrote:
> I think this is probably a good example for imports discouraging manual
> mapping.  If this data was not there mappers would probably meanwhile
> have added at least the larger rivers but with the dense network of NHD
> geometries with a lot of cryptic tags and all flatly tagged as
> waterway=stream it is quite hard for mappers to identify the larger
> rivers and improve mapping there.  Like here (NHD import on the left,
> newer manual mapping on the right):

What *should* have been done: artificial flowlines with shoreline should have
been 'river', most other should have been 'stream'. That would have worked
in most cases. But that's all water under the bridge (and people complain
that in initial mapping, I just cross roads over streams, and go back and
add the bridges and culverts later as time permits - usually it doesn't).

I remain unconvinced that importing or not importing has had any
significant impact on whether people improve the map manually.

NHD was never imported around here. I miss it. Only the most significant
rivers are in OSM. The lack of an import didn't motivate manual mapping,
except that at one point there was a project to map ponds (from a file of
point data). The result was a bunch of pond outlines that are pretty rough,
and confuse floating and emergent vegetation (common in our shallow
waters) with land. For that specific set, I find NHD more reliable.

Across the state line, NHD was imported in some neighbouring states.
There, I at least have the waterways in OSM. Are they any better or
worse than the few manually-mapped ones I have here? On the whole,
they appear to be better. There are some specific instances were
they're very bad. I don't see much maintenance of the data on
either side of the border.

I just inhabit a place where detailed mapping is always going to be
haphazard. Too many land, not enough people, not nearly enough
network connectivity.

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

Re: [Talk-us] Low-quality NHD imports

[Frederik Ramm]

Hi,

On 10/13/17 15:52, Kevin Kenny wrote:
> (I ignore the arguments that
> are based solely on contentions that "imports are always bad for the
> community," or else I'd never import anything.)

I only posted that on the talk list and not here, so for those on
talk-us who don't read talk and who are familiar with the "imports are
always bad for the community" discussion, you might want to have a look
at a scientific paper recently written by Abhishek Nagaraj (UC
Berkeley-Haas) which finds that:

"... a higher level of information seeding significantly lowered
follow-on knowledge production and contributor activity on OpenStreetMap
and was also associated with lower levels of long-term quality."

The paper can be freely downloaded here
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3044581 and there
has been a little discussion about it over on the talk list, here:
https://lists.openstreetmap.org/pipermail/talk/2017-October/079116.html

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-us] Low-quality NHD imports

[Kevin Kenny]

 On 10/13/2017 02:06 AM, Frederik Ramm wrote:

Hi,

   there's a LOT of NHD:* (and nhd:*) tags on OSM objects, see
https://taginfo.openstreetmap.org/search?q=NHD%3A

- 1.9 million NHD:FCode, but also 188k "NHD:Permanent_" (note the
underscore), 10k "NHD:WBAreaComI", or 1.5m "NHD:Resolution" just to grab
a few.

I haven't researched who added them and when, but they would certainly
not clear the quality standards we have for imports today. Most of this
information can be properly modelled in usual OSM tags, and where it
cannot, it probably shouldn't be in OSM in the first place.

Is there any systematic (or even sporadic) effort of cleaning up these
old imports? Is there reason to believe that the neglect extends to more
than just the tags - do geometry and topology usually work well on
these, or are the funny tags a huge "this whole area hasn't had any love
in a long time" sign?

ON IRRELEVANT TAGGING:

I, at least, ordinarily do not make a specific effort to ferret out
irrelevant tags. For the most part, they're harmless to me. If some
random object on the map haapens to have 'zqx3:identifier=2718281828'
among its tags, the only real damage is the diffuse cost of shipping
the data around.

That said, you're quite right that such tags might indeed be a symptom
of a neglected import, or one that was originally done with processes
that wouldn't clear today's bar. Even that has only some bearing on
the data that are meaningful.

ON IMPORTING NHD:

In the specific case of NHD, data quality varies by region. As Dave
correctly notes, Alaska is uniformly atrocious. (There really are no
good mapping data for Alaska. The technical challenge of acquiring
high-quality data for much of the state simply is greater than the
perceived value of the data.)

Where I am, on the other had, NHD is actually quite good - in the
maps that I render, which are almost all in rural areas, I use it.
I most often use it in combination with OSM and with other data
sources (USFWS national wetland inventory, Adirondack Park Authority
wetland inventory, NYSDOT, ...) which give the rendered maps a
somewhat 'cubist' appearance, but I find that appearance helpful -
it's an indication of data variability, and gives me an idea how much
uncertainty to expect in the field.

The fact that NHD is often quite 'stale' does not bother me at all
locally. I live in a heavily glaciated area, and the cities have been
settled for quite a long time by US standards. Out in the countryside,
the streams run typically in deep ravines, disproportionate to the
size of the streams. They aren't moving anywhere. They most likely
haven't moved significantly since the Wisconsinan glaciation, 14000
years ago.

In the valleys, the detailed course of the streams does shift a bit,
but in the cities and towns, the streams are engineered, and
elsewhere, the terrain tends to be beaver swamp, and the streams shift
with every move of the rodents or every major storm. I never expect
the track of a watercourse within a wetland to be accurate, on any
map, ever.

NHD's topology is audited before it is released, so it's at least
consistent (and likely correct).

It's certainly hypothetically possible to map the streams using
'hand-crafted' methods - and I have done so for a few, when I've
happened to follow them in wilderness travel. (I occasionally go
hiking off-trail.) But the OSM community is never going to be able to
do that for the great many watercourses that flow over my extremely
well-watered area. There simply is too much land inhabited by too few
people, most of whom are not well enough connected nor technologically
literate enough to become OSM mappers. (Seriously, in some of these
communities, there is no cell service and only a quarter of the houses
have any sort of network connectivity. It's effectively working with
Third World infrastructure.)

It's virtually impossible to map most of these watercourses as an
'armchair mapper.' Our 'old second growth' timber gives rise to
extraordinarily dense tree cover - denser than true 'old growth'
forest. Even some fairly major watercourses - major enough that I
wouldn't attempt to ford in springtime - are difficult or impossible
to see in aerials.

There has been an OSM project to map lakes and ponds in New York
State, starting from point features giving their names. I've preserved
these tracings in OSM, because I don't replace mappers' work with
imports, ever. Nevertheless, I find them to be uniformly worse than
NHD. They're usually quite rough, and in a great many of them, the
mappers treated mats of floating or emergent vegetation as the
shoreline, making shallow ponds much smaller than they are.

For all these reasons, NHD is what I have in my area. I've never done
a large-scale NHD import, and nobody else has done one around me.  If
I need a stream for a rendered map, and don't want the 'cubist' data,
I sometimes import it as a single object from NHD. Where else will I
get it?

(That's pretty much my guideline on when 

Re: [Talk-us] Texas - redacted roads.

[Kevin Kenny]

On Fri, Oct 13, 2017 at 7:49 AM, Kerry Irons  wrote:
> Yes, but what about when there are two different names on street signs 
> depending on where you are on the street?  It clearly is a mistake on the 
> part of the sign department, but in this case it probably means you have to 
> go with the "un- authoritative" data from the local jurisdiction no matter 
> what the street sign says.

I had one case where a road had three different spellings for its
name in as many blocks. Given that even the locals didn't
know how it was correctly spelt, I tagged the name as signed,
so the road changes name in OSM.

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

Re: [Talk-us] Low-quality NHD imports

[Christoph Hormann]

On Friday 13 October 2017, Frederik Ramm wrote:
>
> I haven't researched who added them and when, but they would
> certainly not clear the quality standards we have for imports today.
> Most of this information can be properly modelled in usual OSM tags,
> and where it cannot, it probably shouldn't be in OSM in the first
> place.

Those are several regional imports made by different people, see 

https://taginfo.openstreetmap.org/keys/NHD%3AFCode#map

to get an idea of the distribution.

In general the NHD water line features are next to impossible to 
properly model in OSM since the natural waterway lines (feature codes 
46000-46007) and the artificial waterway lines (feature codes 
33600-33603) include all sizes of waterways.  They were usually all 
imported as waterway=stream and waterway=ditch which is incorrect in 
many cases.

The geometries in the NHD source data are usually fine (at least in 
recent NHD versions) - though conflation is often poor, lacking 
connectivity to pre-existing data - like here:

https://www.openstreetmap.org/#map=16/45.8945/-111.3596=D

And there are of course also obvious errors like this:

https://www.openstreetmap.org/way/39263506

or this:

https://www.openstreetmap.org/#map=13/38.9733/-108.4790

> Is there any systematic (or even sporadic) effort of cleaning up
> these old imports? Is there reason to believe that the neglect
> extends to more than just the tags - do geometry and topology usually
> work well on these, or are the funny tags a huge "this whole area
> hasn't had any love in a long time" sign?

I think this is probably a good example for imports discouraging manual 
mapping.  If this data was not there mappers would probably meanwhile 
have added at least the larger rivers but with the dense network of NHD 
geometries with a lot of cryptic tags and all flatly tagged as 
waterway=stream it is quite hard for mappers to identify the larger 
rivers and improve mapping there.  Like here (NHD import on the left, 
newer manual mapping on the right):

https://www.openstreetmap.org/#map=13/45.2453/-110.1321

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-us] Texas - redacted roads.

[Kerry Irons]

Yes, but what about when there are two different names on street signs 
depending on where you are on the street?  It clearly is a mistake on the part 
of the sign department, but in this case it probably means you have to go with 
the "un- authoritative" data from the local jurisdiction no matter what the 
street sign says.

-Original Message-
From: Paul Norman [mailto:penor...@mac.com] 
Sent: Thursday, October 12, 2017 11:46 PM
To: talk-us@openstreetmap.org
Subject: Re: [Talk-us] Texas - redacted roads.

On 10/12/2017 6:54 PM, Nick Hocking wrote:
>
> Should we (in OSM) put what the user will probably search for, the 
> correect (hypothetically) Redwil or should we put the "ground truth"
> (REED WILL) which is what the user will see if he acually ever makes 
> it to that location.

Although this has been resolved as a misreading of the site, in this case, 
correct is the ground truth.

For OSM, the data from the city is not authoritative. Ground truth is.

___
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] Tracking Redaction Review

[Max Erickson]

I setup a sheet to try to consolidate information about what has been looked at:

https://docs.google.com/spreadsheets/d/1MbF4BptFvkY_Cp0zh1OKBxt_E9tdXklxRDfMW0baBvU/edit?usp=sharing

Open to anyway so just fill in a state once it is reviewed. I went
through the earlier thread and added anything mentioned as done.


Max

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

Re: [Talk-us] Low-quality NHD imports

[Dave Swarthout]

Sometimes I think it might have been better if OSM had never imported Tiger
data. It is simply pitiful, almost worse than nothing, in many areas of
Alaska. Same with the coastlines and NHD water bodies. I know they
represent a first approximation and without any coastlines we couldn't have
a map, period, but the sheer amount of editing required to clean up the
horrendous data in Alaska is daunting indeed. Same for the riverbanks. I
usually delete them and start over fresh because it's easier to create new
ones than to try to adjust and align the bad stuff already in place.

Given the actual total length of coastline in Alaska, I would venture to
say it will never be cleaned up. Here is an example of a relation
(id:2057975) "glacier" imported from NHD that is actually many named
glaciers all rolled into one. I have been working hard for the past year to
add individual named glaciers in Alaska but I swear, looking at something
like this monster containing 542 members makes me think I'll never get it
done.

Also, if you want to see something else that is really horrendous, take a
look at the Canvec imports for Canada; rivers and streams composed of many
tiny sections, water and woods where there isn't any. Sheesh!

Sorry, couldn't resist.



On Fri, Oct 13, 2017 at 2:18 PM, Wolfgang Zenker 
wrote:

> Hi,
>
> * Frederik Ramm  [171013 08:06]:
> >there's a LOT of NHD:* (and nhd:*) tags on OSM objects, see
>
> > https://taginfo.openstreetmap.org/search?q=NHD%3A
>
> > - 1.9 million NHD:FCode, but also 188k "NHD:Permanent_" (note the
> > underscore), 10k "NHD:WBAreaComI", or 1.5m "NHD:Resolution" just to grab
> > a few.
>
> > I haven't researched who added them and when, but they would certainly
> > not clear the quality standards we have for imports today. Most of this
> > information can be properly modelled in usual OSM tags, and where it
> > cannot, it probably shouldn't be in OSM in the first place.
>
> > Is there any systematic (or even sporadic) effort of cleaning up these
> > old imports? Is there reason to believe that the neglect extends to more
> > than just the tags - do geometry and topology usually work well on
> > these, or are the funny tags a huge "this whole area hasn't had any love
> > in a long time" sign?
>
> the NHD imports that I have encountered so far have numerous problems:
> The data is several decades old, the so-called "medium resolution" is
> pretty bad, and the data was basically just dumped into the OSM database
> without any conflation happening. And larger rivers where often imported
> as monstrous riverbank polygons without the river itself as a flowline.
>
> The worst junk like lakes covering motorways has been mostly cleaned up
> by now, but it is still easy to see where NHD data has been imported by
> looking a KeepRights display of broken highway/waterway crossings.
>
> I clean up the imports in areas where I'm doing TIGER reviews, but I
> have to admit that a few times I have decided to work on different areas
> instead because the huge riverbank polygons where almost impossible to
> edit.
>
> Wolfgang
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Low-quality NHD imports

[Wolfgang Zenker]

Hi,

* Frederik Ramm  [171013 08:06]:
>there's a LOT of NHD:* (and nhd:*) tags on OSM objects, see

> https://taginfo.openstreetmap.org/search?q=NHD%3A

> - 1.9 million NHD:FCode, but also 188k "NHD:Permanent_" (note the
> underscore), 10k "NHD:WBAreaComI", or 1.5m "NHD:Resolution" just to grab
> a few.

> I haven't researched who added them and when, but they would certainly
> not clear the quality standards we have for imports today. Most of this
> information can be properly modelled in usual OSM tags, and where it
> cannot, it probably shouldn't be in OSM in the first place.

> Is there any systematic (or even sporadic) effort of cleaning up these
> old imports? Is there reason to believe that the neglect extends to more
> than just the tags - do geometry and topology usually work well on
> these, or are the funny tags a huge "this whole area hasn't had any love
> in a long time" sign?

the NHD imports that I have encountered so far have numerous problems:
The data is several decades old, the so-called "medium resolution" is
pretty bad, and the data was basically just dumped into the OSM database
without any conflation happening. And larger rivers where often imported
as monstrous riverbank polygons without the river itself as a flowline.

The worst junk like lakes covering motorways has been mostly cleaned up
by now, but it is still easy to see where NHD data has been imported by
looking a KeepRights display of broken highway/waterway crossings.

I clean up the imports in areas where I'm doing TIGER reviews, but I
have to admit that a few times I have decided to work on different areas
instead because the huge riverbank polygons where almost impossible to
edit.

Wolfgang

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

Re: [Talk-us] Texas - redacted roads.

[Rihards]

On 2017.10.13. 05:06, Nick Hocking wrote:
> AAAH - all my questions are answered.
> 
> The City of Austin's use of google base map has "fooled" me into
> thinking that the map data was theirs rather than googles. If I click on
> the "blue line" then I see the actual City of Austin data and indeed it
> is "REED WILL DRIVE".
> 
> Damm - So I have actually just gone and put in a google mistake into
> OSM. Easily fixed tonight and I will check any other roads that I have
> "fixed" in the last two days.
> 
> Ok - so after all this, the only error was in the google data, which is
> no great surprise.

while not too likely, could have been a lye street[1], too.
this is a good example why even only taking a street name from google
maps is not a good idea.
thank you for finding and fixing it :)

[1] https://wiki.openstreetmap.org/wiki/Copyright_Easter_Eggs
-- 
 Rihards

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

[Talk-us] weeklyOSM #377 2017-10-03-2017-10-09

[weeklyteam]

The weekly round-up of OSM news, issue # 377,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9535/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Low-quality NHD imports

[Frederik Ramm]

Hi,

   there's a LOT of NHD:* (and nhd:*) tags on OSM objects, see

https://taginfo.openstreetmap.org/search?q=NHD%3A

- 1.9 million NHD:FCode, but also 188k "NHD:Permanent_" (note the
underscore), 10k "NHD:WBAreaComI", or 1.5m "NHD:Resolution" just to grab
a few.

I haven't researched who added them and when, but they would certainly
not clear the quality standards we have for imports today. Most of this
information can be properly modelled in usual OSM tags, and where it
cannot, it probably shouldn't be in OSM in the first place.

Is there any systematic (or even sporadic) effort of cleaning up these
old imports? Is there reason to believe that the neglect extends to more
than just the tags - do geometry and topology usually work well on
these, or are the funny tags a huge "this whole area hasn't had any love
in a long time" sign?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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