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

[Jan Martinec]

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" :

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

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

[Pavel Machek]

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


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Marián Kyral]

Dne 20.1.2017 v 12:06 Mikoláš Štrajt napsal(a):
> Tak vyzkoušeno v praxi:
>
> https://www.openstreetmap.org/changeset/45323834
>
> A skutečně se to na hlavní mapě projevilo, viz screenshot před úpravou:
>
> http://imgur.com/a/JhY8J 
>
> a po úpravě:
>
> http://imgur.com/a/gvOyL
>
> -- 
> Severák
>

No moc to nefunguje. Čekal bych, že se to zalomí před "u" :-D

Marián

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

Dne 20.1.2017 v 21:17 Jan Martinec napsal(a):
> 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
> 
>

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

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

-- Původní zpráva --
Od: Jan Martinec <j...@martinec.name>
Komu: OpenStreetMap Czech Republic <talk-cz@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Jan Martinec]

(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" :

> 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.ka...@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 > > >
>> > > >:
>> > > 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 > > >
>> > > >:
>> > > 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 > > >
>> > > >:
>> > > 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é“ 

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Martinec]

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.ka...@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  > >
> > > >:
> > > 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  > >
> > > >:
> > > 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  > >
> > > >:
> > > 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
> > > 

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Lukáš Karas]

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

signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[jzvc]

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

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

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

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz




___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Karel Volný]

On Thursday 19 January 2017 17:56:38 Matěj Cepl wrote:
> On 2017-01-19, 08:11 GMT, Mikoláš Štrajt wrote:
> > skutečně toto vše? - takže bychom vlastně neměli mít "Libčice
> > nad Vltavou" ale "Libčice nad Vltava"? :-)
> 
> Ale ta vesnice se tak nejmenuje!
> 
> Matěj

jistě, vesnice se tak nejmenuje poněvadž Libčice jsou město :-)

K.


signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Martinec]

On 01/20/17 13:18, Lukáš Karas wrote:

Ano, lidé na to budou zapmínat a dělat chyby. Stejně jako nyní se může stát že
někdo napíše název bez diakritiky.

Jak chceš indickému nebo čínskému vývojáři vysvětlit že by měl do svého
rendereru integrovat processor pro vkládání pevných mezer do českých názvů?
Jak chceš v rendereru detekovat že se jedná o češtinu?
Tak. Ano, můžeš teoreticky porovnávat name:* a name, a z toho hádat - 
ale vyčteš z toho jedině "toto je asi místní jazyk, tak na 80%" (pokud 
ti to nějaký tatar s Maps.me nepřepíše u Karlova mostu na name:cs=Károly 
Híd :D) - a zbylých dvacet procent bude chyba I.typu: "name=Москва, co 
je další v atributech? Aha, name:ab=Москва, takže máme jasno, použijme 
pravidla pro abcházštinu, další tagy už zkoumat netřeba."


Renderer by neměl být repozitář jazykových konvencí (a fakt pochybuju, 
že i Mapnik má nějakou takovou heuristiku), jen by měl respektovat 
hinty, kterými jsou právě ty konvence vyznačený - a jeden z těch hintů 
je "tady nelámat".


Jediné o co by renderer měl starat je respektovat unicode pravidla -
vykreslovat názvy správně v hebrejštině (psaná zprava) i v latince, či
kombinaci obého (i když jsem takové názvy v OSM ještě neviděl) zalamovat
dlouhé názvy jen tam kde je to možné...

A to je náhoda - v Missing Maps se zrovna mapuje
http://tasks.hotosm.org/project/2419 v Jižním Súdánu. Město se údajně, 
aspoň podle OSM name, jmenuje "Aweil أويل" (fskutčnosti name:en+ar)

http://www.openstreetmap.org/node/234617069#map=14/8.7555/27.3998
(Korejci to mají podobně, ale ti aspoň nemají RTL)

Neboli: NBSP zejména _centrální_ řešení. "Ať se stará renderer" znamená, 
že každý pisatel si bude smolit nějakou svoji interpolaci -

v horším případě se nebude obtěžovat vůbec, a zláme to hlava nehlava.

HPM

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Lukáš Karas]

Ano, lidé na to budou zapmínat a dělat chyby. Stejně jako nyní se může stát že 
někdo napíše název bez diakritiky.

Jak chceš indickému nebo čínskému vývojáři vysvětlit že by měl do svého 
rendereru integrovat processor pro vkládání pevných mezer do českých názvů? 
Jak chceš v rendereru detekovat že se jedná o češtinu?

Jediné o co by renderer měl starat je respektovat unicode pravidla - 
vykreslovat názvy správně v hebrejštině (psaná zprava) i v latince, či 
kombinaci obého (i když jsem takové názvy v OSM ještě neviděl) zalamovat 
dlouhé názvy jen tam kde je to možné...

Lukáš

Dne pátek 20. ledna 2017 10:00:21 CET Marián Kyral napsal(a):
> -- Původní zpráva --
> Od: Pavel Machek <pa...@ucw.cz>
> Komu: OpenStreetMap Czech Republic <talk-cz@openstreetmap.org>
> Datum: 20. 1. 2017 9:33:43
> Předmět: Re: [Talk-cz] Nedělitelná mezera v OSM datech
> 
> "On Thu 2017-01-19 17:57:44, Marián Kyral wrote:
> > Ahoj,
> > za sebe jako za uživatele k tomu můžu říct, že v běžném životě typografii
> > 
> > vůbec neřeším. Ona ta nezalomitelná mezera je stejně jen pomůcka pro
> > programy. Normálně není vidět a já fakt nechci řešit dilema, jestli tam
> > přijde taková nebo maková mezera, když obě od sebe nejdou normálně
> 
> rozeznat.
> 
> > A pochybuji, že to takoví ti příležitostní mappeři vůbec budou řešit. Tam
> > 
> > budeme rádi, když ten název správně opíší a případně u kapitálek správně
> > tipnou, kam dát velká písmena. Sám s tím mám občas problém.
> > 
> > Nějaké nezalomitelné mezery by za ně měly řešit programy. Ať už editory na
> > 
> > vstupu nebo renderery na výstupu.
> 
> Aby neco mohly resit programy, musi byt dana uloha srozumitelna pro
> pocitac. Chtit "kazdy editor musi umet cesky" asi nemuzem. Chtit
> "kazdy renderer musi umet cesky" asi taky neni dobry. Takze jak z toho
> ven?
> "
> 
> 
> Chtít "každý uživatel musí umět vložit nezalomitelnou mezeru na správné
> místo" a chtít "uživatel nikdy nezapomene vložit nezalomitelnou mezeru" asi
> taky nemůžem. V tomhle jsou ty programy spolehlivější. Je jich míň, líp se
> to hlídá a případně opravuje.
> 
> Marián
> =

signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Mikoláš Štrajt]

Tak vyzkoušeno v praxi:



https://www.openstreetmap.org/changeset/45323834





A skutečně se to na hlavní mapě projevilo, viz screenshot před úpravou:




http://imgur.com/a/JhY8J 




a po úpravě:




http://imgur.com/a/gvOyL





-- 

Severák







-- Původní zpráva --
Od: Pavel Machek <pa...@ucw.cz>
Komu: OpenStreetMap Czech Republic <talk-cz@openstreetmap.org>
Datum: 20. 1. 2017 10:21:12
Předmět: Re: [Talk-cz] Nedělitelná mezera v OSM datech

"Ahoj! 

> Od: Pavel Machek <pa...@ucw.cz> 
> Komu: OpenStreetMap Czech Republic <talk-cz@openstreetmap.org> 

> "On Thu 2017-01-19 17:57:44, Marián Kyral wrote: 
> > Ahoj, 
> > za sebe jako za uživatele k tomu můžu říct, že v běžném životě 
typografii 
> 
> > vůbec neřeším. Ona ta nezalomitelná mezera je stejně jen pomůcka pro 
> > programy. Normálně není vidět a já fakt nechci řešit dilema, jestli tam 

> > přijde taková nebo maková mezera, když obě od sebe nejdou normálně 
> rozeznat. 
> > A pochybuji, že to takoví ti příležitostní mappeři vůbec budou řešit. 
Tam 
> 
> > budeme rádi, když ten název správně opíší a případně u kapitálek správně

> > tipnou, kam dát velká písmena. Sám s tím mám občas problém. 
> > 
> > Nějaké nezalomitelné mezery by za ně měly řešit programy. Ať už editory 
na 
> 
> > vstupu nebo renderery na výstupu. 
> 
> Aby neco mohly resit programy, musi byt dana uloha srozumitelna pro 
> pocitac. Chtit "kazdy editor musi umet cesky" asi nemuzem. Chtit 
> "kazdy renderer musi umet cesky" asi taky neni dobry. Takze jak z toho 
> ven? 
> " 
> 
> Ty pravidla kam vložit nezalomitelnou mezeru jsou poměrně jasně daná. 

Hmm. Hezky pokus. Ano, jsou nejake heuristiky. Ale poznat jestli 
pismenko "v" je predlozka nebo neco jineho, spolehlive nejde, stejne 
tak nejde spolehlive poznat jazyk. 

> Nevidím důvod, proč by to nemohly umět i renderery. Vykreslování Unicode 
> nápisů se všema exotickejma písmama je stejně taková bestialita, že se 
vždy 
> volá Pango nebo nějaká jiná knihovna na seskládání znaků.  

Nahore mas dva duvody. 

> "Automaticky pridani tvrdych mezer na uzemi CR by s rozumnou chybovosti 
> melo jit... Takze podle me je rozumny udelat to automaticky, a to 
> znamena debatu na imports@. Hadam ze pri ni se clovek taky dozvi 
> ze to je a ze to neni dobry napad :-). " 
> 
> To je IMHO moc práce s nepříliš velkým užitkem. Navíc hrozí, že něco 
> rozbijeme. 

Tak dle komentare nahore je to jednoduchy, tak jaky moc prace a jaky 
rozbijeme? imports@ se postara o review, o to se nebojim. 

> Nicméně navrhuju to na pár obcích vyzkoušet. Už o tom diskutujeme dost 
> dlouho. :-) 

Klidne... 
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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Pavel Machek]

Ahoj!

> Od: Pavel Machek 
> Komu: OpenStreetMap Czech Republic 

> "On Thu 2017-01-19 17:57:44, Marián Kyral wrote: 
> > Ahoj, 
> > za sebe jako za uživatele k tomu můžu říct, že v běžném životě typografii 
> 
> > vůbec neřeším. Ona ta nezalomitelná mezera je stejně jen pomůcka pro 
> > programy. Normálně není vidět a já fakt nechci řešit dilema, jestli tam 
> > přijde taková nebo maková mezera, když obě od sebe nejdou normálně 
> rozeznat. 
> > A pochybuji, že to takoví ti příležitostní mappeři vůbec budou řešit. Tam 
> 
> > budeme rádi, když ten název správně opíší a případně u kapitálek správně 
> > tipnou, kam dát velká písmena. Sám s tím mám občas problém. 
> > 
> > Nějaké nezalomitelné mezery by za ně měly řešit programy. Ať už editory na
> 
> > vstupu nebo renderery na výstupu. 
> 
> Aby neco mohly resit programy, musi byt dana uloha srozumitelna pro 
> pocitac. Chtit "kazdy editor musi umet cesky" asi nemuzem. Chtit 
> "kazdy renderer musi umet cesky" asi taky neni dobry. Takze jak z toho 
> ven? 
> "
> 
> Ty pravidla kam vložit nezalomitelnou mezeru jsou poměrně jasně daná.

Hmm. Hezky pokus. Ano, jsou nejake heuristiky. Ale poznat jestli
pismenko "v" je predlozka nebo neco jineho, spolehlive nejde, stejne
tak nejde spolehlive poznat jazyk.

> Nevidím důvod, proč by to nemohly umět i renderery. Vykreslování Unicode 
> nápisů se všema exotickejma písmama je stejně taková bestialita, že se vždy 
> volá Pango nebo nějaká jiná knihovna na seskládání znaků. 

Nahore mas dva duvody.

> "Automaticky pridani tvrdych mezer na uzemi CR by s rozumnou chybovosti 
> melo jit... Takze podle me je rozumny udelat to automaticky, a to 
> znamena debatu na imports@. Hadam ze pri ni se clovek taky dozvi 
> ze to je a ze to neni dobry napad :-). "
> 
> To je IMHO moc práce s nepříliš velkým užitkem. Navíc hrozí, že něco 
> rozbijeme.

Tak dle komentare nahore je to jednoduchy, tak jaky moc prace a jaky
rozbijeme? imports@ se postara o review, o to se nebojim.

> Nicméně navrhuju to na pár obcích vyzkoušet. Už o tom diskutujeme dost 
> dlouho. :-)

Klidne...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Marián Kyral]

-- Původní zpráva --
Od: Pavel Machek <pa...@ucw.cz>
Komu: OpenStreetMap Czech Republic <talk-cz@openstreetmap.org>
Datum: 20. 1. 2017 9:33:43
Předmět: Re: [Talk-cz] Nedělitelná mezera v OSM datech 
"On Thu 2017-01-19 17:57:44, Marián Kyral wrote: 
> Ahoj, 
> za sebe jako za uživatele k tomu můžu říct, že v běžném životě typografii 

> vůbec neřeším. Ona ta nezalomitelná mezera je stejně jen pomůcka pro 
> programy. Normálně není vidět a já fakt nechci řešit dilema, jestli tam 
> přijde taková nebo maková mezera, když obě od sebe nejdou normálně 
rozeznat. 
> A pochybuji, že to takoví ti příležitostní mappeři vůbec budou řešit. Tam 

> budeme rádi, když ten název správně opíší a případně u kapitálek správně 
> tipnou, kam dát velká písmena. Sám s tím mám občas problém. 
> 
> Nějaké nezalomitelné mezery by za ně měly řešit programy. Ať už editory na

> vstupu nebo renderery na výstupu. 

Aby neco mohly resit programy, musi byt dana uloha srozumitelna pro 
pocitac. Chtit "kazdy editor musi umet cesky" asi nemuzem. Chtit 
"kazdy renderer musi umet cesky" asi taky neni dobry. Takze jak z toho 
ven? 
"


Chtít "každý uživatel musí umět vložit nezalomitelnou mezeru na správné 
místo" a chtít "uživatel nikdy nezapomene vložit nezalomitelnou mezeru" asi 
taky nemůžem. V tomhle jsou ty programy spolehlivější. Je jich míň, líp se 
to hlídá a případně opravuje.

Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Mikoláš Štrajt]

-- Původní zpráva --
Od: Pavel Machek <pa...@ucw.cz>
Komu: OpenStreetMap Czech Republic <talk-cz@openstreetmap.org>
Datum: 20. 1. 2017 9:33:42
Předmět: Re: [Talk-cz] Nedělitelná mezera v OSM datech

"On Thu 2017-01-19 17:57:44, Marián Kyral wrote: 
> Ahoj, 
> za sebe jako za uživatele k tomu můžu říct, že v běžném životě typografii 

> vůbec neřeším. Ona ta nezalomitelná mezera je stejně jen pomůcka pro 
> programy. Normálně není vidět a já fakt nechci řešit dilema, jestli tam 
> přijde taková nebo maková mezera, když obě od sebe nejdou normálně 
rozeznat. 
> A pochybuji, že to takoví ti příležitostní mappeři vůbec budou řešit. Tam 

> budeme rádi, když ten název správně opíší a případně u kapitálek správně 
> tipnou, kam dát velká písmena. Sám s tím mám občas problém. 
> 
> Nějaké nezalomitelné mezery by za ně měly řešit programy. Ať už editory na

> vstupu nebo renderery na výstupu. 

Aby neco mohly resit programy, musi byt dana uloha srozumitelna pro 
pocitac. Chtit "kazdy editor musi umet cesky" asi nemuzem. Chtit 
"kazdy renderer musi umet cesky" asi taky neni dobry. Takze jak z toho 
ven? 
"



Ty pravidla kam vložit nezalomitelnou mezeru jsou poměrně jasně daná.




TeX na to má program nazývaný vlna (http://www.fit.vutbr.cz/~martinek/latex/
czech.html#03), umí to i Word nebo OpenOffice.




Nevidím důvod, proč by to nemohly umět i renderery. Vykreslování Unicode 
nápisů se všema exotickejma písmama je stejně taková bestialita, že se vždy 
volá Pango nebo nějaká jiná knihovna na seskládání znaků. 




Renderer by prostě před renderThatText volal ehnaceTextTzpography, nebo tak 
něco. 

 
"Automaticky pridani tvrdych mezer na uzemi CR by s rozumnou chybovosti 
melo jit... Takze podle me je rozumny udelat to automaticky, a to 
znamena debatu na imports@. Hadam ze pri ni se clovek taky dozvi 
ze to je a ze to neni dobry napad :-). "



To je IMHO moc práce s nepříliš velkým užitkem. Navíc hrozí, že něco 
rozbijeme.




Nicméně navrhuju to na pár obcích vyzkoušet. Už o tom diskutujeme dost 
dlouho. :-)




-- Mikoláš Štrajt / Severák / http://severak.svita.cz/




___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Martin Ždila]

Podľa mňa dávať do názvov tvrdé medzery zmysel má. Veď na tento účel
vlastne tú tvrdú medzeru vymysleli.

-- 
Ing. Martin Ždila 
OZ Freemap Slovakia
tel:+421-908-363-848
mailto:martin.zd...@freemap.sk
http://www.freemap.sk/
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Pavel Machek]

On Thu 2017-01-19 17:57:44, Marián Kyral wrote:
> Ahoj,
> za sebe jako za uživatele k tomu můžu říct, že v běžném životě typografii 
> vůbec neřeším. Ona ta nezalomitelná mezera je stejně jen pomůcka pro 
> programy. Normálně není vidět a já fakt nechci řešit dilema, jestli tam 
> přijde taková nebo maková mezera, když obě od sebe nejdou normálně rozeznat.
> A pochybuji, že to takoví ti příležitostní mappeři vůbec budou řešit. Tam 
> budeme rádi, když ten název správně opíší a případně u kapitálek správně 
> tipnou, kam dát velká písmena. Sám s tím mám občas problém.
> 
> Nějaké nezalomitelné mezery by za ně měly řešit programy. Ať už editory na 
> vstupu nebo renderery na výstupu.

Aby neco mohly resit programy, musi byt dana uloha srozumitelna pro
pocitac. Chtit "kazdy editor musi umet cesky" asi nemuzem. Chtit
"kazdy renderer musi umet cesky" asi taky neni dobry. Takze jak z toho
ven?

Automaticky pridani tvrdych mezer na uzemi CR by s rozumnou chybovosti
melo jit... Takze podle me je rozumny udelat to automaticky, a to
znamena debatu na imports@. Hadam ze pri ni se clovek taky dozvi
ze to je a ze to neni dobry napad :-).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Macura]

//pardon, odeslal jsem mail předčasně

2017-01-19 9:01 GMT+01:00 Lukáš Karas :

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

2017-01-19 9:11 GMT+01:00 Mikoláš Štrajt :

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

> 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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Macura]

Ahoj,

2017-01-19 9:01 GMT+01:00 Lukáš Karas :

> A proboha, v OSM vytváříme věci ve strojově čitelné podobě, zakládáme mezi
> objekty relace aby je bylo možné strojově zpracovat. A najednou, pokud chci
> aby i texty byly ve strojově zpracovatelné formě, tak je to špatně?
>

To mi přijde trochu přehnané. Měkké mezery strojové zpracování textů
neznemožňují, ty tvrdé ho jen ulehčují.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Matěj Cepl]

On 2017-01-19, 08:11 GMT, Mikoláš Štrajt wrote:
> skutečně toto vše? - takže bychom vlastně neměli mít "Libčice 
> nad Vltavou" ale "Libčice nad Vltava"? :-)

Ale ta vesnice se tak nejmenuje!

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
How fleeting are all human passions compared to the massive
continuity of ducks.
  -- Dorothy L. Sayers: Gaudy Night


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Marián Kyral]

Ahoj,
za sebe jako za uživatele k tomu můžu říct, že v běžném životě typografii 
vůbec neřeším. Ona ta nezalomitelná mezera je stejně jen pomůcka pro 
programy. Normálně není vidět a já fakt nechci řešit dilema, jestli tam 
přijde taková nebo maková mezera, když obě od sebe nejdou normálně rozeznat.
A pochybuji, že to takoví ti příležitostní mappeři vůbec budou řešit. Tam 
budeme rádi, když ten název správně opíší a případně u kapitálek správně 
tipnou, kam dát velká písmena. Sám s tím mám občas problém.

Nějaké nezalomitelné mezery by za ně měly řešit programy. Ať už editory na 
vstupu nebo renderery na výstupu.

Marián


-- Původní zpráva --
Od: Ladislav Laska <la...@kam.mff.cuni.cz>
Komu: OpenStreetMap Czech Republic <talk-cz@openstreetmap.org>
Datum: 19. 1. 2017 9:46:35
Předmět: Re: [Talk-cz] Nedělitelná mezera v OSM datech 
"Ahoj,

nemám zrovna chuť polemizovat nad tím, co je správné a rozumné (není na
to totiž Jediná Správná Odpověď (TM) ).

Nicméně k editorům: Merkaartor si s tím poradí: Pokud vložíš
nezalamující mezeru (jako unicode znak), tak ji hezky uploaduje na
server, z tama si ji potom vyzvedne a ani při další úpravě ji nesmaže
(samozřejmě pokud ji nesmazal uživatel). 

Stejné chování bych čekal od JOSM, protože Java je taky unicodová, a od
maps.me, které je také napsané v Qt (jako Merkaartor), ani jedno jsem
ale netestoval.

On Tue, Jan 17, 2017 at 08:45:48AM +0100, Lukáš Karas wrote:
> Ahoj, o víkendu autor OSM Scout knihovny přidal užitečnou funkcionalitu
> - zalamování dlouhých popisků do více řádků. Dle očekávání se ale názvy 
> zalamují v místech kde vykreslovací engine uzná za vhodné, nikoliv tam kde

> je to správně (předložky zůstávají na konci řádku), například:
> 
> Libčice nad
> Vltavou
> 
> Týnec nad
> Sázavou
> 
> Tam lze "nad" na konci řádku ještě tolerovat i když mě osobně se nelibí, 
> ale u "u": 
> 
> Nová ves u 
> Chýnova
> 
> Je to typograficky špatně. Stejným neduhem trpí i Mapnik.
> 
> Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa 
nedělitelné 
> mezery (v xml "", unicode znak U+00A0) a existuje na to nějaký 
postup 
> jak to provést hromadně? Poradí si s tím běžné editory? Neztratí se ta 
mezera 
> při první editaci? 
> 
> Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba 
opravit 
> renderer, ale bez ní nemá prostě šanci cokoliv hádat...
> 
> Lukáš



> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz


-- 
S pozdravem Ladislav "Krakonoš" Láska http://www.krakonos.org/

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Petr Kadlec]

Ahoj˝,

2017-01-18 22:35 GMT+01:00 Jan Macura :

> 2017-01-18 10:03 GMT+01:00 Karel Volný :
>
>> obecně souhlas, akorát se neshodneme v tom, co je obsah a co je forma
>>
>
> Zalomení řádku je záležitost formy. Při každém zpracování textu může
> dopadnout jinak (jinde). Obsah je na formátování řádek nezávislý. Takže
> medle celá problematika "kde řádek zalomit" padá na hlavu zpracovatele dat.
>

Zalomení řádku je pochopitelně záležitost formy, to ale nic nemění na tom,
že v češtině se za jednopísmennými předložkami a spojkami píše nezlomitelná
mezera. Jak přesně si jaký zpracovatel zalomí řádky (jestli třeba
umí/používá Unicode Line Breaking Algorithm), jaké při tom použije písmo a
jestli zarovná na střed nebo doleva, je samozřejmě na něm. To ale
neznamená, že my nemáme používat správné znaky. Jak se ostatně píše ve
standardu Unicode:

> The actual layout in an implementation may differ in detail. A
mathematical layout system, for example, will have many additional,
domain-specific rules for layout, but a well-designed system leaves no
ambiguities as to which character codes are to be used for a given aspect
of the mathematical expression being encoded.
>
> The purpose of defining Unicode default layout behavior is not to enforce
a single and specific aesthetic layout for each script, but rather to
encourage uniformity in encoding. In that way implementers of layout
systems can rely on the fact that users would have chosen a particular
character sequence for a given purpose, and users can rely on the fact that
implementers will create a layout for a particular character sequence that
matches the intent of the user to within the capabilities or technical
limitations of the implementation.

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

Vkládání nezlomitelných mezer není něco kritického, co musíme hned teď jít
hromadně opravovat (skoro bych řekl naopak, protože to by teď opravdu
vypadalo, že se to jen ladí pro ten jeden konkrétní renderer, kterým tohle
vlákno začlo; ani si nejsem jist, jestli jsem je ve svých vlastních
editacích vkládal), ale je to prostě o trochu _správnější_.

-- Petr Kadlec / Mormegil
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Ladislav Laska]

Ahoj,

nemám zrovna chuť polemizovat nad tím, co je správné a rozumné (není na
to totiž Jediná Správná Odpověď (TM) ).

Nicméně k editorům: Merkaartor si s tím poradí: Pokud vložíš
nezalamující mezeru (jako unicode znak), tak ji hezky uploaduje na
server, z tama si ji potom vyzvedne a ani při další úpravě ji nesmaže
(samozřejmě pokud ji nesmazal uživatel). 

Stejné chování bych čekal od JOSM, protože Java je taky unicodová, a od
maps.me, které je také napsané v Qt (jako Merkaartor), ani jedno jsem
ale netestoval.

On Tue, Jan 17, 2017 at 08:45:48AM +0100, Lukáš Karas wrote:
> Ahoj, o víkendu autor OSM Scout knihovny přidal užitečnou funkcionalitu
>  - zalamování dlouhých popisků do více řádků. Dle očekávání se ale názvy 
> zalamují v místech kde vykreslovací engine uzná za vhodné, nikoliv tam kde 
> je to správně (předložky zůstávají na konci řádku), například:
> 
> Libčice nad
>   Vltavou
> 
>  Týnec nad
>   Sázavou
> 
> Tam lze "nad" na konci řádku ještě tolerovat i když mě osobně se nelibí, 
> ale u "u": 
> 
> Nová ves u 
>  Chýnova
> 
> Je to typograficky špatně. Stejným neduhem trpí i Mapnik.
> 
> Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa 
> nedělitelné 
> mezery (v xml "", unicode znak U+00A0) a existuje na to nějaký postup 
> jak to provést hromadně? Poradí si s tím běžné editory? Neztratí se ta mezera 
> při první editaci? 
> 
> Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba opravit 
> renderer, ale bez ní nemá prostě šanci cokoliv hádat...
> 
> Lukáš



> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz


-- 
S pozdravem Ladislav "Krakonoš" Láskahttp://www.krakonos.org/

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Mikoláš Štrajt]

"



" > Zalamování řádek, dělení slov, skloňování a časování ať je záležitostí
> zpracování dat, ne jejich uložení.

skutečně toto vše? - takže bychom vlastně neměli mít "Libčice nad Vltavou" 
ale
"Libčice nad Vltava"? :-)

"



Heh, napsal jsem to moc obecně :-) Jasně, že v našem případě "Libčice nad 
Vltavou", ale tahle diskuse ("zaveďme do slov nedělitelné mezery, protože to
ulehčí zpracování") by taky mohla vést k tomu, že zavedeme tagy name:genitiv
="Libčic nad Vltavou", name:dativ="Libčicím nad Vltavou", atd. protože 
"routovací enginy nabízejí uživateli i textový popis cesty a tohle jim 
ulehčí práci". A to už bychom v OSM opravdu mít neměli ;-)


"



Fun fact: 




RUIAN už skloňování názvů obcí ve své databázi má. V exportu je to v položce
obi:MluvnickeCharakteristiky.




Např:




Žiželic
ŽiželicímŽiželiceŽiželicíchŽiželicemi





Dokonce jsem to už viděl používané - někdo generoval nápisy na trička "Jsem 
z XY".




* * *




Jinak ale souhlasím s myšlenkou, že nedělitelná mezera není obsah ale forma,
tudíž nemá v DB co dělat.




-- 

Mikoláš Štrajt / Severák / http://severak.svita.cz/
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Lukáš Karas]

Souhlasím, ale mám pocit že oba máme na mysli něco jiného.

Dne středa 18. ledna 2017 22:35:16 CET Jan Macura napsal(a):
> Ahoj,
> 
> 2017-01-18 10:03 GMT+01:00 Karel Volný :
> > obecně souhlas, akorát se neshodneme v tom, co je obsah a co je forma
> 
> Zalomení řádku je záležitost formy. Při každém zpracování textu může
> dopadnout jinak (jinde). Obsah je na formátování řádek nezávislý. Takže
> medle celá problematika "kde řádek zalomit" padá na hlavu zpracovatele dat.
> 

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. 

A proboha, v OSM vytváříme věci ve strojově čitelné podobě, zakládáme mezi 
objekty relace aby je bylo možné strojově zpracovat. A najednou, pokud chci 
aby i texty byly ve strojově zpracovatelné formě, tak je to špatně?

Lukáš

> > kontrolní dotaz - používání malých a velkých písmen je obsah nebo forma?
> 
> To záleží na kontextu. Obecně samozřejmě formy, ale v našem případě, tj.
> sbírání a uchovávání místopisných názvů je extrémně výhodné, aby velikost
> písmen byla přímo brána jako součást obsahu (neměnná). Neexistuje totiž
> případ, kdy bychom ta slova uvažovali samostatně (slovo "libčice", slovo
> "nad" a slovo "vltava") – OSM není ani výkladový slovník ani lexikografická
> databáze.
> 
> > > Zalamování řádek, dělení slov, skloňování a časování ať je záležitostí
> > > zpracování dat, ne jejich uložení.
> > 
> > skutečně toto vše? - takže bychom vlastně neměli mít "Libčice nad Vltavou"
> > ale
> > "Libčice nad Vltava"? :-)
> 
> Heh, napsal jsem to moc obecně :-) Jasně, že v našem případě "Libčice nad
> Vltavou", ale tahle diskuse ("zaveďme do slov nedělitelné mezery, protože
> to ulehčí zpracování") by taky mohla vést k tomu, že zavedeme tagy
> name:genitiv="Libčic
> nad Vltavou", name:dativ="Libčicím nad Vltavou", atd. protože "routovací
> enginy nabízejí uživateli i textový popis cesty a tohle jim ulehčí práci".
> A to už bychom v OSM opravdu mít neměli ;-)
> 
> H.

signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Macura]

Ahoj,

2017-01-18 10:03 GMT+01:00 Karel Volný :

> obecně souhlas, akorát se neshodneme v tom, co je obsah a co je forma
>

Zalomení řádku je záležitost formy. Při každém zpracování textu může
dopadnout jinak (jinde). Obsah je na formátování řádek nezávislý. Takže
medle celá problematika "kde řádek zalomit" padá na hlavu zpracovatele dat.


> kontrolní dotaz - používání malých a velkých písmen je obsah nebo forma?
>

To záleží na kontextu. Obecně samozřejmě formy, ale v našem případě, tj.
sbírání a uchovávání místopisných názvů je extrémně výhodné, aby velikost
písmen byla přímo brána jako součást obsahu (neměnná). Neexistuje totiž
případ, kdy bychom ta slova uvažovali samostatně (slovo "libčice", slovo
"nad" a slovo "vltava") – OSM není ani výkladový slovník ani lexikografická
databáze.


>
> > Zalamování řádek, dělení slov, skloňování a časování ať je záležitostí
> > zpracování dat, ne jejich uložení.
>
> skutečně toto vše? - takže bychom vlastně neměli mít "Libčice nad Vltavou"
> ale
> "Libčice nad Vltava"? :-)
>
>
Heh, napsal jsem to moc obecně :-) Jasně, že v našem případě "Libčice nad
Vltavou", ale tahle diskuse ("zaveďme do slov nedělitelné mezery, protože
to ulehčí zpracování") by taky mohla vést k tomu, že zavedeme tagy
name:genitiv="Libčic
nad Vltavou", name:dativ="Libčicím nad Vltavou", atd. protože "routovací
enginy nabízejí uživateli i textový popis cesty a tohle jim ulehčí práci".
A to už bychom v OSM opravdu mít neměli ;-)

H.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Petr Kadlec]

Ahoj,

souhlas třeba s Kavolem. Do názvu Nová Ves u Chýnova nezlomitelná mezera
patří, proto tam má být i v OSM. Do názvu Týnec nad Sázavou nezlomitelná
mezera nepatří, proto tam nemá být ani v OSM. Nemá to nic společného s
renderery a správným vykreslováním, ale prostě s tím, že se to tak má psát
(stejně jako diakritika, pomlčka pomlčkou, spojovník spojovníkem atd.).
Jestli nějaký renderer, editor, uživatel nezná/neumí Unicode, tak holt
občas nebude dokonale fungovat. A holt taky občas nějaký uživatel něco
zadá/upraví bez té mezery, stejně jako existují uživatelé, kteří (k mému
úžasu) do OSM zadávají názvy bez diakritiky.

-- Petr Kadlec / Mormegil
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Martinec]

Takže "hrůza z bílých znaků, protože Word je přesně jako OSM db"? ;) Na
rozdíl od Wordu je celá OSM infrastruktura na Unicode, tohle je argument
"předtím to tak nebylo, nový špatný." Stejnou logikou bychom vlastně měli
používat jenom ASCII - já sám mám hromadu strašidelných historek o Wordu a
diakritice.

HPM



Dne 18. 1. 2017 12:17 odp. napsal uživatel "Mikoláš Štrajt" <
stra...@seznam.cz>:

> Zdar,
>
> vzhledem k tomu, že jsem taky autor rendereru (https://github.com/severak/
> lunarender), dodal bych rád svůj pohled na věc:
>
> Do dat bych nezalomitelnou mezeru (dále jen NBSP) raději nedával. Dovedu
> si hodně živě představit, že s NBSP něco (renderer, geokóder, editor) co
> zpracovává OSM data nepočítá a výsledkem budou nějaké bizarní chyby, které
> navíc nebude jednoduché odhalit, protože NBSP se zobrazuje jako bílý znak.
>
> Dokonce mě překvapilo, že se vůbec zalamují dlouhé názvy. :-)
>
> Bílé znaky jsou v tomhle celkem svinstvo, pamatuju si jak u nás ve firmě
> přestaly fungovat jakési XML exporty, protože do dat klienti kopírovaly
> (netisknutelné) řídící znaky z Wordu. Vtip byl v tom, že některé bílé znaky
> nejsou validní v XML.
>
> -- Mikoláš Štrajt / Severák / http://severak.svita.cz/
>
> PS: můj renderer "vykresluje" celé názvy na jednom řádku
>
> -- Původní zpráva --
> Od: LukášKaras <lukas.ka...@centrum.cz>
> Komu: talk-cz@openstreetmap.org
> Datum: 17. 1. 2017 8:47:10
> Předmět: [Talk-cz] Nedělitelná mezera v OSM datech
>
> Ahoj, o víkendu autor OSM Scout knihovny přidal užitečnou funkcionalitu
> - zalamování dlouhých popisků do více řádků. Dle očekávání se ale názvy
> zalamují v místech kde vykreslovací engine uzná za vhodné, nikoliv tam kde
> je to správně (předložky zůstávají na konci řádku), například:
>
> Libčice nad
> Vltavou
>
> Týnec nad
> Sázavou
>
> Tam lze "nad" na konci řádku ještě tolerovat i když mě osobně se nelibí,
> ale u "u":
>
> Nová ves u
> Chýnova
>
> Je to typograficky špatně. Stejným neduhem trpí i Mapnik.
>
> Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa
> nedělitelné
> mezery (v xml "", unicode znak U+00A0) a existuje na to nějaký
> postup
> jak to provést hromadně? Poradí si s tím běžné editory? Neztratí se ta
> mezera
> při první editaci?
>
> Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba
> opravit
> renderer, ale bez ní nemá prostě šanci cokoliv hádat...
>
> Lukáš
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Mikoláš Štrajt]

Zdar,



vzhledem k tomu, že jsem taky autor rendereru (https://github.com/severak/
lunarender), dodal bych rád svůj pohled na věc:




Do dat bych nezalomitelnou mezeru (dále jen NBSP) raději nedával. Dovedu si 
hodně živě představit, že s NBSP něco (renderer, geokóder, editor) co 
zpracovává OSM data nepočítá a výsledkem budou nějaké bizarní chyby, které 
navíc nebude jednoduché odhalit, protože NBSP se zobrazuje jako bílý znak.




Dokonce mě překvapilo, že se vůbec zalamují dlouhé názvy. :-)





Bílé znaky jsou v tomhle celkem svinstvo, pamatuju si jak u nás ve firmě 
přestaly fungovat jakési XML exporty, protože do dat klienti kopírovaly 
(netisknutelné) řídící znaky z Wordu. Vtip byl v tom, že některé bílé znaky 
nejsou validní v XML.




-- Mikoláš Štrajt / Severák / http://severak.svita.cz/





PS: můj renderer "vykresluje" celé názvy na jednom řádku



-- Původní zpráva --
Od: LukášKaras <lukas.ka...@centrum.cz>
Komu: talk-cz@openstreetmap.org
Datum: 17. 1. 2017 8:47:10
Předmět: [Talk-cz] Nedělitelná mezera v OSM datech

"Ahoj, o víkendu autor OSM Scout knihovny přidal užitečnou funkcionalitu
- zalamování dlouhých popisků do více řádků. Dle očekávání se ale názvy 
zalamují v místech kde vykreslovací engine uzná za vhodné, nikoliv tam kde 
je to správně (předložky zůstávají na konci řádku), například:

Libčice nad
Vltavou

Týnec nad
Sázavou

Tam lze "nad" na konci řádku ještě tolerovat i když mě osobně se nelibí, 
ale u "u": 

Nová ves u 
Chýnova

Je to typograficky špatně. Stejným neduhem trpí i Mapnik.

Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa 
nedělitelné 
mezery (v xml "", unicode znak U+00A0) a existuje na to nějaký postup 
jak to provést hromadně? Poradí si s tím běžné editory? Neztratí se ta 
mezera 
při první editaci? 

Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba opravit

renderer, ale bez ní nemá prostě šanci cokoliv hádat...

Lukáš
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Martinec]

Zrovna co se týče vyhledávání, tak není třeba se obávat: pokud má Nominatim
Unicode collation (spoiler: má), tak můžeš zadávat nejen normální mezery,
ale dokonce můžeš zadat "usti nad labem" bez diakritiky, a stejně to
matchne "Ústí nadLabem", páč whitespace jako whitespace. Máme už
století ovocného netopýra, nevyžadujeme uživatelský vstup přesně podle
stavu v db ;)

HPM

Dne 18. 1. 2017 10:33 napsal uživatel "majka" :

> No, já bych měla ještě jeden argument proti, a to opět mobilní aplikace
> užívající OSM data. Pokud dám do názvu pevnou mezeru, tak to v první fázi
> podle mě bude znamenat, že jí to bude očekávat i při vyhledávání. Na mobilu
> si dost dobře nedokážu představit. A ve svojí adrese bych jí měla hned jako
> druhý znak v názvu ulice, stačí že ještě poměrně nedávno ten název na
> cedulích a v dokumentech měl celkem 4 varianty, a to bez často užívané
> zkratky : )  U obce je to podobné, jsme "Horní Dolní u Většího města".
> Teoreticky je správná jen jedna varianta rozdělení, ale radši to přežiju
> zalomené špatně jak u ulice, tak u obce...
>
> Fakt jsem v tomhle staromilec a pamětník, ale unicode "formátovací" znaky
> považuju v tomhle za dost problematické.
>
> Majka
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[majka]

No, já bych měla ještě jeden argument proti, a to opět mobilní aplikace
užívající OSM data. Pokud dám do názvu pevnou mezeru, tak to v první fázi
podle mě bude znamenat, že jí to bude očekávat i při vyhledávání. Na mobilu
si dost dobře nedokážu představit. A ve svojí adrese bych jí měla hned jako
druhý znak v názvu ulice, stačí že ještě poměrně nedávno ten název na
cedulích a v dokumentech měl celkem 4 varianty, a to bez často užívané
zkratky : )  U obce je to podobné, jsme "Horní Dolní u Většího města".
Teoreticky je správná jen jedna varianta rozdělení, ale radši to přežiju
zalomené špatně jak u ulice, tak u obce...

Fakt jsem v tomhle staromilec a pamětník, ale unicode "formátovací" znaky
považuju v tomhle za dost problematické.

Majka
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Karel Volný]

čus,

> Forma by měla být oddělena od obsahu.

obecně souhlas, akorát se neshodneme v tom, co je obsah a co je forma

já nedělitelnou mezeru považuju za obsah, úplně stejně jako mezeru normální 
nebo téměř jakýkoliv jiný znak - přeci nejde o to, jak vypadá, ale jaký má v 
textu význam ... v některých případech (nejlépe fonty pro captcha :-)) 
nepoznám vizuálně malé "L" od velkého "i", popř. svislítka, například, ale 
zaměnit je nemohu, tak stejně tak nepoznám ty mezery, ale každá má jiný význam

problém je v tom, že člověk to takto nevnímá, protože narozdíl od hloupého 
počítače nezpracovává text po jednotlivých znacích, a pouze na konci řádku 
přemýšlí "smím zalomit?" namísto aby to řešil mezi každou dvojicí znaků po 
celý řádek, takže mu přijde nepřirozené si tam tu počítačovou reprezentaci 
odpovědi na "smím zalomit" připustit

kontrolní dotaz - používání malých a velkých písmen je obsah nebo forma?

> Zalamování řádek, dělení slov, skloňování a časování ať je záležitostí
> zpracování dat, ne jejich uložení.

skutečně toto vše? - takže bychom vlastně neměli mít "Libčice nad Vltavou" ale 
"Libčice nad Vltava"? :-)

jinak přijde mi smutné, že na konci druhé dekády 21. století tady padají 
argumenty jakože to nemáme dělat, protože to nemá podporu v editorech apod.

za sebe bych to viděl tak, že kdo to chce používat, ať si to používá, s tím, 
že je možné, že mu to někdo přeplácne, protože to neřeší(*), a pokud je to v 
nějakém editoru/jiném programu problém, jakože na tom padá nebo se k tomu 
nechová jako ke whitespace apod., tak ať se sakra ten software opraví

(*) já třeba nevím, jak na obyčejné Xové cz_qwerty nedělitelnou mezeru napsat, 
z nástroje na výběr znaků to extra vkládat nebudu ... jasně, v TeXu vlnka, v 
Libreoffice ctrl+mezera, ale jak to mám dostat jednoduše třeba do Merkaartoru?

nějaké hromadné zavádění nedělitelných mezer je IMHO zlo, pokud někdo dokáže 
vymyslet natolik dobrý algoritmus, aby byl použitelný pro hromadnou změnu(**), 
tak by měl být použitelný renderery, čímž by se celá diskuse stala 
bezpředmětnou

(**) pokud vím, zatím se to TeXpertům nepovedlo ani za ~30 let ...

tož asi tak ...

K.


signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Lukáš Karas]

Ahoj. 

Děkuji všem za názory. Osobně si myslím že konkrétně pevné mezery do OSM 
patří. Stejně tak by měly být součástí běžných textů, jako třeba maily. 
To že to automatické korekce často neopravují a lidé běžně explicitně nepíší 
je jiná věc, ale je to pro mě hlavní argument proti. Lidé je zkrátka nejsou 
zvyklí používat a jejich podpora v editorech je nulová. 

Dne úterý 17. ledna 2017 19:43:40 CET jzvc napsal(a):
> Cus,
> 
> ja bych to neresil. Je to vec renederu. To jaky jazyk je primarni muze
> snadno zjistit - bud tak, ze se podiva s jakym lang tagem se shoduje,
> nebo tak, ze se podiva uvnitr jakych hranic lezi.
> 

Tím _snadno_ jsi mě poslal do kolen. Většina tagů nemá lang tag. 
Snadno to pozná člověk který dokáže na mapě najít státní hranice a otevřít si 
wikipedii aby dohledal jaký jazyk je v dané zemi (oblasti) primární. 
Teď si představ jak bys něco takového programoval... 

> 
> Jak bylo zmineno, to pak zacnem resit jestli se spravne deli slova, co
> je spojka a co predlozka ...


Dělení slov je trochu jiný problém a vůbec bych to k tomu nemíchal... 
Unicode znak na to sice existuje ale jeho použití je trochu nepraktické.
A už jste někdy viděli renderer který by se snažil dělit dlouhá slova?

Lukáš


> 
> Ono tohle porcovani podle mezer nefunguje spravne prakticky v zadnem
> existujicim jazyce.
> 
> Apropos, kdyz uz to zminujes … typograficky spravne by si nemel pouzivat
> "anglicky" ale „cesky“ uvozovky (a ja bych mel psat nabodenicka), stejne
> tak by se nemelo pouzivat spojovnik - ale pomlcka –(—) jedno pripadne
> dvouctvercikova, pripadne minus − (i kdyz to tak nevypada sou to 4 ruzny
> znaky)  ... ;D
> 
> 
> 
> Takovej vyber (vazne nevim jak to dopadne v tom mailu), je to popiska,
> znak (pokud je zobrazovanej), alt sekvence, hexa kod a html entita.
> 
> Uvozovky
> rovné uvozovky (na klávesnici)"   0034x0022   
> spodní uvozovky   „   0132x201E   
> horní uvozovky“   0147x201C   
> spodní jednoduchá uvozovka‚   0130x201A
> horní jednoduchá uvozovka ‘   0145x2018
> apostrof  ’   0146x2019
> francouzká otevírací uvozovka »   0187x00BB   
> francouzká uzavírací uvozovka «   0171x00AB   
> 
> Matematika
> X krát×   0215x00D7   
> děleno÷   0247x00F7   
> plus (na klávesnici)  +   0043x002B   
> mínus −   8722x2212   
> plus mínus±   0177x00B1   
> stupně°   0176x00B0   
> zeměpisné minuty  ′   2032x2032   
> promile   ‰   8240x2030   
> spojovník (na klávesnici) -   0045x002D
> rozdělovník = spojovník   x­x 0173
> pomlčka   –   0150
> dlouhá pomlčka—   0151
> výpustka  …   0133
> nedělitelná mezerax x 0160
> narození  *
> úmrtí †   0134
> euro  €   8364
> copyright ©   0169
> registrovaná značka   ®   0174
> m2㎡   13217
> 
> Dne 17.1.2017 v 8:45 Lukáš Karas napsal(a):
> > Ahoj, o víkendu autor OSM Scout knihovny přidal užitečnou funkcionalitu
> > 
> >   - zalamování dlouhých popisků do více řádků. Dle očekávání se ale názvy
> > 
> > zalamují v místech kde vykreslovací engine uzná za vhodné, nikoliv tam kde
> > je to správně (předložky zůstávají na konci řádku), například:
> > 
> > Libčice nad
> > 
> >Vltavou
> >   
> >   Týnec nad
> >   
> >Sázavou
> > 
> > Tam lze "nad" na konci řádku ještě tolerovat i když mě osobně se nelibí,
> > ale u "u":
> > 
> > Nová ves u
> > 
> >   Chýnova
> > 
> > Je to typograficky špatně. Stejným neduhem trpí i Mapnik.
> > 
> > Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa
> > nedělitelné mezery (v xml "", unicode znak U+00A0) a existuje na to
> > nějaký postup jak to provést hromadně? Poradí si s tím běžné editory?
> > Neztratí se ta mezera při první editaci?
> > 
> > Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba
> > opravit renderer, ale bez ní nemá prostě šanci cokoliv hádat...
> > 
> > Lukáš
> > 
> > 
> > 
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[jzvc]

Cus,

ja bych to neresil. Je to vec renederu. To jaky jazyk je primarni muze 
snadno zjistit - bud tak, ze se podiva s jakym lang tagem se shoduje, 
nebo tak, ze se podiva uvnitr jakych hranic lezi.



Jak bylo zmineno, to pak zacnem resit jestli se spravne deli slova, co 
je spojka a co predlozka ...


Ono tohle porcovani podle mezer nefunguje spravne prakticky v zadnem 
existujicim jazyce.


Apropos, kdyz uz to zminujes … typograficky spravne by si nemel pouzivat 
"anglicky" ale „cesky“ uvozovky (a ja bych mel psat nabodenicka), stejne 
tak by se nemelo pouzivat spojovnik - ale pomlcka –(—) jedno pripadne 
dvouctvercikova, pripadne minus − (i kdyz to tak nevypada sou to 4 ruzny 
znaky)  ... ;D




Takovej vyber (vazne nevim jak to dopadne v tom mailu), je to popiska, 
znak (pokud je zobrazovanej), alt sekvence, hexa kod a html entita.


Uvozovky
rovné uvozovky (na klávesnici)  "  0034x0022   
spodní uvozovky „   0132x201E   
horní uvozovky  “   0147x201C   
spodní jednoduchá uvozovka  ‚   0130x201A   
horní jednoduchá uvozovka   ‘   0145x2018   
apostrof’   0146x2019
francouzká otevírací uvozovka   »   0187x00BB   
francouzká uzavírací uvozovka   «   0171x00AB   

Matematika
X krát  ×   0215x00D7   
děleno  ÷   0247x00F7   
plus (na klávesnici)+   0043x002B   
mínus   −   8722x2212   
plus mínus  ±   0177x00B1   
stupně  °   0176x00B0   
zeměpisné minuty′   2032x2032   
promile ‰   8240x2030   
spojovník (na klávesnici)   -   0045x002D   
rozdělovník = spojovník x­x 0173
pomlčka –   0150
dlouhá pomlčka  —   0151
výpustka…   0133
nedělitelná mezera  x x 0160
narození*   
úmrtí   †   0134
euro€   8364
copyright   ©   0169
registrovaná značka ®   0174
m2  ㎡   13217   


Dne 17.1.2017 v 8:45 Lukáš Karas napsal(a):

Ahoj, o víkendu autor OSM Scout knihovny přidal užitečnou funkcionalitu
  - zalamování dlouhých popisků do více řádků. Dle očekávání se ale názvy
zalamují v místech kde vykreslovací engine uzná za vhodné, nikoliv tam kde
je to správně (předložky zůstávají na konci řádku), například:

Libčice nad
   Vltavou

  Týnec nad
   Sázavou

Tam lze "nad" na konci řádku ještě tolerovat i když mě osobně se nelibí,
ale u "u":

Nová ves u
  Chýnova

Je to typograficky špatně. Stejným neduhem trpí i Mapnik.

Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa nedělitelné
mezery (v xml "", unicode znak U+00A0) a existuje na to nějaký postup
jak to provést hromadně? Poradí si s tím běžné editory? Neztratí se ta mezera
při první editaci?

Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba opravit
renderer, ale bez ní nemá prostě šanci cokoliv hádat...

Lukáš



___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz




___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[majka]

Osobně se z ryze praktických důvodů přikláním k tomu, to zatím ignorovat.

I pokud bychom to opravili, nevěřím tomu, že nám to mobilní editory a
jejich uživatelé zase zpátky při případné editaci nezmění zpátky. Pokud
budeme mít štěstí, zůstanou názvy měst a obcí, ale u ostatních jmen si
nedělám iluze ohledně toho, že by tam nedělitelná mezera zůstala dlouho.
Připadá mi, že je to dost práce s velice nejistým výsledkem.

V skrytu duše doufám, že render bude časem inteligentnější. Tipla bych si,
že slovo o jednom až třech písmenech se zalomením za sebou je chyba v dost
jazycích (nebo je to jedno jestli zalomit před či za). Ale vzhledem k tomu,
že se ignoruje podle mě větší chyba, a to zalamování jmen měst s pomlčkami,
protože to berou jako rozdělovací znaménko, moc naděje si v nejbližší době
nedělám.

Majka
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Macura]

Ahoj, jsem proti.

Forma by měla být oddělena od obsahu.
Zalamování řádek, dělení slov, skloňování a časování ať je záležitostí
zpracování dat, ne jejich uložení.

2017-01-17 11:34 GMT+01:00 Lukáš Karas :

> Ta pravidla, která mezera může být dělitelná a která nemůže, se mohou
> lišit podle jazyka. Renderer (...) by v takovém případě musel hádat v jakém
> jazyce je dané jméno
>

Není od toho v OSM jazykový prefix?

H.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Martinec]

Ahoj,

On 01/17/17 11:13, Miroslav Suchy wrote:

Dne 17.1.2017 v 08:45 Lukáš Karas napsal(a):

Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa nedělitelné
mezery (v xml "", unicode znak U+00A0)


Osobně bych byl proti. To bychom tam pak mohli pridavat i hinty, kde rozdelovat 
slova
  Nove Mesto na Mo-
  rave
to už je overkill - nepíšeme v devanagari, abychom potřebovali znaky pro 
ZWNBJ a ZWJ. Oproti tomu nedělitelná mezera v češtině dává smysl.



Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba opravit
renderer, ale bez ní nemá prostě šanci cokoliv hádat...


Ony existuji jeste i "narrow NBSP", pouzivaji se napr. ve francouzstine.

To taky, ale pro češtinu se to nepoužívá; takových je povícero:
https://en.wikipedia.org/wiki/Whitespace_character#Unicode
Každopádně by se to *teoreticky* mělo chovat všechno jako whitespace, leč:
1. podpora ze strany nástrojů (taky *teoreticky* funkční, ale vsadil 
bych se, že netestovaná - tohle je moje oblíbená třída bugů)
a 2. podpora v tagování - chceme masivně přejmenovávat jak v 
jednadevadesátým? ;) (Osobně bych řekl, že ne)



Ja bych to osobne nechal na renderu.
Renderer má k dispozici jenom heuristiku, což vede k problematickýmu 
věštění z koule typu "končí -a, takže ženský rod, is_in: CZ a má tam 
*nad*, takže za to narvem NBSP" - navíc si to věštění z koule musí každý 
renderer znovu implementovat (po svým?).


Takže bych se těm hintům nebránil, a klidně bych to u těch různých 
Dlouhojmenovic nad Labem a Vedle Kopce u Dálnice zaváděl - ale postupně, 
netřeba to narvat do db po importním způsobu.


Honza "Piškvor" Martinec

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Lukáš Karas]

Ta pravidla, která mezera může být dělitelná a která nemůže, se mohou lišit 
podle jazyka. Renderer (v případě osmscout bych to spíš dal na starosti 
importu) by v takovém případě musel hádat v jakém jazyce je dané jméno a musel 
by si udržovat pravidla pro různé jazyky...

Samozřejmě by to šlo zjednodušit a dát nedělitelnou mezeru za všechna 
jednopísmenná slova...

Lukáš

Dne úterý 17. ledna 2017 11:13:05 CET Miroslav Suchy napsal(a):
> Dne 17.1.2017 v 08:45 Lukáš Karas napsal(a):
> > Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa
> > nedělitelné mezery (v xml "", unicode znak U+00A0)
> 
> Osobně bych byl proti. To bychom tam pak mohli pridavat i hinty, kde
> rozdelovat slova Nove Mesto na Mo-
>   rave
> 
> > Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba
> > opravit renderer, ale bez ní nemá prostě šanci cokoliv hádat...
> 
> Ony existuji jeste i "narrow NBSP", pouzivaji se napr. ve francouzstine.
> 
> Samozrejme ze ma sanci. Napriklad pro TeX existuji makra, ktere to doplnuji.
> http://tex.stackexchange.com/questions/46955/is-there-way-to-put-hard-space
> -after-defined-words
> 
> Ja bych to osobne nechal na renderu.
> 
> Mirek
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Miroslav Suchy]

Dne 17.1.2017 v 08:45 Lukáš Karas napsal(a):
> Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa 
> nedělitelné 
> mezery (v xml "", unicode znak U+00A0)

Osobně bych byl proti. To bychom tam pak mohli pridavat i hinty, kde rozdelovat 
slova
  Nove Mesto na Mo-
  rave

> Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba opravit 
> renderer, ale bez ní nemá prostě šanci cokoliv hádat...

Ony existuji jeste i "narrow NBSP", pouzivaji se napr. ve francouzstine.

Samozrejme ze ma sanci. Napriklad pro TeX existuji makra, ktere to doplnuji.
http://tex.stackexchange.com/questions/46955/is-there-way-to-put-hard-space-after-defined-words

Ja bych to osobne nechal na renderu.

Mirek

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Nedělitelná mezera v OSM datech

[Lukáš Karas]

Ahoj, o víkendu autor OSM Scout knihovny přidal užitečnou funkcionalitu
 - zalamování dlouhých popisků do více řádků. Dle očekávání se ale názvy 
zalamují v místech kde vykreslovací engine uzná za vhodné, nikoliv tam kde 
je to správně (předložky zůstávají na konci řádku), například:

Libčice nad
  Vltavou

 Týnec nad
  Sázavou

Tam lze "nad" na konci řádku ještě tolerovat i když mě osobně se nelibí, 
ale u "u": 

Nová ves u 
 Chýnova

Je to typograficky špatně. Stejným neduhem trpí i Mapnik.

Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa nedělitelné 
mezery (v xml "", unicode znak U+00A0) a existuje na to nějaký postup 
jak to provést hromadně? Poradí si s tím běžné editory? Neztratí se ta mezera 
při první editaci? 

Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba opravit 
renderer, ale bez ní nemá prostě šanci cokoliv hádat...

Lukáš


signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz