Osmand - také vás trápí vyhledávání jmen s diakritikou (diskuse)

[Filip Jirsák]

Takovéhle věci se řeší opačně – při indexování ta slova zaindexujete s diakritiky i bez. Jinak by vám pro vyhledávání vzniklo moc kombinací – kdybyste měl v hledaném textu jenom tři písmena, která mohou mít jedno diakritické znaménko, musel byste vytvořit 2³ kombinací a všechny vyhledat.

[Josef Kufner]

A nebo se ve funkci na porovnávání stringů použije převodní tabulka. Sice pak je porovnání pomalejší, ale ne o moc a můžeš použít indexy, které nerespektují pravidla daného jazyka, takže je pak telefon nemusí přepočítávat.

[Bystroushaak]

Taky se dá ještě porovnávat syntaktická vzdálenost slov v jejich vektorovém prostoru.

[pavlix]

syntaktická vzdálenost slov

To sis teďka vymyslel nebo ten pojem už někdo používá?

[Bystroushaak]

Mám takový pocit, že to mám odněkud z MLMU, ale možná jsem to zkomolil. V podstatě se jedná o hledání slov, které se významově nachází na stejných souřadnicích, i když jsou jinak rozdílná v textové reprezentaci. Výhoda je, že by to pak bralo třeba i skloňování rodů a tak.

Jinak další alternativa by bylo použít modifikovanou Levenshtein distance.

[Filip Jirsák]

To ale pro vyhledávání adres nemá vůbec smysl. Když hledáte Lipovou ulici, nechcete najít Kaštanovou. Vyhledávat podle Levenštejnovy vzdálenosti dává smysl, řeší to i případy, kdy jméno přesně neznáte (někde je Lipová a někde Lípová ulice). Ještě je dobré k tomu přidat synonyma – pro zkratky (nám. vs náměstí), případně třída/ulice. Každopádně tohle všechno už znamená měnit vyhledávací algoritmy, transformace na text bez diakritik při indexování i vyhledávání může být jen otázka konfigurace, případně přidání dvou řádků programu.

[pavlix]

Když hledáte Lipovou ulici, nechcete najít Kaštanovou.

To není vůbec jisté. Třeba moje babička místo Ďáblice běžně říkala Čertovo město.

[Bystroushaak]

To ale pro vyhledávání adres nemá vůbec smysl. Když hledáte Lipovou ulici, nechcete najít Kaštanovou.

Samozřejmě záleží na způsobu, jakým si ten dataset člověk sestaví. Určitě by nemělo smysl používat to jako běžný slovník synonym. Pointa byla, aby to u Kaštanové našlo i "Kaštenovou", "V kaštanové" atp..

K tomu se nemusí používat pouze algoritmus porovnávající řetězce nějakým fuzzy způsobem, ale dá se každá ulice namapovat na N dimenzionální souřadnice vektorového prostoru, přičemž uživateli nabídneš vše, co je ve vektorovém prostoru v nějaké definivané blízkosti.

Vyhledávání je pak docela rychlé, protože ti stačí spočítat vektor pro zadaný řetězec a podívat se do databáze co je mu blízko. Podrobnosti viz:

• Sémantická analýza textů (2)
• Sémantická analýza textů (4)

V případě machine learningu to pak můžeš obohatit ještě daty s modelem jazyka, což ti v tom prostoru přiblíží i věci, které by jinak byly vzdálené, viz to co psal pavlix a Ďáblice / Čertovo město. Pokud to ale chceš dělat automatizovaně, tak na to potřebuješ fakt velké sety dat (dá se to nakrmit třeba všema knížkama, co kdy vyšly a jsou dostupné tak podobně). Je to sice docela náročné na předpočítání, ale pak se v tom rychle vyhledává, proto to používají skoro všechny dnešní vyhledávače.

[Bystroushaak]

Trochu lepší příklad je třeba "Ulice Bratrů", kde by bylo fajn, kdyby to našlo i "bratří", "bratrská" a "bratrovská", což je všechno významově blízko, ale třeba právě levenštejnova vzdálenost mezi „bratrů“ a „bratrovská“ bude daleko. Daly by se asi najít i smysluplnější příklady, ale nic lepšího mě teď v rychlosti nenapadá. Problém běžnému matchování taky dělá třeba české ch, které je brané jako jedno písmeno. Viz třeba Eiphoune, Keiti Pary nebo Bloothoot – nejlepší zkomoleniny v Seznam.cz Vyhledávání za rok 2015 .

[pavlix]

Husova, Husitská, Husinecká, to si taky člověk lehce splete.

[Josef Kufner]

Zdojáky jsou na Githubu. Hrej si

[Filip Jirsák]

Jestli to chápu správně, jedná se o vyhledávání na mobilním telefonu. Myslím, že účelem není čtrnáct dní počítat index a pak jím zaplnit 64GB SD kartu. Účelem je snazší vyhledávání s omezenou klávesnicí mobilních telefonů.

[Bystroushaak]

Sice to nemám nijak potvrzené, ale imho by ten index pro názvy ulic zabral jen pár megabajtů. Předpočítat by se pravda musel.

[JS1]

To ale pro vyhledávání adres nemá vůbec smysl. Když hledáte Lipovou ulici, nechcete najít Kaštanovou.

Adres asi ne, ale kdyz treba nekdo hleda kostel, a vyhodi mu to aspon kapli, mozna bude i rad.

[Petr]

Lepič znovu zasahuje

[Bystroushaak]

Já rozumím tomu, proč jsi to napsal, nerozumím ale tomu, že ti to nepřijde dětinské. V tvé hlavě to asi funguje, ale v očích ostatních, kdo tohle budou číst děláš tímhle způsobem dementa především ze sebe.

[Petr]

podle ostatnich se tu hodnotis akorat ty

[Bystroushaak]

To jako odpověď vůbec nedává smysl.

[Petr]

Tobě toho taky moc smysl dávat nemůže

[Jendа]

Já rozumím tomu, proč jsi to napsal, nerozumím ale tomu, že ti to nepřijde dětinské.

Robotovi generujícímu komentáře pomocí Markovových řetězců a bezkontextové gramatiky nemůže něco přijít.

[pavlix]

Ty už si zase hraješ s robotama? :)

[kyknos]

robotkama

[tom]

Ona vubec lokalizace OsmAnd je takova dost podivna Na syntezu nazvu to nepouziva jazyk, v kterem ten nazev je, ale jazyk navigace. Takze pokud jedete treba po Nemecku a telefon je v AJ, tak to strasse vyslovuje jako "štrasí". Prekvapive nepomuze ani pokud ma misto svuj vlastni nazev v jazyce navigace (treba Munich), tak to porad bere pouziva nazev mistni (Muenchen), ale syntetizuje podle jazyku navigace.

[Josef Kufner]

Tady.

[Jardík]

Lepší by bylo ty navigace vyhodit a pořídit si mapu. Navigace je špehující šmejďárna.

[Josef Kufner]

Osmand je offline navigace, včetně offline vyhledávání a offline map. Jediné, co to špehuje, je stát či region, který si stáhneš.

[Marián Kyral]

Jardík je 32 bit špehující šmějďárna

[Dreit]

Mně by se zase líbilo stahování map přes zsync nebo něco na ten způsob - netahat pořád dokola celou mapu, ale jen změny a pak sestavit dohromady

[Josef Kufner]

Něco na ten způsob se tam nedávno objevilo.

[Dreit]

Tak to se musím podívat, jestli to moje verze z F-droidu umí