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.ma...@gmail.com>: > @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 <jak...@gmail.com>: >> Originalni doraz byl, jestli pouzivat HTML entity , 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 <macura...@gmail.com>: >>> >>> 2018-01-25 12:00 GMT+01:00 Michal Fabík <michal.fa...@gmail.com>: >>>> >>>> (...) OSM renderer, který může počítat s až >>>> puntičkářsky systematizovanými daty. >>> >>> >>> Tak moc bych si nefandil. >>> >>> H. >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-cz >> _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
