[OSM-talk] handling street names in speech
winfixit at gmail.com
Wed Jul 17 07:29:01 UTC 2019
Mapping for the renderer means: adding factually wrong data such that it
renders the way the mapper wants to see it getting rendered (on the
That's not what adding IPA strings would do. True, there are multiple ways
to pronounce certain words.
Unfortunately TTS is not perfect and it never will be, for one thing
because it's often difficult to decide with TTS (which language) to use for
each word in a name string.
If OsmAND were to support the use of IPA, then I would be motivated to
transcribe all Brussels's street names in Dutch and French. Standard common
denominator Dutch and French. It would be a lot nicer to listen to than the
letters A U X spelled separately in Dutch, instead of simply 'O', what
would be the French pronunciation of those 3 letters combined. Some of the
terms in those street names are actually English names. It's simply
impossible for TTS set to Dutch or French to get those right.
IPA would definitely solve that annoyance.
On Wed, Jul 17, 2019 at 12:58 AM Andrew Errington <erringtona at gmail.com>
> I think this is a rendering issue (i.e. rendering speech instead of
> graphics) and as such does not belong in OSM.
> The work to convert an arbitrary string into speech belongs in the TTS
> If we start putting IPA strings in OSM then we will start getting
> arguments about the "correct" pronunciation. At the very least it is
> tagging for the renderer, which we should avoid.
> IMHO, of course.
> On Wed, Jul 17, 2019, 09:20 Greg Troxel <gdt at lexort.com> wrote:
>> John Whelan <jwhelan0112 at gmail.com> writes:
>> > One or two are problematic usually as the street name is an
>> > abbreviation. For example 1e Avenue in French meaning First Avenue.
>> > Any suggestions on how these should be handled? This particular
>> > application is aimed at partially sighted people but I feel we should
>> > be able to come up with a generic solution.
>> Two comments:
>> osm norms are to expand abbreviations, as I understand it. So that
>> should be fixed first
>> Even after that, we have ref tags, and there is often a road whose ref
>> is something like "CT 2", "US 1", or "I 95". I don't really think
>> this should be expanded in the database. Instead, what's needed is a
>> table in the application, perhaps centrally maintained in OSM, of how
>> to pronounce standardize ref abbreviations. Putting phonetics of
>> "connecticut" on all use of CT or the expanded name is not reasonable.
>> But I agree this needs help. I get told to turn on "Court 2" and "Ma
>> 2". Luckily I understand this by now and it actually works ok. But it
>> does need fixing.
>> talk mailing list
>> talk at openstreetmap.org
> talk mailing list
> talk at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk