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 standard rendering).
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. Polyglot On Wed, Jul 17, 2019 at 12:58 AM Andrew Errington <[email protected]> wrote: > 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 > engine. > > 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. > > Andrew > > On Wed, Jul 17, 2019, 09:20 Greg Troxel <[email protected]> wrote: > >> John Whelan <[email protected]> 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 >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk >> > _______________________________________________ > talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk
