zdravím, konečně (...) jsem se dostal k rozběhnutí OTM, ale mám takový problémek, a to s hillshading a s vrstevnicemi v prvém případě se dostanu přes vygenerování dlaždic, ty ještě vypadají celkem dobře, ale .tif z toho generované v dalších krocích jsou černočerné ... co se týče vrstevnic, ty vypadají dobře, akorát jsou posunuté ... výsledky viz http://otm.hajnet.cz/ snažil jsem se postupovat co nejpřesněji podle http://geoinformatics.fsv.cvut.cz/gwiki/Custom_OpenStreetMap_Rendering_- _OpenTrackMap_Experience výřez SRTM dat pro ČR jsem získal od Pavla Zbytovského (kdyžtak doplň, nevím, jestli můžu dát link do konference, aby ti stahovači nepřetížili server :-)) - nicméně první problém se projevuje i s jinýmy SRTM daty, pro která se mi ovšem nepodařilo dokončit import do databáze má někdo nějaký nápad, kde by mohl být zakopán pes, na co se zaměřit při ladění? K.

Dne úterý 15 Prosinec 2009 17:17:57 Karel Volný napsal(a): zobrazit citaci A jak se na ně díváte? Pokud používáte QGIS s výchozím nastavením, tak se TIFFy kvůli rozsahu hodnot zobrazují jako černé. Zkuste v nastavení vrstvy ručně nastavit rozsah hodnot např. od 0 do 2000 nebo zkuste inspektorem hodnot zjistit, jaké hodnoty jsou na jednotlivých pixelech. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: blackhex na post.cz Web: http://blackhex.no-ip.org Jabber: blackhex na jabber.cz

Dne St 16. prosince 2009 Radek Bartoň napsal(a): zobrazit citaci no, zatím jsem zkoušel jen obyčejné grafické prohlížeče, nicméně na dlaždicích z mapniku se to jeví jako uniformně šedé pozadí ... takže QGIS (1.3.0) je na tom přesně naopak, zobrazí mi to jako bílou - tedy hillshade.tif a warped.tif, dlaždice NxxE0yy.tif zobrazuje naopak černě, a nějakou šedou mapu zobrazí jen v srtm.tif když dám Vlastnosti, tak v min/max mi to dovolí zadat jen 0-255, a když tam dám Načíst hodnoty, tak tam vkládá nějaká šílená hausnumera e+-308 K.

To je divny, protoze geotify jsou vice nez 8 bitove (logicky, aby se dala reprezentovat vyska alespon 0 az 10km). Vypada to, ze to prohlizite v necem, co neumi pracovat s tifem s vyssi hloubkou na pixel. Navic je potreba udelat tu korekci min-max a rozume to tak roztahnout na cele spektrum (pokud je 16bit, tak toho bude vetsina cerna, protoze na uzemi nasi republiky tam budou vsude intenzity 200-1600 z 65535). K Dne 16.12.2009 16:10, Karel Volný napsal(a): zobrazit citaci

On Wed, Dec 16, 2009 at 04:10:06PM +0100, Karel Volný wrote: zobrazit citaci zkusil jste jinou paletu? Pseudobarvy, freakout ? j zobrazit citaci -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/JachymCepicky.pgp Key fingerprint: 0C6D 0EAE 76BD 506C F299 ED8A C8AB 74B8 08D4 E08F ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20091217/34f52c7c/attachment.sig>

Dne St 16. prosince 2009 Kubajz napsal(a): zobrazit citaci to asi jsou, GIMP na mě řve něco o tom, že umí pracovat jen s 8bit a že uložením ztratím kvalitu zobrazit citaci mno, to záleží na přesnosti - když řeknu, že krok je nějakých 39,2... m, tak potom 255 = 10 km ale specifikace formátu je to poslední, co by se mi teď chtělo studovat :-) zobrazit citaci ten QGIS by to snad měl umět ... je možné, že je cosi shnilého v knihovnách, co se používají? - mám tiff-3.9.2 a libgeotiff-1.2.4 (a gdal 1.6.2), může mi někdo říci, s jakýma verzema to úspěšně rozběhal? na http://otm.hajnet.cz/HS/ je sada dat a skripty, které jsem na to pustil (konkrétně hs.sh, mírně upravený z http://geoinformatics.fsv.cvut.cz/gwiki/Custom_OpenStreetMap_Rendering_- _OpenTrackMap_Experience#Hill_Shading , který pak volá srtm_generate_hdr.sh) při posledním pokusu jsem jako formát explicitně specifikoval Int16, aby tedy byl jasný ten 16bit rozsah aktuálně mi to hlásí WARNING, že není podporován BigTIFF (tiff to umí až od verze 4, která je zatím beta), ale to by nemělo ničemu vadit, výstup není tak velký (bez BigTIFF je maximum 4 GiB, ne?) a taky jsem si dříve nevšiml, že píše ERROR 1: CPLCreateThread() failed in ChunkAndWarpMulti() nicméně dle zběžného googlení soudím, že by to na funkci nemělo mít vliv (prostě pojede jen v jednom vlákně) když to otevřu v QGIS, tak nyní u všeho lze nastavit ten doporučený rozsah 0-2000, a dlaždice a srtm.tif mi to zobrazí celkem pěkně (poznávám ČR :-)), ale warped.tif a hillshade.tif jsou pořád jednobarevné - když si dám spočítat histogram, tak se tam neukáže nic, zatímco pro dlaždice a srtm.tif mi to nějakou křivku zobrazí takže problém bude asi ve volání gdalwarp ... viz výše, než se pustím do nějakého dalšího debugování, mohl by prosím někdo vzít odkazované zdroje a skripty, a pokud mu budou fungovat, říci mi s jakou konkrétní verzí knihoven? K.

zobrazit citaci viz předchozí mail - po explicitním zadání Int16 to funguje asi jak by mělo pro NxE0yy.tif i pro srtm.tif (btw, pseudobarvy a freakout mi u dlaždic dávají prakticky jednolitou modř/fialovou) ale warped.tif a hillshade.tif nic, a zkusil jsem proklikat snad všechno co šlo ... K.

zobrazit citaci ach jo ... takže vliv to má a setsakramentský - po odstranění parametru "-multi" to všechno funguje ... tedy skoro vše, zbývá ten problém s posunem, ale k tomu se vrátím tam, kde jsem s tím začal zatím dík všem zúčastněným za tipy K.