[Page Update] Junction Style Guide

Moderator: Unholy

Re: [Page Update] Junction Style Guide

Postby davipt » Wed Jul 16, 2014 2:35 pm

PesachZ wrote:Also keep in mind most cul-de-sacs should not be loops or roundabouts at all, rather a single dead end segment like shown in the wiki https://wiki.waze.com/wiki/Dead_end#Cul-de-sacs.


Please let's not mix the two cases. The dead-end cul-de-sac round thingies are indeed problematic, and I wonder why they are no longer mentioned on that wiki page. Those are the >----O ones.
The two-segment-loop, see the other email. These are the ---<===>---- ones
Bruno D. Rodrigues
davipt
 
Posts: 2808
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 284 times
Been thanked: 635 times

Re: [Page Update] Junction Style Guide

Postby davipt » Wed Jul 16, 2014 3:08 pm

PesachZ wrote:
davipt wrote:
PesachZ wrote:Also keep in mind most cul-de-sacs should not be loops or roundabouts at all, rather a single dead end segment like shown in the wiki https://wiki.waze.com/wiki/Dead_end#Cul-de-sacs.


Please let's not mix the two cases. The dead-end cul-de-sac round thingies are indeed problematic, and I wonder why they are no longer mentioned on that wiki page. Those are the >----O ones.
The two-segment-loop, see the other email. These are the ---<===>---- ones


I'm not sure I follow you here. You mentioned the loops at the end of a cul-de-sac add a possible implementation of the two piece loop. I'm just saying that they are mentioned in the wiki not be drawn that way at all.


Captura de ecrã 2014-07-16, às 15.57.42.png
(772.44 KiB) Downloaded 714 times


top one, roundabout at the end of a segment. A lot of newbie editors do this. As far as I remember, these cause problems with routing, and the script marks as dead-end. Fortunately it's a roundabout and easy to delete. When these are necessary because the cul-de-sac is big enough, the roundabout shall have a junction node on the opposite side of the connecting segment, to ensure the roundabout has two half-circle segments. This used to be on some wiki page but it's not on the link I send.

middle one, the one that exists from the basemap, but fortunately it's hard to create from scratch (I wouldn't say impossible). The end of the segment is not connected to itself because I can't, but there are cases where the node is connected coming from the basemap. These cases are infamous not only because the routing is completely broken, but because it's quite hard to disconnect that node (there is the trick of creating a new segment with the same name and type and join together, but usually it's safer to just delete the crap and create a new one)

These two cases are real problems and shall be documented in a very clear manner. The scripts shows the dead-end in yellow and a clear popup "deadend". Perfect. We can discuss how to improve the wiki with those cases, but in a different thread or time. Let's not mix up right now with the case below please.


What matters to me is example 3. The script shows the two segments in orange and somewhere on some script there's a button to mass-fix it by adding an extra node I assume to the parking lot.

This is the case that I wonder why the node is necessary. The primary is straight, and mostly has the same name. The detour is usually a parking lot or private, and is longer, so it should never be picked.

The wiki says that it's problematic to enter or leave those parking lots. I've tested in ROTW in Portugal to navigate into them, to start a route from them, even to add one as a stop point. None failed.

Hence I wonder what is really the problem with those. And if there is really a problem, why should we hack the map to solve a backend bug?
Bruno D. Rodrigues
davipt
 
Posts: 2808
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 284 times
Been thanked: 635 times

Re: [Page Update] Junction Style Guide

Postby davipt » Wed Jul 16, 2014 3:18 pm

PesachZ wrote:
davipt wrote:So you are telling me that if there are two segments connected to the same points -<=>- and one is the same type and same name as the previous and next one, like an highway, and the other one is a parking lot segment that most probably due to geometry it's even longer than the other one, the routing engine or client may confuse both?

They pose an issue for the client app only, not the server. The server has a different method to identify segments.


Are you talking about when the client has no network and tries itself to create a route? The embedded routing engine that is not aware of parking lots or privates (assume them as streets), is not aware of segment lengths with enough precision (hence why both segments are similar), and is not aware of tolls, and not aware of a million other things?

This would make sense, except that I would still not agree on mass adding nodes on all those parking lots just for the sake of clients with broken routing engines and no network. Then what? Red arrows to simulate tolls? Or a dozen nodes to simulate enough penalty on tolls? If the embed routing engine is not updated for years, just kill it and force working only with network, or show a big disclaimer that the route will be broken because of no network.




PesachZ wrote:[*]No novice editors are not supposed to be able to mass edit these. Which script let's a novice editor do mass edits to split loops?


I need to investigate. It's a rank2 editor. And it's either the toolbox or the validator. I can't find out myself as my firefox decided to not show me those scripts on the greasemonkey list albeit they are running.

PesachZ wrote:[*]I don't believe the soft turns are affected (turned hard by the scripts), as the original nodes with the soft turns are not edited, there just a new node added with all turns at the new node allowed.


Street is two-way. Segment on waze is soft-one-way because only one person drove it one way. Mass script touches the segment. boom segment becomes hard-one-way.
Bruno D. Rodrigues
davipt
 
Posts: 2808
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 284 times
Been thanked: 635 times

Re: [Page Update] Junction Style Guide

Postby davipt » Wed Jul 16, 2014 3:37 pm

PesachZ wrote:Regarding the third picture above that is what my response in the post above was talking about. It has been discussed many times throughout the forum, and Waze are the ones who said to add these nodes. They are not 'extra' because they are needed.


Fair enough. There are problems, still don't understand where or what, never saw them happening in all my experience, don't have time to try to find them out on the forum, so I'll keep myself neutral, won't loose my time adding those nodes, but won't forbid new users from mass doing it and earning tens of thousands of points on illogical segment splits.

Thanks anyway.
Bruno D. Rodrigues
davipt
 
Posts: 2808
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 284 times
Been thanked: 635 times

Re: [Page Update] Junction Style Guide

Postby davipt » Wed Jul 16, 2014 3:46 pm

PesachZ wrote:No I am talking about a regular client app, with full network, receiving routes from the server. This causes lots of URs.

The server sends the routes as a list of nodes, so if two segments connect the same two nodes, the client doesn't know which one to take. The server calculates the correct one based on name, type, length, restrictions, etc. But when it conveys that to the client it is just a list of nodes, not segment IDs, so the client has a 50%/50% chance of getting it wrong.


Hah, got it. And now I remember an issue exactly like this, but slightly different - the client shows the correct route, straight. One opens a map report. Then the editor shows a ping route going through the parking lot. But the client surely didn't show a route through the plot. So, same bug, but albeit I never saw it on the client itself, I saw it when the client reports a bug. Fully understood!

PesachZ wrote:
davipt wrote:
PesachZ wrote:[*]No novice editors are not supposed to be able to mass edit these. Which script let's a novice editor do mass edits to split loops?


I need to investigate. It's a rank2 editor. And it's either the toolbox or the validator. I can't find out myself as my firefox decided to not show me those scripts on the greasemonkey list albeit they are running.


Validator doesn't edit anything, it just alerts that edits need to made. An editor using validator to find these would still have to manually fix each one, one-at-a-time.

The toolbox tool for this was originally only available to Rank 6 editors, them it was allowed for Rank 5 as well, as this week it was given to all Area Managers. So if this rank 2 editor is not an AM as well, he won't have access to the toolbox tool.


No idea yet. The guy has 132K points, 65K last week, 13k already this week. Don't know exactly what is he mass editing, just know he posted some 10 links of looped parking lots to unlock from rank3, and his editions are rank2.


PesachZ wrote:
davipt wrote:Street is two-way. Segment on waze is soft-one-way because only one person drove it one way. Mass script touches the segment. boom segment becomes hard-one-way.


What you are describing should only happen if the street was originally 'unknown direction' then soft one way. I've done this many times and it never changed the direction of street from two way to one way for me.

You may have a different problem that the editor is manually causing, possibly by pressing 'r' when selecting the segment accidentally. It's unlikely a rank 2 editor has access to a mass editing script for loops.


Let-me rephrase. Real life street is two ways. Segment is unknown. One guy drives, segment becomes soft-one way. Someone mass-edits, segment becomes hard-one-way. It will never become two-ways because there won't ever be a route on the opposite direction.
Bruno D. Rodrigues
davipt
 
Posts: 2808
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 284 times
Been thanked: 635 times

Re: U-turn prevention

Postby dbraughlr » Wed Jun 04, 2014 5:09 am

… where a U turn is not allowed, but both of the left turns that make up that U turn are allowed separately, one of the following alternate [sic] intersection methods may be used.


What are the alternatives?
dbraughlr
 
Posts: 569
Joined: Tue Aug 13, 2013 2:24 am
Has thanked: 164 times
Been thanked: 98 times

Re: U-turn prevention

Postby dbraughlr » Wed Jun 04, 2014 7:25 am

Does this mean that segment length less than 15 m is not a way to prevent a U-turn?
dbraughlr
 
Posts: 569
Joined: Tue Aug 13, 2013 2:24 am
Has thanked: 164 times
Been thanked: 98 times

Re: word "to" dropped from exit name

Postby dbraughlr » Tue Jun 10, 2014 5:47 pm

PesachZ wrote:The TTS engine (I can confirm at least for Samantha) suppresses the leading "to". The verbal instruction for a wayfinder segment named "to I-87" will be "Stay to the <right/left> at eye eighty seven". This instruction would still be correct, since it's not telling you to go to somewhere, you already are.


I don't consider it to be "correct". When entering I-80 Business W from I-5 S, the big green sign says "TO I-80 W". The TTS should announce what the sign says including the "to" because it is the exit onto I-80 Business W which is the second chance connector to I-80 W.

I think we should use "to" when that is what is on the sign and the "to" should not be suppressed.
dbraughlr
 
Posts: 569
Joined: Tue Aug 13, 2013 2:24 am
Has thanked: 164 times
Been thanked: 98 times

Re: word "to" dropped from exit name

Postby dbraughlr » Tue Jun 10, 2014 8:07 pm

PesachZ wrote:As a side note only the first "to" in the name is suppressed. A ramp for example names "to I-295 N / to I-95 N / New Haven" will be spoken as "keep right at eye 295 north, to eye 95 north, New Haven". If you need the word "to" to be spoken it can probably be accomplished (I haven't tested) by naming the segment "to to I-80 W".


Not only does it look wrong, it sounds wrong: "Stay right at to I-80 W".
dbraughlr
 
Posts: 569
Joined: Tue Aug 13, 2013 2:24 am
Has thanked: 164 times
Been thanked: 98 times

Re: word

Postby dbraughlr » Wed Jun 11, 2014 3:43 pm

PesachZ wrote:
dbraughlr wrote:
PesachZ wrote:As a side note only the first "to" in the name is suppressed. ... If you need the word "to" to be spoken it can probably be accomplished (I haven't tested) by naming the segment "to to I-80 W".


Not only does it look wrong, it sounds wrong: "Stay right at to I-80 W".

it doesn't say the "to" it says "Stay right at I-80 W".


You suggested writing "to to I-80 W" to get "to I-80 W" spoken. Now you claim that it still doesn't say the "to". But the BGS says "to" and Waze should say "to".
dbraughlr
 
Posts: 569
Joined: Tue Aug 13, 2013 2:24 am
Has thanked: 164 times
Been thanked: 98 times

PreviousNext

Return to Wiki Updates and Discussion

Who is online

Users browsing this forum: No registered users