[nSLUG] GPS Turn by Turn (Voice) and XML

David Potter dlpotter at eastlink.ca
Tue Jan 26 19:28:20 AST 2010


Thanks for the responses... I think I set this project back a bit by
upgrading my maps yesterday... now the device is offering me a number of
previously unexplored character sets so I may have to solve that issue
first.

I noticed when I say my earlier post coming back to me that I had not
properly 'closed' the "<txt></tx>" element so  the behaviour before the
map upgrade was most likely unpredictable.

There appears to be some opportunity to liven up the turn by turn
instruction "roundabout" could become "the circle that leads nowhere"
and that suggests a number of other quaint localisms... ;-)

Thanks again

David


Hatem Nassrat wrote:
> On Mon, Jan 25, 2010 at 6:53 AM, David Potter <dlpotter at eastlink.ca> wrote:
> [...]
>   
>> <str>
>>    <tag>TXT_Hwy__STR</tag>
>>    <txt>Highway</tx>
>> </str>
>>     
> [...]
>   
>> "Hwy" in the last item appears to provide string substitution, and also
>> seems to be case sensitive. A couple of weeks ago I edited the file to
>> add some additional variations and was mostly successful in having the
>> voice use "Highway" rather the "H W Y". The other day I happened to look
>> at the screen in the middle of another outburst of "H W Y" and noticed
>> the device was showing "HwY 111".....
>>
>> Can anyone help me figure out some way to use regular expressions (?) in
>> the <tag> </tag> elements to sanitize case abnormalities and standardize
>> the result across different map data...?
>>     
>
> Looking at the XML Schema at:
>
>     http://www8.garmin.com/xmlschemas/GarminTextTranslationv1.xsd
>
> it doesn't show that it is possible or not, however, the documentation
> for the tag field states:
>
>
>   <xs:element name="tag" type="xs:token">
>     <xs:annotation>
>        <xs:documentation>A unique identifier for the translated
> string.</xs:documentation>
>     </xs:annotation>
>   </xs:element>
>
> Which hints to the fact this identifier must uniquely identify a
> string. To me this means that is should identify only one string. So
> if it is possible to do some regular expressions, I would say that the
> statement above is incorrect. (Hence proof by contradiction, it is not
> possible to do some regex in the tag token :p). I will suggest a
> solution that I do not like (but I do not think there is another
> option), there are only 8 uppercase, lowercase combinations, why not
> list them all. In Python, we can generate them:
>
>     a = 'hwy'
>     b = 'HWY'
>     for x in range(8):
>         print ''.join([b[i] if x & y else a[i] for i,y in enumerate([4,2,1])])
>
> >From that we can generate:
>
>     <str>
>        <tag>TXT_hwy__STR</tag>
>        <txt>Highway</tx>
>     </str>
>
>     <str>
>        <tag>TXT_hwY__STR</tag>
>        <txt>Highway</tx>
>     </str>
>
>     <str>
>        <tag>TXT_hWy__STR</tag>
>        <txt>Highway</tx>
>     </str>
>
>     <str>
>        <tag>TXT_hWY__STR</tag>
>        <txt>Highway</tx>
>     </str>
>
>     <str>
>        <tag>TXT_Hwy__STR</tag>
>        <txt>Highway</tx>
>     </str>
>
>     <str>
>        <tag>TXT_HwY__STR</tag>
>        <txt>Highway</tx>
>     </str>
>
>     <str>
>        <tag>TXT_HWy__STR</tag>
>        <txt>Highway</tx>
>     </str>
>
>     <str>
>        <tag>TXT_HWY__STR</tag>
>        <txt>Highway</tx>
>     </str>
>
> I am sure you already thought of this, sorry if my solution is too trivial.
>
>   

-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20100126/f46473bd/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2007-Bench.jpg
Type: image/jpeg
Size: 17251 bytes
Desc: not available
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20100126/f46473bd/attachment-0002.jpg>


More information about the nSLUG mailing list