[Talk-cz] Nedělitelná mezera v OSM datech
Vlákno 17.1. - 20.1.2017, počet zpráv: 37
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áš
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170117/f1c40790/attachment.sig>
Dne 17.1.2017 v 08:45 Lukáš Karas napsal(a):
zobrazit citaci
> 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
zobrazit citaci
> 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
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):
zobrazit citaci
> 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 na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170117/295e5b26/attachment.sig>
Ahoj,
On 01/17/17 11:13, Miroslav Suchy wrote:
zobrazit citaci
> 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.
zobrazit citaci
>
>> 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)
zobrazit citaci
> 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
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 <lukas.karas na centrum.cz>:
zobrazit citaci
> 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.
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170117/e172ab59/attachment.html>
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
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170117/7997f0ef/attachment.html>
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) " 0034 x0022 "
spodní uvozovky „ 0132 x201E „
horní uvozovky “ 0147 x201C “
spodní jednoduchá uvozovka ‚ 0130 x201A
horní jednoduchá uvozovka ‘ 0145 x2018
apostrof ’ 0146 x2019 ’ ’
francouzká otevírací uvozovka » 0187 x00BB »
francouzká uzavírací uvozovka « 0171 x00AB «
Matematika
X krát × 0215 x00D7 ×
děleno ÷ 0247 x00F7 ÷
plus (na klávesnici) + 0043 x002B +
mínus − 8722 x2212 −
plus mínus ± 0177 x00B1 ±
stupně ° 0176 x00B0 °
zeměpisné minuty ′ 2032 x2032 ′
promile ‰ 8240 x2030 ‰
spojovník (na klávesnici) - 0045 x002D
rozdělovník = spojovník xx 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):
zobrazit citaci
> 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 na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
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):
zobrazit citaci
> 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...
zobrazit citaci
>
> 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áš
zobrazit citaci
>
> 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) " 0034 x0022 "
> spodní uvozovky „ 0132 x201E „
> horní uvozovky “ 0147 x201C “
> spodní jednoduchá uvozovka ‚ 0130 x201A
> horní jednoduchá uvozovka ‘ 0145 x2018
> apostrof ’ 0146 x2019 ’ ’
> francouzká otevírací uvozovka » 0187 x00BB »
> francouzká uzavírací uvozovka « 0171 x00AB «
>
> Matematika
> X krát × 0215 x00D7 ×
> děleno ÷ 0247 x00F7 ÷
> plus (na klávesnici) + 0043 x002B +
> mínus − 8722 x2212 −
> plus mínus ± 0177 x00B1 ±
> stupně ° 0176 x00B0 °
> zeměpisné minuty ′ 2032 x2032 ′
> promile ‰ 8240 x2030 ‰
> spojovník (na klávesnici) - 0045 x002D
> rozdělovník = spojovník xx 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 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
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170118/a18c4ca3/attachment.sig>
čus,
zobrazit citaci
> 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?
zobrazit citaci
> 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.
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170118/a9bed45a/attachment.sig>
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
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170118/b514f654/attachment.html>
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í nad Labem", 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" <majka.zem+talk na gmail.com>:
zobrazit citaci
> 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 na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170118/689e6271/attachment.html>
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.karas na centrum.cz>
Komu: talk-cz na 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 na openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170118/84ffcf76/attachment.html>
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" <
strajt9 na seznam.cz>:
zobrazit citaci
> 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.karas na centrum.cz>
> Komu: talk-cz na 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 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
>
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170118/0134687b/attachment.html>
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
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170118/45c03cd9/attachment.html>
Ahoj,
2017-01-18 10:03 GMT+01:00 Karel Volný <kavol na seznam.cz>:
zobrazit citaci
> 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.
zobrazit citaci
> 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.
zobrazit citaci
>
> > 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.
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170118/95f356e0/attachment.html>
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):
zobrazit citaci
> Ahoj,
>
> 2017-01-18 10:03 GMT+01:00 Karel Volný <kavol na seznam.cz>:
> > 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áš
zobrazit citaci
> > 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.
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170119/43792b52/attachment.sig>
"
" > Zalamování řádek, dělení slov, skloňování a časování ať je záležitostí
zobrazit citaci
> 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ř:
<obi:MluvnickeCharakteristiky><com:Pad2>Žiželic</com:Pad2><com:Pad3>
Žiželicím</com:Pad3><com:Pad4>Žiželice</com:Pad4><com:Pad6>Žiželicích</com:
Pad6><com:Pad7>Žiželicemi</com:Pad7></obi:MluvnickeCharakteristiky>
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/
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170119/27f8b870/attachment.html>
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:
zobrazit citaci
> 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áš
zobrazit citaci
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
--
S pozdravem Ladislav "Krakonoš" Láska http://www.krakonos.org/
Ahoj˝,
2017-01-18 22:35 GMT+01:00 Jan Macura <macurajan na gmail.com>:
zobrazit citaci
> 2017-01-18 10:03 GMT+01:00 Karel Volný <kavol na seznam.cz>:
>
>> 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:
zobrazit citaci
> 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.
zobrazit citaci
>
> 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
zobrazit citaci
> 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
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170119/3c1fc84f/attachment.html>
On 2017-01-19, 08:11 GMT, Mikoláš Štrajt wrote:
zobrazit citaci
> 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: mcepl na 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
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 <laska na kam.mff.cuni.cz>
Komu: OpenStreetMap Czech Republic <talk-cz na 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:
zobrazit citaci
> 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
zobrazit citaci
> 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é
zobrazit citaci
> mezery (v xml " ", unicode znak U+00A0) a existuje na to nějaký
postup
zobrazit citaci
> jak to provést hromadně? Poradí si s tím běžné editory? Neztratí se ta
mezera
zobrazit citaci
> při první editaci?
>
> Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba
opravit
zobrazit citaci
> renderer, ale bez ní nemá prostě šanci cokoliv hádat...
>
> Lukáš
zobrazit citaci
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na 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 na openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170119/3ffc7670/attachment.html>
Ahoj,
2017-01-19 9:01 GMT+01:00 Lukáš Karas <lukas.karas na centrum.cz>:
zobrazit citaci
> 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í.
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170119/a09e673a/attachment.html>
//pardon, odeslal jsem mail předčasně
2017-01-19 9:01 GMT+01:00 Lukáš Karas <lukas.karas na centrum.cz>:
zobrazit citaci
> 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 <strajt9 na seznam.cz>:
zobrazit citaci
> 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>:
zobrazit citaci
> 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.
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170119/872dcf20/attachment.html>
On Thu 2017-01-19 17:57:44, Marián Kyral wrote:
zobrazit citaci
> 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 na . 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
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/7af58c34/attachment.sig>
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 <http://www.openstreetmap.org/user/*Martin*>
OZ Freemap Slovakia
tel:+421-908-363-848
mailto:martin.zdila na freemap.sk
http://www.freemap.sk/
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/9aa5f05b/attachment.html>
---------- Původní zpráva ----------
Od: Pavel Machek <pavel na ucw.cz>
Komu: OpenStreetMap Czech Republic <talk-cz na 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:
zobrazit citaci
> Ahoj,
> za sebe jako za uživatele k tomu můžu říct, že v běžném životě typografii
zobrazit citaci
> 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.
zobrazit citaci
> A pochybuji, že to takoví ti příležitostní mappeři vůbec budou řešit. Tam
zobrazit citaci
> 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
zobrazit citaci
> 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 na . 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/
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/da03791a/attachment.html>---------- Původní zpráva ----------
Od: Pavel Machek <pavel na ucw.cz>
Komu: OpenStreetMap Czech Republic <talk-cz na 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:
zobrazit citaci
> Ahoj,
> za sebe jako za uživatele k tomu můžu říct, že v běžném životě typografii
zobrazit citaci
> 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.
zobrazit citaci
> A pochybuji, že to takoví ti příležitostní mappeři vůbec budou řešit. Tam
zobrazit citaci
> 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
zobrazit citaci
> 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
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/8bc0c14b/attachment.html>
Ahoj!
zobrazit citaci
> Od: Pavel Machek <pavel na ucw.cz>
> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>
zobrazit citaci
> "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.
zobrazit citaci
> 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.
zobrazit citaci
> "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 na . 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.
zobrazit citaci
> 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
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/bea42c07/attachment.sig>
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 <pavel na ucw.cz>
Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>
Datum: 20. 1. 2017 10:21:12
Předmět: Re: [Talk-cz] Nedělitelná mezera v OSM datech
"Ahoj!
zobrazit citaci
> Od: Pavel Machek <pavel na ucw.cz>
> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>
zobrazit citaci
> "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
zobrazit citaci
>
> > 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
zobrazit citaci
> > 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
zobrazit citaci
>
> > budeme rádi, když ten název správně opíší a případně u kapitálek správně
zobrazit citaci
> > 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
zobrazit citaci
>
> > 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.
zobrazit citaci
> 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
zobrazit citaci
> volá Pango nebo nějaká jiná knihovna na seskládání znaků.
Nahore mas dva duvody.
zobrazit citaci
> "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 na . 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.
zobrazit citaci
> 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 na openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/81861709/attachment.html>
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):
zobrazit citaci
> ---------- Původní zpráva ----------
> Od: Pavel Machek <pavel na ucw.cz>
> Komu: OpenStreetMap Czech Republic <talk-cz na 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
> =
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/16d3ba92/attachment.sig>
On 01/20/17 13:18, Lukáš Karas wrote:
zobrazit citaci
> 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".
zobrazit citaci
>
> 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
On Thursday 19 January 2017 17:56:38 Matěj Cepl wrote:
zobrazit citaci
> 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.
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/ac17de22/attachment.sig>
Dne 19.1.2017 v 21:36 Jan Macura napsal(a):
zobrazit citaci
> //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.
zobrazit citaci
>
> 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
>
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):
zobrazit citaci
> 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
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/2a87f9b3/attachment.sig>
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>:
zobrazit citaci
> 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
>
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/bd829fbd/attachment.html>
Ahoj!
zobrazit citaci
> > 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.
Ja to nerekl, ale ja to nechci. Myslim ze spravne reseni je hromadna
editace (aka neco co bude potreba vyresit na imports@, ale staci jeden
program).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170120/c22b1833/attachment.sig>
Dne 20.1.2017 v 12:06 Mikoláš Štrajt napsal(a):
zobrazit citaci
> 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« zpět na výpis měsíce