Nedělitelné mezery v názvech ulic

85 zpráv
Zpět na přehled

Nedělitelné mezery v názvech ulic

85 zpráv MMMMPPJM 21 účastníků 59 min čtení
  1. Matej Lieskovský lieskovsky.matej na gmail.com #mebab21
    Ahoj! Pomalu pracuju na tom již zmiňovaném systému na polo-automatickou údržbu street relací a tak narážím na různé podivnosti v databázi, kterých bych si jinak nevšiml. Třeba mě to upozorňuje na to, když jednotlivé segmenty té samé ulice mají různé názvy, což chytá i takové prkotiny, jako je nedělitelná mezera (nbsp). Vím, že se tady před rokem vedl flame na téma nedělitelných mezer a k žádnému konsenzu to (pokud vím) nevedlo. Přijde mi rozumné, aby všechny segmenty ulice měly identické name tagy. Část důvodu, proč celé tyhle street relace dělám je i snaha o automatickou synchronizaci name:<lg> tagů napříč všemi segmenty. Když napíšu nbsp do tagů relace, tak mi to asi náhodní editoři nerozbijou a jsem ochoten to pak opravovat. Co mám dělat? 1) Odstraňuj nbsp z názvů ulic 2) Tam, kde se vyskytují obě varianty, preferuj tu bez nbsp 3) Tam, kde se vyskytují obě varianty, preferuj tu častější 4) Tam, kde se vyskytují obě varianty, preferuj tu s nbsp 5) Přidávej (ručně) nbsp do názvů ulic 6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně Ať se daří, Matej
  2. Matěj Cepl mcepl na cepl.eu #m8a7171
    1) Odstraňuj nbsp z názvů ulic 2) Tam, kde se vyskytují obě varianty, preferuj tu bez nbsp 3) Tam, kde se vyskytují obě varianty, preferuj tu častější 4) Tam, kde se vyskytují obě varianty, preferuj tu s nbsp 5) Přidávej (ručně) nbsp do názvů ulic 6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně
    Já se potácím někde mezi 4 a 6. Na jednu stranu je koncept jména ulice velice nestálý pojem (je skutečně spořilovská Jihovýchodní IV. 2. díl jiná ulice nežli Jihovýchodní IV 1. díl? Hmm, tohle dělení jsme také zjevně vzdaly a ty díly vynecháváme), ale nic lepšího nemáme, a ono to asi souvisí s nejasným konceptem ulice. Ono není nikde žádná metafyzická odpověď na to, proč Vinohradská končí na té křižovatce se Starostrašnickou a je z ní najednou Černokostelecká. Taky Matěj
  3. majka majka.zem+talk na gmail.com #m3bf27f
    2018-01-17 13:49 GMT+01:00 Matej Lieskovský <lieskovsky.matej na gmail.com>:
    6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně
    Trocha teorie - správně by to snad mělo být podle údajů ČÚZK <http://www.cuzk.cz/Uvod/Produkty-a-sluzby/RUIAN/2-Poskytovani-udaju-RUIAN-ISUI-VDP/Ciselniky-ISUI/Nizsi-uzemni-prvky-a-uzemne-evidencni-jednotky.aspx> A teď praxe: vím o změně adresy (nejde o přestěhování ani přejmenování, jen formálně ulice + správná adresa) v letech 2002, 2008 a 2015. Celý ten rozdíl se točí kolem toho, jestli je správně uvedeno "Pražská", "Pražská třída" nebo "Pražská tř." Momentálně je správně to poslední. Musím to znovu zkontrolovat v datech, ale kdysi jsem tam přidávala alt_name, protože s tím vyhledávače měly problémy. A nejlepší jsou "zavedené" ulice v určitých městech, které vůbec neexistovaly. Jako příklad je ulice U Panelárny <https://mapy.cz/s/2koAm> v Jindřichově Hradci. Nemovitosti na ní se nacházející používající tuhle adresu totiž (snad až na jedinou výjimku) do katastru Jindřichova Hradce vůbec nepatří, a ten název se užíval co já pamatuji minimálně patnáct let, než byl podle těch informací ČÚZK 11.09.2014 oficiálně zaveden. Asi jsem Ti moc nepomohla, co říkáš? Majka
  4. Jan Martinec jan na martinec.name #m7a4c74
    Na neoficiální názvy máme loc_name, ne (křižovatka U Bulhara byl taky kdysi neofiko název podle tamního trafikanta)? Minimálně Nominatim podle toho hledat umí. Co se týče logických důvodů, ty celkem neexistují - jen historické ("Vinohradská končí u vozovny, protože to je poslední výspa civilizace v malešických polích, dál už je jenom silnice." - no a pak se Praha rozrostla) Jinak nejde jen o nbsp, někdo přidává Unicode ekvivalenty na římské číslice v názvech. To je medle ok, ale je to kanonický název, nebo ten má být spíše ?, nebo II? Zdar, Honza Piškvor Martinec Dne 17. 1. 2018 14:50 napsal uživatel "majka" <majka.zem+talk na gmail.com>: 2018-01-17 13:49 GMT+01:00 Matej Lieskovský <lieskovsky.matej na gmail.com>:
    6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně
    Trocha teorie - správně by to snad mělo být podle údajů ČÚZK <http://www.cuzk.cz/Uvod/Produkty-a-sluzby/RUIAN/2-Poskytovani-udaju-RUIAN-ISUI-VDP/Ciselniky-ISUI/Nizsi-uzemni-prvky-a-uzemne-evidencni-jednotky.aspx> A teď praxe: vím o změně adresy (nejde o přestěhování ani přejmenování, jen formálně ulice + správná adresa) v letech 2002, 2008 a 2015. Celý ten rozdíl se točí kolem toho, jestli je správně uvedeno "Pražská", "Pražská třída" nebo "Pražská tř." Momentálně je správně to poslední. Musím to znovu zkontrolovat v datech, ale kdysi jsem tam přidávala alt_name, protože s tím vyhledávače měly problémy. A nejlepší jsou "zavedené" ulice v určitých městech, které vůbec neexistovaly. Jako příklad je ulice U Panelárny <https://mapy.cz/s/2koAm> v Jindřichově Hradci. Nemovitosti na ní se nacházející používající tuhle adresu totiž (snad až na jedinou výjimku) do katastru Jindřichova Hradce vůbec nepatří, a ten název se užíval co já pamatuji minimálně patnáct let, než byl podle těch informací ČÚZK 11.09.2014 oficiálně zaveden. Asi jsem Ti moc nepomohla, co říkáš? Majka
  5. Matěj Cepl mcepl na cepl.eu #m2f7200
    Jinak nejde jen o nbsp, někdo přidává Unicode ekvivalenty na římské číslice v názvech. To je medle ok, ale je to kanonický název, nebo ten má být spíše ?, nebo II?
    To už mi připadne jako kravina. Nezlomitelná mezera má svoje výhody, ale ? mi připadne jako čistý manýrismus. Matěj
  6. Matej Lieskovský lieskovsky.matej na gmail.com #m7e4e49
    To se mi zase povedlo kopnout do něčeho fajného... O metafyziku mi v tomto případě opravdu moc nejde - když končí Vinohradská a začíná Černokostelecká, tak končí Vinohradská a začíná Černokostelecká. To mě vážně netrápí. Taky mi nedělá problém přejmenovat celou ulici, kdykoliv kdy se její název změní. Když si všimnu, že to opravdu mám přepsat, tak to díky systému pojede téměř samo. alt_name a loc_name se zatím taky nehodlám ani dotknout. O Římských číslicích můžeme debatovat, ještě chvíli na ně asi nenarazím. Možná bych se dokonce přikláněl k tomu, že ty unicode věci jsou možná i dobře, ale to je na délší debatu. Teď ale naprosto reálně chci vědět, zda se ta ulice má jmenovat "K Jezeru" nebo "K Jezeru", protože naprosto odmítám možnost, že to jsou dvě různé ulice. Výhledově to asi chce na wiki napsat, jak se máme v takovýchto situacích zachovat. Pokud například zvládneme udržet správné názvy v relacích, tak bych měl být schopen dohlížet na nbsp a podobné minimálně pro celou Prahu. Shodneme se tedy na tom, že varianta 4 je bezpečná? Systém bude jen polo-automatický, takže pokud narazí na něco divného, tak nejspíše zase napíšu sem. @Matěj: Podle ČÚZK žádné díly neexistují a basta! :) Matej 2018-01-17 18:29 GMT+01:00 Matěj Cepl <mcepl na cepl.eu>:
  7. jzvc jzvc na tpfree.net #m93e87e
    2018-01-17 13:49 GMT+01:00 Matej Lieskovský <lieskovsky.matej na gmail.com <mailto:lieskovsky.matej na gmail.com>>: 6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně Trocha teorie - správně by to snad mělo být podle údajů ČÚZK
    To se obavam ze je dost naivni ... vzhledem ke kvalite dat. Jinak ad nedelitelna mezera, podle me je to zbytecnej udaj navic dost casto komplikujici spoustu veci (co si budem rikat, je to mnoha editory nesdelitelna informace a o renederu ani nemluve). Nehlede na to, ze tam tech znaku znamenajicich totez muze byt vicero ... Jednak samozrejme unicode ... pak taky napriklad &#xA0; nebo &#160; to se nam to komplikuje coz? A ad unicode znaky ... to bych svym zpusobem prenechal "prirode", jelikoz a protoze u zdroje to nebude (nejmin po dobu nasich zivotu bude pro libovolny podobny data unicode sprosty slovo) a na druhou stranu nema smysl ani nekomu branit to pouzivat. Ostatne, tech znaku ktery v ceskych podminkach maji vyuzitelnost je pomerne dost, jen se obavam, ze opet skoncime u toho, ze na klavesnici nejsou (na ty ostatne neni ani pomlcka). BTW: To ze ulice vznika z nejakyho obecne pouzivanyho pojmenovani danyho mista je asi celkem beznej zpusob.
  8. Jan Dudík jan.dudik na gmail.com #m9577d1
    Já bych měl jeden související dotaz. V naší obci ulice oficiálně jména nemají. Ovšem třeba do projektu opravy po mně starosta chtěl, abych tam uvedl určité jméno. Jak případně tagovat takováto neoficiální (= nejsou v žádném registru) jména? JAnD --- Ing. Jan Dudík projekce dopravních staveb tel. 777082195
  9. majka majka.zem+talk na gmail.com #me968bd
    Podle mého jednoznačně loc_name. Ve chvíli, kdy se to objeví na cedulích pak přesunout do name 2018-01-18 6:56 GMT+01:00 Jan Dudík <jan.dudik na gmail.com>:
  10. Michal Fabík michal.fabik na gmail.com #mb52f80
    2018-01-18 8:45 GMT+01:00 majka <majka.zem+talk na gmail.com>:
    Podle mého jednoznačně loc_name. Ve chvíli, kdy se to objeví na cedulích pak přesunout do name
    Na cedulích? Jednou mně tady bylo řečeno, že cedule jsou irelevatní a že směrodatná jsou data ČÚZK.
  11. Pavel Machek pavel na ucw.cz #mdc84c2
    Ahoj! Pomalu pracuju na tom již zmiňovaném systému na polo-automatickou údržbu street relací a tak narážím na různé podivnosti v databázi, kterých bych si jinak nevšiml. Třeba mě to upozorňuje na to, když jednotlivé segmenty té samé ulice mají různé názvy, což chytá i takové prkotiny, jako je nedělitelná mezera (nbsp). Vím, že se tady před rokem vedl flame na téma nedělitelných mezer a k žádnému konsenzu to (pokud vím) nevedlo. Přijde mi rozumné, aby všechny segmenty ulice měly identické name tagy. Část důvodu, proč celé tyhle street relace dělám je i snaha o automatickou synchronizaci name:<lg> tagů napříč všemi segmenty. Když napíšu nbsp do tagů relace, tak mi to asi náhodní editoři nerozbijou a jsem ochoten to pak opravovat. Co mám dělat? 1) Odstraňuj nbsp z názvů ulic
    1). ...Tedy ve skutecnosti... 1). Pripadne se zeptat na data working group, co si o tom mysli, a jestli chteji v ramci celeho sveta nbsp v nazvech. A podle toho dal. Do te doby... Pavel
  12. Jan Martinec jan na martinec.name #me265bb
    2018-01-18 8:45 GMT+01:00 majka <majka.zem+talk na gmail.com>:
    Podle mého jednoznačně loc_name. Ve chvíli, kdy se to objeví na cedulích pak přesunout do name
    Na cedulích? Jednou mně tady bylo řečeno, že cedule jsou irelevatní a že směrodatná jsou data ČÚZK.
    No, to se mi nezdá. ČÚZK je sice právně směrodatný zdroj, ale OSM stojí na OTGR, čili ověřitelnosti v terénu. Pokud je tam cedule, budiž to zmapováno i podle cedule (alt_name?). (Tohle je kupodivu anglicky i slovensky, ale česky ne? No vida, zkusím to o dlouhém večeru přeložit: https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground ) Zdar, HPM
  13. Michal Fabík michal.fabik na gmail.com #m6fae05
    2018-01-18 11:02 GMT+01:00 Jan Martinec <jan na martinec.name>:
    No, to se mi nezdá. ČÚZK je sice právně směrodatný zdroj, ale OSM stojí na OTGR, čili ověřitelnosti v terénu. Pokud je tam cedule, budiž to zmapováno i podle cedule (alt_name?). (Tohle je kupodivu anglicky i slovensky, ale česky ne? No vida, zkusím to o dlouhém večeru přeložit: https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground
    Takhle jo, _i_ podle cedule, do alt_name. Prý by ale cedule (resp. podoba názvu na ní) nemá sloužit jako zdroj pro name.
  14. Marián Kyral mkyral na email.cz #m8d8bc7
    "2018-01-18 11:02 GMT+01:00 Jan Martinec <jan na martinec.name>:
    No, to se mi nezdá. ČÚZK je sice právně směrodatný zdroj, ale OSM stojí na OTGR, čili ověřitelnosti v terénu. Pokud je tam cedule, budiž to zmapováno
    i
    podle cedule (alt_name?). (Tohle je kupodivu anglicky i slovensky, ale česky ne? No vida, zkusím to
    o
    dlouhém večeru přeložit: https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_
    ground Takhle jo, _i_ podle cedule, do alt_name. Prý by ale cedule (resp. podoba názvu na ní) nemá sloužit jako zdroj pro name. Jestli to spíše nebylo míněno tak, že do name nepatří "Tř. 1. máje", "Kpt. Jaroše", "Nám. Svobody"... To je pravda. Do name by se to mělo rozepsat. Ale jinak nevidím důvod, proč do name tu ceduli nepřepsat. Marián
  15. Matěj Cepl mcepl na cepl.eu #me7a7f5
    Jestli to spíše nebylo míněno tak, že do name nepatří "Tř. 1. máje", "Kpt. Jaroše", "Nám. Svobody"...
    Já jsem měl na mysli spíše ulici V jámě. Matěj
  16. Marián Kyral mkyral na email.cz #m19d9f8
    Jestli to spíše nebylo míněno tak, že do name nepatří "Tř. 1. máje", "Kpt. Jaroše", "Nám. Svobody"...
    Já jsem měl na mysli spíše ulici V jámě. Tam je problém, pravidla pravopisu se občas mění a záleží jak se k tomu postaví místní samospráva (ta co pojmenovává ulice). Někde se snaží mít to dle pravidel, jinde lpí na starém názvu a někde to neřeší a píší si to jak chtějí - jinak je to v KM, jinak v registrech, půlka cedulí tak, druhá půlka jinak. Už nevím, kde jsem to viděl/četl, ale stalo se, že zastupitelé schválili určitý název, ale do KM se (zřejmě chybou úředníka) dostalo něco trochu jiného. Pro případ výše jsou podle mně možné obě možnosti, záleží na kontextu: V jámě - v nějaké obecné rýze, která jámu připomíná V Jámě - dané místo je jmenuje Jáma. Bez bližší znalosti místa je těžké říct, jak je to správně. A už vůbec nedokáži říct, odkud se to má brát. Marián Matěj
  17. Mikoláš Štrajt strajt9 na seznam.cz #m102993
    Uliční cedule jsou navíc typicky psány CAPS LOCKem, takže to neulehčují.
  18. Petr Kadlec petr.kadlec na gmail.com #m5255f6
    Ahoj, 4 nebo 3 (nebo 5, ale to je jiná práce, úplně bych to s tímhle nemíchal). 2018-01-18 10:46 GMT+01:00 Pavel Machek <pavel na ucw.cz>:
    ...Tedy ve skutecnosti... 1). Pripadne se zeptat na data working group, co si o tom mysli, a jestli chteji v ramci celeho sveta nbsp v nazvech. A podle toho dal. Do te doby...
    Budeme se ptát data working group, jestli chtějí v rámci celého světa v názvem používat tečky, velká písmena, mezery, azbuku, ? atd.? V českém textu se prostě např. po jednopísmenných předložkách píše nezlomitelná mezera. Ale tahle debata už tu proběhla. Římské číslice v Unicode jsou úplně jiná situace a do názvů nepatří. Viz Unicode Standard 10.0.0, kapitola 22.3 (s. 798) [1]; TLDR existují jen kvůli východoasijským zemím: ?For most purposes, it is preferable to compose the Roman numerals from sequences of the appropriate Latin letters. However, the uppercase and lowercase variants of the Roman numerals through 12, plus L, C, D, and M, have been encoded in the Number Forms block (U+2150..U+218F) for compatibility with East Asian standards. Unlike sequences of Latin letters, these symbols remain upright in vertical layout. Additionally, in certain locales, compact date formats use Roman numerals for the month, but may expect the use of a single character.? -- Petr Kadlec / Mormegil [1]: https://www.unicode.org/versions/Unicode10.0.0/ch22.pdf
  19. Matěj Cepl mcepl na cepl.eu #m4084b7
    Tam je problém, pravidla pravopisu se občas mění a záleží jak se k tomu postaví místní samospráva (ta co pojmenovává ulice).
    Point nebylo velké nebo malé písmeno (a tady je zcela nepochybně velké, protože se jedná o bývalou hospodu Jáma, https://www.openstreetmap.org/way/4387743), ale jednopísmenová předložka, která si zaslouží oddělit od druhého slova nezlomitelnou mezerou, což je co jsem v tom textu měl. Matěj
  20. jzvc jzvc na tpfree.net #m0ad501
    Ahoj, 4 nebo 3 (nebo 5, ale to je jiná práce, úplně bych to s tímhle nemíchal). 2018-01-18 10:46 GMT+01:00 Pavel Machek <pavel na ucw.cz <mailto:pavel na ucw.cz>>: ...Tedy ve skutecnosti... 1). Pripadne se zeptat na data working group, co si o tom mysli, a jestli chteji v ramci celeho sveta nbsp v nazvech. A podle toho dal. Do te doby... Budeme se ptát data working group, jestli chtějí v rámci celého světa v názvem používat tečky, velká písmena, mezery, azbuku, ? atd.? V českém textu se prostě např. po jednopísmenných předložkách píše nezlomitelná mezera.
    Ne, nepise, nic jako nezalomitelna mezera neexistuje. To je pouze typograficka pomucka pro SW, ktery neumi jinak rict, ze by neco melo drzet pri sobe. Ve skutecnosti je to exaktne totez, jako kdyz budes neco tagovat pro reneder, coz se v OSM vyslovene zapovida. Spravne by mel reneder sam vedet, ze v dany lokalite ma ten text spojit. Ale tahle debata už tu proběhla.
    Římské číslice v Unicode jsou úplně jiná situace a do názvů nepatří. Viz Unicode Standard 10.0.0, kapitola 22.3 (s. 798) [1]; TLDR existují jen kvůli východoasijským zemím: ?For most purposes, it is preferable to compose the Roman numerals from sequences of the appropriate Latin letters. However, the uppercase and lowercase variants of the Roman numerals through 12, plus L, C, D, and M, have been encoded in the Number Forms block (U+2150..U+218F) for compatibility with East Asian standards. Unlike sequences of Latin letters, these symbols remain upright in vertical layout. Additionally, in certain locales, compact date formats use Roman numerals for the month, but may expect the use of a single character.?
    Ve skutecnosti ma trebas dolar znak pro svoji menu, ale v OSM by nikdy nikde byt nemel, tam by mel byt kod meny. Opet je to vec renederu. Na druhou stranu existuji znaky, trebas (c), coz ve skutecnosti je jeden znak, a tudiz by to i jako jeden znak melo byt pouzivano.
    -- Petr Kadlec / Mormegil
    A mimochodem, v textu se pise pomlcka ? (pripadne ? pokud pises basne) a ne minus -.
  21. Jan Martinec jan na martinec.name #mb08354
    No...ulice je tam od 13.století, zatímco hospoda vznikla i zanikla v době, k níž ještě existují pamětníci - jmenovala se hospoda podle ulice, nikoli naopak (dokonce vedle Jámy byla kavárna Kyvadlo). Velké "J" by tam sice mělo být podle nového pravopisu, byť je ulice asi pojmenovaná podle morové jámy, která pravděpodobně pojmenování ani neměla, ale s tou jednoznačností jména je to hodně vratké ;) Zdar, HPM Dne 18. 1. 2018 16:02 napsal uživatel "Matěj Cepl" <mcepl na cepl.eu>:
    Tam je problém, pravidla pravopisu se občas mění a záleží jak se k tomu postaví místní samospráva (ta co pojmenovává ulice).
    Point nebylo velké nebo malé písmeno (a tady je zcela nepochybně velké, protože se jedná o bývalou hospodu Jáma, https://www.openstreetmap.org/way/4387743), ale jednopísmenová předložka, která si zaslouží oddělit od druhého slova nezlomitelnou mezerou, což je co jsem v tom textu měl. Matěj
  22. Petr Kadlec petr.kadlec na gmail.com #m8eb44d
    Ahoj, 2018-01-18 17:36 GMT+01:00 jzvc <jzvc na tpfree.net>:
    Ne, nepise, nic jako nezalomitelna mezera neexistuje. To je pouze typograficka pomucka pro SW, ktery neumi jinak rict, ze by neco melo drzet pri sobe. Ve skutecnosti je to exaktne totez, jako kdyz budes neco tagovat pro reneder, coz se v OSM vyslovene zapovida. Spravne by mel reneder sam vedet, ze v dany lokalite ma ten text spojit.
    Ano, v platónském světě názvů ulic neexistuje nezalomitelná mezera, existuje název, v němž se nesmí na nějakém místě zalomit řádek. My ale nežijeme v platónském světě názvů, my vyrábíme data pro software a tento software pro reprezentaci textových dat používá Unicode. Proto bychom měli vzít název a podle toho, jak se má správně psát,[1] bychom měli zvolit odpovídající reprezentaci v Unicode. Nejde jen o renderer. Když si z databáze OSM stáhnu seznam všech ulic, chci to tam mít.
    Ve skutecnosti ma trebas dolar znak pro svoji menu, ale v OSM by nikdy nikde byt nemel, tam by mel byt kod meny. Opet je to vec renederu.
    E? Kde v OSM se v jakém kontextu [ne]vyskytuje jaký znak pro měnu a co s tím má společného renderer? Jako že když existuje podnik ?Vše za $0,99?, tak tam mám psát ?Vše za USD0,99? a je věcí rendereru, aby to vykreslil správně, nebo jakožecože?
    -- Petr Kadlec / Mormegil A mimochodem, v textu se pise pomlcka ? (pripadne ? pokud pises basne) a ne minus -.
    ?-? není minus o nic víc než pomlčka (minus je ???). A ?--? není a nemá být pomlčka. -- Petr Kadlec / Mormegil [1]: http://prirucka.ujc.cas.cz/?id=880
  23. Marián Kyral mkyral na email.cz #me82b50
    Ahoj, 2018-01-18 17:36 GMT+01:00 jzvc <jzvc na tpfree.net>: "Ne, nepise, nic jako nezalomitelna mezera neexistuje. To je pouze typograficka pomucka pro SW, ktery neumi jinak rict, ze by neco melo drzet pri sobe. Ve skutecnosti je to exaktne totez, jako kdyz budes neco tagovat pro reneder, coz se v OSM vyslovene zapovida. Spravne by mel reneder sam vedet, ze v dany lokalite ma ten text spojit. Ano, v platónském světě názvů ulic neexistuje nezalomitelná mezera, existuje název, v němž se nesmí na nějakém místě zalomit řádek. My ale nežijeme v platónském světě názvů, my vyrábíme data pro software a tento software pro reprezentaci textových dat používá Unicode. Proto bychom měli vzít název a podle toho, jak se má správně psát,[1] bychom měli zvolit odpovídající reprezentaci v Unicode. Nejde jen o renderer. Když si z databáze OSM stáhnu seznam všech ulic, chci to tam mít. Takže pokud pak budu tu ulici hledat, tak si musím pamatovat, že za "V" musím napsat nezalomitelnou mezeru, jinak mi třeba nominatin najde velké kulové? U něj by to ještě šlo nějak ošetřit, ale třeba u Overpass už na to musím myslet já. Sám to za mně neudělá. Nekomplikuješ nám to tak trochu? Marián
  24. Jan Martinec jan na martinec.name #ma0564a
    N i O mají plnou podporu Unicode, tj. měly by "vidět" všechny mezerovité znaky jako ekvivalentní. HPM Dne 18. 1. 2018 18:24 napsal uživatel "Marián Kyral" <mkyral na email.cz>:
  25. Matej Lieskovský lieskovsky.matej na gmail.com #ma4bb93
    Nominatim tohle zvládá, Overpass (alespoň standardně) nikoliv - ten bere nápisy s přesností na znak. Díky tomu jsem na tyhle problémy přišel. 2018-01-18 18:26 GMT+01:00 Jan Martinec <jan na martinec.name>:
  26. Lukáš Karas lukas.karas na centrum.cz #m992c80
    Overpass to bere s přesností na znak nebo na binární iterpretaci? Ptám se protože i pitomá česká diakritika se dá v unicode zapsat různou sekvencí bytů... Pokud nějaký software neumí pracovat s unicode, je to chyba toho softwaru. Pokud ale v nějakém jazyce nemá být nějaká sekvence znaků samostatně na konci řádku, je potřeba za ní dát nedělitelnou mezeru. Protože tohle si žádný software z prstu nevycucá. To není psaní názvů pro renderer, to je normální psaní textu v unicode. Lukáš
  27. Pavel Machek pavel na ucw.cz #m0b73c4
    Ahoj, 4 nebo 3 (nebo 5, ale to je jiná práce, úplně bych to s tímhle nemíchal). 2018-01-18 10:46 GMT+01:00 Pavel Machek <pavel na ucw.cz>:
    ...Tedy ve skutecnosti... 1). Pripadne se zeptat na data working group, co si o tom mysli, a jestli chteji v ramci celeho sveta nbsp v nazvech. A podle toho dal. Do te doby...
    Budeme se ptát data working group, jestli chtějí v rámci celého světa v názvem používat tečky, velká písmena, mezery, azbuku, ? atd.? V českém
    Tohle neni ferova argumentace, ze? Pevne mezery nejsou jen v cestine, takze dava smysl to mit konzistentni pres cely svet. Osobne si myslim ze mit je v name="" je pekna kravina. Kazdopadne... data working group. Vsude nebo nikde. Pavel
  28. Petr Kadlec petr.kadlec na gmail.com #m15770a
    2018-01-18 20:45 GMT+01:00 Lukáš Karas <lukas.karas na centrum.cz>:
    Overpass to bere s přesností na znak nebo na binární iterpretaci? Ptám se protože i pitomá česká diakritika se dá v unicode zapsat různou sekvencí bytů... Pokud nějaký software neumí pracovat s unicode, je to chyba toho softwaru.
    Ano, a zjevně je to přesně tak, viz seznam omezení na https://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide#Accents_and_decorated_characters (pokud vstup není v NFC, nebude to fungovat; třeba ?way["name"="Na Rybni?c?ku"]?; i když tohle se dá ještě relativně snadno řešit automaticky na vstupu (dokud se pohybujeme v češtině, kde se nic složitějšího nevyskytuje)). O složitějších případech nemluvě (jako třeba hledání bez diakritiky). V zásadě si Overpass asi představuje, že si to každý ošetří stylem way["name"~"^V[ \u00A0]Tůních$"] O implementaci Overpassu nic moc nevím, takže netuším, kolik práce by bylo to nějak opravit/dodělat. -- Petr Kadlec / Mormegil
  29. Petr Kadlec petr.kadlec na gmail.com #m9c8506
    2018-01-18 21:42 GMT+01:00 Pavel Machek <pavel na ucw.cz>:
    Budeme se ptát data working group, jestli chtějí v rámci celého světa v názvem používat tečky, velká písmena, mezery, azbuku, ? atd.? V českém
    Tohle neni ferova argumentace, ze? Pevne mezery nejsou jen v cestine, takze dava smysl to mit konzistentni pres cely svet. Osobne si myslim ze mit je v name="" je pekna kravina. Kazdopadne... data working group. Vsude nebo nikde.
    Pravidlo o jednopísmenných předložkách je jen české. A jako že by se nikde na světě nezlomitelné mezery vůbec nepoužívaly, to bych taky netvrdil? Namátkou (i když přiznávám, že jsem čekal větší užití). https://www.openstreetmap.org/node/2380290743 https://www.openstreetmap.org/relation/1074049 https://www.openstreetmap.org/node/5337546040 https://www.openstreetmap.org/way/454759316 Či dokonce s ještě zajímavějšími variantami? https://www.openstreetmap.org/node/530880275 Každopádně mi to přijde podobné, jako chtít zakazovat třeba pomlčku; jasně, není na klávesnici a ?-? může víceméně vcelku fungovat taky a renderer si to může vyřešit a kdo má vědět, že to mám do Overpass psát takhle atd. A ano, nástrojům zjevně k ideálu ledacos chybí, ale právě proto je potřeba vylepšovat nástroje, ne zhoršovat data; jinak bychom dodnes na počítačích psali bez diakritiky všichni. -- Petr Kadlec / Mormegil
  30. Matěj Cepl mcepl na cepl.eu #m3da4ab
    @Matěj: Podle ČÚZK žádné díly neexistují a basta! :)
    To je další neřešitelná diskuse: je rozhodující ČÚZK nebo cedule na plotě? Matěj
  31. Matěj Cepl mcepl na cepl.eu #m191706
    No...ulice je tam od 13.století, zatímco hospoda vznikla i zanikla v době, k níž ještě existují pamětníci - jmenovala se hospoda podle ulice, nikoli naopak (dokonce vedle Jámy byla kavárna Kyvadlo). Velké "J" by tam sice mělo být podle nového pravopisu, byť je ulice asi pojmenovaná podle morové jámy, která pravděpodobně pojmenování ani neměla, ale s tou jednoznačností jména je to hodně vratké ;)
    Tak se omlouvám ? o jménu blábolím, i když jsem do té hospody chodíval na oběd. A pozitivní na tom je, že alespoň vypadá stejně dobrá jako bývala před těma skoro dvaceti lety. Úžasné. Matěj
  32. jzvc jzvc na tpfree.net #me3e784
    Ahoj, 2018-01-18 17:36 GMT+01:00 jzvc <jzvc na tpfree.net <mailto:jzvc na tpfree.net>>: Ne, nepise, nic jako nezalomitelna mezera neexistuje. To je pouze typograficka pomucka pro SW, ktery neumi jinak rict, ze by neco melo drzet pri sobe. Ve skutecnosti je to exaktne totez, jako kdyz budes neco tagovat pro reneder, coz se v OSM vyslovene zapovida. Spravne by mel reneder sam vedet, ze v dany lokalite ma ten text spojit. Ano, v platónském světě názvů ulic neexistuje nezalomitelná mezera, existuje název, v němž se nesmí na nějakém místě zalomit řádek. My ale nežijeme v platónském světě názvů, my vyrábíme data pro software a tento software pro reprezentaci textových dat používá Unicode. Proto bychom měli vzít název a podle toho, jak se má správně psát,[1] bychom měli zvolit odpovídající reprezentaci v Unicode. Nejde jen o renderer. Když si z databáze OSM stáhnu seznam všech ulic, chci to tam mít.
    Ja chci a chci a chci ... to je presne tvuj pristup. Nazev se pise s mezerou, a znak nedelitelny mezery v zadnych pravidlech ani v zadnych datech NEEXISTUJE!. Jestli je tvuj SW hloupej a neumi implementovat pravidla pravopisu, je to problem toho SW, ale netahej to do dat, tam to nema co pohledavat. Znak nedelitelny mezery nema ani naprosto nic spolecnyho s unicode, jen tam ma nejakou reprezentaci, stejne jako tuny jinych znaku. Ja zase chci, aby se spravne pouzivaly ligatury, takze ti do name misto tech dvou znaku latinky dam ten jeden znak unicode kterej resi tu konkretni ligaturu. Sem vazne zvedav, jak v tom pak budes neco hledat. Opet, je to vec SW aby to pouzil, ale nema to co pohledavat v datech. Mimochodem, ukaz mi jedinyho cloveka na tyhle planete, kterej kdyz pise text na klavesnici, tak misto mezerniku pouziva ctrl/alt/... . A pak chci taky videt, kde ma nbsp zadat nekdo z telefonu.
    Ve skutecnosti ma trebas dolar znak pro svoji menu, ale v OSM by nikdy nikde byt nemel, tam by mel byt kod meny. Opet je to vec renederu. E? Kde v OSM se v jakém kontextu [ne]vyskytuje jaký znak pro měnu a co s tím má společného renderer? Jako že když existuje podnik ?Vše za $0,99?, tak tam mám psát ?Vše za USD0,99? a je věcí rendereru, aby to vykreslil správně, nebo jakožecože?
    Ne, to je jen o tom ze podle vseho naprosto nerozumis tomu jak databaze (a OSM neni nic jineho) funguji. Protoze v datech ma byt castka a oznaceni meny ... zvlast.
  33. Karel Volný kavol na seznam.cz #ma27b5f
    Ja chci a chci a chci ... to je presne tvuj pristup. Nazev se pise s mezerou, a znak nedelitelny mezery v zadnych pravidlech ani v zadnych datech NEEXISTUJE!
    popravdě, přístup, kdy někdo normálně vyjádří své zbožné přání, je mi podstatně sympatičtější, než když někdo něco označuje za prostý fakt, bez důkazu a ve zjevném rozporu s realitou - pakliže "v zadnych datech NEEXISTUJE", zřejmě neexistuje ani tato diskuse, neboť ta se rozvinula pod mailem o tom, že v datech OSM nějaké ty nbsp máme ... ...
    Ve skutecnosti ma trebas dolar znak pro svoji menu, ale v OSM by nikdy nikde byt nemel, tam by mel byt kod meny. Opet je to vec renederu.
    E? Kde v OSM se v jakém kontextu [ne]vyskytuje jaký znak pro měnu a co s tím má společného renderer? Jako že když existuje podnik ?Vše za $0,99?, tak tam mám psát ?Vše za USD0,99? a je věcí rendereru, aby to vykreslil správně, nebo jakožecože?
    Ne, to je jen o tom ze podle vseho naprosto nerozumis tomu jak databaze (a OSM neni nic jineho) funguji. Protoze v datech ma byt castka a oznaceni meny ... zvlast.
    rád bych viděl nějakou vzorovou implementaci toho nehloupého SW, ve které bude fungovat výše uvedený příklad, s tím, že označení měny bude zvlášť když tedy, ještě jednou zdůrazňuji z citace: "... v OSM by NIKDY NIKDE byt nemel ..." K.
  34. Petr Kadlec petr.kadlec na gmail.com #m5ad982
    Ahoj, 2018-01-19 13:36 GMT+01:00 jzvc <jzvc na tpfree.net>:
    2018-01-18 17:36 GMT+01:00 jzvc <jzvc na tpfree.net <mailto:jzvc na tpfree.net
    :
    Ano, v platónském světě názvů ulic neexistuje nezalomitelná mezera, existuje název, v němž se nesmí na nějakém místě zalomit řádek. My ale nežijeme v platónském světě názvů, my vyrábíme data pro software a tento software pro reprezentaci textových dat používá Unicode. Proto bychom měli vzít název a podle toho, jak se má správně psát,[1] bychom měli zvolit odpovídající reprezentaci v Unicode. Nejde jen o renderer. Když si z databáze OSM stáhnu seznam všech ulic, chci to tam mít.
    Ja chci a chci a chci ... to je presne tvuj pristup.
    Mohl bys prosím přestat vyskakovat jako čertík z krabičky a normálně argumentovat? Kdyby to aspoň bylo na téma prezidentských voleb nebo něco, ale kvůli mezerám v OSM se snad nemusíme takhle hádat?
    Nazev se pise s mezerou, a znak nedelitelny mezery v zadnych pravidlech ani v zadnych datech NEEXISTUJE!. Jestli je tvuj SW hloupej a neumi implementovat pravidla pravopisu, je to problem toho SW, ale netahej to do dat, tam to nema co pohledavat. Znak nedelitelny mezery nema ani naprosto nic spolecnyho s unicode, jen tam ma nejakou reprezentaci, stejne jako tuny jinych znaku.
    Unicode specifikuje způsob reprezentace textových dat v počítačích. To je jeho podstata. Součástí toho standardu reprezentace je definice sémantiky těch jednotlivých codepointů. Odkaz třeba na IJP ÚJČ jsem sem dával už předtím. Aby každý software na světě nemusel implementovat pravidla psaní ve všech možných jazycích a kódováních zcela od nuly, vzniknul Unicode.
    Ja zase chci, aby se spravne pouzivaly ligatury, takze ti do name misto tech dvou znaku latinky dam ten jeden znak unicode kterej resi tu konkretni ligaturu. Sem vazne zvedav, jak v tom pak budes neco hledat. Opet, je to vec SW aby to pouzil, ale nema to co pohledavat v datech.
    Dalo by se bavit o tom, zda je tam chceme mít, ale myslím, že ligatury jsou v Unicode zpravidla jen jako prezentační forma znaků pro zpětnou kompatibilitu, přičemž mají kompatibilní dekompozicí na ty základní znaky, s tím, že dnes by se to mělo nechat na vykreslování, kterému se pomáhá pomocí označení míst, kde se to chová nestandardně (např. na švu slova), pomocí ZWJ/ZWNJ. Takže z tohohle pohledu by se ZWJ/ZWNJ v datech případně objevit mohly, ale ligatury tam, myslím, nepatří.
    Mimochodem, ukaz mi jedinyho cloveka na tyhle planete, kterej kdyz pise text na klavesnici, tak misto mezerniku pouziva ctrl/alt/... . A pak chci taky videt, kde ma nbsp zadat nekdo z telefonu.
    Takového neznám, ani nevím, jak to s touto debatou souvisí. Jestli tě zajímá někdo, kdo *navíc* k mezerníku používá ctrl/alt/? (fskutčnosti AltGr), když chce napsat nbsp, tak třeba já. A taky píšu české uvozovky a trojtečku místo tří teček. Ale netvrdím, že jsem normální. A už vůbec netvrdím, že to má být povinné a pokud někdo nenapíše (třeba na telefonu, ale i kdekoli jinde) správnou nezlomitelnou mezeru, tak se má vyhodit z OSM a upálit na hranici.
    Ve skutecnosti ma trebas dolar znak pro svoji menu, ale v OSM by
    nikdy nikde byt nemel, tam by mel byt kod meny. Opet je to vec renederu. E? Kde v OSM se v jakém kontextu [ne]vyskytuje jaký znak pro měnu a co s tím má společného renderer? Jako že když existuje podnik ?Vše za $0,99?, tak tam mám psát ?Vše za USD0,99? a je věcí rendereru, aby to vykreslil správně, nebo jakožecože?
    Ne, to je jen o tom ze podle vseho naprosto nerozumis tomu jak databaze (a OSM neni nic jineho) funguji. Protoze v datech ma byt castka a oznaceni meny ... zvlast.
    Nech si ty nesmyslné ad hominem útoky a vysvětli mi, jak souvisí oddělená reprezentace částky a označení měny s tím, že se do textového pole pro název má psát správně formátovaný název. Nebo snad chceš říct, že v databázi má být předložka a následující obsah ? zvlášť? Anebo to prostě nemá s touto diskusí společného nic? -- Petr Kadlec / Mormegil
  35. Pavel Machek pavel na ucw.cz #m4dee99
    2018-01-18 21:42 GMT+01:00 Pavel Machek <pavel na ucw.cz>:
    Budeme se ptát data working group, jestli chtějí v rámci celého světa v názvem používat tečky, velká písmena, mezery, azbuku, ? atd.? V českém
    Tohle neni ferova argumentace, ze? Pevne mezery nejsou jen v cestine, takze dava smysl to mit konzistentni pres cely svet. Osobne si myslim ze mit je v name="" je pekna kravina. Kazdopadne... data working group. Vsude nebo nikde.
    Pravidlo o jednopísmenných předložkách je jen české. A jako že by se nikde na světě nezlomitelné mezery vůbec nepoužívaly, to bych taky netvrdil? Namátkou (i když přiznávám, že jsem čekal větší užití). https://www.openstreetmap.org/node/2380290743 https://www.openstreetmap.org/relation/1074049 https://www.openstreetmap.org/node/5337546040 https://www.openstreetmap.org/way/454759316 Či dokonce s ještě zajímavějšími variantami? https://www.openstreetmap.org/node/530880275
    Myslim ze v oficialnich dokumentech se ulice jmenuje "U Lomu" ne "U&nbsp;Lomu". Kazdopadne se nema cenu hadat tady, tohle je na data working group. Pavel
  36. Pavel Machek pavel na ucw.cz #m0b83e9
    2018-01-18 21:42 GMT+01:00 Pavel Machek <pavel na ucw.cz>:
    Budeme se ptát data working group, jestli chtějí v rámci celého světa v názvem používat tečky, velká písmena, mezery, azbuku, ? atd.? V českém
    Tohle neni ferova argumentace, ze? Pevne mezery nejsou jen v cestine, takze dava smysl to mit konzistentni pres cely svet. Osobne si myslim ze mit je v name="" je pekna kravina. Kazdopadne... data working group. Vsude nebo nikde.
    Pravidlo o jednopísmenných předložkách je jen české. A jako že by se nikde na světě nezlomitelné mezery vůbec nepoužívaly, to bych taky netvrdil? Namátkou (i když přiznávám, že jsem čekal větší užití). https://www.openstreetmap.org/node/2380290743 https://www.openstreetmap.org/relation/1074049 https://www.openstreetmap.org/node/5337546040 https://www.openstreetmap.org/way/454759316 Či dokonce s ještě zajímavějšími variantami? https://www.openstreetmap.org/node/530880275 Každopádně mi to přijde podobné, jako chtít zakazovat třeba pomlčku; jasně, není na klávesnici a ?-? může víceméně vcelku fungovat taky a renderer si to může vyřešit a kdo má vědět, že to mám do Overpass psát takhle atd. A ano, nástrojům zjevně k ideálu ledacos chybí, ale právě proto je potřeba
    Hmm. A nemam pocit ze by mail mel v subjektu pevnou mezeru, nebo ze by ve vete co cituju byly pevny mezery. Proste tam nemaj co delat, to je az veci formatovani pro tisk... Stejne nepatrej do name. Pavel
  37. Petr Kadlec petr.kadlec na gmail.com #m840e91
    Ahoj, 2018-01-19 14:49 GMT+01:00 Pavel Machek <pavel na ucw.cz>:
    Myslim ze v oficialnich dokumentech se ulice jmenuje "U Lomu" ne "U&nbsp;Lomu".
    To se těžko hodnotí. Co je ten oficiální dokument? Je to vytištěný/rukou psaný papír? Je to forma ve Wordu? Ve vytištěné/rukou psané formě to nepoznáš, když se to zrovna nezalomí (což by zase naopak naznačovalo, že ten člověk neumí správně psát), ve Wordu to naopak dost často bude správně, protože se o to postará sám Word. Zcela namátkou: Zápis z jednání Místopisné komise Rady HMP z 27.4.2011 používá ve zmíněné ulici ?K jelenám? nezlomitelnou mezeru. Je to důkaz, není to důkaz? A co se týče státních databází, tak na ty bych v tomto ohledu moc nespoléhal. Ostatně, v takovém obchodním rejstříku se stát neobtěžuje ani s pomlčkami. I když máš zakladatelskou dokumentaci, ve které se zjevně používá pomlčka, nahlížení do OR ukazuje název se spojovníkem. Zcela namátkou: IČO 27799719. -- Petr Kadlec / Mormegil
  38. Matej Lieskovský lieskovsky.matej na gmail.com #m4b077b
    Dobrá, ráno napíšu na DWG. Ozvu se, až budeme mít odpověď. Matej 2018-01-19 15:46 GMT+01:00 Petr Kadlec <petr.kadlec na gmail.com>:
  39. Martin Janda jandam na crcdata.cz #ma28b3d
    Dobry den, jsem PROTI nedelitelnym mezeram (unicode cislicim). Jako programator v nich vidim spis dalsi problemy pri zpracovani. *) nastroje - JOSM, webove nepodporuji zobrazeni nedelitelnych mezer *) nazev ulice s mezerou a nedelitelnou mezerou neni povazovan za stejny. Mozna pomuze normalizace ale ta znamena docela vyznamny overhead. *) nejsem si jisty ze vsechny adresy/adresni body v ulici dodrzi pouziti nbsp. Jedna ulice muze byt na dvou ways na jedne s nbsp a na druhe s normalni mezerou. *) regexp - myslim ze i tady mohou byt problemy. Nemam zde moc skusenosti *) spravne zobrazeni ma byt reseno rendererem i kdyz nebude fungovat ve vsech pripadech spravne Navrh :-) Pokud chcete resit problem pak je to "Ch Martin JANDA 21. 1. 2018 v 1:13, Matej Lieskovský <lieskovsky.matej na gmail.com>:
  40. Matej Lieskovský lieskovsky.matej na gmail.com #m9c584f
    Ahoj! Ohledně nbsp: DWG tvrdí, že si to když tak máme rozhodnout sami, případně se zeptat na Tagging (nikoliv na Talk). Hlasují pro možnost 6. Co dál? Mně se možnost 6 fakt nelíbí, prostě buď tam ty nbsp chceme, nebo nechceme. Můžu napsat na Tagging, ale 1) nejsem si jist, zda se dopracujeme k výsledku 2) tohle mi (vzhledem k tomu, že to ovlivňuje hlavně nástroje pro přispěvatele a konzumenty) opravdu přijde spíš jako problém pro Talk. Technicky vzato máme od DWG posvěcení si to nějak rozhodnout lokálně a problémy s globálními nástroji řešit pak. Velmi rád bych se vyhnul editační válce. Matej 2018-01-21 7:17 GMT+01:00 Martin Janda <jandam na crcdata.cz>:
  41. Michal Fabík michal.fabik na gmail.com #mae95ae
    Ahoj! Ohledně nbsp: DWG tvrdí, že si to když tak máme rozhodnout sami, případně se zeptat na Tagging (nikoliv na Talk). Hlasují pro možnost 6. Co dál? Mně se možnost 6 fakt nelíbí, prostě buď tam ty nbsp chceme, nebo nechceme. Můžu napsat na Tagging, ale 1) nejsem si jist, zda se dopracujeme k výsledku 2) tohle mi (vzhledem k tomu, že to ovlivňuje hlavně nástroje pro přispěvatele a konzumenty) opravdu přijde spíš jako problém pro Talk. Technicky vzato máme od DWG posvěcení si to nějak rozhodnout lokálně a problémy s globálními nástroji řešit pak. Velmi rád bych se vyhnul editační válce. Matej
    Ahoj, jen takový nápad: co se zeptat v komunitách (na mailing listech) jiných zemí, jestli to někde nějak řeší? To typografické pravidlo o jednopísmenných předložkách na konci řádku se zdaleka netýká jen češtiny. I když je fakt, že asi málokterá z lokálních komunit je na takové úrovni, aby se něčím takovým vůbec zabývali... Jinak za mě taky nedělitelné mezery do tagů nedávat, ať si to ošetří renderer, zas taková věda to snad není.
  42. Matej Lieskovský lieskovsky.matej na gmail.com #mc3e88f
    Možná relevantní pozorování: Program VLNA, který doplňuje nbsp do TeXových zdrojáků je český výmysl. Je možné, že tohle prostě řešíme (na mezinárodní poměry) relativně hodně. 2018-01-23 18:44 GMT+01:00 Michal Fabík <michal.fabik na gmail.com>:
  43. majka majka.zem+talk na gmail.com #m7c3965
    Netroufám si mluvit za jiné jazyky jako nějaký expert. Ale z toho, co se vyskytuje po Evropě, bych to odhadla na nás, možná bratry Slováky a pak ještě Francouze, kteří něco takového řeší. Taková Británie je zvyklá, že jim Angličtinu przní kde kdo, a jsou tak nějak nad věcí. České jednopísmenné předložky zkrátka vypadají mimořádně špatně, pokud jsou oddělené na konci řádku / zalomení, už i dvě písmena se při troše vůle dají skousnout, i když mě to tahá za oči. Z toho bych také odhadla, že jsme ze školy v tomhle ohledu podstatně víc vycepovaní než jiné národy. Když se k tomu přidá ještě problém s kódováním češtiny z dřívějška, byly nedělitelné mezery vlastně jen taková drobnost navíc. Do dat bych ale nedělitelné mezery netahala, kromě jiného z toho kouká nutnost to stále kontrolovat a opravovat. Mít to v datech napůl je podle mého k ničemu, a dosáhnout toho, že to všichni a všude budou respektovat, nevidím jako reálné. Navíc udělat to co nejméně komplikované se mi zkrátka líbí nejvíc. 2018-01-23 20:34 GMT+01:00 Matej Lieskovský <lieskovsky.matej na gmail.com>:
  44. Matej Lieskovský lieskovsky.matej na gmail.com #mb098b0
    Kontrolování a opravování je proveditelné. Teď řeším ty street relace (a školu), ale pak se klidně můžu podívat na nbsp. S "mít to v datech napůl je k ničemu" souhlasím - proto se mi nelíbí možnost 6. 2018-01-23 21:01 GMT+01:00 majka <majka.zem+talk na gmail.com>:
  45. Michal Fabík michal.fabik na gmail.com #mefb27e
    Netroufám si mluvit za jiné jazyky jako nějaký expert. Ale z toho, co se vyskytuje po Evropě, bych to odhadla na nás, možná bratry Slováky a pak ještě Francouze, kteří něco takového řeší.
    Nejsem si jistý, jestli myslíš "řeší v OSM" nebo "řeší v rámci typografických zásad", ale pokud to druhé, tak se to týká prakticky všech slovanských jazyků, i když teď z hlavy fakt nevím, jak často v těch jednotlivých jazycích nastává situace, že se něco takového vyskytne v místním názvu.
  46. Mikoláš Štrajt strajt9 na seznam.cz #m190b46
    Nbsp IMHO do dat nepatří. Důvod je jednoduchý - nejsou vidět a zároveň nejsou mezera (ve smyslu ASCII/ UTF-8 znak 32). Domnívám se, že nad daty OSM operuje dost věcí, které namejí skutečnou podporu Unicode a spíše zneužívají toho, že UTF-8 je zpětně kompatibilní s ASCII. Kromě toho, bílé znaky se strašně těžko debugují. V diskuzi výše byl zmíněn program vlna. Mám za to, že by bylo lepší nedělitelné mezery přidávat až před vykreslováním v preprocesingu. Například německá verze OSM provádí podobným způsobem transliterace nelatinkových abeced.
  47. Matej Lieskovský lieskovsky.matej na gmail.com #m551696
    Zase na druhou stranu platí, že pokud se budeme omezovat na to, co zvládá již existující software, tak se nikdy nikam neposuneme. Minimálně výhledově mi přijde jako správné se posouvat směrem k plnohodnotnému Unicode. Souhlasím, že se bílé znaky blbě debugují, ale minimálně bychom mohli protlačit do editorů možnost zobrazovat bílé znaky. Vlna má základní problém v tom, že musíš hlídat, ve kterém jazyce který název je a spoustu podobných blbostí. Například pokud zahodíme i římské číslice, tak bude potřeba tipovat, zda je to "v" nebo římská číslice pět. Část debaty je vlastně o tom, zda je snažší doplňovat nebo zahazovat nbsp. Mně přijde, že se data vždy snadněji zahazují, ale je otázka, jak často je co z toho potřeba. Ono se taky může stát, že teď budeme nbsp mazat a za pár let zase přidávat, protože se SW zlepší. 2018-01-23 22:06 GMT+01:00 Mikoláš Štrajt <strajt9 na seznam.cz>:
  48. Matěj Cepl mcepl na cepl.eu #m38bca8
    Důvod je jednoduchý - nejsou vidět a zároveň nejsou mezera (ve smyslu ASCII/ UTF-8 znak 32). Domnívám se, že nad daty OSM operuje dost věcí, které namejí skutečnou podporu Unicode a spíše zneužívají toho, že UTF-8 je zpětně kompatibilní s ASCII.
    Jenom pro upřesnění: &nbsp; je mezera, alespoň patří do kategorie WSpace=Y v Unicode (https://en.wikipedia.org/wiki/Whitespace_character). Matěj
  49. Jan Dudík jan.dudik na gmail.com #m54a62e
    &nbsp; není mezera, je to html zápis mezery, která jinak není vidět :-) Přijde mi, že tato problematika je zatím příliš futuristická, v době, kdy v mapě chybí ještě sposuta existujících objektů, my už řešíme drobné grafické finesy. (což nemusí být nutně špatně) A druhá věc - jak často nastává případ, že je nutné zalomit dlouhý název, který obsahuje někde kolem poloviny nedělitelnou mezeru? Většina názvů jí obsahuje hned na začátku (V°Jámě, U°Dlouhého mostu), byť se najdou Výjimky (Rokytnice v°Orlických horách, U°Karla°IV.) JAnD --- Ing. Jan Dudík projekce dopravních staveb tel. 777082195
  50. Lukáš Karas lukas.karas na centrum.cz #m8d2b5c
    Jinak za mě taky nedělitelné mezery do tagů nedávat, ať si to ošetří renderer, zas taková věda to snad není.
    Tohle mi přijde hrozně lokální pohled na problematiku (podobně jako spousta jiných věcí co se zde na listu řeší). Já bych rád aby se české názvy rozumě zalamovaly a zobrazovaly i v rendereru který si napíše třeba Japonec. Někdo mimoevropský nebude vůbec řešit jaké tu v Česku máme typografická pravidla. Zkuste u nějakého renrereru na githubu vytvořit issue že se nějaký český název špatně zobrazuje a že si to přeci může vyřešit. Taková věda to přeci není. Ještě těch chudákům vývojářům můžete poradit že exituje probram "vlnka" který to přeci dokázal před deseti lety. Stejně tak já nedokážu posoudit jestli se arabské jméno hospody má vykreslit zleva doprava nebo zprava doleva a už vůbec (bez unicode hitnů) nedokážu napsat renderer kde arabský název obsahuje číslovku! Otevřete trochu svoji mysl a myslete prosím za hranice českého rybníčku. Lukáš
  51. Michal Fabík michal.fabik na gmail.com #m495441
    2018-01-24 22:17 GMT+01:00 Lukáš Karas <lukas.karas na centrum.cz>:
    Jinak za mě taky nedělitelné mezery do tagů nedávat, ať si to ošetří renderer, zas taková věda to snad není.
    Tohle mi přijde hrozně lokální pohled na problematiku (podobně jako spousta jiných věcí co se zde na listu řeší). Já bych rád aby se české názvy rozumě zalamovaly a zobrazovaly i v rendereru který si napíše třeba Japonec. Někdo mimoevropský nebude vůbec řešit jaké tu v Česku máme typografická pravidla. Zkuste u nějakého renrereru na githubu vytvořit issue že se nějaký český název špatně zobrazuje a že si to přeci může vyřešit. Taková věda to přeci není. Ještě těch chudákům vývojářům můžete poradit že exituje probram "vlnka" který to přeci dokázal před deseti lety. Stejně tak já nedokážu posoudit jestli se arabské jméno hospody má vykreslit zleva doprava nebo zprava doleva a už vůbec (bez unicode hitnů) nedokážu napsat renderer kde arabský název obsahuje číslovku!
    Tohle mně zas přijde jako argumentace nefungující, neřkuli přímo záměrně zlomyslnou, komunikací mezi uživatelem a autorem rendereru. Přece když budu chtít, aby si japonský renderer správně poradil s nějakým obskurním aspektem české typografie, tak autorovi neřeknu: "V českých názvech máte špatně pevné mezery, spravte si to, tohle si přece můžete vyřešit, vlnka to umí taky". Naopak, vysvětím, proč je to důležité, popíšu jednotlivá pravidla, dám příklady, třeba ukážu _jak_ to ta vlnka dělá (a ne, že už to dělá deset let). Podobně, až budu mít ve svém rendereru problém se zobrazováním arabštiny, zeptám se někoho, kdo umí arabsky. Asi to vidím naivně, ale s jazykovými daty pracuju a přesně taková komunikace je pro mě naprosto normální a v podstatě nevyhnutelná. Podle mě prostě ty pevné mezery jsou tagging for the renderer. Pevná mezera slouží ke správnému _zobrazení_, tj. renderingu, žádnou věcnou informaci nenese.
  52. Petr Slavíček, Bc. pslavicek na seznam.cz #maddd75
    Mapovat pro render se nesmí (teda nemělo by), ale psát text pro render se smí? "Petr
  53. Mikoláš Štrajt strajt9 na seznam.cz #m6e30e3
    "Tohle mi přijde hrozně lokální pohled na problematiku (podobně jako spousta jiných věcí co se zde na listu řeší). Já bych rád aby se české názvy rozumě zalamovaly a zobrazovaly i v rendereru který si napíše třeba Japonec. Někdo mimoevropský nebude vůbec řešit jaké tu v Česku máme typografická pravidla. Zkuste u nějakého renrereru na githubu vytvořit issue že se nějaký český název špatně zobrazuje a že si to přeci může vyřešit. Taková věda to přeci není. Ještě těch chudákům vývojářům můžete poradit že exituje probram "vlnka" který to přeci dokázal před deseti lety. Stejně tak já nedokážu posoudit jestli se arabské jméno hospody má vykreslit zleva doprava nebo zprava doleva a už vůbec (bez unicode hitnů) nedokážu napsat renderer kde arabský název obsahuje číslovku! Otevřete trochu svoji mysl a myslete prosím za hranice českého rybníčku." Jenomže autor rendereru/stylu musí myslet zároveň globálně i lokálně. Musím mít kupříkladu vyřešeny fonty - můžu mít například nějaký primární font, který se mi líbí vzhledem, ale pak musím mít fallback pro arabštinu/ čínštinu/cyrilici. Dále pak může provádět transliteraci nepřeložených názvů (jako to dělá německý styl na https://www.openstreetmap.de/karte.html). Tohle je v praxi celkem užitečné - když neumím azbuku a chci studovat mapu nějakého ruského města, hned se líp zorientuju. V neposlední řadě se často děje, že se názvy na mapě zobrazují v jazyce toho, kdo si mapu prohlíží/provozuje. Mapy.cz zobrazují mapu světa s českými názvy, Kosmosnimki zase s ruskými. Další věc je, že ne všechny typografický/kartografický vychytávky jdou provést ve všech jazycích - kupříkladu mapy.cz mají části obce napsané caps lockem (ŘEPORYJE) oproti samostatným obcím, které jsou bez caps locku (Ořech). Tohle ale jde udělat jen v jazycích, které rozlišují velká a malá písmena. * * * Jinak "cartography labeling" je samostatná věda. A správné vykreslování Unicode je další samostatná věda.
  54. Lukáš Karas lukas.karas na centrum.cz #m5ef514
    Ano, řekl bych že je žo naivní pohled. Pevné mezery automaticky nepřidají ani webové prohlížeče za kterými stojí obrovské týmy vývojárů. Proto je potřeba je v datech mít - jak ve webových stránkách i OpenStreetMap. Pokud tvrdíš že se jedná pro tagování pro renderer, protože to slouží pouze ke správnému zobrazení, tak mi tedy vysvětli proč píšeme velká písmena na záčátku názvů a po předložkách? To taky slouží jen ke správnému zobrazební. Vždyť v datech může bez problémů být "kralupy nad vltavou", "na poříčí". To že tam někde mají být velká písmena si přeci může domyslet renderer... Lukáš
  55. Mikoláš Štrajt strajt9 na seznam.cz #mf5cc06
    jak tahle debata pokračuje dál, začínám mít chuť napsat program vlna pro mapnik, abych dokázal, že to jde. ;-)
  56. Matěj Cepl mcepl na cepl.eu #me09764
    Mapovat pro render se nesmí (teda nemělo by), ale psát text pro render se smí?
    Přesně tak. Rozdíl je v tom, že rendererů je mnoho a ještě mnoho jich vznikne a nechceme dělat data, tak aby jeden konkrétní to zvládnul a ostatní ne. Množství rendererů, které pracují s přetahováním předložek na novou řádku? 0 A v budoucnosti takových rendererů vznikne? Hádám, že taky nula. Množství rendererů, kterým se ublíží když budou mít nedělitelnou mezeru v názvu? Nevím, ale řekl bych že se to také bude limitně blížit nule. Matěj
  57. Michal Fabík michal.fabik na gmail.com #m206e21
    2018-01-25 9:45 GMT+01:00 Lukáš Karas <lukas.karas na centrum.cz>:
    Ano, řekl bych že je žo naivní pohled. Pevné mezery automaticky nepřidají ani webové prohlížeče za kterými stojí obrovské týmy vývojárů. Proto je potřeba je v datech mít - jak ve webových stránkách i OpenStreetMap.
    Je potřeba je mít v datech, protože nějaké obrovské týmy nějakých vývojářu v nějakém úplně nesouvisejícím projektu fungujícím podle jiných pravidel něco nedělá? No dobře. Navíc se IMHO nedá srovnávat prohlížeč (který počítá s tím, že do něho může být nalito prakticky cokoliv, včetně textů, u kterých se dá jen těžko určit jazyk, ve kterém jsou napsány) a OSM renderer, který může počítat s až puntičkářsky systematizovanými daty.
    Pokud tvrdíš že se jedná pro tagování pro renderer, protože to slouží pouze ke správnému zobrazení, tak mi tedy vysvětli proč píšeme velká písmena na záčátku názvů a po předložkách? To taky slouží jen ke správnému zobrazební. Vždyť v datech může bez problémů být "kralupy nad vltavou", "na poříčí". To že tam někde mají být velká písmena si přeci může domyslet renderer...
    Velká písmena jsou nositeli významu. "Černá Hora" je město, "Černá hora" se může jmenovat kdejaký kopec. V ulici, kde bydlím, je kadeřnictví, které se oficiálně jmenuje "Kadeřnictví" - s malým 'k' bych si řekl, že to tam nabouchal nějaký začátečník, který nechápe rozdíl name=* vs. amenity=* vs. description=*. Když uvidím víc velkých písmen vedle sebe, vím, že asi jde o zkratku, a tedy má smysl zjišťovat, jaký je oficiální plný název s rozvinutou zkratkou. Velké písmeno uprostřed slova obvykle znamená, že jde o nějakou moderní složeninu atd. Pevná mezera neříká naprosto nic o popisovaném objektu. Říká jen to, že tato mezera nemá být na konci řádku.
  58. Marián Kyral mkyral na email.cz #mddec85
    Mapovat pro render se nesmí (teda nemělo by), ale psát text pro render se smí?
    Přesně tak. Rozdíl je v tom, že rendererů je mnoho a ještě mnoho jich vznikne a nechceme dělat data, tak aby jeden konkrétní to zvládnul a ostatní ne. Množství rendererů, které pracují s přetahováním předložek na novou řádku? 0 A v budoucnosti takových rendererů vznikne? Hádám, že taky nula. Množství rendererů, kterým se ublíží když budou mít nedělitelnou mezeru v názvu? Nevím, ale řekl bych že se to také bude limitně blížit nule. Zajímavá debata, chvíli souhlasím s jedním, chvíli s druhým. Jak z toho ven? Napadá mně, jestli by nebylo lepší zavést nějakou speciální značku pro render. Když už máme značky pro navigaci a výslovnost. Marián
  59. Jan Macura macurajan na gmail.com #m8f0303
    2018-01-25 12:00 GMT+01:00 Michal Fabík <michal.fabik na gmail.com>:
    (...) OSM renderer, který může počítat s až puntičkářsky systematizovanými daty.
    Tak moc bych si nefandil. H.
  60. Jakub Jelen jakuje na gmail.com #m7bf5d7
    Originalni doraz byl, jestli pouzivat HTML entity &nbsp;, nebo ne. Podle me HTML entity by nemely byt v tagu name (i kdyz jsem to nenasel nikde explicitne zakazane, ani povolene, doporucovane nebo nedoporucovane). Nebo uz mame nejake pripady, kde se HTML entity v nazvu pouzivaji? Druha otazka je, jestli pouzivat nejakou unicode reprezentaci pro nedelitelnou mezeru, ktera by nevyzadovala, aby render interpretoval HTML entity. To mi prijde jako rozumnejsi moznost, pokud se neukaze, ze by s tim mohly byt nejake problemy s vyhledavanim, vyslovnosti, atd. Ale bez konkretniho pripadu, ukazky a zkusenosti je to stale pouze teoreticka diskuze, ktera nevede nikam s desitkami nazoru. Mnohem lepe by se rozhodovalo, kdyby v puvodnim emailu bylo nekolik odkazu na nejak konkretni priklady, ktere Matej zatim nasel, kde bychom si mohli vysledky prohlednout v zivych renderech, vyzkouset, jaka je pro ruzna reseni podpora, popripade kde se ktere rendery snazi neco zalamovat. Zde mluvime o nazvech ulic, ktere se kresli podel cary ulice. Pripad, kde by se to mohlo stat mi prijde pouze, kdyz mame velmi kratkou ulici, ale snazi se rendery v takovem pripade vubec jmena zalamovat? Mame nejaky priklad? V tu chvili, kdy budeme vymysleno co s temito daty, neni problem pouzit podobny program jako vlna, ktery hromadne zmeni, doporuci, nebo bude generovat varovani, ze v tomto miste pred touto jednoznakovou predlozkou by mela byt nedelitelna mezera. Jakub 2018-01-25 13:00 GMT+01:00 Jan Macura <macurajan na gmail.com>:
  61. Matej Lieskovský lieskovsky.matej na gmail.com #m8f1100
    @Jakub Jelen: Kdepak, nbsp zmiňuju jen jako relativně časté označení pro zmíněný Unicode znak, který se mi 1) nedaří do Gmailu zadat a 2) není moc dobře vidět. Relevantní dotaz pro Overpas Turbo: http://overpass-turbo.eu/s/vnx 2018-01-25 14:05 GMT+01:00 Jakub Jelen <jakuje na gmail.com>:
  62. Matej Lieskovský lieskovsky.matej na gmail.com #m741fc2
    Vypadá to, že minimálně osm.org nbsp řeší správně: https://www.openstreetmap.org/way/34942987#map=19/50.09373/14.46366 ukazuje, že nic typu "vlna" osm.org nepoužívá https://www.openstreetmap.org/node/3226473433#map=19/50.09439/14.34787 ukazuje, že nedělitelné mezery zobrazí správně (Tedy, alespoň to tak vypadá) U ostatních renderů jsem zatím nenašel vhodný případ. Ano, já hlavně řeším názvy ulic (kde je zalamování vzácné), ale otázka je prostá: chceme nbsp v datech, nebo nikoliv? Zatím to nevypadá, že bychom se měli shodnout. Aktuální stav je asi nejhorší možný: máme nbsp v datech, ale ne vždy a ani ne na celých ulicích najednou. Je někdo silně proti tomu, abych do vyřešení tohoto problému fungoval podle možnosti 4 a pak když tak ty mezery hromadně smazal? Budeme alespoň mít celé ulice se stejným názvem a nbsp se budou snadněji mazat, než zpětně doplňovat. Současně ale nbsp nebudu doplňovat tam, kde ji zatím žádný úsek ulice nemá. 2018-01-25 22:19 GMT+01:00 Matej Lieskovský <lieskovsky.matej na gmail.com>:
  63. Pavel Machek pavel na ucw.cz #mcb1626
    Ahoj!
    Vypadá to, že minimálně osm.org nbsp řeší správně: https://www.openstreetmap.org/way/34942987#map=19/50.09373/14.46366 ukazuje, že nic typu "vlna" osm.org nepoužívá https://www.openstreetmap.org/node/3226473433#map=19/50.09439/14.34787 ukazuje, že nedělitelné mezery zobrazí správně (Tedy, alespoň to tak vypadá) U ostatních renderů jsem zatím nenašel vhodný případ. Ano, já hlavně řeším názvy ulic (kde je zalamování vzácné), ale otázka je prostá: chceme nbsp v datech, nebo nikoliv? Zatím to nevypadá, že bychom se měli shodnout. Aktuální stav je asi nejhorší možný: máme nbsp v datech, ale ne vždy a ani ne na celých ulicích najednou. Je někdo silně proti tomu, abych do vyřešení tohoto problému fungoval podle možnosti 4 a pak když tak ty mezery hromadně smazal? Budeme alespoň mít celé ulice se stejným názvem a nbsp se budou snadněji mazat, než zpětně doplňovat. Současně ale nbsp nebudu doplňovat tam, kde ji zatím žádný úsek ulice nemá.
    Zpetne smazat i zpetne doplnit je stejne tezke -- ta mezera jde doplnit algoritmicky -- takze ano, jsem proti 4. (Protoze to rozbije hledani, protoze to neni v oficialnich seznamech, protoze je to tagovani pro renderer, protoze to rozbije lokalni programy snazici se pracovat s OSM daty, a protoze neviditelny znaky jsou skodoliba past na kohokoliv kdo se s timbude snazit pracovat.) DWG navrhovala zeptat se na tagging listu, to by asi byl dalsi rozumny krok. Pavel
  64. Matej Lieskovský lieskovsky.matej na gmail.com #m49d400
    Napsal jsem na Tagging. Očekávám flame za 3... 2... 1... Jen tak mimochodem: - hledání to nerozbije, Nominatim umí Unicode Collation - je to v cca polovině oficiálních seznamů, mimo jiné protože office to automaticky doplňuje - teoreticky by se za tagování pro renderer mohly považovat i velká a malá písmena v názvech ulic (OTG jsou celá velkými) - rozumně spolehlivé algoritmické doplnění bude řádově složitější než 100% spolehlivé algoritmické odstranění (leda že bys nám laskavě zveřejnil tvůj program na automatické doplňování nedělitelných mezer) Problém je v tom, že teď nejen že tam ty nedělitelné mezery občas jsou (takže co se má rozbít, to se rozbije), ale taky nejsou zdaleka všude (takže se občas něco renderuje ošklivě a člověka netrkne tak rychle, co se děje) a občas se dvě části TÉ SAMÉ ULICE liší v tom, zda mají nedělitelnou mezeru (takže se rozbije i to, co by jinak nedělitelné mezery zkouslo). 2018-01-26 0:17 GMT+01:00 Pavel Machek <pavel na ucw.cz>:
  65. Martin Mares mj na ucw.cz #mf3c237
    Hello, world! Osobně považuji za nejdůležitější pravidlo, že do primárních dat nepatří nic, co jde odvodit algoritmicky. Mimo jiné proto, že udržovat takové věci ručně obvykle vede k chaosu a jakmile je umíme udržovat algoritmicky, tak je tam už nemusíme ukládat :) Označování nedělitelných mezer je v tak jednoduchých českých textech, jaké se vyskytují na mapách, docela jednoduchá úloha. Navíc nevadí, když se tu a tam objeví nějaké false positives. Souhlasím, že nedává smysl, aby každý renderer musel ovládat pravidla pro české zalamování. Jenže renderery potřebují i spoustu jiných jazykově specifických znalostí, třeba pravidla pro transliteraci mezi abecedami. Proto by mi dávalo daleko lepší smysl ukládat toho do primárních dat co nejméně a napsat preprocesor, který bude umět tyto věci odvozovat a jehož výstup bude moci využít libovolný renderer. Ale opravdu se teď nenabízím, že ho napíšu :-) Mějte se skvěle
  66. Jan Macura macurajan na gmail.com #mcaa970
    Ahoj, 2018-01-27 19:36 GMT+01:00 Martin Mares <mj na ucw.cz>:
    Proto by mi dávalo daleko lepší smysl ukládat toho do primárních dat co nejméně a napsat preprocesor, který bude umět tyto věci odvozovat a jehož výstup bude moci využít libovolný renderer.
    To se mi zatím zdá jako nejrozumnější argument v této diskusi. A neexistuje třeba už nějaký takový preprocesor? Vybavuji si článek, ve kterém nějaký tým řešil, jak lépe zalamovat popisky v mapě (dokonce bych řekl, že to bylo pro OSM Carto), tak aby to vypadalo hezky. To s naším problémem jednopísmených předložek na koncích řádek docela souvisí. H.
  67. Matej Lieskovský lieskovsky.matej na gmail.com #m6b5247
    Opravdu chci vidět preprocesor, který zvládne rozpoznat "Dům V. Hálka" od "Jindřich V. Sálský" (fiktivní příklady). 2018-01-28 17:16 GMT+01:00 Jan Macura <macurajan na gmail.com>:
  68. Jan Macura macurajan na gmail.com #m57ef75
    2018-01-31 14:56 GMT+01:00 Matej Lieskovský <lieskovsky.matej na gmail.com>:
    Opravdu chci vidět preprocesor, který zvládne rozpoznat "Dům V. Hálka" od "Jindřich V. Sálský" (fiktivní příklady).
    V předmětu tohoto vlákna stále ještě stojí "Nedělitelné mezery v názvech ulic". Nic víc, nic míň. A na to jsem taky reagoval. H.
  69. Matej Lieskovský lieskovsky.matej na gmail.com #m309752
    Vždyť jo. V prvním případě má být nbsp za "V.", v druhém před. 2018-01-31 19:20 GMT+01:00 Jan Macura <macurajan na gmail.com>:
  70. Jan Macura macurajan na gmail.com #md55035
    2018-01-31 19:58 GMT+01:00 Matej Lieskovský <lieskovsky.matej na gmail.com>:
    Vždyť jo. V prvním případě má být nbsp za "V.", v druhém před.
    Aha, to mě nenapadlo. Chmno, tak ten by musel mít ten druhý řetězec uložený s Unicode znakem U+2164 ;-) H.
  71. Karel Volný kavol na seznam.cz #m2c5245
    2018-01-31 19:58 GMT+01:00 Matej Lieskovský <lieskovsky.matej na gmail.com>:
    Vždyť jo. V prvním případě má být nbsp za "V.", v druhém před.
    Aha, to mě nenapadlo. Chmno, tak ten by musel mít ten druhý řetězec uložený s Unicode znakem U+2164 ;-)
    ano, Jindřich [pátý] by takto mohl fungovat ovšem co takový Xindl [iks]? - hm, X není předložka ... a kdyby někdo vymyslel ulici na počest Anny [ká]? (aktuálně se sice na svém webu nazývá s tečkou, ale varianta bez tečky je též dosti rozšířená) přijde mi, že se tu furt vymejšlí rovnák na vohejbák ... *nikdy* to nebudeme mít 100% správně chápat různé druhy mezer obecně jako mezeru je triviální úložka, povětšinou již vyřešená, i ten blbej grep umí [:space:] vyvěštit z obecné mezery, jestli tam zrovna patří nsbp (popř. i něco jiného), je úložka hodná AI kvalitnější než průměrný maturant z češtiny, a vyřešená není - jistě, co se prvého týče, s jistou chybovostí se můžeme smířit, ale pak vzniká otázka, kdyby si někdo chtěl dát tu práci a docílit, aby ten program chyby nedělal, tak jaké má možnosti, nemá-li to být vázáno na konkrétní data? ... co mě napadá je seznam vyjímek, ale čeština má tu krásnou vlastnost, že by určitě brzy vyplulo něco, co se píše stejně, ale má různé významy, a tudíž ta vazba osamoceného písmene může být na obě strany prozradí nám někdo lepší řešení? - co se druhého týče, sice lze argumentovat existencí vlny apod., ale, jak zde již padlo, problém je, kdo to zaháčkuje do všech rendererů, co kdy vznikly a vzniknou? kdo bude nutit člověka na druhém konci světa implementovat nějakou specialitu pro zaprděnou desetimilionovou zemičku, když ani zde mezi zastánci odstranění nbsp se nenajde dobrovolník, co by ten preprocesor napsal? pozn. "renderer" se zde nemusí myslet jen vykreslování mapy, ale obecně cokoli, co když si třeba budu chtít adresy tisknout na obálky nebo jánevímco se dá nad OSM vymyslet, skutečně to všechno pokryjeme, aby to používalo ten (neexistující) preprocesor? obecně dobré pravidlo "nemapovat pro renderer" se zde dovádí ad absurdum, asi jako kdyby někdo řekl "pojďme odstranit u mostů layer, vždyť to se přece dá odvodit a existuje na to i pravidlo, renderer musí vědět, že cesta vede nad řekou" (hm, ne vždy) K.
  72. Martin Mares mj na ucw.cz #m6e8fc7
    Ahoj,
    *nikdy* to nebudeme mít 100% správně
    nebudeme. Stejně jako nebudeme mít 100% správně nic jiného. To je myslím lepší přijmout jako fakt, než investovat ohromné množství úsilí do něčeho, co bude mít místo 99% úspěšnosti 99.9%. Chci-li podle dat OSM vytvořit papírovou mapu, vyladím si ji do nejmenších detailů. To často znamená ručně předělávat algoritmická rozhodnutí i v daleko zásadnějších věcech než dělitelnost mezer: například je často potřeba ručně posunout nějakou značku, přemístit či zrušit popisek, nakreslit nějaký objekt mimo měřítko atd. Je to spousta práce, ale výsledek stojí za to. Na druhou stranu, u online mapy zobrazující data, která lidé pořád upravují, je taková snaha o dokonalost spíše škodlivá -- nedokonalosti v datech budou celkovému dojmu škodit víc než nedokonalosti v prezentaci. Proto je důležitější udržet editaci dat co nejjednodušší, i kdyby to stálo o zlomek procenta vyšší pravděpodobnost chybné prezentace. Have a nice fortnight
  73. Matej Lieskovský lieskovsky.matej na gmail.com #m6c1e71
    Co přesně se na editaci zkomplikuje, když budeme podporovat nedělitelné mezery? To, že na to budeme muset myslet, když budeme psát dotaz do Overpassu? Podobnými argumenty budeme za chvíli zase všude mazat diakritiku. 2018-01-31 22:16 GMT+01:00 Martin Mares <mj na ucw.cz>:
  74. Matej Lieskovský lieskovsky.matej na gmail.com #m017bea
    Diskuze na Tagging už celkem odezněla. Klidně se na ni podívejte, ale přijde mi, že celkem výrazná většina zastávala názor, že nástroje mají už dávno umět Unicode collation a že typografické nápovědy jsou v datech spíše žádoucí. Zatím jsem neslyšel o ničem, co by se doslova rozbíjelo (Overpass Unicode collation nedělá schválně a mám nápad, co s tím) a taky se neozval nikdo, kdo by byl ochoten napsat ten "jednoduchý" preprocesor. My jsme cca půl na půl, DWG to nevetovalo a Tagging je pro - myslím si, že nedělitelné mezery jsou tudíž akceptovatelné. Pokud se většinový názor změní, nebude problém ty mezery zase smazat. ToDo: - Overpass by mohl získat režim, kdy zadanou hodnotu přeloží na regex simulující Unicode collation - Editorům by prospělo zvýrazňování whitespace Začátek diskuze na Tagging: https://lists.openstreetmap.org/pipermail/tagging/2018-January/034986.html Ať se daří! Matej PS: Doporučuju http://www.babelstone.co.uk/Unicode/whatisit.html 2018-02-01 0:56 GMT+01:00 Matej Lieskovský <lieskovsky.matej na gmail.com>:
  75. Mirek Dlask dlask.m na gmail.com #m6f4dca
    Ahoj, jsem pro 1). Nedělitelné mezery mají více nevýhod, než výhod. Navíc jsem od známé dostal takovou drobnou prosbu, snad se sem hodí. S hrůzou jsem zjistila, že už nebydlím v ulici T. G. Masaryka. Aniž bych se složitě stěhovala, bydlím v ulici Tomáše Garrigue Masaryka. Naštěstí se nezbláznilo město, ale pouze mapa, kterou si mi doporučil. Už jsem začala vymýšlet, co s dokladama, abych nemusela na úřady. ..... Můžeš zjednat nápravu? ..... Z tégémasaryka zdraví ............ Rád bych odpověděl a nevím co. Je to chyba, nebo schválený, chtěný stav? Na wiki jsem našel pouze toto. Ustálené zkratky Nepoužíváme ustálené zkratky "nám.", "ryb.". Způsobují problémy při vyhledávání objektu. Ani zmínka o tom, že by se neměly používat zkratky křestních jmen. Něco jsem přehlédl? Ať se podívám na mapy.cz nebo na google.cz/maps zkratky používají. Jak to ti čerchmanti dělají, že nemají "problémy při vyhledávání objektů"? Mirek Dne 17. ledna 2018 13:49 Matej Lieskovský <lieskovsky.matej na gmail.com>
  76. Matej Lieskovský lieskovsky.matej na gmail.com #med40f8
    Ahoj! Zkratky jmen v názvech ulic jsou asi trochu jiné téma, ale určitě to chce se na ně podívat. Co se týče nedělitelných mezer, tak: 1) Zatím jediné dvě mně známé nevýhody jsou "budeme muset dělat Unicode collation" (což je argument i pro odstranění nabodeníček) a "blbě se to zadává" (tak to holt většina nebude zadávat). Filozofické argumenty typu "nepatří to do dat" a "napíšeme na to preprocesor" zatím nedodaly onen triviální preprocesor. 2) Aktuálně mají mírnou převahu lidi pro odstranění, každopádně už jsem s tím (na popud tohoto talku) prudil DWG (těm je to fuk) a globální Tagging (kde jsou spíše pro nedělitelné mezery). Jakou zásadní nevýhodu jsem zatím neslyšel? Máš ten preprocesor? (Sorry, pokud zním trochu hrubě, spěchám) Ať se daří, Matej 2018-02-12 14:14 GMT+01:00 Mirek Dlask <dlask.m na gmail.com>:
  77. majka majka.zem+talk na gmail.com #m805ee0
    2018-02-12 14:14 GMT+01:00 Mirek Dlask <dlask.m na gmail.com>:
    S hrůzou jsem zjistila, že už nebydlím v ulici T. G. Masaryka. Aniž bych se složitě stěhovala, bydlím v ulici Tomáše Garrigue Masaryka
    Tohle krásně ilustruje, jak jsou zavedené konvence odtrhnuté od skutečného stavu, alespoň v ČR. Vychází se totiž víceméně z toho, že oficiální jméno je plný název bez zkratek. Což u nás ani vzdáleně neplatí. Teoreticky, pokud se nepletu: V OSM by mělo být rozepsané celé (nepoužívejte zkratky <https://wiki.openstreetmap.org/wiki/Cs:N%C3%A1zvy#Zkracov.C3.A1n.C3.AD_.28ned.C4.9Bjete_to.29>) a ten zkrácený název by byl v official_name <https://wiki.openstreetmap.org/wiki/Cs:Key:name> Ovšem pak to vede přesně k tomuhle problému - že se na mapě zobrazí jméno, a člověk se diví, kde že to najednou bydlí. Prakticky, a přiznávám se k tomu bez mučení: do jména dávám ty "official_name" vč. zkratek, a rozepisuji alt_name, short_name, sorting_name, pokud jsou třeba. Majka
  78. Jan Dudík jan.dudik na gmail.com #mb7b59f
    Jo, toť otázka. https://openstreetmap.cz/#map=18/48.96086/14.47347&layers=d vs. https://openstreetmap.cz/#map=18/48.96086/14.47347&layers=x vs. https://mapy.cz/s/2okEA a http://www.c-budejovice.cz/nazvy-budejovickych-ulic --- Ing. Jan Dudík projekce dopravních staveb tel. 777082195
  79. Petr Vozdecký vop na seznam.cz #m4dd529
    Ahoj, začal bych u toho odkazu, který Majka postovala na wiki: "V OSM by mělo být rozepsané celé (nepoužívejte zkratky )". Článek je totiž zjevně překladem anglického originálu a kapitola s původním názvem "Abbreviation (don't do it)" podle mě popisuje to, že mapper nemá automaticky používat zkratky tam, kde je vidí na ceduli a má si zjistit skutečný celý název. Pro diskutované případy s názvy T.G.M. atd. to v českých podmínkách dle mého platí asi do té míry, že nelze slepě napsat zkratku názvu ulice jen proto, že "kratší je to přehlednější", případně "bylo to na ceduli", ale je správné jako název zvolit oficiální název (zde je asi rozhodující názor obce, byť jsem tu vícekrát četl, že komunita upřednostňuje data z RÚIAN). No a Majka asi vcelku správně vidí jako vhodné doplnit databázi OSM o nezkrácené názvy. Otázkou je, které názvy do kterých tagů. Na wiki totiž čtu, že name_official je určen pouze pro názvy států... vop
  80. Jan Sten Adámek sten na adamek.online #md5ea33
    Ahoj, já dávám do name plný název (bez jakýchkoliv zkrácenin, podle Wiki) a do short_name zkrácený tvar, takže to Nominatim najde i podle krátkého tvaru. IMO je to stejné, jako když název v RÚIAN používá ?nám.?, ?tř.? nebo ?nábř.?. Mapy.cz i Google mají asi nějakou tabulku pro plná jména, která nezobrazují, protože je umí vyhledávat a přitom se nenechají zmást chybnými jmény: ?Karla Jaroslava Mašky? najde K. J. Mašky, Blansko, ale ?Karla Jaromíra Mašky? již ne. Ale vypadá to na (polo-)automaticky generovanou tabulku, protože obsahuje (pro ruční zpracování) očividné chyby: třeba ?Jarmily Václava Živcových? je na Mapy.cz nutné zadat bez ?a? mezi křestními jmény (J. V. Živcových, Rudná), ale opět se nenechá zmást a nenajde ?Jaroslavy Václava Živcových?; Google tohle jméno ulice nejspíš nedokázal rozluštit, protože se mi jej nepodařilo najít jinak než zkrácené. official_name by asi také šlo použít, ale to je IMO spíš pro případy, kdy oficiální jméno obsahuje navíc slova, která se běžně v name neuvádí (třeba ?Kostel svatého Jiří? pro name ?svatý Jiří?), ne pro rozepisování zkratek. Při editaci OSM jsem již také viděl klíč long_name, ale ten není dokumentovaný ani podporovaný Nominatimem. Sten
  81. majka majka.zem+talk na gmail.com #m7c48c6
    Problém je, že ty ulice se dlouhým názvem nejmenují a žádná zkratka to není. Tím dlouhým názvem se na tu ulici nemáte šanci doptat - všichni místní budou přemýšlet, o čem to mluvíte. Je to specifický případ, který by se měl i v datech ukázat, nehledě na heslo "rozepisujte zkratky". Nechcete mi snad říct, že je nutné opravit třeba tohle <https://www.openstreetmap.org/node/24569684#map=19/50.07446/14.43052>. 2018-02-12 22:23 GMT+01:00 Jan Sten Adámek <sten na adamek.online>:
  82. Mirek Dlask dlask.m na gmail.com #mfb626b
    Preprocesor nemám, vystačil bych si s převodní tabulkou. Přesvědčil bych nějakého renderistu, aby si z převodní tabulky udělal UPDATE ..... SET name .... FROM ...... a posoudil bych, jestli výsledek odpovídá vynaloženému úsilí. Pokud ano, stejnou cestou bych 'svoji pravdu' šířil dál. Nevím jak to máš vymyšleno ty. Co když ti do mapy přidám novou odbočku. To ji chceš "ručně" upravit a přidat do relace? Obavu mám ještě z něčeho jiného. Jak dlouho to hodláš vydržet a co potom? V neposlední řadě mi vadí další narušení vazby mezi názvem ulice a názvem ulice na adresních bodech. Ale chápu moje řešení je moc jednoduché. Ty potřebuješ naštvat co nejvíc lidí, udělat okolo co největší humbuk, a nakonec všechno urovnat, aby ses moh v sívíčku poplácat po ramenou jakej seš pašák. Dne 12. února 2018 14:33 Matej Lieskovský <lieskovsky.matej na gmail.com>
  83. Mirek Dlask dlask.m na gmail.com #m7e7af1
    Díky Majko za odkaz a nakonec i za tu I. P. Pavlova. Vážně jsem za svůj už poměrně dlouhý život, neslyšel o nikom kdo by místo ípé Pavlova mluvil o náměstí Ivana Petroviče Pavlova. Nevím co na to cizinec, který přijde metrem na I. P. Pavlova a naráz se ocitne na náměstí s podivným dlouhým jménem. Dovolím si tvrdit, že většina evropanů zná lépe slintající psa pana Palova, než jeho křestní jména.
  84. Jan Sten Adámek sten na adamek.online #m8478ac
    Problém je, jak to do OSM zapsat. Dovedu si dobře představit, že třeba nábř. Kpt. Jaroše v Jičíně bude někdo hledat jako nábřeží Kapitána Jaroše, protože v Praze se jmenuje takhle (a naopak), a tak by to OSM mělo umět najít. Podle Wiki je name pro plnou formu, kratší forma patří do short_name a žádný long_name není, ale jestli se v ČR ustaví jiná konvence, která bude rozumně fungovat (prosazení long_name či display_name asi není realistické, official_name by bylo spíš pro tu krátkou formu ? ta je ta oficiální, možná alt_name?), tak klidně budu používat tu. A taky je otázka, jak řešit TTS, protože pokud bude v name nábř. Kpt. Jaroše, tak to přečte fakt příšerně (viz pravidlo u name, že zkracovat se dá při zpracování dat snadno, ale doplňovat ne; name:pronunciation je reálně nepoužitelné). Takže možná v name rozepisovat zkratky s výjimkou iniciál (které se často čtou jako iniciály), tedy T. G. Masaryka nechat s plným jménem v jiném tagu (alt_name?), ale Masarykovo nám. rozepsat jako Masarykovo náměstí a zkrácenou formu dát do official_name nebo short_name?
  85. majka.zem+talk na gmail.com majka.zem+talk na gmail.com #mda2dfd
    Problém je, jak to do OSM zapsat. Dovedu si dobře představit, že třeba nábř. Kpt. Jaroše v Jičíně bude někdo hledat jako nábřeží Kapitána Jaroše, protože v Praze se jmenuje takhle (a naopak), a tak by to OSM mělo umět najít.
    Musela bych se podívat jak jsem přesně zadávala tu Pražskou v ČB, ale hledání funguje i podle alt_name (Pražská třída), short_name (Pražská) a loc_name. Mám pocit, že jsem dávala ještě nějaké "name" navíc. Takhle umí hledat jak Nominatim, tak i třeba Osmand. TTS je věc druhá - "lepší" ty běžné zkratky umí (tř. =třída), nebo je umí nadefinovat v místě (mobilu). Ideální by ale bylo to nadefinovat do tagu pro výslovnost, který se taky řeší. Netuším, jestli už je u něj shoda a/nebo se běžně užívá. Nedávno tu proběhl odkaz na debatu na francouzském talku, kde to probírali.
Napsat odpověď e-mailem… Odpovědět

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