>:

> Ahoj, > > To jsme zase zpátky hledání problému pro řešení - pokud je ten datový > zdroj s jakoukoli Unicode collation (mimo *_bin), tj. stávající stav, tak > to bude hledat i porovnávat bez ohledu na diakritiku, velká a malá písmena, > a dokonce i "exotické" whitespacy. (Exhibit A: Nominatim, zkuste si v něm > trochu zavyhledávat) > > Já chápu, že po třiceti letech Kameníků a win1250 a kdoví čeho ještě máme > všichni (já taky) neurózu z nabôdeníček, ale tady máme systém, který je > (přinejmenším pro latinku) docela slušně promyšlený. Nevynalézejme hranatá > kola. > > HPM > > Dne 20. 1. 2017 6:55 odp. napsal uživatel "Lukáš Karas" < > lukas.karas na centrum.cz>: > >> Tak tento problém musí všichni řešit už nyní. >> A nemusíš ani chtít párovat OSM s jinými daty, ale třeba jen strojově >> vytvořit >> strom adres z OSM dat... >> >> Například máme název ulice "Pod Lipami" [1] ale adresní nody mají v >> "addr:street" hodnotu "Pod lipami" [2]. >> >> Takže musíš minimálně normalizovat velikost písmen, což je docela sranda >> ale >> dá se to pro latinku s přimhouřeným okem zvádnout, ale co dělat když máš >> administrativní oblast "Bělá u Turnova" [3] ale tag "addr:place" je >> nastaven >> na "Bělá" [4] ? >> >> Je ale pravda že pokud program nenormalizuje bílé znaky tak jej pevná >> mezera >> rozbije, to je potřeba také zohlednit :-( OSM není bohužel (bohudík?) >> relační >> databáze, takže při práci s ní vždy bude docházet ke špatnému provázání >> dat. >> >> Lukáš >> >> >> 1) https://www.openstreetmap.org/way/28714626 >> 2) https://www.openstreetmap.org/node/296700722 >> 3) https://www.openstreetmap.org/relation/426770 >> 4) https://www.openstreetmap.org/node/198686670 >> >> >> Dne pátek 20. ledna 2017 16:45:07 CET jzvc napsal(a): >> > Dne 19.1.2017 v 21:36 Jan Macura napsal(a): >> > > //pardon, odeslal jsem mail předčasně >> > > >> > > 2017-01-19 9:01 GMT+01:00 Lukáš Karas <lukas.karas na centrum.cz >> > > >> > > <mailto:lukas.karas na centrum.cz>>: >> > > Ano, zalomení řádku je forma (pokud nepíši poezii). Ale nikdo >> nechce >> > > do osm >> > > dat dávat konce řádku do názvů - tedy to kde zalomit. Ale bavíme >> se >> > > o pevných >> > > mezerách. Tedy kde nezalomit. Je to věcí jazyka, měly by dle mě >> být >> > > součástí >> > > všech strojově čitelných textů - tedy dle mě obsah. >> > > >> > > Chápu, ale pořád mi to nepřijde jako dostatečný argument. Je to jedno >> > > bez druhého – informace o tom, kde nezalomit řádek může existovat jen >> > > pro potřeby jeho zalomení a jsme zpátky u formátování dat (textu) pro >> > > konkrétní potřeby. >> > > >> > > Ale ten hate Jana Martince mě trochu nalomil (sic!). Pokud neexistuje >> > > žádný argument proti, kromě logického (to, co se tu snažím obhajovat), >> > > nemá asi smysl tomu bránit. Navíc, když Ladislav Laska píše, že >> některé >> > > editory s tím umí pracovat, bral bych to v nejlepším duchu OSM (a >> > > dobrovolnictví) jako možnost, ale určitě ne nutnost. >> > >> > Existuje minimalne jeden zasadni argument proti, u znacne casti prvku >> > mapy je jejich nazev zaroven jejich identifikatorem (jednoduse proto, ze >> > neni jiny). A sem opravdu zvedav, az bude nekdo porovnavat (pripadne na >> > sebe navazovat) dve databaze, co rekne na to, ze mu to proti sobe nesedi >> > jen proto, ze na jedny strane sou nejaky divny znaky, coz mu trvalo >> > tyden zjistit. >> > >> > > 2017-01-19 9:11 GMT+01:00 Mikoláš Štrajt <strajt9 na seznam.cz >> > > >> > > <mailto:strajt9 na seznam.cz>>: >> > > Fun fact: >> > > >> > > RUIAN už skloňování názvů obcí ve své databázi má. V exportu je >> to v >> > > položce obi:MluvnickeCharakteristiky. >> > > >> > > A to je dobře. Plní tak pečlivě funkci registru územní identifikace. >> > > Stejně tak bych čekal "mluvnické charakteristiky" třeba v GeoNames, >> ale >> > > ne v OSM ;-) >> > > >> > > 2017-01-19 10:35 GMT+01:00 Petr Kadlec <petr.kadlec na gmail.com >> > > >> > > <mailto:petr.kadlec na gmail.com>>: >> > > A ještě k >> > > >> > > > je extrémně výhodné, aby velikost písmen byla přímo brána jako >> > > > součást obsahu> >> > > To přece není „extrémně výhodné“ [wut?], to je přece _pravda_. Ta >> > > obec se _nejmenuje_ „libčice nad vltavou“˝, ale „Libčice nad >> > > Vltavou“. _Proto_ to tam takhle máme. Ne proto, aby bylo >> jednodušší >> > > to hezky vykreslovat. Stejně tak máme mít třeba „PP Opatřilka//– >> > > Červený lom“, nikoli „PP Opatřilka - Červený lom“ (bez ohledu na >> to, >> > > jakým písmem to pak kdo vykresluje). >> > > >> > > Je to off-topic, ale snad bude strpen. Dokážu si představit takový >> > > datový model, kde jméno objektu nebude řetězec "Kostelec nad Černými >> > > lesy", ale objekt (v OSM tedy relace) se členy "kostelec", "černá", >> > > "les" a vyjádřením jejich vzájemných vztahů , které by velikost písmen >> > > implikovaly. Možné by to bylo, jen je to úplná blbost, takhle to >> > > modelovat (= tím myslím, že je to extrémně nevýhodné ;-) ) >> > > >> > > H. >> > > >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > Talk-cz mailing list >> > > Talk-cz na openstreetmap.org >> > > https://lists.openstreetmap.org/listinfo/talk-cz >> > >> > _______________________________________________ >> > Talk-cz mailing list >> > Talk-cz na openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/talk-cz >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-cz >> >>

> > ---------- Původní zpráva ---------- > Od: Jan Martinec <jan na martinec.name> > Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org> > Datum: 20. 1. 2017 20:21:09 > Předmět: Re: [Talk-cz] Nedělitelná mezera v OSM datech - poznámka na okraj > > ...protože to první jsou čtyři znaky, a druhý je fskutčnosti znaků šest, > totiž "B(kombinující háček)el(kombinující čárka)a", a obojí je rovnocenný > způsob zápisu - ani jedno není workaround či hack. > > *fskutčnosti* - to je nějaký novotvar? Poprvé jsem to bral jako překlep, > ale podruhé už to nebude náhoda. > > Marián > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz > >

> Jo pardon, je to novotvar vytvořený Opráski Sčeskí Historje. > Evidentně ho používám, aniž bych si to uvědomil. > Zde starší (2012) > varianta: http://historje.tumblr.com/post/36601048973/mitlologické-počátki > <http://historje.tumblr.com/post/36601048973/mitlologick%C3%A9-po%C4%8D%C3%A1tki> >

> (A když jsme u toho párování, porovnávání a podobných mňamek, __normalizace > velkých písmen už teď zdaleka nestačí__ - je třeba používat nástroje, který > má daný jazyk pro Unicode. Ne proto, že by to jinak nešlo, ale proto, že to > tuhle práci udělá samo, i pro případy, který by mě ani nenapadly. Což > znamená mj. to, že když ty stringy budeš porovnávat po bajtech, tak tě > kousne nejen whitespace, ale i případ, kdy "Bělá" je sice v Unicode rovno > "Bělá", ale převedený __na bajty__ bez normalizace do NFC nebo NFD to není > identický, protože to první jsou čtyři znaky, a druhý je fskutčnosti znaků > šest, totiž "B(kombinující háček)el(kombinující čárka)a", a obojí je > rovnocenný způsob zápisu - ani jedno není workaround či hack.

> (A když jsme u toho párování, porovnávání a podobných mňamek,

> velkých písmen už teď zdaleka nestačí__ - je třeba používat nástroje,

> má daný jazyk pro Unicode. Ne proto, že by to jinak nešlo, ale proto, že

> tuhle práci udělá samo, i pro případy, který by mě ani nenapadly. Což > znamená mj. to, že když ty stringy budeš porovnávat po bajtech, tak tě > kousne nejen whitespace, ale i případ, kdy "Bělá" je sice v Unicode rovno > "Bělá", ale převedený __na bajty__ bez normalizace do NFC nebo NFD to není > identický, protože to první jsou čtyři znaky, a druhý je fskutčnosti znaků > šest, totiž "B(kombinující háček)el(kombinující čárka)a", a obojí je > rovnocenný způsob zápisu - ani jedno není workaround či hack.