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

Jan Martinec jan na martinec.name #m2e85ff 20. 1. 2017 20:19

(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 na centrum.cz

: 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

Marián Kyral mkyral na email.cz #m6cf1fa 20. 1. 2017 21:00

...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

Jan Martinec jan na martinec.name #m14a6fe 20. 1. 2017 21:17

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 na email.cz>:

Marián Kyral mkyral na email.cz #mc08601 20. 1. 2017 22:13

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

Pavel Machek pavel na ucw.cz #m8ca9a2 31. 1. 2017 12:42

(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

signature.asc

Jan Martinec jan na martinec.name #m3b3eb3 31. 1. 2017 13:00

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 na ucw.cz>:

(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

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 na ucw.cz>: On Fri 2017-01-20 20:19:31, Jan Martinec wrote:

(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 _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz