sketch wrote:We built the Wiki ourselves, and it is ours to change. I understand the desire for a voting process, but I don't think it's necessary, and to be honest it seems like a bit of a nightmare. We can have a yes or no question asking whether members of the community approve, and if it's "no", we're left with the existing faulty system; or, we can have a few different proposals, none of which will ever get a majority.

Nothing truly great has ever come out of a focus group. Design by committee gave us the Chevy Citation, not the iPod.

The maps are maintained by a community of editors that have a vested interest in the standards outlined in the wiki. Your description of committee usefulness makes it obvious that you're frustrated and favor playing dictator, I don't think that will work here.

If proposed changes to the standards outlined in the wiki are not met with obvious consensus in the forums, I then think voting on competing proposals is the best way forward (and leaving it the way it is shall always be an option).

I'm not in favor of having multiple colons. It looks funny to me and is something you would never do grammatically. I know what we are doing is shorthand for directions, but I think we do need to follow some rules of punctuation usage.

Someone had said that the request was made to have the slash also execute a pause so I say we keep the current standard with one Colin have the exit number and patiently wait for Waze to update the TTS.

What we also have to keep in mind is that not everyone wants TTS so we want to keep the ramp name clear too and I think the additional colons makes that confusing.

banished wrote: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.

Total agree. No need to edit now for something that will likely need to be reedited in the (hopefully) near future.

Double colons are the devil.

Beyond my initial feelings that multiple colons just look wonky, there are several other reasons why I think it isn't best practices to use them.

Suppose we have an exit sign as follows:

Exit ##
I-XX US-YY US-ZZ
City 1
City 2
City 3

The exit sign gives you all of those options so having "Exit ##: I-XX / US-YY / US-ZZ / Town 1 / Town 2 / Town 3" is a valid segment name. It also provides all the information available on the sign, in the order that it is presented.

It can be argued that having the city name linked to the road options provides more information. I can understand that, but I don't think that can be achieved easily and consistently.

If we start linking roads and cities then we start reorganizing the signs. So no longer do the segment names correspond to the way people read (right to left, top to bottom), but start jumping all over the place. I think this becomes confusing to the driver and is distracting. It also introduces further complexity for the editor because they then have to link the roads and city names. This requires even more work and sometimes isn't the easiest thing to do as that information is not always apparent from what is provided on the exit sign.

Also, exit signs farther down the road (or as Exit ##A, Exit ##B, etc.) will provide you with more information about which roads/cities are linked when you need to exit to those roads so we are not losing information by not linking them on the initial sign.

Finally, I don't think that an one easy rule can be applied for colons. Take the above exit sign example and suppose I-XX and US-YY overlap and US-ZZ leads to both City 2 and City 3. Then you going to have the segment labeled:

"Exit ##: I-XX / US-YY: City 1 / US-ZZ: City 2 / City 3"

To me, that gets really confusing because we are mixing the slashes for the overlap and using a slash to parse the second road out (US-ZZ) and then using another slash for City 2 / City 3. So the slashes lose their meaning rather quickly becuase they are used in multiple scenarios.

I'm sure we can come up with multiple if/then scenarios for colon use, but that again because for confusing and makes editing more difficult.

What we should strive to do is to have segment names that:
1) Provide as much information as possible;
2) Are intuitive for the driver; and
3) Are easy to implement for the editor.

And then further down the list we try to minimize the number of characters, but not at the expense of the other three, which I think the double colon does.

Since standard changes are being suggested...

Regarding entry ramp naming, why is 'to' needed? The TTS ignores the word to in the entry ramp name and says it or 'at' natively. Every road goes 'to' somewhere. Other GPS applications don't have have 'to' displayed for the next turn instruction.

It's redundant and not needed.

CBenson wrote:I always thought the "to" was needed to distinguish from the actual road. Not so important if the sign has the control city, but if it doesn't you need to say "to I-95 N" rather than just "I-95 N" on the ramp.

If it's a type ramp, we know it's not the actual road. As far as reports, there is the map preview.

And really if we were not overly concerned with reports, we could leave the entry ramps unnamed since the next road segment will be picked up and displayed.

Exit ramps do need to remain as named. There is value add to match the BGS, provide exit number, control city, etc.

Just to add another perspective. I had mentioned earlier in this thread that ramps named as 'to xyz' is not common with other Navigation applications. Of course a couple of days afterwards when using MotionX-GPS Drive I see ramps names in their application named:

'Ramp to xyz'

So they are going even a step further and using the word 'Ramp' in the naming. MotionX-GPS Drive uses map data from Navteq. So if Navteq is labeling ramps in this manner...

Unfortunately, as with many of these types of proposals - I don't see this going anywhere.

We need to come up with a better process to present a proposal that affects editing standards, some type of formal voting process, and a deadline. Weeks and months of opinions...

The point of naming a ramp on the Waze map is to help the driver identify the proper sign, either by seeing or hearing its contents. We shouldn't be trying to parse the sign and use punctuation in place of prepositions, to make the meaning of the sign clearer or bring out its structure. The sign is what the driver should be looking at; we only need to help him recognize which one.

I put a colon after the exit number (if any) because the signs around here generally make that look like a heading, under which is an (often indented) list of destinations--which I list using slashes as a delimiter, like a line-feed as bmitch3020 mentioned. I use an initial "to" with on-ramps because that is how I interpret the arrow that is typically on the signs around here. Granted, TTS threw us a curve ball, but if it just gets the pauses right and reads the words on the signs, that's all a driver needs.