« zpět na výpis měsíce |

[Talk-cz] Nedělitelná mezera v OSM datech - poznámka na okraj

Vlákno 20.1. - 31.1.2017, počet zpráv: 6


20.1.2017 08:19:31 (#1)
gravatar

Jan Martinec

<jan at martinec.name>
377 2310
(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. Konec hlášení pro řetězcovou veřejnost ;)) Dne 20. 1. 2017 18:55 napsal uživatel "Lukáš Karas" <lukas.karas at centrum.cz zobrazit citaci
>:
zobrazit citaci
> 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 at 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 at centrum.cz >> > > >> > > <mailto:lukas.karas at 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 at seznam.cz >> > > >> > > <mailto:strajt9 at 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 at gmail.com >> > > >> > > <mailto:petr.kadlec at 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 at openstreetmap.org >> > > https://lists.openstreetmap.org/listinfo/talk-cz >> > >> > _______________________________________________ >> > Talk-cz mailing list >> > Talk-cz at openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/talk-cz >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-cz >> >>
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/6b25de6e/attachment.html>

20.1.2017 09:00:56 (#2)
gravatar

Marián Kyral

<mkyral at email.cz>
2242 2430
---------- Původní zpráva ---------- Od: Jan Martinec <jan at martinec.name> Komu: OpenStreetMap Czech Republic <talk-cz at 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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/1ea6f38d/attachment-0001.html>

20.1.2017 09:17:41 (#3)
gravatar

Jan Martinec

<jan at martinec.name>
377 2310
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 Dne 20. 1. 2017 21:02 napsal uživatel "Marián Kyral" <mkyral at email.cz>: zobrazit citaci
> > ---------- Původní zpráva ---------- > Od: Jan Martinec <jan at martinec.name> > Komu: OpenStreetMap Czech Republic <talk-cz at 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 at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/e1add264/attachment.html>

20.1.2017 10:13:53 (#4)
gravatar

Marián Kyral

<mkyral at email.cz>
2242 2430
Dne 20.1.2017 v 21:17 Jan Martinec napsal(a): zobrazit citaci
> 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> >
Aha tak proto to neznám. Jejich prznění češtiny se mi nelíbí, takže je ignoruji. Konec zvídavého dotazu. Marián ------------- další část --------------- HTML příloha byla odstraněna... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/6bcbe509/attachment.html>

31.1.2017 12:42:26 (#5)
gravatar

Pavel Machek

<pavel at ucw.cz>
1036 1226
On Fri 2017-01-20 20:19:31, Jan Martinec wrote: zobrazit citaci
> (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.
Hmm. To abychom do kernelu pridali unicodovej normalizator. Ne-e, sorry. Zapsat pomoci 6-ti znaku na co staci 4 znaky je workaround a hack. Podobne by mi prislo rozumny normalizovat _pred_ ulozenim do osm databaze. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170131/4e50e4b4/attachment.sig>

31.1.2017 01:00:57 (#6)
gravatar

Jan Martinec

<jan at martinec.name>
377 2310
Já bych si dovolil tvrdit něco jiného: Můžeme s tím nesouhlasit, můžeme o tom diskutovat, ale to je situace, kterou s Unicode a s UTF8 už teď máme, a je to stav odpovídající specifikaci unikodu, tj.ne chyba k opravě. Volat "fuj fuj hack nechci to" je sice možný názor, ale jakou navrhuješ alternativu? Vrátíme se ke Kameníkům, byli takoví hezký a přehledný? Tahle loď už odplula - planetfile je tak nějak z definice celosvětový, a Unicode znaky nejsou bajty, ba ani 1:1 sekvence bajtů (kernelu se to medle netýká vůbec, to je záležitost OSM toolchainu). Normalizovat před uložením - já jsem úplně pro, když zrovna pro češtinu ten kratší způsob zápisu existuje...jenže to si můžeme říct tady, a kdo to bude hlídat, že třeba nějaká appka nebude zapisovat tagy v NFD? Z principu to ani nemůže nikdo u-hlídat; prostě je třeba počítat s tím, že občas dostaneme validní data kódovaná jinak než tou konvencí, kterou si tady my vzájemně řekneme. TL;DR: nemáme vliv na všechna vstupní data, a nic s tím nenaděláme. Pokud jsou validní, musíme s nimi žít. Dne 31. 1. 2017 12:43 odp. napsal uživatel "Pavel Machek" <pavel at ucw.cz>: On Fri 2017-01-20 20:19:31, Jan Martinec wrote: zobrazit citaci
> (A když jsme u toho párování, porovnávání a podobných mňamek,
__normalizace zobrazit citaci
> velkých písmen už teď zdaleka nestačí__ - je třeba používat nástroje,
který zobrazit citaci
> má daný jazyk pro Unicode. Ne proto, že by to jinak nešlo, ale proto, že
to zobrazit citaci
> 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.
Hmm. To abychom do kernelu pridali unicodovej normalizator. Ne-e, sorry. Zapsat pomoci 6-ti znaku na co staci 4 znaky je workaround a hack. Podobne by mi prislo rozumny normalizovat _pred_ ulozenim do osm databaze. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni. cz/~pavel/picture/horses/blog.html _______________________________________________ Talk-cz mailing list Talk-cz at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170131/11378c69/attachment.html>

« zpět na výpis měsíce