*UPDATED* Ramp naming convention proposal

[R4CLucky14]

I believe, even if they aren't synonyms, to match the BGS, this would be best:

Exit 298: I-176 / PA-10 to Morgantown / Reading

I may be different, but I read BGS's like anything else. Basically, I would read I-176 and then PA-10 next to it, then I would read Morgantown, with Reading underneath it.

I believe the TTS should match how the user would typically read the BGS. As far as the to is concerned, it makes much more sense than any of the other formatting suggestions I have seen.

[TheBuca]

What about signs that have 2 routes and 2 cities?
example:

Exit 298: I-176 / PA-10 / Morgantown / Reading
What would we do there?

Exit 298: 1-176 / PA-10: Morgantown / Reading

I don't think that works. I think we need something simple, that isn't a colon, that waze then makes a pause. or better yet, something that waze makes a pause and then doesn't display
maybe:

Exit 298: I-176(p) PA-10(p) Morgantown(p) Reading(p)
which would show up as

Exit 298: I-176 PA-10 Morgantown Reading

hmm no that looks like crap, but I think the point is we need to decide what looks good and then get waze to add a pause for it.

I used to eat at the pizza hut near that interchange all the time on the back way to coatesville

I still maintain adding a pause for a slash will benefit us the most, then we use the word "to" for multi road exits, but only if the sign groups the city and road separately. Using Morgantown for the example, the sign has the two road shields and then "Reading" with "Morgantown" underneath it. If you look at the sign, the text "Exit 298: I-176 / PA-10 / Reading /Morgantown" will read the sign verbatim.

If the sign had I-176 with Reading under it and then next to it PA-10 with Morgantown under it, then having it say "Exit 298: I-176 to Reading / PA-10 to Morgantown" would read the sign verbatim.


Sent from my iPad using Tapatalk

[AlanOfTheBerg]

I still maintain adding a pause for a slash will benefit us the most

I can't imagine why it's taking so stinking long to get it implemented. It was supposed to be a fairly easy adjustment on the routing server.

[MReiser4670]

I used to eat at the pizza hut near that interchange all the time on the back way to coatesville

I still maintain adding a pause for a slash will benefit us the most, then we use the word "to" for multi road exits, but only if the sign groups the city and road separately. Using Morgantown for the example, the sign has the two road shields and then "Reading" with "Morgantown" underneath it. If you look at the sign, the text "Exit 298: I-176 / PA-10 / Reading /Morgantown" will read the sign verbatim.

If the sign had I-176 with Reading under it and then next to it PA-10 with Morgantown under it, then having it say "Exit 298: I-176 to Reading / PA-10 to Morgantown" would read the sign verbatim.


Sent from my iPad using Tapatalk

In my opinion, we just need to do our best to recreate the signs as the driver sees them. I can't imagine adding control cities where there aren't any listed, and sometimes there are discrepancies through interchanges that create confusion unless the driver can simply hear what they see.

My local PA Turnpike exit is a great example. This is how the signs read all the way through the interchange in all directions:

Both EB & WB exiting the turnpike "Exit 343: Willow Grove / PA-611 to Doylestown / Jenkintown"

Go through toll

SB "PA-611 S to Willow Grove / Abington"
Center "to Home Depot Dr"
NB "PA-611 N to Doylestown / Horsham / NAS JRB Willow Grove"

Getting onto the turnpike from PA-611:

NB No BGS, just a big Penna Turnpike sign with a tiny I-276 crest attached. So "to I-276 / PA Turnpike"
SB "I-276 / PA Turnpike to Philadelphia / Harrisburg"

Go through toll

WB "I-276 W to Harrisburg"
EB "I-276 E to New Jersey"

Note that there are 6 different control cities exiting the turnpike and 3 entering. Also notice that Jenkintown doesn't even show NB or SB after the toll even though it was one of the control cities on the exit signs. Also notice that PA-611 SB traffic gets Philadelphia as a control city, but it doesn't show EB or WB after the toll. I can't imagine any other way to name these ramps but to merely repeat the signs as they are seen.

[TheBuca]

In my opinion, we just need to do our best to recreate the signs as the driver sees them. I can't imagine adding control cities where there aren't any listed, and sometimes there are discrepancies through interchanges that create confusion unless the driver can simply hear what they see.

My local PA Turnpike exit is a great example. This is how the signs read all the way through the interchange in all directions:

Both EB & WB exiting the turnpike "Exit 343: Willow Grove / PA-611 to Doylestown / Jenkintown"

Go through toll

SB "PA-611 S to Willow Grove / Abington"
Center "to Home Depot Dr"
NB "PA-611 N to Doylestown / Horsham / NAS JRB Willow Grove"

Getting onto the turnpike from PA-611:

NB No BGS, just a big Penna Turnpike sign with a tiny I-276 crest attached. So "to I-276 / PA Turnpike"
SB "I-276 / PA Turnpike to Philadelphia / Harrisburg"

Go through toll

WB "I-276 W to Harrisburg"
EB "I-276 E to New Jersey"

Note that there are 6 different control cities exiting the turnpike and 3 entering. Also notice that Jenkintown doesn't even show NB or SB after the toll even though it was one of the control cities on the exit signs. Also notice that PA-611 SB traffic gets Philadelphia as a control city, but it doesn't show EB or WB after the toll. I can't imagine any other way to name these ramps but to merely repeat the signs as they are seen.

I agree. What we put in the map should be exactly what the driver sees as he's reading the sign. A generic shield with some cities gets "Exit 000: PA-999 / Gotham City / Joisey" and specific names for shields gets "Exit 000: PA-999 to Gotham City / I-76 E to Filthadelphia".


Sent from my iPad using Tapatalk

[AlanOfTheBerg]

The only exception I employ for not putting ALL the info on the sign into a single segment is when a ramp exits to two distinct exits and the BGS for the first ramp shows both the exit numbers.

For example, ramp exits with BGS showing "Exit 12A: I-95 N / Cityname1 ; Exit 12B: I-95 S / Cityname2" and then down the ramp is a split in some manner into both ramps. This BGS is too long for a single segment name to be useful and to have TTS fit into an announcement before the next split into the actual ramp happens. TTS would be too late.

The standard agreed to in previous ramp name threads (I think it was agreed to) is to not name the first segment, and let the next ramp segments be named and propagate "backward" so that if the driver is heading to 12A, they will get "Exit 12A: I-95 N / Cityname1" for the first exit and the next, which will match part of the first BGS they see, and will match the second BGS they see.

[TheBuca]

The only exception I employ for not putting ALL the info on the sign into a single segment is when a ramp exits to two distinct exits and the BGS for the first ramp shows both the exit numbers.

For example, ramp exits with BGS showing "Exit 12A: I-95 N / Cityname1 ; Exit 12B: I-95 S / Cityname2" and then down the ramp is a split in some manner into both ramps. This BGS is too long for a single segment name to be useful and to have TTS fit into an announcement before the next split into the actual ramp happens. TTS would be too late.

The standard agreed to in previous ramp name threads (I think it was agreed to) is to not name the first segment, and let the next ramp segments be named and propagate "backward" so that if the driver is heading to 12A, they will get "Exit 12A: I-95 N / Cityname1" for the first exit and the next, which will match part of the first BGS they see, and will match the second BGS they see.

I can't recall if that was in the wiki or not, but I recently did an interchange like that where the off ramp connected to the interstate was unnamed and the individual ramp segments which split off of that had the names of the exits (A and B). Did the PA turnpike like that too where as you approach it will say "exit to the right at Pennsylvania Turnpike, I-76, Philadelphia, Pittsburgh" and once you pass through the toll booth the split segments will direct you where to go, as in "stay to the left at I-76 E / Philadelphia". REALLY cool how it pretty much speaks the signs as you pass them.


Sent from my iPad using Tapatalk

[R4CLucky14]

The only exception I employ for not putting ALL the info on the sign into a single segment is when a ramp exits to two distinct exits and the BGS for the first ramp shows both the exit numbers.

For example, ramp exits with BGS showing "Exit 12A: I-95 N / Cityname1 ; Exit 12B: I-95 S / Cityname2" and then down the ramp is a split in some manner into both ramps. This BGS is too long for a single segment name to be useful and to have TTS fit into an announcement before the next split into the actual ramp happens. TTS would be too late.

The standard agreed to in previous ramp name threads (I think it was agreed to) is to not name the first segment, and let the next ramp segments be named and propagate "backward" so that if the driver is heading to 12A, they will get "Exit 12A: I-95 N / Cityname1" for the first exit and the next, which will match part of the first BGS they see, and will match the second BGS they see.

The only issue I have with this is if the first sign makes it unclear that A and B comes from the same ramp, as letters are also used (around here) if the exits are within the same mile marker of each other. Some BGS say Exit ### A-B: xxxxxxxxx, but others may just say Exit ###. If the client told me to exit at Exit ###B, and the sign said Exit ###, then I would probably miss the exit, presuming B is further down the road.

Therefore, I believe if the first BGS doesn't help indicate it, perhaps the first ramp should at least have the exit number on the first BGS.

[sketch]

Exit 298: 1-176 / PA-10: Morgantown / Reading

That's how I do it now, but to make the TTS sound best, I think it would be Exit 298: I-176 to Morgantown / PA-10 to Reading.

This is optimal.

Signs may be read left-right then up-down, but we'd be doing people a service by breaking it down logically, I think. Plus, it breaks down better.

[*]"Exit 298: I-176 / PA-10: Morgantown / Reading" is okay but for the double colon.
[*]"Exit 298: I-176 / PA-10 to Morgantown / Reading" is kind of okay right now, but once pauses are returned for flashes, it'll break down wrong, and "PA-10 to Morgantown" will be the only complete logical unit, which is wrong.
[*]"Exit 298: I-176 / PA-10 / Reading / Morgantown" may read okay when the slash pause is added to TTS, but we can't say it'll read "exactly like the sign", because we can't say that people read shields and control cities at the same speed, and so forth. We also have to respect that some people won't be using TTS so we should keep it legible on the client as well.

The only exception I employ for not putting ALL the info on the sign into a single segment is when a ramp exits to two distinct exits and the BGS for the first ramp shows both the exit numbers.

For example, ramp exits with BGS showing "Exit 12A: I-95 N / Cityname1 ; Exit 12B: I-95 S / Cityname2" and then down the ramp is a split in some manner into both ramps. This BGS is too long for a single segment name to be useful and to have TTS fit into an announcement before the next split into the actual ramp happens. TTS would be too late.

The standard agreed to in previous ramp name threads (I think it was agreed to) is to not name the first segment, and let the next ramp segments be named and propagate "backward" so that if the driver is heading to 12A, they will get "Exit 12A: I-95 N / Cityname1" for the first exit and the next, which will match part of the first BGS they see, and will match the second BGS they see.

I agree with this. I do this whenever one ramp has two separate signs which are replicated exactly at the split further down the ramp. This is indeed commonly found in "Exit 12A / Exit 12B" situations.

If you're missing exits because they have two separate signs, I might recommend paying closer attention to the arrows at the bottom of exit signs. That, and Waze tells you to exit when you get there, so there should be no confusion concerning whether this is the right exit. Better to display information relevant to the user's current route, and to get TTS directions out of the way of the next direction. Putting two interstate signs full of information on one segment is poor form when there is inevitably going to be another important instruction pretty soon ahead.

[banished]

Could we wait until Waze implements the slash pronunciation delay before abandoning our ramp syntax agreement made at the Meetup? Slashes ruin TTS, but I got onboard with it (at the Meetup) predicated upon Waze making it sound like a comma. Now because there's impatience waiting for Waze to implement it, there's a move afoot to make another change to try and finesse TTS into doing what we want. At least that's the way I've read this thread. Have I got it mostly right?

I am having to go back and fix ramps were people added the double-colon in my local area to get those segments into conformity with our agreement. Of course, there's no such thing as "my local area" under this editing system, but I'll keep fixing them as I find them. When Waze gets the slash pronunciation change implemented and if it doesn't meet our expectations, then it would be fruitful to reopen this discussion.

The only two solutions I can think of at this point are as follows:

1. AMs to agree on some etiquette that if they want to implement a syntax change, they need to keep in in their home area. That etiquette would have to manifest itself in gentlemen's agreements between neighboring AMs not to fuss in the other AMs home area and agree where the border lies between the two.

2. Less desirable would be to stop the ability of AMs to edit or unlock outside the area where they live regardless of what level they are, including me.

I am as eager as the next AM to reach resolution on syntax and TTS, but I ask we wait for Plan B (slashes creating a TTS comma-like pause) to take effect before considering a Plan C. As I recall, Waze said TTS is a 3rd party product, so they have to submit a ticket to the 3rd party. That's why I am not surprised the change has not occurred, as yet.

Thanks for reading.