[Talk-us] multiple-value problem in ref tags

Jack Burke burkejf3 at gmail.com
Tue Sep 16 02:03:05 UTC 2014

Hi, all.

I have a question regarding punctuation in ref tags with multiple values
(NOT to do with spaces within the values themselves).  The recommended
standard appears to be to separate them with a semicolon but no space after
the punctuation (e.g., "US 41;GA 3").  The only official reason I can see
for this in the wiki is because it's how the Germans do it.

>From the wiki:
"If more than one reference is given, you are recommended to separate them
with a semicolon and without a space character, because this is the widely
established syntax in Germany and maybe other countries. But note, this
syntax is being heavily discussed in Germany."

I'd taken to putting a space after the semicolon ("US 41; GA 3") for a
specific technical reason:  the lack of space causes reading problems for
some TTS engines, most notably the Samsung TTS engine that ships with some
Samsung devices (including my S4).  When fed a ref string without the
space, the engine says "semicolon" and when fed a string with the space, it
doesn't say "semicolon".  Since the space is the standard delimiter to
separate words, it stands to reason that a TTS engine would be written to
recognize the space for what it is.  Also, as standard grammar in English
(U.S. and U.K), not to mention most other European langauges, and even
probably others, is to follow punctuation symbols with a space, it seems a
basic design decision to write the engine to recognize that combination and
speak it properly (which is to say, not speak the punctuation symbol).  You
could call it a design oversight that the Samsung engine doesn't recognize
a semicolon without a space correctly, but I wouldn't necessarily call that
a bug.  (I will note that the Google TTS engine appears to not speak
"semicolon" in the same situation as the Samsung engine.)  As the wiki
doesn't specifically say *don't* put a space after the semicolon, I didn't
see a problem with doing it. [1]

It's been brought to my attention that the space causes problems with at
least one renderer, MapQuest Open, resulting in highway shields not always
being drawn correctly, and it has been suggested that I stop including the
space to fix the problem (in effect, to tag for the renderer) and because
'no one else in the U.S. does it that way'.  In my opinion, it's a bug that
the MQ Open renderer does not recognize standard punctuation.  It is worth
noting that Mapnik doesn't appear to have a problem with the space.

So it's time to ask the assembled multitude which way to go.  Do I continue
to include a space, avoiding the speech problem in affected TTS engines, or
do I start tagging for the renderer so that highway badges are properly
drawn in MQ Open?

Or are there other questions that need to be answered first?


[1] The Samsung engine also exibits this behavior--and the Google engine
doesn't--with destination tags that have multiple semicolon-no-space
separated values, and speaks "correctly" when a space is included.  As
semicolon-space punctuation in destination tags doesn't appear to affect MQ
Open, I'm only mentioning it in passing in this footnote.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20140915/5c49445e/attachment-0001.html>

More information about the Talk-us mailing list