Ahoj,
ten RASDAMAN mi přijde takový těžkopádný - poměrně složitá instalace a
konfigurace, složitá DB struktura, neintuitivní makro jazyk (člověk musí
zabít nějakou dobu jeho nastudováním - přitom není moc dobře
dokumentován), no a co do rychlosti, tak je to srovnatelné zhruba s
PostGIS Rastrem (zase záleží na typu operací). Na druhou stranu umožňuje
zpracování dat přímo přes parametry WMS či WCS - to může být pro někoho
výhodou...
U GRASSu pak je trochu krkolomná správa dat v GRASS Temporal DB (t.rast)
- ale jinak moc dobré a při mnoha typech operací rychlejší než "konkurenti".
Tonda
On 15.11.2016 23:53, Jáchym Čepický wrote:
To mě zajímá,
co ten RASDAMAN? Nějaké praktické postřehy?
Dík
J
Dne 15.11.2016 v 22:38 Antonin Orlik napsal(a):
Nakonec jsem na to přišel - přehlédl jsem parametr "mode" pro PG driver
GDALu - ten musí být v tomto případě nastaven na hodnotu 2 - viz:
https://trac.osgeo.org/gdal/wiki/frmts_wtkraster.html
Správně tedy:
gdal_translate "PG:dbname='test' table=tile where='rid IN (18,19,20,21)'
mode=2" /tmp/test.tif
Jinak co do rychlosti - před časem jsem prováděl benchmark - porovnával
jsem různé operace mezi PostGIS Raster, GRASS, RASDAMAN a souborovým
přístupem přes GDAL API. Hodně záleží, co chceš s těmi rastry dělat -
PostGIS Raster sice nedosahuje rychlosti jako souborový přístup přes
GDAL API, ale v mnoha ohledech zjednodušuje život a zavádí v datech
pořádek. V mém případě provádím nad velkým množstvím časových řad časté
prostorové dotazy, různé agregace, statistiky a exportuji kompozice -
zde je PostGIS Raster dobrou volbou...
Jinak souborový přístup přes GDAL API + numpy + scipy je bezkonkurenčně
nejrychlejší, pokud provádím jednorázové zpracování dat.
I tak díky!
Zdraví
Tonda
On 15.11.2016 21:12, Jáchym Čepický wrote:
> Ahoj,
>
> nemám moc odpověď, jenom dám do placu co jsem slyšel od autorů:
> postgis raster sice funguje, ale je to příšerně neefektivní a pomalý a
> moc by se to používat nemělo.
>
> No ... nějaký vacuum analyze nenapoví? Moc toho o databázích nevím,
> jenom tak malinko, asi to máš už načtený..
>
> J
>
> Dne 15.11.2016 v 10:59 Antonin Orlik napsal(a):
>> Zdravim,
>>
>> nemuzu najit efektivni zpusob, jak z PostGIS Raster DB ulozit do
>> jedineho souboru (treba GTiff) vice tiles (rastr byl do DB
importovan s
>> parametrem -t).
>> Pokud exportuji jeden tile z cele mozaiky, pak funguje napr.:
>> gdal_translate "PG:dbname='test' table=tile where='rid=18'"
>> /tmp/test.tif
>>
>> ale pokud chci exportovat cely rastr nebo jen nekolik tiles z cele
>> mozaiky, ktera je slozena treba z 500 tiles, pak toto nefunguje:
>> gdal_translate "PG:host=localhost port=5432 dbname='test' user='user'
>> password='password' schema='public' table=tile where='rid IN
>> (18,19,20,21)'" /tmp/test.tif
>> (Input file contains subdatasets. Please, select one of them for
>> reading.)
>>
>> Zkousel jsem to i pres St_AsTIFF, kde jsem tiles spojil pomoci
ST_Union,
>> ale pokud je tiles hodne, trva to zatracene dlouho.
>> Zkousel jsem i gdal_merge.py, ale neumi s tim pracovat.
>>
>> Mate s tim nekdo zkusenosti? Ve skriptech od Martina L. jsem
videl, ze
>> uvadi utilitu pgsql2raster, ale zadnou takovou jsem nenasel (jen
>> samozrejme raster2pgsql) - pravdepodobne omyl.
>>
>> Predem diky!
>> Tonda
>>
>>
>>
>>
>> ___
>> FreeGeoCZ mailing list
>> FreeGeoCZ@fsv.cvut.cz
>> http://mailman.fsv.cvut.cz/mailman/listinfo/freegeocz
>>
>
>
>
> ___
> FreeGeoCZ mailing list
> FreeGeoCZ@fsv.cvut.cz
> http://mailman.fsv.cvut.cz/mailman/listinfo/freegeocz
___
FreeGeoCZ mailing list
FreeGeoCZ@fsv.cvut.cz
http://mailman.fsv.cvut.cz/mailman/listinfo/freegeocz
___
FreeGeoCZ mailing list
FreeGeoCZ@fsv.cvut.cz
http://mailman.fsv.cvut.cz/mailman/listinfo/freegeocz
___
FreeGeoCZ mailing list
FreeGeoCZ@fsv.cvut.cz
http://mailman.fsv.cvut.cz/mailman/listinfo/freegeocz
