Re: [Talk-us] Check your turn:lanes

[Jack Burke]

I have to disagree. If that's how to interpret  the tags, then the tagging 
definition is deficient. 

Under that interpretation, how do you tag a lane that both continues and 
branches off as an exit, but doesn't have signage that it continues? 


-- 
Typos courtesy of fancy auto spell technology

On August 25, 2016 1:22:58 AM EDT, David Mease  wrote:
>According to the wiki, "none" means that there are no indications on
>the lane. The value "none;slight_right" says that there are both no
>indications and a slight right indication on the lane, which is of
>course impossible. These "scripted" edits are therefore a correct
>interpretation of the original tagging. The problem here is that the
>original tagging was incorrect.
>
>> On Aug 24, 2016, at 7:24 PM, Jack Burke  wrote:
>> 
>> And I, too, have a preference for using "none" instead of leaving and
>endless line of "|" to try to parse.  My eyesight isn't getting
>better as I get older.
>> 
>> Having said that, if that had been the only thing they did, I
>wouldn't have bothered saying anything.  But when their edits turned
>continuing lanes into exit-only lanes...well, then it became a
>*problem*.
>> 
>>> On Wed, Aug 24, 2016 at 8:20 PM, Tod Fitch 
>wrote:
>>> I’m of half a mind to use a script to find the edits in my area
>where they changed something like “left|none|none|” to “left||” and
>then revert them manually.
>>> 
>>> I know they are both officially acceptable variations but for those
>of us editing by hand counting the occurrences of “|none” to make sure
>the lane count is correct and matches what is on the ground is harder
>than counting the “|” occurrences. At least it is for me and I’ve had
>decades of practice counting open and close parens to make sure
>compilers wouldn’t squawk at me because they weren’t balanced.
>>> 
>>> And while I haven’t seen a “none;slight_right”, it looks syntacticly
>correct and I can imagine cases where it might be used and would defer
>to the local mapper who used it. (The ones in my area are much more
>likely to be “through;slight_right”.)
>>> 
>>> 
>>> 
 On Aug 24, 2016, at 4:52 PM, Jack Burke  wrote:
 
 No, it's https://github.com/mapbox/mapping/issues/193
 
 And they appear to be telling me that the combination
>"none;slight_right" isn't valid.
 
 Also, in their reply to me, they do specifically mention that they
>know none is valid, yet they're replacing it anyway.  And the worst
>part of it is that while they're using a script to *find* what they
>think is invalid, they're *manually* making the changes.
 
 --jack
 
> On Wed, Aug 24, 2016 at 7:31 PM, Hans De Kryger
> wrote:
> The link Jack's talking about,
> 
> https://github.com/mapbox/mapping/issues/180
> 
> Regards,
> Hans
> 
> 
>> On Aug 24, 2016 4:09 PM, "Toby Murray" 
>wrote:
>> Mind sharing the link to the GitHub issue?
>> 
>> Do they think that "none" is an invalid option and are replacing
>it
>> with a blank globally? If so, this should be shut down
>immediately.
>> "none" and blank are both valid values and while I wouldn't mind
>> seeing it be consistent, any such edit would need to be discussed
>> before it is done.
>> 
>> Toby
>> 
>> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke 
>wrote:
>> > An active OSM group (leaving names, etc. out while they check
>out what I
>> > reported) is running a script or plug-in or challenge called
>"to-fix" that
>> > is apparently supposed to help fix incorrect turn:lanes values
>(and maybe
>> > other things, I haven't investigated deeply enough).
>> >
>> > The problem is, it's breaking the values instead.  I found a
>section of road
>> > that I'd added turn:lanes to in order to provide lane guidance
>at an exit.
>> > My original value of "none|none|none|none|none;slight_right"
>was replaced by
>> > "slight_right".
>> >
>> > While, per the wiki, there's nothing particularly wrong with a
>null value
>> > for a field vs. specifying "none" as the value, it *does* make
>a difference
>> > when there are two values in the field, as in my example above.
> They turned
>> > a continue-on-or-exit lane into an exit-only lane.
>> >
>> > So if you find broken lane guidance like that, with empty
>fields where
>> > "none" would also be appropriate, that's probably what
>happened.  Check the
>> > history on the way and see if you can backtrack what happened
>(fortunately,
>> > the group involved here included a url to a github issue where
>they are
>> > tracking what they're doing).
>> >
>> > Now I have 200 miles of Interstate to go back through and
>re-check.
>> >
>> > --jack
>> >
>> >
>> > ___
>> > Talk-us mailing list
>> > Talk-us@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-us
>> >
>> 
>> _

Re: [Talk-us] Check your turn:lanes

[David Mease]

According to the wiki, "none" means that there are no indications on the lane. 
The value "none;slight_right" says that there are both no indications and a 
slight right indication on the lane, which is of course impossible. These 
"scripted" edits are therefore a correct interpretation of the original 
tagging. The problem here is that the original tagging was incorrect.

> On Aug 24, 2016, at 7:24 PM, Jack Burke  wrote:
> 
> And I, too, have a preference for using "none" instead of leaving and endless 
> line of "|" to try to parse.  My eyesight isn't getting better as I 
> get older.
> 
> Having said that, if that had been the only thing they did, I wouldn't have 
> bothered saying anything.  But when their edits turned continuing lanes into 
> exit-only lanes...well, then it became a *problem*.
> 
>> On Wed, Aug 24, 2016 at 8:20 PM, Tod Fitch  wrote:
>> I’m of half a mind to use a script to find the edits in my area where they 
>> changed something like “left|none|none|” to “left||” and then revert them 
>> manually.
>> 
>> I know they are both officially acceptable variations but for those of us 
>> editing by hand counting the occurrences of “|none” to make sure the lane 
>> count is correct and matches what is on the ground is harder than counting 
>> the “|” occurrences. At least it is for me and I’ve had decades of practice 
>> counting open and close parens to make sure compilers wouldn’t squawk at me 
>> because they weren’t balanced.
>> 
>> And while I haven’t seen a “none;slight_right”, it looks syntacticly correct 
>> and I can imagine cases where it might be used and would defer to the local 
>> mapper who used it. (The ones in my area are much more likely to be 
>> “through;slight_right”.)
>> 
>> 
>> 
>>> On Aug 24, 2016, at 4:52 PM, Jack Burke  wrote:
>>> 
>>> No, it's https://github.com/mapbox/mapping/issues/193
>>> 
>>> And they appear to be telling me that the combination "none;slight_right" 
>>> isn't valid.
>>> 
>>> Also, in their reply to me, they do specifically mention that they know 
>>> none is valid, yet they're replacing it anyway.  And the worst part of it 
>>> is that while they're using a script to *find* what they think is invalid, 
>>> they're *manually* making the changes.
>>> 
>>> --jack
>>> 
 On Wed, Aug 24, 2016 at 7:31 PM, Hans De Kryger 
  wrote:
 The link Jack's talking about,
 
 https://github.com/mapbox/mapping/issues/180
 
 Regards,
 Hans
 
 
> On Aug 24, 2016 4:09 PM, "Toby Murray"  wrote:
> Mind sharing the link to the GitHub issue?
> 
> Do they think that "none" is an invalid option and are replacing it
> with a blank globally? If so, this should be shut down immediately.
> "none" and blank are both valid values and while I wouldn't mind
> seeing it be consistent, any such edit would need to be discussed
> before it is done.
> 
> Toby
> 
> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke  wrote:
> > An active OSM group (leaving names, etc. out while they check out what I
> > reported) is running a script or plug-in or challenge called "to-fix" 
> > that
> > is apparently supposed to help fix incorrect turn:lanes values (and 
> > maybe
> > other things, I haven't investigated deeply enough).
> >
> > The problem is, it's breaking the values instead.  I found a section of 
> > road
> > that I'd added turn:lanes to in order to provide lane guidance at an 
> > exit.
> > My original value of "none|none|none|none|none;slight_right" was 
> > replaced by
> > "slight_right".
> >
> > While, per the wiki, there's nothing particularly wrong with a null 
> > value
> > for a field vs. specifying "none" as the value, it *does* make a 
> > difference
> > when there are two values in the field, as in my example above.  They 
> > turned
> > a continue-on-or-exit lane into an exit-only lane.
> >
> > So if you find broken lane guidance like that, with empty fields where
> > "none" would also be appropriate, that's probably what happened.  Check 
> > the
> > history on the way and see if you can backtrack what happened 
> > (fortunately,
> > the group involved here included a url to a github issue where they are
> > tracking what they're doing).
> >
> > Now I have 200 miles of Interstate to go back through and re-check.
> >
> > --jack
> >
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
> >
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>>> 
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinf

Re: [Talk-us] Check your turn:lanes

[Bryan Housel]

This was discussed extensively on the tagging mailing list 2 months ago:
https://lists.openstreetmap.org/pipermail/tagging/2016-June/029335.html 


The consensus at the time was that combinations including ‘none’ are not valid, 
and people should use `transit:lanes` style tags to indicate what happens to a 
lane - whether it branches, forks, or ends.

see http://wiki.openstreetmap.org/wiki/Proposed_features/transit 
  for more 
details.

At the time of that thread, I did use taginfo to search for values like 
`none;left` or `none;slight_right`, and there were only a handful of such lanes 
worldwide - maybe 10 or so.

Thanks, Bryan



> On Aug 25, 2016, at 4:48 AM, Jack Burke  wrote:
> 
> I have to disagree. If that's how to interpret the tags, then the tagging 
> definition is deficient. 
> 
> Under that interpretation, how do you tag a lane that both continues and 
> branches off as an exit, but doesn't have signage that it continues? 
> 
> 
> -- 
> Typos courtesy of fancy auto spell technology
> 
> On August 25, 2016 1:22:58 AM EDT, David Mease  wrote:
> According to the wiki, "none" means that there are no indications on the 
> lane. The value "none;slight_right" says that there are both no indications 
> and a slight right indication on the lane, which is of course impossible. 
> These "scripted" edits are therefore a correct interpretation of the original 
> tagging. The problem here is that the original tagging was incorrect.
> 
> On Aug 24, 2016, at 7:24 PM, Jack Burke  > wrote:
> 
>> And I, too, have a preference for using "none" instead of leaving and 
>> endless line of "|" to try to parse.  My eyesight isn't getting 
>> better as I get older.
>> 
>> Having said that, if that had been the only thing they did, I wouldn't have 
>> bothered saying anything.  But when their edits turned continuing lanes into 
>> exit-only lanes...well, then it became a *problem*.
>> 
>> On Wed, Aug 24, 2016 at 8:20 PM, Tod Fitch > > wrote:
>> I’m of half a mind to use a script to find the edits in my area where they 
>> changed something like “left|none|none|” to “left||” and then revert them 
>> manually.
>> 
>> I know they are both officially acceptable variations but for those of us 
>> editing by hand counting the occurrences of “|none” to make sure the lane 
>> count is correct and matches what is on the ground is harder than counting 
>> the “|” occurrences. At least it is for me and I’ve had decades of practice 
>> counting open and close parens to make sure compilers wouldn’t squawk at me 
>> because they weren’t balanced.
>> 
>> And while I haven’t seen a “none;slight_right”, it looks syntacticly correct 
>> and I can imagine cases where it might be used and would defer to the local 
>> mapper who used it. (The ones in my area are much more likely to be 
>> “through;slight_right”.)
>> 
>> 
>> 
>>> On Aug 24, 2016, at 4:52 PM, Jack Burke >> > wrote:
>>> 
>>> No, it's https://github.com/mapbox/mapping/issues/193 
>>> 
>>> 
>>> And they appear to be telling me that the combination "none;slight_right" 
>>> isn't valid.
>>> 
>>> Also, in their reply to me, they do specifically mention that they know 
>>> none is valid, yet they're replacing it anyway.  And the worst part of it 
>>> is that while they're using a script to *find* what they think is invalid, 
>>> they're *manually* making the changes.
>>> 
>>> --jack
>>> 
>>> On Wed, Aug 24, 2016 at 7:31 PM, Hans De Kryger >> > wrote:
>>> The link Jack's talking about,
>>> 
>>> https://github.com/mapbox/mapping/issues/180 
>>> 
>>> Regards,
>>> Hans
>>> 
>>> 
>>> On Aug 24, 2016 4:09 PM, "Toby Murray" >> > wrote:
>>> Mind sharing the link to the GitHub issue?
>>> 
>>> Do they think that "none" is an invalid option and are replacing it
>>> with a blank globally? If so, this should be shut down immediately.
>>> "none" and blank are both valid values and while I wouldn't mind
>>> seeing it be consistent, any such edit would need to be discussed
>>> before it is done.
>>> 
>>> Toby
>>> 
>>> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke >> > wrote:
>>> > An active OSM group (leaving names, etc. out while they check out what I
>>> > reported) is running a script or plug-in or challenge called "to-fix" that
>>> > is apparently supposed to help fix incorrect turn:lanes values (and maybe
>>> > other things, I haven't investigated deeply enough).
>>> >
>>> > The problem is, it's breaking the values instead.  I found a section of 
>>> > road
>>> > that I'd added turn:lanes to in order to provide lane guidance at an exit.
>>> > My original value of "none|none|none|none|none;slig

Re: [Talk-us] Check your turn:lanes

[Paul Johnson]

On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke  wrote:

> An active OSM group (leaving names, etc. out while they check out what I
> reported) is running a script or plug-in or challenge called "to-fix" that
> is apparently supposed to help fix incorrect turn:lanes values (and maybe
> other things, I haven't investigated deeply enough).
>
> The problem is, it's breaking the values instead.  I found a section of
> road that I'd added turn:lanes to in order to provide lane guidance at an
> exit.  My original value of "none|none|none|none|none;slight_right" was
> replaced by "slight_right".
>

You may want to try through|through|through|through|through;slight_right as
the value; I've noticed routers that actually use this data struggle with
null or none values, which isn't *entirely* unreasonable, but the former
does describe the allowed movements even if the DOT doesn't feel the need
to explicitly paint it out.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

Even if the road isn't signed that way?  The use of "through" when there is
no explicit marking to that effect seems to be contraindicated by the wiki.

Don't get me wrong--I don't see why we _couldn't_ use it when that is the
obvious traffic direction, even with the lack of explicit signage.  But if
that's how we want to use "through" then shouldn't we update the wiki to be
more clear?



On Thu, Aug 25, 2016 at 10:58 AM, Paul Johnson  wrote:

> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke  wrote:
>
>> An active OSM group (leaving names, etc. out while they check out what I
>> reported) is running a script or plug-in or challenge called "to-fix" that
>> is apparently supposed to help fix incorrect turn:lanes values (and maybe
>> other things, I haven't investigated deeply enough).
>>
>> The problem is, it's breaking the values instead.  I found a section of
>> road that I'd added turn:lanes to in order to provide lane guidance at an
>> exit.  My original value of "none|none|none|none|none;slight_right" was
>> replaced by "slight_right".
>>
>
> You may want to try through|through|through|through|through;slight_right
> as the value; I've noticed routers that actually use this data struggle
> with null or none values, which isn't *entirely* unreasonable, but the
> former does describe the allowed movements even if the DOT doesn't feel the
> need to explicitly paint it out.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Paul Johnson]

On Thu, Aug 25, 2016 at 11:04 AM, Jack Burke  wrote:

> Even if the road isn't signed that way?  The use of "through" when there
> is no explicit marking to that effect seems to be contraindicated by the
> wiki.
>

I'm considering the ground truth in this case to be how the lane can
actually be legally used, since (at least in North America where the
direction of travel is obviated by the yellow centerline) lane arrows are
much less common than in some other parts in the world.  Otherwise most
intersections with turn pockets would end up as none|none|none|none instead
of left|through|through|right.  Low-angle intersections are especially
tricky for routing engines; in absense of anything other than a lane count,
for example, Osmand will "invent" a new lane for the departing ramp
(indicating say, the right most of through|through|through) instead of the
correct through|through;slight_right (with the slight_right highlighted).


> Don't get me wrong--I don't see why we _couldn't_ use it when that is the
> obvious traffic direction, even with the lack of explicit signage.  But if
> that's how we want to use "through" then shouldn't we update the wiki to be
> more clear?
>

I think the wiki should be updated, yes, since the wiki's not describing
how it's been implemented in the real world right now.  Though, to be fair,
the only consumer I know that's actually doing anything with this data
right now is Osmand.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[David Mease]

>From the wiki:

The *turn*=* key can be used to specify the *indicated* direction in which
a way or a lane will lead. It is used on the way segment from the first
indication via *road markings*, *signposts* or similar indications to the
junction or completion of merge. If you instead want to specify legal
turning restrictions please see the article about the restriction relation
.

The turn:lanes schema is for identifying the painted/signed lane marking
arrows, not for describing where you can legally go from that lane. That's
what the turn restriction relation is for.

Putting "through" on a lane means that there is a straight arrow painted on
it. Putting "none" on a lane means that there is no marking.

On Thu, Aug 25, 2016 at 9:04 AM, Jack Burke  wrote:

> Even if the road isn't signed that way?  The use of "through" when there
> is no explicit marking to that effect seems to be contraindicated by the
> wiki.
>
> Don't get me wrong--I don't see why we _couldn't_ use it when that is the
> obvious traffic direction, even with the lack of explicit signage.  But if
> that's how we want to use "through" then shouldn't we update the wiki to be
> more clear?
>
>
>
> On Thu, Aug 25, 2016 at 10:58 AM, Paul Johnson 
> wrote:
>
>> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke  wrote:
>>
>>> An active OSM group (leaving names, etc. out while they check out what I
>>> reported) is running a script or plug-in or challenge called "to-fix" that
>>> is apparently supposed to help fix incorrect turn:lanes values (and maybe
>>> other things, I haven't investigated deeply enough).
>>>
>>> The problem is, it's breaking the values instead.  I found a section of
>>> road that I'd added turn:lanes to in order to provide lane guidance at an
>>> exit.  My original value of "none|none|none|none|none;slight_right" was
>>> replaced by "slight_right".
>>>
>>
>> You may want to try through|through|through|through|through;slight_right
>> as the value; I've noticed routers that actually use this data struggle
>> with null or none values, which isn't *entirely* unreasonable, but the
>> former does describe the allowed movements even if the DOT doesn't feel the
>> need to explicitly paint it out.
>>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

So I take it that at least you and I are in agreement that the wiki is
deficient for branching exits like this one:  http://mapillary.com/map/im/
7igAGXSa6EsUYlTIujXchw

Your Osmand "invention" example is a perfect case-study of what I'm working
on.  I'm trying to get exits on I 75 in Georgia and Florida tagged with
destination and lane guidance so that Osmand can show proper guidance, and
hopefully other OSM-based navigation apps will add that feature, too.  As
it stands, I use Osmand to test my tags.




On Thu, Aug 25, 2016 at 12:55 PM, Paul Johnson  wrote:

> On Thu, Aug 25, 2016 at 11:04 AM, Jack Burke  wrote:
>
>> Even if the road isn't signed that way?  The use of "through" when there
>> is no explicit marking to that effect seems to be contraindicated by the
>> wiki.
>>
>
> I'm considering the ground truth in this case to be how the lane can
> actually be legally used, since (at least in North America where the
> direction of travel is obviated by the yellow centerline) lane arrows are
> much less common than in some other parts in the world.  Otherwise most
> intersections with turn pockets would end up as none|none|none|none instead
> of left|through|through|right.  Low-angle intersections are especially
> tricky for routing engines; in absense of anything other than a lane count,
> for example, Osmand will "invent" a new lane for the departing ramp
> (indicating say, the right most of through|through|through) instead of the
> correct through|through;slight_right (with the slight_right highlighted).
>
>
>> Don't get me wrong--I don't see why we _couldn't_ use it when that is the
>> obvious traffic direction, even with the lack of explicit signage.  But if
>> that's how we want to use "through" then shouldn't we update the wiki to be
>> more clear?
>>
>
> I think the wiki should be updated, yes, since the wiki's not describing
> how it's been implemented in the real world right now.  Though, to be fair,
> the only consumer I know that's actually doing anything with this data
> right now is Osmand.
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

Thus my problem.  The wiki doesn't consider what to do when there's a
branching exit.  It's a complete hole in the tagging schema, even though
it's probably the most common type of freeway exit in the U.S.

So, since there is no "through" indication, I resorted to
"none;slight_right" even though the usage of "none" is technically
incorrect because there *is* a signed indication of a slight_right.  But
being incorrect that way seemed better than being incorrect by using
"through;slight_right".

On Thu, Aug 25, 2016 at 12:58 PM, David Mease  wrote:

>
> From the wiki:
>
> The *turn*=* key can be used to specify the *indicated* direction in
> which a way or a lane will lead. It is used on the way segment from the
> first indication via *road markings*, *signposts* or similar indications
> to the junction or completion of merge. If you instead want to specify
> legal turning restrictions please see the article about the restriction
> relation .
>
> The turn:lanes schema is for identifying the painted/signed lane marking
> arrows, not for describing where you can legally go from that lane. That's
> what the turn restriction relation is for.
>
> Putting "through" on a lane means that there is a straight arrow painted
> on it. Putting "none" on a lane means that there is no marking.
>
> On Thu, Aug 25, 2016 at 9:04 AM, Jack Burke  wrote:
>
>> Even if the road isn't signed that way?  The use of "through" when there
>> is no explicit marking to that effect seems to be contraindicated by the
>> wiki.
>>
>> Don't get me wrong--I don't see why we _couldn't_ use it when that is the
>> obvious traffic direction, even with the lack of explicit signage.  But if
>> that's how we want to use "through" then shouldn't we update the wiki to be
>> more clear?
>>
>>
>>
>> On Thu, Aug 25, 2016 at 10:58 AM, Paul Johnson 
>> wrote:
>>
>>> On Wed, Aug 24, 2016 at 5:19 PM, Jack Burke  wrote:
>>>
 An active OSM group (leaving names, etc. out while they check out what
 I reported) is running a script or plug-in or challenge called "to-fix"
 that is apparently supposed to help fix incorrect turn:lanes values (and
 maybe other things, I haven't investigated deeply enough).

 The problem is, it's breaking the values instead.  I found a section of
 road that I'd added turn:lanes to in order to provide lane guidance at an
 exit.  My original value of "none|none|none|none|none;slight_right"
 was replaced by "slight_right".

>>>
>>> You may want to try through|through|through|through|through;slight_right
>>> as the value; I've noticed routers that actually use this data struggle
>>> with null or none values, which isn't *entirely* unreasonable, but the
>>> former does describe the allowed movements even if the DOT doesn't feel the
>>> need to explicitly paint it out.
>>>
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Paul Johnson]

On Thu, Aug 25, 2016 at 11:58 AM, David Mease  wrote:

>
> From the wiki:
>
> The *turn*=* key can be used to specify the *indicated* direction in
> which a way or a lane will lead. It is used on the way segment from the
> first indication via *road markings*, *signposts* or similar indications
> to the junction or completion of merge. If you instead want to specify
> legal turning restrictions please see the article about the restriction
> relation .
>
> The turn:lanes schema is for identifying the painted/signed lane marking
> arrows, not for describing where you can legally go from that lane. That's
> what the turn restriction relation is for.
>

No, turn restriction relations describe restrictions applying for *the
entire movement* defined in the restriction, from *any* lane.


> Putting "through" on a lane means that there is a straight arrow painted
> on it. Putting "none" on a lane means that there is no marking.
>

I really think this is an overly generous view and essentially renders lane
tagging nearly useless as a result, and is the exact opposite of how it's
actually being used.  Remember, the wiki should reflect how things work in
practice, particularly once something's established enough to get
rendering/routing based on it.  As previously indicated, in statistically
significant parts of the world, turn lanes are implied by context and
position and not by signs and lane markings, unless the usage is
nonstandard.  Additionally, routing engines typically interpret "none" or
blank as "there is no specific restriction on which way you can go from
this lane", so lane usage for a right turn will light up all the none lanes
and the right turn lane.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Paul Johnson]

On Thu, Aug 25, 2016 at 12:09 PM, Jack Burke  wrote:

> So I take it that at least you and I are in agreement that the wiki is
> deficient for branching exits like this one:
> http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>

Yes, that's correct.  Moving a couple frames closer to
http://mapillary.com/map/im/MsMAW3HKVNYxEVCtkRneBg, here's how I would tag
three segments based on what's visible there and no other context:

Ahead of camera after diverging ramp:

highway=motorway
oneway=yes
lanes=3
ref=I 75
hgv:lanes=no|yes|yes

The ramp from the physical gore (next to the exit sign) to the tip of the
theoretical (painted) gore (with the node for the intersection being even
with the theoretical gore):

highway=motorway_link
oneway=yes
placement=transition
lanes=1
destination=Sycamore;Ocilla
destination:ref=GA 32  (also, damn, had to check the minimap on that, I
almost said MO 32 based on the shape).
junction:ref=78

Behind the camera:

highway=motorway
oneway=yes
lanes=3
ref=I 75
hgv:lanes=no|yes|yes
turn:lanes=through|through|through;slight_right

Your Osmand "invention" example is a perfect case-study of what I'm working
> on.  I'm trying to get exits on I 75 in Georgia and Florida tagged with
> destination and lane guidance so that Osmand can show proper guidance, and
> hopefully other OSM-based navigation apps will add that feature, too.  As
> it stands, I use Osmand to test my tags.
>

I've been testing this, as well.  I'm fortunate enough to live in a city
that has nearly every kind of interchange to play with (except for some of
the newer CFI styles, but OKC and...for like, no reason, rural interchanges
with basically no traffic on I 40 leading into the Ouachitas are getting
those) and well enough aware of the tagging in play to have seen what works
and what doesn't, now.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Toby Murray]

On Thu, Aug 25, 2016 at 12:09 PM, Jack Burke  wrote:
> So I take it that at least you and I are in agreement that the wiki is
> deficient for branching exits like this one:
> http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw

Why does this example even need any special lane tagging? I would map
this as lanes=3 on the motorway and then draw the motorway_link with a
lanes=1 tag out to right in front of where that picture is. Right now
the motorway_link doesn't branch off of the main way until WAY past
where the white solid line starts and where you must commit to the
exit.

Toby

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

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

Fixing where the motorway_link branches out is also one of the things I'm
working on fixing with this project.

But as to why...so that a navigation app can provide proper lane guidance.
I selected this particular example because it's very simple, without other
details to clutter up the discussion.  But in large cities, such as Atlanta
where we have a lot of freeway exits just around a curve and you can't see
them in time, it can be incredibly important to know what lane you need to
be in well ahead of time--especially in periods of heavy traffic, were you
can't get into the correct lane at the last minute.

On Thu, Aug 25, 2016 at 1:42 PM, Toby Murray  wrote:

> On Thu, Aug 25, 2016 at 12:09 PM, Jack Burke  wrote:
> > So I take it that at least you and I are in agreement that the wiki is
> > deficient for branching exits like this one:
> > http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>
> Why does this example even need any special lane tagging? I would map
> this as lanes=3 on the motorway and then draw the motorway_link with a
> lanes=1 tag out to right in front of where that picture is. Right now
> the motorway_link doesn't branch off of the main way until WAY past
> where the white solid line starts and where you must commit to the
> exit.
>
> Toby
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Jack Burke]

Paul, your examples are pretty much exactly what I've been doing, with the
exception that for the last one I was using:

turn:lanes=none|none|none;slight_right

because of the aforementioned discussion of whether or not to use "through"
without signage.

--jack

On Thu, Aug 25, 2016 at 1:38 PM, Paul Johnson  wrote:

> On Thu, Aug 25, 2016 at 12:09 PM, Jack Burke  wrote:
>
>> So I take it that at least you and I are in agreement that the wiki is
>> deficient for branching exits like this one:
>> http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>>
>
> Yes, that's correct.  Moving a couple frames closer to
> http://mapillary.com/map/im/MsMAW3HKVNYxEVCtkRneBg, here's how I would
> tag three segments based on what's visible there and no other context:
>
> Ahead of camera after diverging ramp:
>
> highway=motorway
> oneway=yes
> lanes=3
> ref=I 75
> hgv:lanes=no|yes|yes
>
> The ramp from the physical gore (next to the exit sign) to the tip of the
> theoretical (painted) gore (with the node for the intersection being even
> with the theoretical gore):
>
> highway=motorway_link
> oneway=yes
> placement=transition
> lanes=1
> destination=Sycamore;Ocilla
> destination:ref=GA 32  (also, damn, had to check the minimap on that, I
> almost said MO 32 based on the shape).
> junction:ref=78
>
> Behind the camera:
>
> highway=motorway
> oneway=yes
> lanes=3
> ref=I 75
> hgv:lanes=no|yes|yes
> turn:lanes=through|through|through;slight_right
>
> Your Osmand "invention" example is a perfect case-study of what I'm
>> working on.  I'm trying to get exits on I 75 in Georgia and Florida tagged
>> with destination and lane guidance so that Osmand can show proper guidance,
>> and hopefully other OSM-based navigation apps will add that feature, too.
>> As it stands, I use Osmand to test my tags.
>>
>
> I've been testing this, as well.  I'm fortunate enough to live in a city
> that has nearly every kind of interchange to play with (except for some of
> the newer CFI styles, but OKC and...for like, no reason, rural interchanges
> with basically no traffic on I 40 leading into the Ouachitas are getting
> those) and well enough aware of the tagging in play to have seen what works
> and what doesn't, now.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Paul Johnson]

On Thu, Aug 25, 2016 at 12:42 PM, Toby Murray  wrote:

> On Thu, Aug 25, 2016 at 12:09 PM, Jack Burke  wrote:
> > So I take it that at least you and I are in agreement that the wiki is
> > deficient for branching exits like this one:
> > http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>
> Why does this example even need any special lane tagging? I would map
> this as lanes=3 on the motorway and then draw the motorway_link with a
> lanes=1 tag out to right in front of where that picture is.


Because what's obvious to a human isn't going to be obvious to a machine.
Let's try a similar but slightly more complicated example with no lane
markings but definite turn lanes:

http://mapillary.com/map/im/Usplvj-EDevqwnBbZmXvQA

Right now the section leading up to the junction is tagged
"slight_left|slight_left;through|through", with the left junction being
"junction:ref=2" "destination=Glenpool;Okmulgee" and "destination:ref=US 75
South"; the right route is "destination=Oklahoma City", "destination:ref=I
244 West".   The turn lane part is technically correct, but the ground
perspective makes it look almost the opposite; I'm considering changing the
"through|through" part to "slight_right|slight_right" for clarity
(especially given that almost all traffic exits I 244 for Exit 2 towards
Okmulgee here).  Osmand invents four lanes without the lane tagging, which
doesn't help if you're still behind the curve and don't know the setup at
the decision point.


> Right now
> the motorway_link doesn't branch off of the main way until WAY past
> where the white solid line starts and where you must commit to the
> exit.
>

I would put the motorway_junction node at the commit point (the start of
the theoretical gore).  Extending the ramp lane centerline tends to be
messy and cause routers to assume you've already left the freeway before
you've even made the turn on particularly wide motorways.  Obviously I'm
not actually looking at the data to see what it is right now.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Check your turn:lanes

[Paul Johnson]

Here's another example of how none breaks:
http://mapillary.com/map/im/IUibLmC-b_nkLkYjziO7pA

If you're only going by signs and pavement markings without context, this
would be none|none|none|none leading up to the intersection, instead of
left|through|through|merge_to_left


On Thu, Aug 25, 2016 at 12:53 PM, Jack Burke  wrote:

> Paul, your examples are pretty much exactly what I've been doing, with the
> exception that for the last one I was using:
>
> turn:lanes=none|none|none;slight_right
>
> because of the aforementioned discussion of whether or not to use
> "through" without signage.
>
> --jack
>
> On Thu, Aug 25, 2016 at 1:38 PM, Paul Johnson  wrote:
>
>> On Thu, Aug 25, 2016 at 12:09 PM, Jack Burke  wrote:
>>
>>> So I take it that at least you and I are in agreement that the wiki is
>>> deficient for branching exits like this one:
>>> http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>>>
>>
>> Yes, that's correct.  Moving a couple frames closer to
>> http://mapillary.com/map/im/MsMAW3HKVNYxEVCtkRneBg, here's how I would
>> tag three segments based on what's visible there and no other context:
>>
>> Ahead of camera after diverging ramp:
>>
>> highway=motorway
>> oneway=yes
>> lanes=3
>> ref=I 75
>> hgv:lanes=no|yes|yes
>>
>> The ramp from the physical gore (next to the exit sign) to the tip of the
>> theoretical (painted) gore (with the node for the intersection being even
>> with the theoretical gore):
>>
>> highway=motorway_link
>> oneway=yes
>> placement=transition
>> lanes=1
>> destination=Sycamore;Ocilla
>> destination:ref=GA 32  (also, damn, had to check the minimap on that, I
>> almost said MO 32 based on the shape).
>> junction:ref=78
>>
>> Behind the camera:
>>
>> highway=motorway
>> oneway=yes
>> lanes=3
>> ref=I 75
>> hgv:lanes=no|yes|yes
>> turn:lanes=through|through|through;slight_right
>>
>> Your Osmand "invention" example is a perfect case-study of what I'm
>>> working on.  I'm trying to get exits on I 75 in Georgia and Florida tagged
>>> with destination and lane guidance so that Osmand can show proper guidance,
>>> and hopefully other OSM-based navigation apps will add that feature, too.
>>> As it stands, I use Osmand to test my tags.
>>>
>>
>> I've been testing this, as well.  I'm fortunate enough to live in a city
>> that has nearly every kind of interchange to play with (except for some of
>> the newer CFI styles, but OKC and...for like, no reason, rural interchanges
>> with basically no traffic on I 40 leading into the Ouachitas are getting
>> those) and well enough aware of the tagging in play to have seen what works
>> and what doesn't, now.
>>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Freeway exit tagging

[Jack Burke]

Freeway exit tagging


I am totally confused.

What is the proper method to use turn:lanes to tag freeway lanes
approaching an exit, where the exit branches directly from an edge lane
without being part of the freeway itself, but the freeway lanes are not
signed with an arrow, such as this one?
http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw

Through examples[1], the wiki shows that when the freeway lanes *are*
signed, then "through;slight_right" appears to be the correct value.  The
wiki examples also appear to indicate that "through" is *only* appropriate
when there is corresponding signage.  The wiki is also very clear what to
do when an edge lane is an exit-only lane ("slight_right"), and what to do
when a lane is signed for both through and right turn ("through;right").
So what's the right thing to use when there is no "through" indicator, yet
there is an upcoming branching exit?  By inference from what's contained in
the wiki, "none;slight_right" appears to be the appropriate value, but it
looks like a lot of people are disagreeing with that[2], even though it
appears to be the only logical conclusion.  Others think that
"through;slight_right" should be used because it's the reality on the
ground[2] despite the lack of paint/signs.

I'm bringing this up because I'm trying to get exits on I 75 in Georgia and
Florida tagged with destination and lane guidance (though only one
navigation app processes lane guidance AFAIK, but I hope that by adding the
data, others will take it up, too), and don't want to waste my time tagging
it incorrectly.  One helpful group trying to fix what they consider
incorrect lane counts & tags, turned a bunch of my continue-or-exit lanes
tagged with "none;slight_right" into exit-only lanes[3] with just
"slight_right".  I'm worried about switching to "through;slight_right"
because I don't want some *other* do-gooder coming along later and
similarly breaking lane guidance because there's no arrow on the ground or
on a sign.  Thus, I am now at a standstill because there doesn't appear to
be any correct tagging scheme for this incredibly common situation.

Note:  I am intentionally leaving the proposal for "transit:lanes" out of
this, both because it hasn't been voted on, as well as it doesn't appear to
cover this situation any better than turn:lanes does.

--jack



References:

[1] http://wiki.openstreetmap.org/wiki/Key:turn

[2] https://lists.openstreetmap.org/pipermail/tagging/2016-June/029335.html

[3]
https://lists.openstreetmap.org/pipermail/talk-us/2016-August/016643.html
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Freeway exit tagging

[Rihards]

On 2016.08.26. 00:15, Jack Burke wrote:

Freeway exit tagging


I am totally confused.

What is the proper method to use turn:lanes to tag freeway lanes
approaching an exit, where the exit branches directly from an edge lane
without being part of the freeway itself, but the freeway lanes are not
signed with an arrow, such as this one?
 http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw

Through examples[1], the wiki shows that when the freeway lanes *are*
signed, then "through;slight_right" appears to be the correct value.
The wiki examples also appear to indicate that "through" is *only*
appropriate when there is corresponding signage.  The wiki is also very


referencing the previous topic in talk-us about how lane tagging should 
follow lane _markings_, i'd like to suggest to only map the legally 
allowed driving directions, no matter how we arrive at them.


mapping the road markings seems extremely strange - what if they are 
very faded, when do we map them ? is there a threshold of % of the paint 
left ?

what is there are no road markings but there are signs ?
do we remove those tags during the winter in some regions ?

mapping of markings separately also seems to have no functional benefit. 
the information should be useful for navigation software - or, more 
importantly, for the end user (no matter which software delivers useful 
service to them). they don't really care how exactly the allowed 
directions are marked, as long as they get through it all without 
crashes and fines.



clear what to do when an edge lane is an exit-only lane
("slight_right"), and what to do when a lane is signed for both through
and right turn ("through;right").  So what's the right thing to use when
there is no "through" indicator, yet there is an upcoming branching
exit?  By inference from what's contained in the wiki,
"none;slight_right" appears to be the appropriate value, but it looks
like a lot of people are disagreeing with that[2], even though it
appears to be the only logical conclusion.  Others think that
"through;slight_right" should be used because it's the reality on the
ground[2] despite the lack of paint/signs.

I'm bringing this up because I'm trying to get exits on I 75 in Georgia
and Florida tagged with destination and lane guidance (though only one
navigation app processes lane guidance AFAIK, but I hope that by adding
the data, others will take it up, too), and don't want to waste my time
tagging it incorrectly.  One helpful group trying to fix what they
consider incorrect lane counts & tags, turned a bunch of my
continue-or-exit lanes tagged with "none;slight_right" into exit-only
lanes[3] with just "slight_right".  I'm worried about switching to
"through;slight_right" because I don't want some *other* do-gooder
coming along later and similarly breaking lane guidance because there's
no arrow on the ground or on a sign.  Thus, I am now at a standstill
because there doesn't appear to be any correct tagging scheme for this
incredibly common situation.

Note:  I am intentionally leaving the proposal for "transit:lanes" out
of this, both because it hasn't been voted on, as well as it doesn't
appear to cover this situation any better than turn:lanes does.

--jack



References:

[1] http://wiki.openstreetmap.org/wiki/Key:turn

[2] https://lists.openstreetmap.org/pipermail/tagging/2016-June/029335.html

[3]
https://lists.openstreetmap.org/pipermail/talk-us/2016-August/016643.html



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




--
 Rihards

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

[Talk-us] weeklyOSM #318 08/16/2016-08/22/2016

[weeklyteam]

The weekly round-up of OSM news, issue # 318,
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/8022/

Enjoy!

weeklyOSM is brought to you by ... 
https://wiki.openstreetmap.org/wiki/WeeklyOSM#Languages
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Katahdin Woods and Waters National Monument

[Jeffrey Ollie]

So, if you haven't seen the announcement, yesterday President Obama
established the latest National Monument.

https://www.whitehouse.gov/blog/2016/08/24/president-obama-designates-national-monument-maines-north-woods
https://www.nps.gov/kaww/index.htm

It'd be nice to get at least the boundaries into OSM, anyone have a
source for the data? I didn't see anything obvious in the NPS data
portal.

-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.

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

Re: [Talk-us] Freeway exit tagging

[David Mease]

My interpretation:

What is the proper method to use turn:lanes to tag freeway lanes
>> approaching an exit, where the exit branches directly from an edge lane
>> without being part of the freeway itself, but the freeway lanes are not
>> signed with an arrow, such as this one?
>>  http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>>
>
This exit has no turn lane. There is no staging lane prior to the exit
where tags could be placed, one should not be created just so that there is
a place to put tags. This freeway should not be split. You said yourself
that the exit is not part of the freeway itself, so tags should not be
placed on the freeway. This intersection is a candidate for the destination
tag.


> mapping the road markings seems extremely strange - what if they are very
> faded, when do we map them ? is there a threshold of % of the paint left ?
>
what is there are no road markings but there are signs ?
>

Same difference. But the arrow in the above example is pointing to where
the exit is, not describing a turn lane preceding the exit.


> do we remove those tags during the winter in some regions ?
>

Do we remove the name tag from roads when the street signs get iced over or
overgrown with vegetation?

mapping of markings separately also seems to have no functional benefit.
> the information should be useful for navigation


Road markings are both beneficial and useful for navigation. Cities and
governments have paid a lot of money installing them all over globe
precisely for these reasons. OSM would be well served to include them
exactly as is. I don't hear a lot of people complaining about how those
arrows on the roads led them astray.

In the above example, I would not expect navigation software to direct me
to get into the lane marked with a slight right arrow. In fact, I would be
miffed when I found there was no such lane. All I would expect is a simple
"In x distance take exit 78 towards Sycamore/Ocilla"
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Katahdin Woods and Waters National Monument

[Kevin Kenny]

Perhaps you could inquire via the contact information in
http://www.katahdinmaine.com/images/pdf/KatahdinVG2015-WEB.pdf where they
got the GIS data? There are maps of the new area on pp. 44-45, 50-51,
54-55, 76-77.

Failing that:

We could georeference the map of the area at
https://www.nps.gov/kaww/planyourvisit/upload/KAWW-Recreation-Map-08_2016.pdf
(presumably a US Government work not subject to copyright) and select the
corresponding area in the tax parcel map available from
http://www.maine.gov/megis/catalog/ (which appears to have OSM-compatible
usage terms: http://www.maine.gov/megis/catalog/metadata/parcels_ut.htm).

I've managed to extract park boundaries from tax parcel data in New York in
the recent past.

I'm lookng at the tax parcels from
http://www.maine.gov/megis/catalog/shps/state/parcels_uts.zip overlaid atop
a roughly georeferenced version of the NPS map in QGIS right now, and
except for the fact that two parcels (01-1 and 01-3.1) in the southwest
corner appear to have been subdivided, the NPS map follows the tax map.
There appears to be an error in the boundary between lots 01-2.21 and
01-2.2 as well, and there, since the shape appears to be similar, I'm more
inclined to trust the taxing authority. (A lot of these backcountry
property lines are based on ancient surveys where the errors of closure
could literally be tens or even hundreds of metres, so I strongly suspect
that there's an indefinite boundary in there, anyway.)

Dissolving the parcel polygons, slicing off the line at the southern
boundary, and adding the little missing bit by Whetstone Falls, would give
us a pretty darned accurate outline. It would look like hell on the
rendered map unless we also brought in the polygons for the rivers, but
that would also surely be doable.

I'm likely not to have time for this project for a couple of weeks, but
I'll happily put it on the 'things to do' list if the legal beagles are
comfortable with this approach.


Kevin

On Thu, Aug 25, 2016 at 10:58 PM, Jeffrey Ollie  wrote:

> So, if you haven't seen the announcement, yesterday President Obama
> established the latest National Monument.
>
> https://www.whitehouse.gov/blog/2016/08/24/president-
> obama-designates-national-monument-maines-north-woods
> https://www.nps.gov/kaww/index.htm
>
> It'd be nice to get at least the boundaries into OSM, anyone have a
> source for the data? I didn't see anything obvious in the NPS data
> portal.
>
> --
> Jeff Ollie
> The majestik møøse is one of the mäni interesting furry animals in Sweden.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Katahdin Woods and Waters National Monument

[Clifford Snow]

I asked the question on the talk-us-nps mailing list. A number of NPS folks
follow that list.

NPS data center, IRMA[1], doesn't have boundaries for the park yet.

[1] https://irma.nps.gov/DataStore/

On Thu, Aug 25, 2016 at 9:56 PM, Kevin Kenny 
wrote:

> Perhaps you could inquire via the contact information in
> http://www.katahdinmaine.com/images/pdf/KatahdinVG2015-WEB.pdf where they
> got the GIS data? There are maps of the new area on pp. 44-45, 50-51,
> 54-55, 76-77.
>
> Failing that:
>
> We could georeference the map of the area at https://www.nps.gov/kaww/
> planyourvisit/upload/KAWW-Recreation-Map-08_2016.pdf (presumably a US
> Government work not subject to copyright) and select the corresponding area
> in the tax parcel map available from http://www.maine.gov/megis/catalog/
> (which appears to have OSM-compatible usage terms: http://www.maine.gov/
> megis/catalog/metadata/parcels_ut.htm).
>
> I've managed to extract park boundaries from tax parcel data in New York
> in the recent past.
>
> I'm lookng at the tax parcels from http://www.maine.gov/megis/
> catalog/shps/state/parcels_uts.zip overlaid atop a roughly georeferenced
> version of the NPS map in QGIS right now, and except for the fact that two
> parcels (01-1 and 01-3.1) in the southwest corner appear to have been
> subdivided, the NPS map follows the tax map. There appears to be an error
> in the boundary between lots 01-2.21 and 01-2.2 as well, and there, since
> the shape appears to be similar, I'm more inclined to trust the taxing
> authority. (A lot of these backcountry property lines are based on ancient
> surveys where the errors of closure could literally be tens or even
> hundreds of metres, so I strongly suspect that there's an indefinite
> boundary in there, anyway.)
>
> Dissolving the parcel polygons, slicing off the line at the southern
> boundary, and adding the little missing bit by Whetstone Falls, would give
> us a pretty darned accurate outline. It would look like hell on the
> rendered map unless we also brought in the polygons for the rivers, but
> that would also surely be doable.
>
> I'm likely not to have time for this project for a couple of weeks, but
> I'll happily put it on the 'things to do' list if the legal beagles are
> comfortable with this approach.
>
>
> Kevin
>
> On Thu, Aug 25, 2016 at 10:58 PM, Jeffrey Ollie  wrote:
>
>> So, if you haven't seen the announcement, yesterday President Obama
>> established the latest National Monument.
>>
>> https://www.whitehouse.gov/blog/2016/08/24/president-obama-
>> designates-national-monument-maines-north-woods
>> https://www.nps.gov/kaww/index.htm
>>
>> It'd be nice to get at least the boundaries into OSM, anyone have a
>> source for the data? I didn't see anything obvious in the NPS data
>> portal.
>>
>> --
>> Jeff Ollie
>> The majestik møøse is one of the mäni interesting furry animals in Sweden.
>>
>> ___
>> 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
>
>


-- 
@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] Freeway exit tagging

[Greg Morgan]

> mapping the road markings seems extremely strange - what if they are very
> faded, when do we map them ? is there a threshold of % of the paint left ?
> what is there are no road markings but there are signs ?

I encouraged MapBox to add some of their workflow information to the
wiki page.[1] The MapBox team will be the first to tell you that they
may not get things right.  However, I'd rather follow their lead right
now because they are making an effort to improve navigation.

I don't see how the questions help with the discussion.  I believe
that you are asking questions for something that does not exist.
1.The sun beats down on asphalt.  That's why I mark a road as
surface=asphalt and not surface=paved.  Asphalt handles so much
differently than concrete.  Up north water seeps into the cracks and
freezes.  This process generates frost heaves, where potholes form in
the road.  Down here in the land of the sun, the cracks are filled
with tar until the point of no return sets in just like frost
heaves.[2] The street feels like you are driving on cobble stones.
2.A pavement profiler comes in and removes the asphalt near the
sidewalk so there is less of a bump.  At this point, the picture shows
that the new asphalt was laid down.  Note the appropriate safety
signs.[3]
3.Days later there's a new glassy smooth road with new lane lines.[4]
I don't even bother adding construction tags when a road is being
resurfaced.  It is over and done too quickly to bother with.

> do we remove those tags during the winter in some regions ?
The tags stay the same in both good and bad conditions.  You have
drifted into hyperbole at this point. In the snow filled north and the
sunny south, these are still usable roads.  It would be useful to know
that there are three lanes on a snow packed street when only one is
drive-able.  The lane count and turn lanes are also useful knowledge
when the freeway is flooded and you are looking for an alternate
because the street ahead has only two lanes functional piled high with
freeway traffic.[5][6]

I would rather attempt to add the information for routing rather than
have no data.  NINO is far worse than the alleged GIGO.  The community
needs to let mappers attempt to understand the problem and improve
upon the knowledge or tagging.  My eyes glazed over when I looked at
the wiki page. I found sanity to the MapBox workflow.[1]

[1] 
https://github.com/mapbox/mapping/wiki/Mapping-guide-for-turn-lanes-from-imagery
[2] http://mapillary.com/map/im/AwRbJa0dDr_RSnnjteTTFA
[3] http://mapillary.com/map/im/i40PBdYRIMs7vHttf_SiZg
[4] http://mapillary.com/map/im/ZUvJ4et2qVGLC8JJDl43CQ
[5] http://mapillary.com/map/im/AbmqIXz9Wi0EQMoLLiSLyg
[6] http://mapillary.com/map/im/QHY4gXilNHH2yyp9PEInlA

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

Re: [Talk-us] Freeway exit tagging

[Paul Johnson]

On Thu, Aug 25, 2016 at 4:28 PM, Rihards  wrote:

> On 2016.08.26. 00:15, Jack Burke wrote:
>
>> Freeway exit tagging
>>
>>
>> I am totally confused.
>>
>> What is the proper method to use turn:lanes to tag freeway lanes
>> approaching an exit, where the exit branches directly from an edge lane
>> without being part of the freeway itself, but the freeway lanes are not
>> signed with an arrow, such as this one?
>>  http://mapillary.com/map/im/7igAGXSa6EsUYlTIujXchw
>>
>> Through examples[1], the wiki shows that when the freeway lanes *are*
>> signed, then "through;slight_right" appears to be the correct value.
>> The wiki examples also appear to indicate that "through" is *only*
>> appropriate when there is corresponding signage.  The wiki is also very
>>
>
> referencing the previous topic in talk-us about how lane tagging should
> follow lane _markings_, i'd like to suggest to only map the legally allowed
> driving directions, no matter how we arrive at them.
>
> mapping the road markings seems extremely strange - what if they are very
> faded, when do we map them ? is there a threshold of % of the paint left ?
> what is there are no road markings but there are signs ?
> do we remove those tags during the winter in some regions ?
>
> mapping of markings separately also seems to have no functional benefit.
> the information should be useful for navigation software - or, more
> importantly, for the end user (no matter which software delivers useful
> service to them). they don't really care how exactly the allowed directions
> are marked, as long as they get through it all without crashes and fines.
>

This is a pretty nice summary of what I was getting at in the previous
thread on talk-us.  Especially given how common it is to not have the turn
arrows in the first place.  I'm a firm believer that the wiki is wrong on
this one and the ground truth for turn lane tagging should be the actual
application of the lanes, with or without the presence of supporting
signage or pavement markings.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Freeway exit tagging

[Paul Johnson]

On Thu, Aug 25, 2016 at 11:06 PM, David Mease  wrote:

> Road markings are both beneficial and useful for navigation. Cities and
> governments have paid a lot of money installing them all over globe
> precisely for these reasons. OSM would be well served to include them
> exactly as is. I don't hear a lot of people complaining about how those
> arrows on the roads led them astray.


Arrows on the road, at least in North America, are typically only installed
to indicate relatively unusual lane restrictions, with the typical lane
restrictions assumed to be common knowledge.  This is where this trips up
automation, as machines need to be told about these restrictions in order
for them to be able to provide useful feedback from it or lane guidance
will be a NP-complete thing for data consumers to deal with.  I mean, I get
it, don't tag for the data consumer.  But on the other hand, don't break
the data consumer with stupid tagging schemes, either.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us