Re: [Talk-us] Relation roles for two-way way segments carrying routes in a single direction

2016-12-27 Thread Peter Dobratz
There's a bit of confusion around this and it took me quite a while playing
around with the relation editor in JOSM ("Select Next Gap") to understand
how the "forward" and "backward" roles work.

https://i.imgur.com/RGV2XOX.png

First, consider how you would create a road route relation for your example
if the red segment didn't exist.  Also, for the moment ignore the signed
cardinal directions of the route.  In that case, you would arbitrarily
chose to start from the left-most or right-most segment in the picture.  If
you chose to start with the right-most segment:

right-most (role: "")
blue (role: "")
green (role: "")
left-most (role: "")

All of the roles would be empty and you would not need to use the roles
"forward" or "backward".

Now consider that the red segment exists and you need to indicate that the
road route splits in two and then reconverges.  In this case, you would do
the following, again starting at the right side of the picture:

right-most (role: "")
blue (role: "backward")
green (role: "backward")
red (role: "forward")
left-most (role: "")

You traverse the segments where the road splits first following the
direction of the route and then backtracking to the point where the road
splits and then start adding segments with empty roles.  If either blue,
green, or red is reversed in direction, then they would need to have the
role "backward" instead of "forward", but would still retain the same
position in the list (by convention red should not be reversed since it has
oneway=yes).


So now consider that you want to change the route to indicate "east" and
"west" signed cardinal directions.

One idea is to leave the roles as "forward" and "backward" and just add a
direction=west tag on the relation object.

One idea is that "east" and "west" become synonyms for "forward".  First,
reverse the direction of blue and green and change their roles to
"forward".  Then change the roles to "east" and "west":

right-most (role: "")
blue (role: "west")
green (role: "west")
red (role: "east")
left-most (role: "")

In this case, it is critical that blue and green are not reversed again.


Another approach is to create separate route relations for each direction
of the route.  In that case, you would have one relation with
direction=east:
left-most (role: "")
red (role: "")
right-most (role: "")

And a separate relation with direction=west
right-most (role: "")
blue (role: "")
green (role: "")
left-most (role: "")

In this case, it will also help to update the name tag of the relation to
include "(East)" or "(West)" to more easily tell the route relations apart
in the editor.  Also, the relations can be added to a route_master relation
(type=route_master  route_master=road).


Overall, I think it is cleanest to create 2 route relations, 1 for each
signed cardinal direction of the route.  You don't have to arbitrarily
decide whether to start the route at the eastern or western terminus as
each route relation has a natural starting point based on the signed
cardinal direction.  You don't have to deal with roles on member Ways,
which are very confusing.  You don't have to worry about the direction of
each member way either (again in practice many of them will be marked
oneway=yes and have the direction following the flow of traffic).


Note that whatever approach you chose, the route relations will often break
when the member Ways are split or combined.  Not all OSM editors do the
right thing to preserve the contiguousness of the route relations when
performing these operations.  When people decide to add lane or speed limit
information to the roads that make up the route, they may inadvertently
break the route relation.  In the rare case where multiple users are
concurrently splitting Ways that belong to the same route relation, the
relation usually breaks.

Peter

On Mon, Dec 26, 2016 at 9:29 AM, Albert Pundt  wrote:

> So I understand that one-way ways carrying a route (e.g. a one-way pair or
> divided highway) should have relation roles of north/south/east/west, but
> say you have a situation like this . Say
> you have an east-west route that follows the primary roads in that picture.
> The eastbound direction follows the channelized right turn slip ramp,
> marked with a red arrow. The westbound direction follows the blue-arrow
> way, before turning left onto the green-arrow way.
>
> How should relation memberships and roles be assigned here? I would think
> that the slip ramp would be part of the relation, since right-turning
> traffic must follow it. Ideally, that would be given the role "east", but
> what about the green and blue ways? It might seem right to give them the
> role "west", but how then is it differentiated which direction is westbound
> for it? Since all the ways in this picture are arranged "pointing" north or
> east, the green and blue ways would need to be given the role "backward",
> which is the older way of doing things that can't specify cardinal

Re: [Talk-us] [OSM-talk] Fwd: Re: Beware Pokemon users

2016-12-27 Thread Rihards
On 2016.12.27. 10:15, David Kewley wrote:
> I thought this might be a big problem at first, but now I think it's
> probably a net good thing.
> 
> In Southern California, I saw about 40 users join in the first 24-48
> hours after the video was posted (Dec 22), who immediately started
> mapping footways and similar. A few were bad, most improved the map
> incrementally, if not with great skill, completeness, or accuracy. The
> rate of new people joining and adding footways and similar has gone way
> down since the first 24 hours.
> 
> I just now used Overpass-Turbo to check for new footways in the past ~2
> days in all the western U.S. (to just west of San Antonio, not including
> Alaska and Hawaii), zoomed in briefly on each locality in turn, and
> found with this quick ad hoc eyeball survey only two users who were
> obviously gaming OSM for Pokemon Go in an unhelpful way. I'll address
> them or send them to DWG. All the others looked reasonable upon a first
> pass, although I might have missed a few. Some I didn't see may already
> have been cleaned up, of course.
> 
> So the potential problem is big, but I think the actual problem is not
> too big, and can probably be contained with our current level of effort.
> Meanwhile there are tons of incremental additions that are probably net
> improvements to the map, and a few of these folks will continue to
> improve the map over time. I've already seen a few of these new users
> branch out into non-Pokemon-related improvements. Plus it gives OSM
> wider awareness.
> 
> One other thing to look out for, which most people are doing well, but a
> few are doing inappropriately, is changing school grounds from
> amenity=school to =college or =university.
> See 
> https://www.reddit.com/r/TheSilphRoad/comments/5jv1c4/i_think_i_figured_out_why_pokemon_never_spawned/.
> I had to change one secondary school back to =school after an apparent
> Pokemon user changed it to =college. I also changed one community
> college from =school to =college when I noticed it was mistagged while
> looking at new footways drawn there. Hope it helps them have fun with
> their game. :)
> 
> I've also seen fake parks, piers, lakes, and similar area objects get
> added in an apparent attempt to help Pokemon. Footways may be the most
> common manifestation of this wave of activity, but not the only one.

could you please share the overpass query you used ? i'd like to review
such additions around here as well.
i am following the edits of new users, and so far contributions of 2 or
3 have been worthy a revert.

it would be also useful to have a list of tags/changes the pokemon go
players make. footways are the most obvious, but i've also seen
(incorrect_ recreational_grounds added. several users have also changed
existing residentials, pedestrian streets and tracks to footways -
incorrectly in all the cases.

> Fun fact: On 12/22 I actually stumbled across a deletion of the footway
> added in the video, before I was aware of the existence of the video and
> the Pokemon-related editing. That issue is since resolved. The
> videographer is pretty local to me, and in the video he hikes in hills I
> know. A brush with a weird kind of notoriety, I guess.
> 
> David
...
-- 
 Rihards

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