Should it include Territories?

banished wrote:Oh, well. Ever the contrarian. One nation, under Waze, divisible, with undisciplined TTS for all.

Well, that's the two sides to this: should Waze force every state to use the exactly same phrase to refer to state routes or highways? Or should Waze be forced to adopt what the local naming and speaking conventions are?

I like the option to make Waze be flexible.

CTGreybeard wrote:It seems to me that whatever we use MUST agree with the SIGNAGE! When whats-her-name says "keep left for" (or whatever she really says) it really should agree with the signage. If I look up to see WTH she is talking about I should be able to make an instant correlation. I shouldn't have to even THINK about it for an moment.

For that reason, which is really driver safety after all, YES each state has to have it's own "rules". I think what Andy is trying to do here is to refine what those rules might be and how they affect the editors and TTS.

Well, of course, but no signage in Oregon necessarily says, "highway 18" but it does have http://upload.wikimedia.org/wikipedia/c ... 18.svg.png. It's how that sign is pronounced which is different all over the country. We can either standardize it across the US within Waze (a laudable goal, IMO), or we can customize it by state. Both the pronunciation, the shield, and the text description should be totally independent, in my perfect map world.

CBenson wrote:Are we expecting to get shields in the navigation bar?

They used to be there in the pre-2.4 or pre-2.0 days. I think @sketch has a screenshot....

We certainly do not need an alt field for the shield data. That's what the shieldtext field is for. Primary name is for local name or state route naming or local highway naming as desired by local needs and signage and (currently) what is desired for spoken name.

AndyPoms wrote:

AlanOfTheBerg wrote:We certainly do not need an alt field for the shield data. That's what the shieldtext field is for. Primary name is for local name or state route naming or local highway naming as desired by local needs and signage and (currently) what is desired for spoken name.

In my talks with a few different people at Waze, I've been told that the plan is to use the Alt-Names for exactly that - Alternate Names for the segment.

It will support things like a road that runs on the border between two town, where the addresses on the right are in one city and the ones on the left are in the other city. One city gets the primary field, the other gets the Alt- field (i.e. "Anytown/Main St" as the primary and "Othertown/Main St" as an Alt).

It will also support things like multiple shields per segment. This is especially useful for concurrences - I-84 would be the primary, but shields will also be generated for the overlaps (US-7, US-7, US-202) that are designated in the Alt-Name field.

You're mistaking alt-name for linked street shield information. Every street has a name and shieldtype and shieldtext. If Waze gives us the control over the shield text directly, which they've stated multiple times they would, then the linked street name doesn't need to have any relationship (technically-speaking) to the shield data. This data model is already in place, all we need is the UI to control it.

sketch wrote:But how many shieldtype and shieldtext fields are there? If there's only one, and if there can only be one, then the system needs to be changed. And does the existing system replace all instances of the road name with the shield? Because that would be absolutely unacceptable. I know I don't ever see "I-10 E" or "I-10 W" on shielded segments. We need to display "Airline Dr" AND [US-61 shield], NOT one or the other. And we need to display [I-59 shield] AND [I-20 shield], and it sounds like that wouldn't be possible under the current infrastructure.

Every alternate segment already has it's own, so it is essentially unlimited in what we can define. What Waze will (eventually) display is a totally different conversation.

sketch wrote:I'm not sure what you mean by "every alternate segment". If you mean every segment as opposed to every street-within-a-particular-city as I'm assuming, would I go down Airline Dr and choose to add a US-61 shield to every fifth segment or so, and it'd show shields just for those bits?

As I noted above, there's a stark difference between defining the shield and displaying them. Don't confuse what I'm writing. At this time, livemap and the app only display a single value for any segment, whether that is a shield or the primary name. No alternate data is allowed to display at all today.

I would never advise adding some data to limited segments in order to trick the display. I've seen editors do this to the primary segment, switching between two concurrent interstate numbers so that the display showed both.

We should be defining the data properly and as free from kludges as possible. It's up to Waze to actually show it as we want.

I've posted this screenshot before, showing that the multiple shield data is already definable and usable. The data below comes from the shieldtype and shieldtext fields only, not from the names of segments.

sketch wrote: I see what you're saying. I still don't see the advantage of having to add shields manually except where maybe an automated process didn't work properly. I suppose it could also be used to remove shields for unsigned routes.

If a segment name has data to use, fine. But why have duplicate data: same "name" in primary name which is used to create the shield data? I'd like to have "Main St" be the primary name with "US-141" for the shield data and call it good. No need for alt names at all. Waze figures out how to display the name and shield.

sketch wrote:It's only "duplicate data" in that it exists in both the name field and the shield field. But if the shield field is automatically-generated instead of user-generated, then what does it matter if the data exists twice? "Major highway" and "thick" and "red" are also "duplicate data" in that regard.

Yes, that's exactly why it's duplicate data. Why have it if you don't need it? I am not aware of any location where we could enter "thick" or "red." I'd much rather have the ability to name a street "Main St" and set a shield for it than having to set it to "Main St" with no shield associated, then go add an alternate street named "US-141" which would then (hopefully) generate the shield data for the alternate segment. I see that as overly complex, unintuitive, and a waste of database space. The primary segment already has the fields sitting empty for shield data, so adding an alternate name increases space and processing requirements. For one segment, minuscule impact. But for billions of segments, a significant impact.

I would much rather have direct control over shield data (pre-populated as much as possible with current primary and alternate street data) than rely on any scripted expression handler. That's just too unintuitive to me. I want the control. There's little possibility a computer could screw it up because there's an extra whitespace somewhere.

sketch wrote:Plus, doing it this way doesn't account for the possibility of putting shields in the navigation instructions.

What? Where'd you get this? If the shield is specified in the shield data for "Main St" then certainly it could be put in nav instructions. If you want the nav instructions to say something other than "Main St" then what would you do? Alternate names aren't spoken. If you want it to say "US 141" that will have to be the primary name, just like your example of OH-53. (However, if they also give us the phonetic field, you can fill that with whatever level of detail you want "Ohio 53 / Main St")

sketch wrote:It's pie in the sky, maybe, but having manual controls for shields would not allow for the placement of shields inline, on exit signs and such.

Again, why not? Why is manual field control all of a sudden not allowing shields to appear anywhere? I don't get where this assumption is coming from.

sketch wrote:Besides, the map is already full of alt names for concurrent routes. Why do away with--or bother trying to convert--all the data we have and make it harder to enter?

I'm not advocating changing everything, but if there is an easier way to do things going forward, I say we go for it. Waze should use and display data from primary name+shield data and alternate streets and shield data. That's what I'm advocating.

sketch wrote:I like Riamus's idea of choosing which names to display, btw. If something is "I-10 E" and "US-90 E" and "AL-10 E", but the Alabama route isn't signed, uncheck the box next to "AL-10 E". If the data's already there, great, and if they choose to sign it we can check the box without checking where AL-10 actually goes.

That kind of selectability is a nice feature.