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: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

Simon, thanks for the constructive criticism, as it allows improvements
rather than aggravation. I propose that "rejections" are saved as a new
tag, for example "_autoreject".  In a way, this is very similar to the
"nobot" proposal - users reject a specific bot by hand.

_autoreject will store a semicolon-separated multivalue tag.  A query will
contain some "ID", e.g. "amenity-sanatorium", and that ID will be added to
the _autoreject whenever user clicks "reject suggestion" button.

Benefits:
* use existing tools to analyse, search, and edit this tag, without
creating anything new
* we can use it inside the queries themselves to say "only suggest to fix X
if the users have rejected Y", or if someone creates a bad query and most
values are rejected, we can easily find them and clean them up
* very easy to implement, few chances for bugs, no chances to loose
rejection data by accident
* other tools can also use this field to store rejections, e.g. mapRoulette
or Omose.
* Query authors can easily search for it to see why they showed up in the
query result, and fix the original query

The biggest problem is the tag name, any suggestions?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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 

[talk-ph] Mapping with friends is more fun with awesome PH-izzas!

[Erwin Olario]

The local OSM advocates in the Philippines is keen in finding ways to
engage, and expand the community of OpenStreetMap contributors in the
country. As you may7 know, many mapa-thons and hacking events are fueled by
passion, and pizza. You can help drive the passion, and we canl take care
of the pizza.

We just launched a new program: *the OSM PH-izza Challenge* that offers to
send free ph-izza for mapa-thon events in every possible part of the
country - especially those outside Metro Manila. If your mapa-thon proposal
is selected, the PH-izza is on us!

We're hoping to select at least one event every month - and we'd like to
hear your proposal!

If your club, or informal group would like to send your proposals, please
fill-in this application form so we can evaluate your them:
https://goo.gl/forms/si06mto1fOkeY3652

/Erwin




-- 

/Erwin Olario

e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s: https://mstdn.io/@GOwin
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

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: [OSM-talk] [Tagging] New OSM Quick-Fix service

[Steve Doerr]

Way to go!

 

This looks like just the kind of productivity tool OSM is crying out for. Great 
idea, Yuri.

 

Steve

 

 

From: Yuri Astrakhan [mailto:yuriastrak...@gmail.com] 
Sent: 13 October 2017 22:25
To: Tag discussion, strategy and related tools ; 
OpenStreetMap talk mailing list 
Subject: [Tagging] New OSM Quick-Fix service

 

I would like to introduce a new quick-fix editing service.  It allows users to 
generate a list of editing suggestions using a query, review each suggestion 
one by one, and click "Save" on each change if they think it's a good edit.

 

For example, RU community wants to convert  amenity=sanatorium  ->  
leisure=resort + resort=sanatorium.  Clicking on a dot shows a popup with the 
suggested edit. If you think the edit is correct, simply click Save.

Try it:  http://tinyurl.com/y8mzvk84

 

I have started a Quick fixes wiki page, where we can share and discuss quick 
fix ideas.

* Quick fixes  

* Documentation 

 

 

This is a very new project, and bugs are likely. Please go slowly, and check 
the resulting edits. Let me know if you find any problems. Your technical 
expertise is always welcome, see the code at 
https://github.com/nyurik/wikidata-query-gui  The service has adapted some code 
from the Osmose project (thanks!)

 

TODO:

* Allow multiple edits per one change set

* Show objects instead of the dots

* Allow users to change comment before saving

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

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: [OSM-talk] New OSM Quick-Fix service

[Simon Poole]

My major issue with this: you don't actually "confirm" that something is
a good edit or not. You only have the choice of making an edit or
leaving it to others to do. This is substantially different to
maproulette, osmose, keepright and so on.

This makes the whole thing entirely equivalent to a mechanical edit.

Simon


On 13.10.2017 23:25, Yuri Astrakhan wrote:
> I would like to introduce a new quick-fix editing service.  It allows
> users to generate a list of editing suggestions using a query, review
> each suggestion one by one, and click "Save" on each change if they
> think it's a good edit.
>
> For example, RU community wants to convert  amenity=sanatorium  -> 
> leisure=resort + resort=sanatorium.  Clicking on a dot shows a popup
> with the suggested edit. If you think the edit is correct, simply
> click Save.
> Try it:  http://tinyurl.com/y8mzvk84
>
> I have started a Quick fixes wiki page, where we can share and discuss
> quick fix ideas.
> * Quick fixes 
> * Documentation
> 
>
> This is a very new project, and bugs are likely. Please go slowly, and
> check the resulting edits. Let me know if you find any problems. Your
> technical expertise is always welcome, see the code
> at https://github.com/nyurik/wikidata-query-gui  The service has
> adapted some code from the Osmose project (thanks!)
>
> TODO:
> * Allow multiple edits per one change set
> * Show objects instead of the dots
> * Allow users to change comment before saving
>
>
> ___
> 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] New OSM Quick-Fix service

[Frederik Ramm]

Yuri,

On 13.10.2017 23:25, Yuri Astrakhan wrote:
> I would like to introduce a new quick-fix editing service.  It allows
> users to generate a list of editing suggestions using a query, review
> each suggestion one by one, and click "Save" on each change if they
> think it's a good edit.

I am appalled that after your abysmal OSM editing history where you more
often than not ignored existing customs rules, while *claiming* to
follow them, you're now building a service that entices others to do the
same.

You know full well that your "review suggestions one by one" is a
fig-leaf and that most people will not do that - because it wouldn't be
a quick fix otherwise, would it? How should anyone confirm that
something is "a good edit" when you allow them to make the edit on a map
at ZOOM LEVEL 3? What, in your mind, should someone do to verify that
something is "a good edit"?

You have proven that you have a very different outlook on OSM than what
our community lives by. You think OSM is just a database; if it were for
you, you'd prefer to log in to the database server and do a quick UPDATE
query to change every occurrence of tag A to tag B, and you look down on
the idea that such edits should not be made.

> For example, RU community wants to convert  amenity=sanatorium  -> 
> leisure=resort + resort=sanatorium.  

... yet the map shows world-wide results. Have the RU community decided
they would like to change this tag world-wide?

This service is going to create only trouble, and you know that
perfectly well.

Bye
Frederik

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

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

[OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

I would like to introduce a new quick-fix editing service.  It allows users
to generate a list of editing suggestions using a query, review each
suggestion one by one, and click "Save" on each change if they think it's a
good edit.

For example, RU community wants to convert  amenity=sanatorium  ->
leisure=resort + resort=sanatorium.  Clicking on a dot shows a popup with
the suggested edit. If you think the edit is correct, simply click Save.
Try it:  http://tinyurl.com/y8mzvk84

I have started a Quick fixes wiki page, where we can share and discuss
quick fix ideas.
* Quick fixes 
* Documentation


This is a very new project, and bugs are likely. Please go slowly, and
check the resulting edits. Let me know if you find any problems. Your
technical expertise is always welcome, see the code at
https://github.com/nyurik/wikidata-query-gui  The service has adapted some
code from the Osmose project (thanks!)

TODO:
* Allow multiple edits per one change set
* Show objects instead of the dots
* Allow users to change comment before saving
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-in] old_name tag for merged Associate State Banks

[Warin]

Revert the name changesets and start again?

The new changes should then place the original name into old_name and 
introduce the new name.


On 13-Oct-17 11:08 PM, Srihari Thalla wrote:


Chetan, Is there any possibility to update them via script?

I am not sure if Overpass API can download based on changes in changesets.
If not, manually going through the spreadsheet would be the obvious 
choice.


It would be better to write a script to query the histories of Bank 
amenity objects

and import them into JOSM and update.

Scripting would, of course, need approval from the community!

Here are my changesets: OSMCha: https://goo.gl/V76HoH

I bundled all the changes into two changesets. (There are 5 other 
singled out changesets too.)


Manually :: Downloading the changeset -> going through each object 
history -> updating each object


What do you say would be a good idea?


On Fri 13 Oct, 2017, 17:03 Chetan H A, > wrote:


Srihari, makes sense. I wonder how to get back deleted old names
and add it in old_name tag in one go like you added?



On Fri, Oct 13, 2017 at 2:37 PM, Srihari Thalla
> wrote:

Hi,

Back in May 2017, we have updated the name tags of merged
Associate State Banks from their old names (State Bank of xxx)
to the new name, "State Bank of India".

We have identified and tracked the entries in a spreadsheet
[1]. I have updated many entries.
However, I forgot to add the old_name tag with the old name
(State Bank of xxx) and just updated the name tag to State
Bank of India.

I think it is good to have the old names in the old_name tag
as people might still remember the banks with their old names.

Thoughts?

Cheers,
Srihari

[1] -

https://docs.google.com/spreadsheets/d/17VXVWQVF1rujmQiSQVrXiTOi2sRImh29I2JCGWCKaxc/edit#gid=1622201629

talk-in Discussions
[1] -
https://lists.openstreetmap.org/pipermail/talk-in/2017-April/002862.html
[2] -
https://lists.openstreetmap.org/pipermail/talk-in/2017-May/002888.html

cc Chetan, Bharata
-- 
Cheers,

Srihari

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


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

--
Cheers,
Srihari


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



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

Re: [Talk-GB] Barriers and PRoWs

[Bob Hawkins]

I thank Roland so much for taking the time to read my message and provide 
examples; I am indebted to him.
Might I request just one enhancement:  could the barrier locations be shown on 
the ways to which they relate in the case of > 1. to identify PRoWs having 
stiles?  I fully accept I did not request that, specifically.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[OSM-talk-fr] Fonds et Fondations en France

[Paul Desgranges]

Bonjour,

Le Centre Français des Fonds et Fondations 
 (CFF) a organisé les 14/15 
septembre derniers un voyage d'études en Rhône-Alpes, différentes 
rencontres étaient organisées avec des acteurs locaux des données 
numériques, de l'OpenData, des universitaires, etc. , et j'ai à cette 
occasion eu l'honneur de pouvoir présenter en une petite demi-heure 
OpenStreetMap à la bonne vingtaine de représentants des fondations en 
France qui étaient présents : ma présentation est ici pour ceux que ça 
intéresse 
. Une 
bonne partie du public ne connaissait pas OSM et c'était une première 
pour eux, et j'ai senti un certain intérêt pour le sujet ! Pour eux, qui 
collectent des fonds, gèrent et financent des projets d'intérêt général, 
il est important de maîtriser les outils qui permettent de suivre ces 
projets, de les représenter, de communiquer, d'informer etc. Donc l'idée 
ce n'était pas d'essayer d'obtenir des financement pour quoi que ce 
soit, mais bien de faire de la sensibilisation à l'utilisation d'OSM ...


Je suis recontacté maintenant par un représentant du CFF qui souhaite 
"poursuivre la réflexion sur le recensement des fondations", c'est vrai 
que à l'issue de la présentation, ce point avait fait l'objet d'une 
question et j'avais mentionné le tag 
http://wiki.openstreetmap.org/wiki/Tag:office%3Dfoundation et donc la 
possibilité de mettre les fondations dans OSM ... La vérité c'est qu'il 
n'y en a que très très peu http://overpass-turbo.eu/s/skk (à comparer 
aux 4000 fondations et fonds de dotations en France) et que le tag 
office=foundation n'est pas très détaillé pour l'instant (il existe 
différents types de fondations en France que je ne détaille pas ici, 
mais je pourrais rédiger, maintenant que j'ai étudié la question, une 
page wiki osm en français sur le sujet pour enrichir cette spec ?)


Voilà, je voulais simplement informer la communauté OSM française de ce 
besoin qui a été exprimé par le CFF, pour que chacun pense aussi, à 
l'occasion à mapper une fondation (comme on mappe une association par 
exemple). Je vais essayer de creuser un peu la question avec eux, et 
mieux comprendre ce qu'ils souhaitent : ils doivent avoir un inventaire 
et je ferais alors un coup de géocodage dessus pour voir ce que ça 
donne. Mais je suis intéressé par ceux qui auraient eu à faire un 
travail similaire...


Merci

Paul


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

Re: [Talk-it] Alta Via dei Parchi (e percorsi a tappe con sovrarelazione in generale)

[Alfredo Gattai]

Personalmente non sono una grande fan delle superroute percio' tendo ad
evitarle ogni volta che posso.
Nel caso dell'AVP sicuramente devi fare le singole tappe come lwn e poi se
le vuoi raggruppare fai una superroute come rwn.
Ti suggerirei per dare il massimo dell'infomazione di usare ref=AVP21 +
name=Alta Via dei Parchi - Tappa 21 in quelle lwn e ref=AVP + name=Alta Via
dei Parchi nella superroute.
Siccome in queste via di lunga percorrenza la segnaletica e' messa a dura
prova, se l'indicazione corretta del percorso e della tappa e' facilmente
accessibile si da una bella mano a chi va in giro.

Alfredo



2017-10-13 17:30 GMT+02:00 matteocalosi :

> Ciao,
> starei accarezzando l'idea di mettermi ad aggiungere l'Alta Via dei Parchi
> come route hiking visto che mi sembra sorprendemente assente al momento.
> Però c'è una situazione preesistente in cui:
> - La variante mtb è completamente presente come route, con le singole tappe
> relazioni distinte raccolte in una sovrarelazione
> - Le tappe 20-25 sono state aggiunte da un mappatore ma come route singole
> con tag un po' opinabili
>
> Mi adeguo a questo tipo di pratica e creo una sovrarelazione e ci metto le
> singole tappe dentro? Non mi sta simpaticissima come cosa e preferirei fare
> una singola relazione.
>
> Poi, anche se appunto preferirei non farlo, vorrei qualche opinione su come
> uno dovrebbe taggare un percorso con route tappe dentro una sovrarelazione
> (vale anche per le varie tappe del Sentiero Italia che vedo sta aggiungendo
> un altro mappatore):
>
> Sia sulle tappe preesistenti che sulla relazione mtb ci sono ref del tipo
> AVP 21 e name del tipo "Alta Via dei Parchi - Tappa 21". Sui segnavia il n
> di tappa non compare mai quindi io personalmente metterei per il ref
> sicuramente solo AVP, per il name non so sia giusto "Alta Via dei Parchi" o
> tenere la dicitura tappa che altrimenti non saprei in che tag mettere.
> Come network meglio mettere singole tappe lwn e sovrarelazione rwn o tutto
> rwn?
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Alfredo Gattai]

2017-10-12 17:32 GMT+02:00 matteocalosi :

> Magari arbitrari è il termine sbagliato, mi riferivo semplicemente
> all'assegnazione in massa (catasto sentieri?) della formula partenza-arrivo
> come nome relazione. Che magari se si decide che un sentiero DEVE avere un
> nome è anche la soluzione migliore ma personalmente vederli sulla mappa non
> mi piace.
>

E' una prassi consolidata. Ormai esiste un protocollo creato dal CAI per
assegnare dei codici univoci (in osm lo trovi dentro ref:REI) che e' stato
gia' recepito da diverse regioni (Piemonte, Lombardia, Liguria, Trentino,
Emilia Romagna, etc.) e le altre si stanno via via allineando.
Quando un percorso non ha gia' un nome storico conosciuto in fase di
inserimento a catasto viene assegnato un nome che abbia una logica e
rispetti la toponomastica locale. Da qui' i nomi che ricordano le partenze,
punti intermedie gli arrivi.
Capisco che possa non piacere ma visto che e' diventata la regola ed i
percorsi sono accatastati cosi' presso le regioni e nel catasto nazionale
del CAI (per il quale i CAI ha stipulato un accordo col MIBAC) non avrebbe
senso omettere questa informazione se la si conosce.



> Non sapevo che osmand facesse anche il render del nome relazione (io
> abitualmente uso openandromaps/elevate), devo dire che effettivamente la
> qualità render del nome a partire dalla relazione piuttosto che dalle way è
> superiore (e ci mancherebbe) ma il risultato nei tratti con millemila
> rwn/nwn è quello che temevo https://imgur.com/a/JDpnz (cioè, sono tratti
> che
> sono già orrendi anche semplicemente con le ref ma così è peggio).
>


Si, dove ci sono molte relazioni sovrapposte puo' esserci questo rischio ma
sono casi abbastanza limite, ad alcuni livelli di zoom si cominciano a
vedere i ref, poi appaiono i nomi. Io lo uso parecchio e non trovo quasi
mai situazioni di illegibilita', l'estetica magari non e' il massimo ma
come utilizzo e' sicuramente meglio che si vedano anche i nomi.

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

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: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Hi Frederik
The Overpass query shows me this morning that with your last redaction the 
names are back for the 620 highways.
Thanks
 
Pierre 
 

Le mercredi 11 octobre 2017 13:08:42 HAE, Pierre Béland  
a écrit :  
 
 Re-visiting this changeset I see that of the 620 ways with tag 
"source:name"="geobase.ca", 552 ways have no name restored. See for example way 
32798176 where I validated the name + added source:name Overpass query 
http://overpass-turbo.eu/s/sh6

Pierre 
 
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[OSM-talk-be] Réunion OSM à Arlon - OSM Meeting in Arlon - 24 October 2017 at 19.30

[Pierre Parmentier]

To the OSM Mappers of the Luxembourg province and around,

We shall meet on Tuesday 24 October 2017 at 19.30 in Arlon.
Already 4 subscribed! WiFi available.
Meeting at the taverne Les Arcades, place Léopold 5.

--

Salut à tous les cartographes OSM de la province de Luxembourg et alentour,

Mardi 24 octobre 2017, à 19.30 h, réunion à Arlon.
Déjà 4 inscrits ! WiFi disponible.
Rendez-vous à la taverne Les Arcades, place Léopold 5.

Pierre P. /// foxandpotatoes
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] Alta Via dei Parchi (e percorsi a tappe con sovrarelazione in generale)

[liste DOT girarsi AT posteo DOT eu]

Il 13/10/2017 17:30, matteocalosi ha scritto:

Ciao,
starei accarezzando l'idea di mettermi ad aggiungere l'Alta Via dei Parchi
come route hiking visto che mi sembra sorprendemente assente al momento.
Però c'è una situazione preesistente in cui:
- La variante mtb è completamente presente come route, con le singole tappe
relazioni distinte raccolte in una sovrarelazione
- Le tappe 20-25 sono state aggiunte da un mappatore ma come route singole
con tag un po' opinabili



In ogni caso, puoi creare una relazione per tappa e togliere i dettagli 
di troppo dalle singole way che la riguardano nello specifico.


Poi crei la superroute con le singole relazioni, però ricorda che la 
superroute al momento, che io sappia, l'unico che le renderizza in 
un'unica route è waymarkedtrails.org, oppure quello che analizza anche 
le relazioni superroute è http://ra.osmsurround.org/, però quest'ultimo 
non renderizza, vedi solo i tag principali inseriti nella superroute.



--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-it-lazio] Incontri / was ...

[flaminiatumino]

Ciao,
Le volte che ci siamo incontrati abbiamo fatto un giro e mappato,
Un altra volta invece ci siamo visti in un posto,
Io personalmente preferirei rivederci e mappare in giro.
Avevamo iniziato con i murales e nel mentre mappato altri punti di Interesse 
che mancavano su open street map.
Tu che preferisci?
Flaminia 



> On 13 Oct 2017, at 17:21, FelynX  wrote:
> 
> Ciao,
> provo a riprendere...
> 
> Si fa un incontro a Roma?
> Come vi organizzate in genere? Incontri dove? Per strada mappando o in 
> qualeche luogo?
> Avevo letto da qualche parte di incontri a Ninux, è lì che vi incontrate?
> 
> Leggevo dell'inserimento dei civici, su questo tema avrei qualcosa di cui 
> parlarvi, però preferirei vivavoce
> 
> A presto
> 
> Il 2017-09-28 15:31 Martin Koppenhoefer ha scritto:
>> 2017-09-28 15:21 GMT+02:00 jprimav :
>>> Ciao Martin, Flaminia
>>> sarebbe bello continuare col progetto, dopo una lunghissima pausa
>>> estiva :)
>> Infatti. Quando potete? Ubaldo, Pelatom, Luca, ci state?
>> Ciao,
>> Martin
>> ___
>> Talk-it-lazio mailing list
>> Talk-it-lazio@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it-lazio
> 
> -- 
> FelynX // PP / #RomaPirata / ReTer
> 
> ___
> Talk-it-lazio mailing list
> Talk-it-lazio@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-lazio

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

[Talk-it] Alta Via dei Parchi (e percorsi a tappe con sovrarelazione in generale)

[matteocalosi]

Ciao,
starei accarezzando l'idea di mettermi ad aggiungere l'Alta Via dei Parchi
come route hiking visto che mi sembra sorprendemente assente al momento.
Però c'è una situazione preesistente in cui:
- La variante mtb è completamente presente come route, con le singole tappe
relazioni distinte raccolte in una sovrarelazione
- Le tappe 20-25 sono state aggiunte da un mappatore ma come route singole
con tag un po' opinabili

Mi adeguo a questo tipo di pratica e creo una sovrarelazione e ci metto le
singole tappe dentro? Non mi sta simpaticissima come cosa e preferirei fare
una singola relazione.

Poi, anche se appunto preferirei non farlo, vorrei qualche opinione su come
uno dovrebbe taggare un percorso con route tappe dentro una sovrarelazione
(vale anche per le varie tappe del Sentiero Italia che vedo sta aggiungendo
un altro mappatore): 

Sia sulle tappe preesistenti che sulla relazione mtb ci sono ref del tipo
AVP 21 e name del tipo "Alta Via dei Parchi - Tappa 21". Sui segnavia il n
di tappa non compare mai quindi io personalmente metterei per il ref
sicuramente solo AVP, per il name non so sia giusto "Alta Via dei Parchi" o
tenere la dicitura tappa che altrimenti non saprei in che tag mettere.
Come network meglio mettere singole tappe lwn e sovrarelazione rwn o tutto
rwn?



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

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-GB] Oxford Railway Station

[Richard Mann]

More correct than it was. I'm sure someone local will improve it ere long.

On 13 Oct 2017 12:46, "Dave F"  wrote:

> Hi
>
> Is there anybody familiar with Oxford Railway Station who could give it a
> check?  A user has made some amendments that don't appear correct. It's a
> few years since I've been & I'm aware there was some redevelopment in the
> area so feel ill-equipped to decide what's correct.
>
> Items I've noted:
> Is there still a short stay car park & a building?
> Buildings are duplicated
> Platform 2 is very narrow.
> Platform 1 drawing inaccurately & with unnecessary relation
>
> Cheers
> DaveF
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-in] old_name tag for merged Associate State Banks

[Srihari Thalla]

Chetan, Is there any possibility to update them via script?

I am not sure if Overpass API can download based on changes in changesets.
If not, manually going through the spreadsheet would be the obvious choice.

It would be better to write a script to query the histories of Bank amenity
objects
and import them into JOSM and update.

Scripting would, of course, need approval from the community!

Here are my changesets: OSMCha: https://goo.gl/V76HoH

I bundled all the changes into two changesets. (There are 5 other singled
out changesets too.)

Manually :: Downloading the changeset -> going through each object history
-> updating each object

What do you say would be a good idea?

On Fri 13 Oct, 2017, 17:03 Chetan H A,  wrote:

> Srihari, makes sense. I wonder how to get back deleted old names and add
> it in old_name tag in one go like you added?
>
>
>
> On Fri, Oct 13, 2017 at 2:37 PM, Srihari Thalla 
> wrote:
>
>> Hi,
>>
>> Back in May 2017, we have updated the name tags of merged Associate State
>> Banks from their old names (State Bank of xxx) to the new name, "State Bank
>> of India".
>>
>> We have identified and tracked the entries in a spreadsheet [1]. I have
>> updated many entries.
>> However, I forgot to add the old_name tag with the old name (State Bank
>> of xxx) and just updated the name tag to State Bank of India.
>>
>> I think it is good to have the old names in the old_name tag as people
>> might still remember the banks with their old names.
>>
>> Thoughts?
>>
>> Cheers,
>> Srihari
>>
>> [1] -
>> https://docs.google.com/spreadsheets/d/17VXVWQVF1rujmQiSQVrXiTOi2sRImh29I2JCGWCKaxc/edit#gid=1622201629
>>
>> talk-in Discussions
>> [1] -
>> https://lists.openstreetmap.org/pipermail/talk-in/2017-April/002862.html
>> [2] -
>> https://lists.openstreetmap.org/pipermail/talk-in/2017-May/002888.html
>>
>> cc Chetan, Bharata
>> --
>> Cheers,
>> Srihari
>>
>> ___
>> Talk-in mailing list
>> Talk-in@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-in
>>
>>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
-- 
Cheers,
Srihari
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

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-GB] Oxford Railway Station

[Dave F]

Hi

Is there anybody familiar with Oxford Railway Station who could give it 
a check?  A user has made some amendments that don't appear correct. 
It's a few years since I've been & I'm aware there was some 
redevelopment in the area so feel ill-equipped to decide what's correct.


Items I've noted:
Is there still a short stay car park & a building?
Buildings are duplicated
Platform 2 is very narrow.
Platform 1 drawing inaccurately & with unnecessary relation

Cheers
DaveF


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

[OSM-talk-be] mapping ALPR cameras (in Ghent)

[Santens Seppe]

Hi all,

I was triggered by a tweet from a journalist 
(https://twitter.com/bertstaes/status/918017848844476416) to start mapping ALPR 
cameras in Ghent that control access to the "car free area". Could you have a 
look at one example I tried to work out? All advice is welcome.

http://www.openstreetmap.org/node/5160676344

Some questions:

*Can this camera used for access enforcement be seen as a surveillance 
camera? In other words, is it ok to use man_made=surveillance for this?

*I added an enforcement relation with this camera as "device". I put 
the node where the traffic sign is as "from", but I don't see which node I 
should put as "to". Can I just choose the next node on this way (that would be 
http://www.openstreetmap.org/node/201250401). It seems ok to me, but also a bit 
arbitrary...

Other suggestions?

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

Re: [Talk-in] old_name tag for merged Associate State Banks

[Chetan H A]

Srihari, makes sense. I wonder how to get back deleted old names and add it
in old_name tag in one go like you added?



On Fri, Oct 13, 2017 at 2:37 PM, Srihari Thalla 
wrote:

> Hi,
>
> Back in May 2017, we have updated the name tags of merged Associate State
> Banks from their old names (State Bank of xxx) to the new name, "State Bank
> of India".
>
> We have identified and tracked the entries in a spreadsheet [1]. I have
> updated many entries.
> However, I forgot to add the old_name tag with the old name (State Bank of
> xxx) and just updated the name tag to State Bank of India.
>
> I think it is good to have the old names in the old_name tag as people
> might still remember the banks with their old names.
>
> Thoughts?
>
> Cheers,
> Srihari
>
> [1] - https://docs.google.com/spreadsheets/d/
> 17VXVWQVF1rujmQiSQVrXiTOi2sRImh29I2JCGWCKaxc/edit#gid=1622201629
>
> talk-in Discussions
> [1] - https://lists.openstreetmap.org/pipermail/talk-in/2017-
> April/002862.html
> [2] - https://lists.openstreetmap.org/pipermail/talk-in/2017-
> May/002888.html
>
> cc Chetan, Bharata
> --
> Cheers,
> Srihari
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[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-cz] Školení Alpina

[Vladimír Slávik]

Rád bych pomohl, ale jako obvykle se mi tam nacpala nějaká svatba, takže
holt ani jedno. Někdo nahoře nechce abych se kamarádil s českými mapery :P

V.
-- Původní e-mail --
Od: Marián Kyral 
Komu: OpenStreetMap Czech Republic 
Datum: 13. 10. 2017 13:16:47
Předmět: Re: [Talk-cz] Školení Alpina
"
-- Původní e-mail --
Od: Miroslav Suchy 
Komu: OpenStreetMap Czech Republic 
Datum: 13. 10. 2017 13:11:11
Předmět: [Talk-cz] Školení Alpina
"Ahoj,
4.11. budu dělat školení o OpenStreetMap pro průvodce Alpiny v Brně. Bude to
celý den.
Zatím nemám vůbec tušení kolik tam bude lidí. Ale pokud by mi s tím někdo
chtěl pomoci, tak neodmítnu.
Akorát je problém, že to konfliktí se sobotním programem OpenAltu. :( Což je
zároveň důvod, proč mě v sobotu na OpenAltu
neuvidíte.
"



Snad se někdo najde. Já mám v sobotu přednášku pro širší veřejnost, takže
budu muset na OpenAlt ;-)




Marián

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

Re: [Talk-cz] Školení Alpina

[Marián Kyral]

-- Původní e-mail --
Od: Miroslav Suchy 
Komu: OpenStreetMap Czech Republic 
Datum: 13. 10. 2017 13:11:11
Předmět: [Talk-cz] Školení Alpina
"Ahoj,
4.11. budu dělat školení o OpenStreetMap pro průvodce Alpiny v Brně. Bude to
celý den.
Zatím nemám vůbec tušení kolik tam bude lidí. Ale pokud by mi s tím někdo
chtěl pomoci, tak neodmítnu.
Akorát je problém, že to konfliktí se sobotním programem OpenAltu. :( Což je
zároveň důvod, proč mě v sobotu na OpenAltu
neuvidíte.
"



Snad se někdo najde. Já mám v sobotu přednášku pro širší veřejnost, takže
budu muset na OpenAlt ;-)




Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Školení Alpina

[Miroslav Suchy]

Ahoj,
4.11. budu dělat školení o OpenStreetMap pro průvodce Alpiny v Brně. Bude to 
celý den.
Zatím nemám vůbec tušení kolik tam bude lidí. Ale pokud by mi s tím někdo chtěl 
pomoci, tak neodmítnu.
Akorát je problém, že to konfliktí se sobotním programem OpenAltu. :( Což je 
zároveň důvod, proč mě v sobotu na OpenAltu
neuvidíte.

Mirek

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

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

[Talk-in] old_name tag for merged Associate State Banks

[Srihari Thalla]

Hi,

Back in May 2017, we have updated the name tags of merged Associate State
Banks from their old names (State Bank of xxx) to the new name, "State Bank
of India".

We have identified and tracked the entries in a spreadsheet [1]. I have
updated many entries.
However, I forgot to add the old_name tag with the old name (State Bank of
xxx) and just updated the name tag to State Bank of India.

I think it is good to have the old names in the old_name tag as people
might still remember the banks with their old names.

Thoughts?

Cheers,
Srihari

[1] -
https://docs.google.com/spreadsheets/d/17VXVWQVF1rujmQiSQVrXiTOi2sRImh29I2JCGWCKaxc/edit#gid=1622201629

talk-in Discussions
[1] -
https://lists.openstreetmap.org/pipermail/talk-in/2017-April/002862.html
[2] - https://lists.openstreetmap.org/pipermail/talk-in/2017-May/002888.html

cc Chetan, Bharata
-- 
Cheers,
Srihari
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

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

semanarioOSM Nº 377 2017-10-03-2017-10-09

[weeklyteam]

Hola, el semanario Nº 377, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

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

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

semanarioOSM Nº 377 2017-10-03-2017-10-09

[weeklyteam]

Hola, el semanario Nº 377, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

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

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cu mailing list
Talk-cu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cu

semanarioOSM Nº 377 2017-10-03-2017-10-09

[weeklyteam]

Hola, el semanario Nº 377, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

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

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

semanarioOSM Nº 377 2017-10-03-2017-10-09

[weeklyteam]

Hola, el semanario Nº 377, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

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

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

semanarioOSM Nº 377 2017-10-03-2017-10-09

[weeklyteam]

Hola, el semanario Nº 377, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

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

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

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

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

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

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

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

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

[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