Nedělitelná mezera v OSM datech

37 zpráv
Zpět na přehled

Nedělitelná mezera v OSM datech

37 zpráv LJJMMPMJ 14 účastníků 30 min čtení
  1. Lukáš Karas lukas.karas na centrum.cz #m5ee2e4
    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áš
  2. Miroslav Suchy miroslav na suchy.cz #m69c0e6
    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
  3. Lukáš Karas lukas.karas na centrum.cz #m2223e9
    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áš
  4. Jan Martinec jan na martinec.name #me7b194
    Ahoj,
    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
  5. Jan Macura macurajan na gmail.com #m679b5d
    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>:
    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.
  6. majka majka.zem+talk na gmail.com #m1df2f5
    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
  7. jzvc jzvc na tpfree.net #m93f419
    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 &quot; spodní uvozovky ? 0132 x201E &bdquo; horní uvozovky ? 0147 x201C &ldquo; spodní jednoduchá uvozovka ? 0130 x201A horní jednoduchá uvozovka ? 0145 x2018 apostrof ? 0146 x2019 &rsquo; &#8217; francouzká otevírací uvozovka ? 0187 x00BB &raquo; francouzká uzavírací uvozovka ? 0171 x00AB &laquo; Matematika X krát × 0215 x00D7 &times; děleno ÷ 0247 x00F7 &divide; plus (na klávesnici) + 0043 x002B &plus; mínus ? 8722 x2212 &minus; plus mínus ? 0177 x00B1 &plusmn; stupně ° 0176 x00B0 &deg; zeměpisné minuty ? 2032 x2032 &prime; promile ? 8240 x2030 &permil; spojovník (na klávesnici) - 0045 x002D rozdělovník = spojovník x­x 0173 &shy; pomlčka ? 0150 &ndash; dlouhá pomlčka ? 0151 &mdash; výpustka ? 0133 &hellip; nedělitelná mezera x x 0160 &nbsp; narození * úmrtí ? 0134 &dagger; euro ? 8364 &euro; copyright ? 0169 &copy; registrovaná značka ? 0174 &reg; m2 ? 13217
  8. Lukáš Karas lukas.karas na centrum.cz #m97ee04
    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á.
    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áš
  9. Karel Volný kavol na seznam.cz #m4b7285
    č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.
  10. majka majka.zem+talk na gmail.com #med4cb9
    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
  11. Jan Martinec jan na martinec.name #mc1c1a8
    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&nbsp;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>:
  12. Mikoláš Štrajt strajt9 na seznam.cz #m47935a
    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
  13. Jan Martinec jan na martinec.name #mb7cd08
    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
  14. Petr Kadlec petr.kadlec na gmail.com #mc1fd10
    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
  15. Jan Macura macurajan na gmail.com #m0123ba
    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.
    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.
  16. Lukáš Karas lukas.karas na centrum.cz #m45f8a5
    Souhlasím, ale mám pocit že oba máme na mysli něco jiného.
    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áš
  17. Mikoláš Štrajt strajt9 na seznam.cz #m366a15
    " > 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ř: <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.
  18. Ladislav Laska laska na kam.mff.cuni.cz #mcbeb6c
    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.
  19. Petr Kadlec petr.kadlec na gmail.com #m0b4040
    Ahoj˝, 2017-01-18 22:35 GMT+01:00 Jan Macura <macurajan na gmail.com>:
    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:
    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
  20. Matěj Cepl mcepl na cepl.eu #mfc51d9
    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
  21. Marián Kyral mkyral na email.cz #m1a5c9a
    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
  22. Jan Macura macurajan na gmail.com #m4e1fa7
    Ahoj, 2017-01-19 9:01 GMT+01:00 Lukáš Karas <lukas.karas na centrum.cz>:
    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í.
  23. Jan Macura macurajan na gmail.com #meefbb5
    //pardon, odeslal jsem mail předčasně 2017-01-19 9:01 GMT+01:00 Lukáš Karas <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. 2017-01-19 9:11 GMT+01:00 Mikoláš Štrajt <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>:
    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.
  24. Pavel Machek pavel na ucw.cz #mbb800b
    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
  25. Martin Ždila martin.zdila na freemap.sk #me6157b
    Podľa mňa dávať do názvov tvrdé medzery zmysel má. Veď na tento účel vlastne tú tvrdú medzeru vymysleli.
  26. Mikoláš Štrajt strajt9 na seznam.cz #me5ba5b
    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 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/
  27. Marián Kyral mkyral na email.cz #mc5eb6b
    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
  28. Pavel Machek pavel na ucw.cz #mc47d5b
    Ahoj!
    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 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.
    Nicméně navrhuju to na pár obcích vyzkoušet. Už o tom diskutujeme dost dlouho. :-)
    Klidne... Pavel
  29. Mikoláš Štrajt strajt9 na seznam.cz #m0d1424
    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
  30. Lukáš Karas lukas.karas na centrum.cz #m740a05
    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áš
  31. Jan Martinec jan na martinec.name #ma97b9f
    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
  32. Karel Volný kavol na seznam.cz #ma75275
    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.
  33. jzvc jzvc na tpfree.net #mecde0a
    //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.
  34. Lukáš Karas lukas.karas na centrum.cz #m9546ab
    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
  35. Jan Martinec jan na martinec.name #m897665
    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
  36. Pavel Machek pavel na ucw.cz #m9c223d
    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.
    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
  37. Marián Kyral mkyral na email.cz #mbcb83c
    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
    No moc to nefunguje. Čekal bych, že se to zalomí před "u" :-D Marián
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.