dibavod: vodní toky uvnit? vodních ploch

31 zpráv
Zpět na přehled

dibavod: vodní toky uvnit? vodních ploch

31 zpráv MPSMKMTA 12 účastníků 20 min čtení
  1. Stanislav Brabec utx na penguin.cz #me7461b
    Všiml jsem si, že na mapě vodní toky pokračují i uvnitř rybníků. Domníval jsem se, že dibavod je natolik chytrý, a mapuje i vypouštěcí kanály. Ale není tomu tak. Při porovnání s ortofoto jednoho vypuštěného rybníku to vůbec nesedí, přestože části toku mimo rybník jsou správně. Zdá se, že tyto podvodní toky jsou všude, a že jde o zcela falešná data, že to prostě jen náhodně protáhli, aby data byla spojitá. Pokud je zde někdo pokročilejší, možná by nebylo od věci tyto podvodní toky smazat, a zajistit napojení dibavod na příslušný rybník (což naopak většinou chybí). Ukázka: http://www.openstreetmap.org/?lat=49.0742&lon=14.7411&zoom=13&layers=M
  2. "Petr Morávek [Xificurk]" xificurk na gmail.com #m64c09d
    Všiml jsem si, že na mapě vodní toky pokračují i uvnitř rybníků. Domníval jsem se, že dibavod je natolik chytrý, a mapuje i vypouštěcí kanály. Ale není tomu tak. Při porovnání s ortofoto jednoho vypuštěného rybníku to vůbec nesedí, přestože části toku mimo rybník jsou správně.
    Ono asi záleží jak kde...
    Zdá se, že tyto podvodní toky jsou všude, a že jde o zcela falešná data, že to prostě jen náhodně protáhli, aby data byla spojitá. Pokud je zde někdo pokročilejší, možná by nebylo od věci tyto podvodní toky smazat, a zajistit napojení dibavod na příslušný rybník (což naopak většinou chybí).
    Tenhle "problém" byl zanesen do renderování mapy na hlavní stránce OSM v http://trac.openstreetmap.org/changeset/24983/applications/rendering/mapnik/inc/layer-water.xml.inc Bohužel to bylo zaneseno do stylů tak nešťastně, že ten bílý obrys se renderuje všude, tj. i v rybnících a napojeních na řeky s vyznačeným břehem. Imho by měla v případě potoků zůstat vyznačena cesta i skrze rybníky (byť něpřesně), protože ten potok tamtudy skutečně protéká. Petr
  3. Mike mike na mikecrash.com #mf2c0d9
    Ale on neprotéká, on se do rybníka vlévá a z rybníka jde nový potok, i když má stejné jméno. Navíc občas hlavně u větších rybníků, kde je hodně přítoků, je tam příšerný nic neříkající uzel. Osobně je mažu a zakončuju potok na hraně vodní plochy. Vždy se to tak dělalo, tak proč to měnit.
  4. Marek Prokop marek na sovavsiti.cz #m598376
    Ahoj, 2011/2/24 Mike <mike na mikecrash.com>:
    Osobně je mažu a zakončuju potok na hraně vodní plochy.
    Dělám totéž. Zdraví, Marek
  5. jzvc jzvc na tpfree.net #m6265b9
    Ahoj, 2011/2/24 Mike <mike na mikecrash.com>:
    Osobně je mažu a zakončuju potok na hraně vodní plochy.
    Dělám totéž. Zdraví, Marek
    Viz predchozi, to je celkem zasadni chyba, protoze a) rybnik vzdy existuje v miste, kde proteka potok, nikoli naopak b) vodni tok je spojita vec, a pokud budete chtit napriklad podle vodniho toku navigovat nebo resit jine automaticke ulohy, tak jeho preruseni jsou problem - vodni tok nekde zacina a nekde konci (vlitim se do jineho nebo do more) Takze rozhodne neprerusovat u ruznych nadrzi. To ze to v ty hromade vody vede jinudy nez by pripadne tekla voda pri vypusteny nadrzi je naprosto nepatrny problem. Ja naopak pokud na to nekde narazim, tak potoky spojuju.
  6. Mike mike na mikecrash.com #m57a11b
    Mazal jsem je proto, že to tak je všude a zavedený postup. Souhlasím s tím, že je dobré mít celý strom řeky a změnit zavedený postup, ale dodávám - je dobré mít označené, kde je to opravdu řeka a kde je to nádrž. Už kvůli tomu, aby se to nechalo zjistit jednoduše dotazem do OSM a ne nějakým složitým algoritmem. Ale jak to tak bývá, lidé se prostě domluvit nechtějí a tak někdo to bude tagovat jako řeku i pod nádrží, jiný to bude mazat, v nejhorším se o to budou přetahovat, měnit si to navzájem a nikam to nepovede. Programátoři ať se s tím poperou po svým, přestože jim to přidělá práci jim i procesoru, nikoho jiného to nezajímá. Kompromis nikdo udělat nechce. Já ho navrhl a byl smeten ze stolu. Navrhuji, aby každý dal své řešení, napsal pro a proti a z uvedených variant se hlasováním jedna vybere, ta se pak pokusí prosadit do OSM celosvetově. Zopakuji můj návrh: 1. Dělat relaci toku, která bude obsahovat všechny elementy (klidně i včetně nádrží a přítoků) - pak se jedním dotazem získá celý tok 2. části, kde je tekoucí a ničím nepřekrytá řeka (kromě riverbank) značit jako waterway=stream/river/... tak jak je to dosud 3. části uvnitř rybníka/nádrže označit jiným tagem či dodatkem tagu ke stávajícím, který renderer může ignorovat bez toho, aby musel hledat všechny vodní plochy (podobně je to třeba u relací a role=inner/outer, které se také v podstatě uvádět nemusí, přesto se uvádí).
  7. Stanislav Brabec utx na penguin.cz #m637ba3
    Mike píše v Po 07. 03. 2011 v 21:41 +0100:
    Mazal jsem je proto, že to tak je všude a zavedený postup. Souhlasím s tím, že je dobré mít celý strom řeky a změnit zavedený postup, ale dodávám - je dobré mít označené, kde je to opravdu řeka a kde je to nádrž. Už kvůli tomu, aby se to nechalo zjistit jednoduše dotazem do OSM a ne nějakým složitým algoritmem. Ale jak to tak bývá, lidé se prostě domluvit nechtějí a tak někdo to bude tagovat jako řeku i pod nádrží, jiný to bude mazat, v nejhorším se o to budou přetahovat, měnit si to navzájem a nikam to nepovede. Programátoři ať se s tím poperou po svým, přestože jim to přidělá práci jim i procesoru, nikoho jiného to nezajímá. Kompromis nikdo udělat nechce. Já ho navrhl a byl smeten ze stolu.
    Spíš by bylo dobré, kdyby se s tím nějaký schopný geoprogramátor popral, průsečíky spočítal jednou (přidal heuristiku, která by jej vytvořila, pokud přítok končí méně než dejme tomu 10 m od vodní plochy) a podvodní části nechal přetagovat automaticky, a to vše nahrál do OSM. Dělat to ručně by byla obrovská práce.
    Navrhuji, aby každý dal své řešení, napsal pro a proti a z uvedených variant se hlasováním jedna vybere, ta se pak pokusí prosadit do OSM celosvetově. Zopakuji můj návrh: 1. Dělat relaci toku, která bude obsahovat všechny elementy (klidně i včetně nádrží a přítoků) - pak se jedním dotazem získá celý tok
    To je logické a dělá se to už i dnes.
    2. části, kde je tekoucí a ničím nepřekrytá řeka (kromě riverbank) značit jako waterway=stream/river/... tak jak je to dosud 3. části uvnitř rybníka/nádrže označit jiným tagem či dodatkem tagu ke stávajícím, který renderer může ignorovat bez toho, aby musel hledat všechny vodní plochy (podobně je to třeba u relací a role=inner/outer, které se také v podstatě uvádět nemusí, přesto se uvádí).
    To je také poměrně logické, pokud práci nechceme nechat na rendereru (vodní plochy by se kreslily později). Ještě je otázka, co s riverbank v místě vodní plochy (napojit k ploše?, protáhnout?). Dále stojí otázka, zda by měly části uvnitř rybníka obsahovat tag name. Pokud ano, asi by se neměl vykreslovat. Nejsem proti. Sice jsem původně navrhoval opak (podvodní toky smazat), ale toto má svou logiku a zjednoduší geoprogramování.
  8. MP singularita na gmail.com #me5713a
    Spíš by bylo dobré, kdyby se s tím nějaký schopný geoprogramátor popral, průsečíky spočítal jednou (přidal heuristiku, která by jej vytvořila, pokud přítok končí méně než dejme tomu 10 m od vodní plochy) a podvodní části nechal přetagovat automaticky, a to vše nahrál do OSM. Dělat to ručně by byla obrovská práce.
    Nejdřív bychom se asi měli dohodnout na tom, jaký má být cílový stav a pak teprve přemýšlet jak se do něj dostat. Předpokládám, že se všíchni asi shodneme, že části "pod vodou" (v rybníce, přehradě), pokud by měly zůstat, tak je musí být možné odlišit od částí tekoucích nad vodou, a to pokud možno bez toho, aby se počítaly průsečíky Jakmile se na tom dohodneme, tak se může jednak začít přetagovávat, jednak to zapsat na wiki a jednak šťouchat do rendererů aby to renderovali podle nového schématu. Takže návrhy: 1. smazat části pod vodou. + "vyřeší" se problémy s rendererem - tok je nespojitý - nelze zjistit strom toku, délku řeky - ztratí se data která se někomu hodí 2. přetagovat části pod vodou, stylem waterway=underwater_route (nebo něco podobného, jakmile vybereme variantu, tak se už pak nějak dohodneme na vhodném názvu tagu), případně s přidaným tagem underwater_route=river|stream + renderer to přestane zobrazovat + tok je spojitý strom - je třeba naučit nástroje novému tagu 3. přetagovat části pod vodou, waterway nechat a přidat tag underwater_route=yes - nutno naučit renderery aby to nezobrazovali, nebo zobrazovali jinak + tok je spojitý strom Osobně jsem pro variantu 3. K 2 a 3 je pak otázka, jestli chceme (a jestli vůbec v praxi můžeme) nějak rozlišovat případy, kdy ten podvodní tok má správný tvar (odpovídající realitě, pokud by byla nádrž vypuštěna) a kdy ne (tedy je to jen odhad, protože jezero se za posledních pár století nevypouštělo)
    Dále stojí otázka, zda by měly části uvnitř rybníka obsahovat tag name. Pokud ano, asi by se neměl vykreslovat.
    Např. mosty na silnicích, což jsou krátké úseky kde je silnice obdobně "přerušena" tag name obsahují. Tedy bych asi name zachoval, rederery se naučí, že by ho asi spíš zobrazovzat neměly. Martin
  9. Pavel Pilát pavel.pilat na gmail.com #m0cf8ff
    Taky jsem pro variantu 3, je tak nějak - logická. River je to pořád, pouze se někde zpomalí (až téměř k nule, ale nula to není - v přehradě, v rybníku), rozšíří se - pak se zas zrychlí. Mnohdy opravdu nejde definovat, kde se voda začíná zvedat a tok se mění v přehradu, je to příliš pozvolné. Renderery se přizpůsobí (ostatně jak už bylo řečeno, to je základní myšlenka OSM, že se mapuje podle skutečnosti, nikoliv pro renderery) 2011/3/8 MP <singularita na gmail.com>
  10. "Petr Morávek [Xificurk]" xificurk na gmail.com #md0a41b
    Mazal jsem je proto, že to tak je všude a zavedený postup.
    Skutečně? To by mne tedy moc zajímalo, kde to "všude" je? Kde všude krom ČR proběhl takto kompletní import vodních toků a následně se ty části v nádržích mazali?
    dodávám - je dobré mít označené, kde je to opravdu řeka a kde je to nádrž. Už kvůli tomu, aby se to nechalo zjistit jednoduše dotazem do OSM a ne nějakým složitým algoritmem.
    Než se vrhnem do řešení "problému", chtělo by to odpovědět na základní otázku - a proč (k čemu) je to dobré? Jediný důvod ke změně, který tu zatím padl (a který to taky celé rozpoutal), je snaha opravit způsob vykreslování mapy v jednom konkrétním rendereru. Petr
  11. "Petr Morávek [Xificurk]" xificurk na gmail.com #mb823bd
    Předpokládám, že se všíchni asi shodneme, že části "pod vodou" (v rybníce, přehradě), pokud by měly zůstat, tak je musí být možné odlišit od částí tekoucích nad vodou, a to pokud možno bez toho, aby se počítaly průsečíky
    Asi tu budu za neskutečného rýpala, ale... proč? Navíc i když se tedy na tomto shodnem, tak je celkem problém definovat, co to znamená "pod vodou".
    Takže návrhy: 1. smazat části pod vodou. + "vyřeší" se problémy s rendererem - tok je nespojitý - nelze zjistit strom toku, délku řeky - ztratí se data která se někomu hodí 2. přetagovat části pod vodou, stylem waterway=underwater_route (nebo něco podobného, jakmile vybereme variantu, tak se už pak nějak dohodneme na vhodném názvu tagu), případně s přidaným tagem underwater_route=river|stream + renderer to přestane zobrazovat + tok je spojitý strom - je třeba naučit nástroje novému tagu 3. přetagovat části pod vodou, waterway nechat a přidat tag underwater_route=yes - nutno naučit renderery aby to nezobrazovali, nebo zobrazovali jinak + tok je spojitý strom
    Nazývejme věci pravými jmény - první plus má spíše znít: "vyřeší chybu _ve stylu_ pro renderování mapy na hlavní stránce OSM" Mapnik (renderer) to dokáže kreslit správně, pokud se mu dodá rozumný styl. Další věc je, že ani jeden z návrhů tuto chybu nevyřeší kompletně, stále zůstane problém s napojením potoků do širokých řek [1]. Návrh 4. nechat vodní toky jako spojitý strom stejně jako po importu + renderer se správným stylem bude kreslit všechno dle očekávání + zachová se spojitá stromová struktura vodních toků od pramene po jejich konec + není potřeba dodatečná lidská práce (krom níže uvedeného mínus) - někdo bude muset napsat patch pro ticket #3468 pro mapnik styl pro mapu na hlavní stránce OSM [1] http://www.openstreetmap.org/?lat=50.07622&lon=15.846349&zoom=18&layers=M Petr
  12. Mike mike na mikecrash.com #mbea13b
    Druhý důvod je ten, že pokud stáhnu relaci toku, tak poznám jedním XAPI dotazem, které části (a jejich délku) jsou nádrže a které jsou volně tekoucí bez toho, abych musel počítat průnik s vodními plochami, což už se musí řešit nějak programově. To je docela důležitá vlastnost.
  13. Mike mike na mikecrash.com #ma3f5dc
    Hezky vypsáno, jsem také pro variantu 3, možná bych ale ten tag zjednodušil na underwater=yes riverbank lze plynule navázat na reservoir, v tom není problém, rozlišení začátku jde vetšinou udělat snadno, v některých případech hůře - intuitivně, ale stejně povětšinou je toto již zakresleno/importováno. Ještě k argumentu, že rybník je tekoucí voda. Většinou není, protože výpust bývá velmi často nějakým přepadem klidně uprostřed rybníka do nějaké trubky, nejde o obyčejný jez. Naopak jez je většinou tekoucí, protože voda tam teče plynule, jak přiteče, tak i odteče, jde jen o umělé zvednutí hladiny a případnou regulaci výšky této hladiny - tam stačí riverbank. Naopak přehrada dokáže tu vodu zadržet zcela a reguluje se primárně odtok, ne hladina (ta je následkem rozdílu odtoku a přítoku). Jméno uvnitř plochy bych klidně nechal, i případné vyrenderování jména není na škodu.
  14. Stanislav Brabec utx na penguin.cz #m8c94fa
    "Petr Morávek [Xificurk]" píše v Út 08. 03. 2011 v 08:39 +0100:
    Předpokládám, že se všíchni asi shodneme, že části "pod vodou" (v rybníce, přehradě), pokud by měly zůstat, tak je musí být možné odlišit od částí tekoucích nad vodou, a to pokud možno bez toho, aby se počítaly průsečíky
    Asi tu budu za neskutečného rýpala, ale... proč? Navíc i když se tedy na tomto shodnem, tak je celkem problém definovat, co to znamená "pod vodou".
    V současném stavu je jedinou možností, jak poznat podvodní část toku, poměrně složitý algoritmus hledající průsečíky toku se všemi vodními plochami v okolí. Lodní routování na vodní plochu je pak nemožné, protože neexistuje spojnice mezi řekou a jezerem. Pokud budou spojnice existovat, vše půjde snadněji. Navíc tento algoritmus může najít chyby dibavod dat, kdy se chybou interpolace vodní tok a vodní plocha vůbec neprotínají.
  15. MP singularita na gmail.com #mc25fcd
    Předpokládám, že se všíchni asi shodneme, že části "pod vodou" (v rybníce, přehradě), pokud by měly zůstat, tak je musí být možné odlišit od částí tekoucích nad vodou, a to pokud možno bez toho, aby se počítaly průsečíky
    Asi tu budu za neskutečného rýpala, ale... proč? Navíc i když se tedy na tomto shodnem, tak je celkem problém definovat, co to znamená "pod vodou".
    "pod vodou" znamená uvnitř uzavřeného polygonu, který je podle definice jeho tagu vodní plochou (waterway=riverbank, landuse=reservoir, atd...)
    Nazývejme věci pravými jmény - první plus má spíše znít: "vyřeší chybu _ve stylu_ pro renderování mapy na hlavní stránce OSM"
    To není jen hlavní stránka OSM. Např. GPSMid (navigace pro mobily) tímhle trpí taky (jelikož by default vykresluje všechny liniové objekty až po plošných) a pokud ty kusy "pod vodou" nepůjdou pomocí tagů odlišit, tak to nepůjde ani spravit (styly tam definovatelné neumožňují pravidla typu "tam kde to protíná jiný polygon, renderuj jinak")
    Mapnik (renderer) to dokáže kreslit správně, pokud se mu dodá rozumný styl. Další věc je, že ani jeden z návrhů tuto chybu nevyřeší kompletně, stále zůstane problém s napojením potoků do širokých řek [1].
    To se může řešit stejně jako by se ten tok vléval do přehrady - poslední kus se označí že je "pod vodou".
    Návrh 4. nechat vodní toky jako spojitý strom stejně jako po importu + renderer se správným stylem bude kreslit všechno dle očekávání + zachová se spojitá stromová struktura vodních toků od pramene po jejich konec + není potřeba dodatečná lidská práce (krom níže uvedeného mínus) - někdo bude muset napsat patch pro ticket #3468 pro mapnik styl pro mapu na hlavní stránce OSM
    K tomu bych přidal možná malé mínus, že neinformovaní lidé mohou mít tendenci ty části uvnitř mazat, takže by se muselo asi do mnoha míst na wiki dopsat ať tak nedělají. Martin
  16. Marek Prokop marek na sovavsiti.cz #m9e1f0b
    K tomu bych přidal možná malé mínus, že neinformovaní lidé mohou mít tendenci ty části uvnitř mazat, takže by se muselo asi do mnoha míst na wiki dopsat ať tak nedělají.
    To není malé mínus. To je velké mínus. Nejde o mazání, ale o to, že prakticky všude, na celém světě (resp. kdekoli jsem se koukal) se vodní toky uvnitř vodních ploch nekreslí. Chápu, že u nás vznikla odlišná situace v důsledku importu, ale asi nemá smysl, abychom dělali tak důležitou věc zcela jinak než jinde. IMHO je proto stále nutné, aby došlo k nějakému "globálnímu" konsensu a správný postup se zanesl do Wiki, protože to je asi první místo, kam každý jde, když neví, jak co nakreslit. Zdraví, Marek
  17. Mike mike na mikecrash.com #m8914db
    Právě proto se chce teď na něčem domluvit, abychom prezentovali jednotný názor. Myslím, že to nikdo celosvětově nebude bojkotovat, je to rozumné řešení. Až se dohodnem, dáme to do proposed features na wiki.
  18. Tomáš Tichý t.tichy na post.cz #mdd0267
    Já jsem taky pro 3, ale nechápu proč chcete zavádět ten nový tag underwater? Na vyjádření toho že něco je pod něčím je přeci v OSM zaužívaný tag layer, tak proč vymýšlet něco nového? Každému musí být na pohled jasné, co se tím myslí i bez hledání obskurního lokálního tagu na wiki. Případně by se mohly přidat layer=-1 i underwater_route=yes pro účely odlišení podhladinních toků od toků v trubkách až bude někdo dělat ty vzývané analýzy délek toků. TT 2011/3/8 Mike <mike na mikecrash.com>
  19. Karel Volný kavol na seznam.cz #me6c3a3
    Já jsem taky pro 3, ale nechápu proč chcete zavádět ten nový tag underwater? Na vyjádření toho že něco je pod něčím je přeci v OSM zaužívaný tag layer, tak proč vymýšlet něco nového? Každému musí být na pohled jasné, co se tím myslí i bez hledání obskurního lokálního tagu na wiki.
    ehm, a co ponorné řeky apod.? nemůžu chtít mít v mapě průběh řeky v podzemí? - jak pomocí layer rozliším situaci "nezobrazovat, je to pod vodní hladinou" a "zobrazovat jako podzemní tok"? K.
  20. Jakub Sykora kubajz na kbx.cz #m90ffd0
    To IMO vyresi styl v mapniku...
  21. Karel Volný kavol na seznam.cz #m25c568
    To IMO vyresi styl v mapniku...
    a to jak? - bude řešit, jestli je to pod hladinou vodní plochy nebo pod něčím jiným? to jsem myslel, že se řeklo, že není optimální, aby hledal, jestli to leží v nějakém polygonu nebo ne ... nebo mi něco uniká? K.
  22. Tomáš Tichý t.tichy na post.cz #mda721b
    Vyřešit to lze zcela jednoduše, pomocí tagu tunnel=yes, případně covered=yes. Navíc nikde není psáno, že to co má layer -1 se nemá zobrazovat. Jak se objekt zobrazí je věcí konkrétního rendereru. Layer -x pouze vyjadřuje, že objekt je pod jiným objektem, rozhodně neznamená že je pod zemí (maximálně se dá usuzovat, že je pod úrovní okolního terénu). TT 2011/3/10 Karel Volný <kavol na seznam.cz>
  23. Mike mike na mikecrash.com #mae9bc3
    Ale zase to nevyřeší jiné situace - třeba ten dotaz na získání toku a zjištění celkové délky a délky nádrží.
  24. Aleš Janda openstreetmap na kyblsoft.cz #m8a1b16
    Netřeba nic počítat. Mapnik používá ?malířův algoritmus? - nakreslí všechno, přičemž pozdější objekty (ty co jsou výše) přepíšou všechny objekty níže. Už jsem k bugu [1] poslal patch, který vodstvo řeší konkrétně tím, že přesouvá vodní cesty pod plochy. Zkoušel jsem ho a pro náš případ funguje pěkně. Je k tomu však nějaká námitka ohledně vodních tunelů, nicméně brzy se snad dočkáme funkčního vykreslování. Ještě přesunout ty administrativní hranice do zvláštní vrstvy a bude se mi ten výchozí vzhled i líbit :-) Aleš Janda [1] http://trac.openstreetmap.org/ticket/3468
  25. Karel Volný kavol na seznam.cz #m367f94
    Netřeba nic počítat. Mapnik používá ?malířův algoritmus? - nakreslí všechno, přičemž pozdější objekty (ty co jsou výše) přepíšou všechny objekty níže.
    hm, takže pokud tomu rozumím správně, tak s "layer logikou" by les nebo vpodstatě jakýkoliv objekt musel mít -2, aby se přes něj vykreslil průběh ponorné řeky (pokud mě v mapě zajímá), která bude mít -1, protože je pod normálním povrchem v případě vodní plochy, řeka v ní bude mít tedy stále -1, a plocha bude mít 0, čímž dojde k tomu, že se plocha vykreslí nad řekou a zakryje ji což je samozřejmě pěkná blbost asi mi furt něco nedochází no nic, zalezu zpátky do své nory, nějak se dohodněte, hoďte to na wiki, ať je to snadno dohledatelné, budu se tím řídit když na něco narazím (btw, pokyny pro místní tagování by stály za významné doplnění ... já vím, je to wiki, může každý ... a ještě jsem ani zdaleka nedodělal ty turistické značky, co jsem už dost dávno nakous ... achjo, nemohla by ta zima bejt delší a mít víc a ještě delší večery? :-/ ) K.
  26. "Petr Morávek [Xificurk]" xificurk na gmail.com #m11a047
    Netřeba nic počítat. Mapnik používá ?malířův algoritmus? - nakreslí všechno, přičemž pozdější objekty (ty co jsou výše) přepíšou všechny objekty níže.
    hm, takže pokud tomu rozumím správně, tak s "layer logikou" by les nebo vpodstatě jakýkoliv objekt musel mít -2, aby se přes něj vykreslil průběh ponorné řeky (pokud mě v mapě zajímá), která bude mít -1, protože je pod normálním povrchem
    Ne! V jakém pořadí se vykreslují jednotlivé objekty je záležitostí rendereru (resp. dodaného stylu) a nemá to (skoro) nic společného s tagem layer. Petr
  27. MP singularita na gmail.com #m1caee2
    Netřeba nic počítat. Mapnik používá ?malířův algoritmus? - nakreslí všechno, přičemž pozdější objekty (ty co jsou výše) přepíšou všechny objekty níže.
    Ale mapnik není ani zdaleka jediný renderer. Ne všechny renderery používají malířův algoritmus a i u podobných rendererů může být problém např. pokud něco kreslí průsvitně (pak to "pod něčím" bude vidět). Takže to řeší problém u jednoho rendereru, a co ty ostatní?
    hm, takže pokud tomu rozumím správně, tak s "layer logikou" by les nebo vpodstatě jakýkoliv objekt musel mít -2, aby se přes něj vykreslil průběh ponorné řeky (pokud mě v mapě zajímá), která bude mít -1, protože je pod normálním povrchem
    layer funguje hlavně proto, aby se daly v mapě separovat objekty v rámci stejného nebo podobného typu (např. silnice / železnice, když se kříží mimoúrovňově), které jsou nad sebou nebo pod sebou a říct tak co se má zobrazit nad čím, ale pokud se nějaký typ objektů (např. polotransparentní hranice okresu) zobrazuje vždy nad jiným (např. silnice) tak s tím layer nic nenadělá. Martin
  28. Mike mike na mikecrash.com #m62bf30
    Přesně tak, layer jen označuje, kde co je. Zobrazení pak je na rendereru. On to může zobrazit klidně přes, ale třeba to vyčárkovat apod. Tady jde o to, aby se to nekreslilo vůbec. Možná by třeba šlo udělat nějaký univerzální tag (třeba hidden), který by pak fungoval na vše, ne jen underwater pro vodní toky.
  29. Aleš Janda openstreetmap na kyblsoft.cz #m1e32b9
    Tenhle "problém" byl zanesen do renderování mapy na hlavní stránce OSM v http://trac.openstreetmap.org/changeset/24983/applications/rendering/mapnik/inc/layer-water.xml.inc Bohužel to bylo zaneseno do stylů tak nešťastně, že ten bílý obrys se renderuje všude, tj. i v rybnících a napojeních na řeky s vyznačeným břehem. Imho by měla v případě potoků zůstat vyznačena cesta i skrze rybníky (byť něpřesně), protože ten potok tamtudy skutečně protéká.
    Dnes to bylo opraveno, nově vyrenderované dlaždice se zobrazují bez potoků ve vodních plochách, a dokonce se u řek začaly zobrazovat názvy. AJ
  30. Jakub Rychlý jakub.rychly na weboveaplikace.info #m50301a
    Koukám, že už se to pomalu překresluje. Bohužel názvy potoků jsou stále renderovány na vodní plochy. Navíc, když jsem prohlížel vodní plochy, narazil jsem na další chybku. Když je vodní plocha patřičně zahnutá, vykreslí se její název klidně do lesa (nejspíš težiště). Oba problémy viz: http://www.openstreetmap.org/?lat=49.91178&lon=17.52637&zoom=17&layers=M Jakub Rychlý
  31. "Petr Morávek [Xificurk]" xificurk na gmail.com #m6fcd79
    narazil jsem na další chybku. Když je vodní plocha patřičně zahnutá, vykreslí se její název klidně do lesa (nejspíš težiště). Oba problémy viz:
    Známý problém mapniku [1], který by měl být vyřešen v budoucí verzi. Momentálně je jediným řešením preprocesing OSM dat. [1] http://trac.mapnik.org/ticket/709 Petr
Napsat odpověď e-mailem… Odpovědět

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