Re: [Talk-us] Per-State relations for the Appalachian Trail

[OSM Volunteer stevea]

Kevin Kenny > writes:
> Breaking apart the AT into separate relations - ideally with a superrelation 
> joining them - would be sensible, I think, but be careful about the 
> assumption about state lines. The AT literally spends a good many miles with 
> the hiker having one foot in North Carolina and the other in Tennessee - the 
> ridge that it follows is the state line.

Yes, “break apart elements so they are in a single state” simply does not make 
logical sense here, so I believe that “logical senseless" alone is a good 
reason for not doing so — it would needlessly frustrate somebody to implement 
this.  There is likely very wide agreement here, but it bears repeating:  be 
sensible, but not slavish to an ideal where it doesn’t make sense to do so.

> We also, I think, need to put some more thought simply into the support of 
> large relations. I've recently found that even the New York Long Path (only a 
> fifth the length of the AT) crashes JOSM (I haven't yet diagnosed the 
> problem) and wound up editing in Meerkartor instead. Trails, highways, 
> rivers, railroads, we have a good many places where things reasonably and 
> predictably break down into thousands of parts over thousands of km, and I 
> don't think we yet have a unified theory of how to handle them.

It would be nice to “have a unified theory,” yes.  However, as this could be 
fraught with endless discussion of “should we here?” or “what’s the best method 
there?” I’d say letting common sense guide us is a very good place to start and 
use as an approach.  “Along state lines” certainly settles out of that nicely, 
and so it sounds like OSM in the USA both does already and can continue going 
forward like this.  When it doesn’t or something else DOES make sense 
(especially MORE sense) then, do that, instead.  Eventually, “more firm rules” 
might be established.  And as this continues to get discussed, there might even 
be some relief from tools (editors, the database itself) which are better 
written or can better accommodate larger relations, although I don't hold my 
breath about that.  Super-relations can help, but they are not always the 
answer, either, and some renderers or other data consumers don’t completely 
implement them as you might hope.  Sometimes technology “naturally” grows to 
accommodate “entire planet sized” data size problems, then again, sometimes 
very focussed, specific efforts are required to “fix” things.  Those seem like 
they will (and have) make themselves more obvious as we go along.

Cheers,
SteveA
California___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] iD news: v1.9.4 released

[Bryan Housel]

iD v1.9.4 was released May 3 2016 and is now available for editing on 
openstreetmap.org 

The release includes:
- Fix bug causing the Save button to remain disabled even when changeset 
comment entered
- Support setting imagery offset via url parameter
- New multiple selection field type (built by Kushan Joshi), used for tagging:
   - `payment:*`  (supported on Vending Machine presets)
   - `currency:*`  (supported on Vending Machine, Money Exchange, ATM presets)
   - `fuel:*`  (supported on Gas Station, Marine Fuel Station presets)
   - `recycling:*`  (supported on Recycling presets)
- Additional bug fixes and usability improvements

Changelog:  https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#194 

Twitter:   https://twitter.com/bhousel/status/727858394414100481 



Thanks,
Bryan

Follow me on Twitter https://twitter.com/bhousel , 
or follow the iD project on GitHub https://github.com/openstreetmap/iD 
 for more iD tips and updates.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Per-State relations for the Appalachian Trail

[Richard Welty]

On 5/4/16 9:54 AM, Elliott Plack wrote:
> Thanks for all of the feedback. I definitely won't be merging any
> relations based on some of what you have all stated. What I will do is
> go through and look at each relation state by state to ensure there is
> connectivity and what not. I'll update anything of interest here. 
if i found myself looking at a relation which was on a border (as Kenny
pointed out)
i'd probably just give the relation a name like NC-TN. there's no reason
to make this
any harder than that.

richard

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




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

Re: [Talk-us] Per-State relations for the Appalachian Trail

[Elliott Plack]

Thanks for all of the feedback. I definitely won't be merging any relations
based on some of what you have all stated. What I will do is go through and
look at each relation state by state to ensure there is connectivity and
what not. I'll update anything of interest here.
On Tue, May 3, 2016 at 22:35 Kevin Kenny  wrote:

> On 05/03/2016 03:09 PM, OSM Volunteer stevea wrote:
> > In the USA, partly because we are such a geographically large part of
> > the North American continent and partly because each of our fifty
> > states is sovereign, I find that breaking apart very large relations
> > so they are across a single state at a time (then perhaps these are
> > collected into a super-relation) is often (though not always) a
> > sensible approach.  It is part size (large relations with vast numbers
> > of members are unwieldy), it is part “what sort of an entity is this
> > politically?"
> >
> > For example, there is a note in OSM’s Amtrak wiki page on the
> > route=train relation for the California Zephyr:  "The relation is said
> > to be so big it is hard to work with.”  That is something we might
> > take to heart and break apart the relation into statewide components.
> >  I haven’t done that, but somebody might, after considering that it
> > makes editing easier, and that state-at-a-time is a good way to do
> > this.  Even a simple web browser request to display this relation
> > results in "Sorry, the data for the relation with the id 905830, took
> > too long to retrieve." The practicality of potentially better avoiding
> > edit conflicts has been mentioned, and is also true.
> >
> Breaking apart the AT into separate relations - ideally with a
> superrelation joining them - would be sensible, I think, but be careful
> about the assumption about state lines. The AT literally spends a good
> many miles with the hiker having one foot in North Carolina and the
> other in Tennessee - the ridge that it follows is the state line.
>
> We also, I think, need to put some more thought simply into the support
> of large relations. I've recently found that even the New York Long Path
> (only a fifth the length of the AT) crashes JOSM (I haven't yet
> diagnosed the problem) and wound up editing in Meerkartor instead.
> Trails, highways, rivers, railroads, we have a good many places where
> things reasonably and predictably break down into thousands of parts
> over thousands of km, and I don't think we yet have a unified theory of
> how to handle them.
>
> --
> 73 de ke9tv/2, Kevin
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
-- 
Elliott Plack
http://elliottplack.me
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Improving coverage of exit numbers and destinations on motorways

[Elliott Plack]

So, I am confused here. What Paul is talking about, isn't that what is
being proposed (besides the junction:ref bit)? This is a proposal to use
the node and way approach, like the one Duane points too, right?


On Tue, May 3, 2016 at 10:31 AM Duane Gearhart  wrote:

> Hey all,
>
> I believe the way-junction:ref should be used in addition to the node-ref
> only when needed at splits - like this example:
> http://wiki.openstreetmap.org/wiki/Exit_Info#A.2FB_Split_Example
> These types of splits do not happen very often - however, when they do -
> having the way-junction:ref helps to improve the guidance for the user at
> key decision points.
>
> Regards,
> Duane
>
>
> On Tue, May 3, 2016 at 10:02 AM, Jinal Foflia 
> wrote:
>
>> Hi Paul,
>>
>> These are good points, but it does not look like the `junction:ref`
>> tagging scheme is very common. Till there is widespread usage by the
>> community we will continue to follow the conventional tagging of the
>> reference numbers on the motorway_junction node [1].
>>
>> Curious to know what the others think of the `junction:ref` tag.
>>
>> Cheers,
>> Jinal Foflia
>>
>>
>> [1] http://taginfo.openstreetmap.org/search?q=highway%3Dmotorway_junction
>>
>>
>> On Tue, May 3, 2016 at 3:49 PM, Paul Johnson  wrote:
>>
>>> I'm wondering why the push to tag a node with directional information
>>> when tagging the first segment of the diverging way would be more concise
>>> and already had support in some navigational data consumers?  This handles
>>> weird situations where ramps diverge to the left or from a lane other than
>>> the edge much more cleanly.
>>>
>>> For example, Exit 2 in West Tulsa on I 244. First segment could be
>>> tagged as...
>>>
>>> name=Okmulgee Beeline
>>> junction:ref=2
>>> destination=Okmulgee
>>> destination:ref=US 75 South
>>> ref=US 75
>>> highway=motorway
>>>
>>> Or, the number 3 lane exit westbound US 26 north of Beaverton at exit
>>> 71A (lanes 1, 2 and 4 remain on US 26, oddly enough).
>>>
>>> name=Canyon Road
>>> highway=motorway_link
>>> ref=OR 8
>>> junction:ref=71A
>>> destination=Beaverton
>>> destination:ref=OR 8 West
>>>
>>> This along with the departure angle, gives navigation systems ample
>>> information to accurately describe the ramp that point data just leaves out.
>>>
>>>
>>> On Tue, May 3, 2016 at 4:46 AM, Jinal Foflia 
>>> wrote:
>>>
 There has been a recent push to improve the coverage of exit numbers
 and destination signs on the motorways in the US by the data team at
 Mapbox. Some context here [1][2][3][4]. The primary sources of data were
 DoT documents and Mapillary images. The secondary source was Wikipedia, but
 as per the conversation with the local mappers, it is not a good idea to
 completely trust wikipedia documents for mapping the exit numbers and
 destinations. There are certain highways which do not have Mapillary
 coverage and it is difficult to validate/identify the missing exit numbers
 and destination. It will be a great help if local mappers can help share
 reliable sources and validate the existing data that will help improve the
 coverage of this data on the map

 We been working on this from the beginning of April and reviewed more
 than 220 highways in 9 states. The goal would be to authenticate all
 the existing data and fill in the gaps using verifiable sources wherever
 possible.

 Here is the Overpass query to get a better sense of the stats:

 * Total motorway_junction edited by team in last two weeks: 179 [5]

 This is the detailed workflow for *Exit mapping* [6] and *Destination
 mapping* [7] that was used for this mapping activity. Would be great
 to hear your feedback on how it can be improved for further such tasks,
 please drop a comment on the *project tracker* [3] .

 I want to thank all of you in the community for giving feedback,
 calling us out on the occasional errors, and working with us to improve
 signpost mapping conventions. I feel proud to be a member of such a great
 mapping community!
 Cheers,

 Jinal Foflia

 [1] https://www.openstreetmap.org/user/jinalfoflia/diary/38501

 [2] https://www.openstreetmap.org/user/jinalfoflia/diary/38342

 [3] https://github.com/mapbox/mapping/issues/178

 [4] https://github.com/mapbox/mapping/issues/169

 [5] http://overpass-turbo.eu/s/fzA

 [6]
 https://gist.github.com/poornibadrinath/a8f3652deb566d95b848c5e9cd68011f

 [7]
 https://gist.github.com/poornibadrinath/f982a947c6a063ed1a9016a2d3246d4a




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


>>>
>>> ___
>>> Talk-us mailing list
>>> 

Re: [Talk-us] Improving coverage of exit numbers and destinations on motorways

[Mike N]

On 5/4/2016 4:18 AM, Greg Morgan wrote:

 At one time there was a discussion on the list about moving exit_to
tags as destination tags on the ramp.  I moved most of the exit_to tags
that I mapped to the ramps.  Here you are proposing something different
by leaving some exit_to tags and adding destination tags occasionally.


Just to add to this - someone has added ref:left and ref:right to split 
exits near me, but it appears that this is an abandoned proposal.


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

Re: [Talk-us] Improving coverage of exit numbers and destinations on motorways

[Paul Johnson]

On Wed, May 4, 2016 at 3:18 AM, Greg Morgan  wrote:

>
>
> The work flow that you mention drive me batty.[0]  At one time there was a
> discussion on the list about moving exit_to tags as destination tags on the
> ramp.  I moved most of the exit_to tags that I mapped to the ramps.  Here
> you are proposing something different by leaving some exit_to tags and
> adding destination tags occasionally.  The batty part, is that the original
> way I mapped these without exit_to was what I found in Europe. It looks
> like Paul has a point because junction:ref is in the wiki page
> that Duane cites. I don't know that you can use "does not look like the x 
> tagging
> scheme is very common" or "we will continue to follow the conventional
> tagging" when the wiki page has changes as recent as 9/2015.
>
>
Plus Osmand consumes the ramp tagging, not the node tagging (and in no
small part because it's not obvious which direction the node means if
you're a machine).  Most of the interstates (soon, all) will have both.
Though Osmand doesn't use motorway junction refs or the way's junction:ref
(yet).

That said, yes, destination has legs.
http://taginfo.openstreetmap.org/keys/destination#map  Junction:ref=* is
getting there.  http://taginfo.openstreetmap.org/keys/junction%3Aref#map
 And here's a control with highway=motorway_link
http://taginfo.openstreetmap.org/tags/highway=motorway_link#map

Seems with the more flexible tagging (junction:ref=* and destination=*)
there's a strong correlation between regions with the strongest car culture
(Route 66, New England and Germany) and where it's being tagged.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Improving coverage of exit numbers and destinations on motorways

[Greg Morgan]

On Tue, May 3, 2016 at 2:46 AM, Jinal Foflia  wrote:

> There has been a recent push to improve the coverage of exit numbers and
> destination signs on the motorways in the US by the data team at Mapbox.
> Some context here [1][2][3][4]. The primary sources of data were DoT
> documents and Mapillary images.
>
One of the first things that I mapped was exit numbers.  At least that
would provide some clue about the distance you have left or what not.  That
is a great first step but the focus is on urban mapping.  More important
for long distance driving or even navigation are mile markers.  The exit
numbers are tied to the mile markers.  The traffic engineer makes a
decision on an exit number based on the proximity of a mile marker. I have
added part of a press release[2] from Arizona DOT. Milepost/mile maker 346
is referenced.  Milepost/mile markers are far more valuable[1] but are not
rendered and thus have little value to an urban mapper or little reward for
the effort involved.  Also note that the exit numbers/mile makers for a
motorway will reset at state borders.  As I recall I-15 ends around 411 as
you enter Idaho.  Finally, expect gaps in the the exit numbers. Two or more
routes may share a section of the road for awhile until they diverge in
other directions.  Another case, is when the route is split by a city.  In
this case, a route might have run through a city at one time.

The work flow that you mention drive me batty.[0]  At one time there was a
discussion on the list about moving exit_to tags as destination tags on the
ramp.  I moved most of the exit_to tags that I mapped to the ramps.  Here
you are proposing something different by leaving some exit_to tags and
adding destination tags occasionally.  The batty part, is that the original
way I mapped these without exit_to was what I found in Europe. It looks
like Paul has a point because junction:ref is in the wiki page
that Duane cites. I don't know that you can use "does not look like
the x tagging
scheme is very common" or "we will continue to follow the conventional
tagging" when the wiki page has changes as recent as 9/2015.

I don't mind adding these features but there has to be something presented
on the main OSM maps other than another art project.  If you are looking
for mapper participation or encouraging passive users to become mappers,
then there has to be a reward on the main OSM site.  Otherwise, OSM has
developed the most boring video game that shows no lights nor rings any
bells.  It is the cartographers and not the importers that are killing off
mappers!

Regards,
Greg


[0] https://gist.github.com/poornibadrinath/f982a947c6a063ed1a9016a2d3246d4a
Look out for red outer circle for missing destination. Use open in JOSM
button to open the node in JOSM. Orange outer circle represents exit_to tag
and we don't need to add destination tags in the way. Green outer circle
represent that the concern way already has destination tag.

[1] http://www.openstreetmap.org/node/3910143420

[2] Bridge work to close State Route 89 for four hours late Friday
Those traveling between Prescott and I-40 should consider alternate routes

PHOENIX ‒ State Route 89 will close for four hours approximately 13 miles
north of Chino Valley starting at 9 p.m. Friday, May 6, so crews can pour a
concrete bridge deck at Hell Canyon __(milepost 346).__ It’s one of the
final steps in readying a $14.4 million bridge scheduled to open to traffic
in mid-June.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us