Para el tema 2: Aquí hay una investigación más larga de JP2, porque también estaba interesado, para usar una compresión más eficiente. Y el resultado IMO es: Dentro de GDAL / QGIS (como QgsRastrerDataProvider) no puede combinar la compresión adecuada jpeg2000 y las opciones de almacenamiento en caché rápido como conjuntos de mosaicos y estructuras de bloques de una manera simple.
Normalmente prefiero GeoTiff para Raster-DB's, está bien respaldado por GDAL desde hace mucho tiempo y tiene muchas características para facilitar la vida.
Puede encontrar las capacidades del controlador de datos JP2 en la página de gdal. Para sus necesidades jp2k, el JPEG2000 (dependencias de libjasper) se enumera en esta página: http://www.gdal.org/frmt_jpeg2000.html . Como se enumera en http://www.gdal.org/formats_list.html, el "controlador" admite lectura, escritura, está limitado a 2GiB y está integrado desde GDAL versión 1.9 y tiene algunas opciones de bloqueo ...
Entonces, para estar seguro de lo que es posible con JP2, he creado un conjunto de prueba.
Utilizo grandes fotos ariales para detectar aves marinas en el mar Báltico con un tamaño de ca. 12000 por 10000 píxeles (RGB) y una resolución de suelo de 2 cm (espero que sea lo suficientemente grande). Tengo actualmente 270 archivos con una capacidad de alrededor de 130 GiB en mi proyecto QGIS. Y funciona con fluidez y bien en un SO Linux Debian 7.0 de 64 bits con núcleos Opteron de 8GB y 4xAMD. ... pero con GeoTiff.
Para obtener un acceso rápido en la herramienta SIG, se hace referencia a las imágenes y se vuelven a muestrear con GDAL utilizando los siguientes pasos y opciones (... lo siento por el estilo de script bash):
Hacer referencia a la imagen con conjuntos de datos del gps-log:
gdal_translate \
-of GTiff \
-gcp 0 0 $ulx $uly \
-gcp 0 $hg $llx $lly \
-gcp $cwd $chg $cpx $cpy \
-gcp $wd 0 $urx $ury \
-gcp $wd $hg $lrx $lry \
-a_srs epsg:32632 \
$raw_tif $ref_tif
Las variables $ [u | o] [l | r] [x | y] son las esquinas de la imagen dada por el cálculo fotogramático y la variable $ wd es el ancho de la imagen, $ hg la altura de la imagen y $ cwd $ chg el punto central.
Deforma la imagen con las opciones de conjunto de mosaicos en el mundo real:
gdalwarp \
--config GDAL_CACHEMAX 2000 -wm 2000 -wo NUM_THREADS=4 \
-r bilinear -dstnodata '0 0 0' \
-of GTiff \
-t_srs epsg:32632 \
-tr 0.02 0.02 \
-co COMPRESS=LZW \
-co TILED=YES \
-co BLOCKXSIZE=512 \
-co BLOCKYSIZE=512 \
$ref_tif $geo_tif
Los parámetros: --config GDAL_CACHEMAX 2000 -wm 2000 -wo NUM_THREADS = 4 le dice a la plancha que use mucho caché y cuatro hilos de procesador para calcular las cosas. El remuestreo se realiza por vía bilineal y el sistema de coordenadas es UTM-32 ... pero quiero bloques de bloques de 512x512, para que las operaciones de navegación (zoom, desplazamiento, punto) sean rápidas y fluidas. Esto se realiza mediante las opciones -co TILED = YES -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512.
Escriba las pirámides en el GeoTiff en los niveles de zoom 2,4,8 y 16:
gdaladdo -r gauss $geo_tif 2 4 8 16
El GeoTiff resultante que muestra gdalinfo es:
Driver: GTiff/GeoTIFF
Files: CF006135.TIF
Size is 12419, 9900
Coordinate System is:
PROJCS["WGS 84 / UTM zone 32N",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",9],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","32632"]]
Origin = (656099.007276594405994,5998980.139660121873021)
Pixel Size = (0.020000000000000,-0.020000000000000)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 656099.007, 5998980.140) ( 11d23'17.54"E, 54d 6'54.87"N)
Lower Left ( 656099.007, 5998782.140) ( 11d23'17.17"E, 54d 6'48.47"N)
Upper Right ( 656347.387, 5998980.140) ( 11d23'31.21"E, 54d 6'54.60"N)
Lower Right ( 656347.387, 5998782.140) ( 11d23'30.84"E, 54d 6'48.20"N)
Center ( 656223.197, 5998881.140) ( 11d23'24.19"E, 54d 6'51.54"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
NoData Value=0
Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
NoData Value=0
Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
NoData Value=0
Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619
¡Así que en GeoTiff todo está bien! Si trato de crear un JP2 con un paso de conversación directa:
gdalwarp -of jpeg2000 -co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512 CF006135.TIF CF006135.jp2
Output driver `jpeg2000' not recognised or does not support
direct output file creation. The following format drivers are configured
and support direct output:
VRT: Virtual Raster
GTiff: GeoTIFF
NITF: National Imagery Transmission Format
HFA: Erdas Imagine Images (.img)
ELAS: ELAS
MEM: In Memory Raster
BMP: MS Windows Device Independent Bitmap
PCIDSK: PCIDSK Database File
ILWIS: ILWIS Raster Map
SGI: SGI Image File Format 1.0
Leveller: Leveller heightfield
Terragen: Terragen heightfield
netCDF: Network Common Data Format
HDF4Image: HDF4 Dataset
ISIS2: USGS Astrogeology ISIS cube (Version 2)
ERS: ERMapper .ers Labelled
RMF: Raster Matrix Format
RST: Idrisi Raster A.1
INGR: Intergraph Raster
GSBG: Golden Software Binary Grid (.grd)
PNM: Portable Pixmap Format (netpbm)
ENVI: ENVI .hdr Labelled
EHdr: ESRI .hdr Labelled
PAux: PCI .aux Labelled
MFF: Vexcel MFF Raster
MFF2: Vexcel MFF2 (HKV) Raster
BT: VTP .bt (Binary Terrain) 1.3 Format
LAN: Erdas .LAN/.GIS
IDA: Image Data and Analysis
GTX: NOAA Vertical Datum .GTX
NTv2: NTv2 Datum Grid Shift
ADRG: ARC Digitized Raster Graphics
SAGA: SAGA GIS Binary Grid (.sdat)
y falla Puede ser que el mensaje de error le dé una pista u otro formato que pueda usar.
La prueba con la herramienta gdal_translate le dará un JP2000 adecuado
gdal_translate -of jpeg2000\
-co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512\
CF006135.TIF CF006135.jp2
ls -l
-rw-r--r-- 1 huckfinn huckfinn 63538529 Jan 28 23:55 CF006135.jp2
-rw-r--r-- 1 huckfinn huckfinn 388 Jan 28 23:04 CF006135.jp2.aux.xml
-rw-r--r-- 1 huckfinn huckfinn 519882980 Sep 30 21:01 CF006135.TIF
y la tasa de compresión es 1: 8 pero perdemos las propiedades del conjunto de bloques y mosaicos como se muestra en gdalinfo:
gdalinfo CF006135.jp2
Driver: JPEG2000/JPEG-2000 part 1 (ISO/IEC 15444-1)
Files: CF006135.jp2
CF006135.jp2.aux.xml
Size is 12419, 9900
Coordinate System is:
PROJCS["WGS 84 / UTM zone 32N",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",9],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","32632"]]
Origin = (656099.007276594405994,5998980.139660121873021)
Pixel Size = (0.020000000000000,-0.020000000000000)
Metadata:
AREA_OR_POINT=Area
Corner Coordinates:
Upper Left ( 656099.007, 5998980.140) ( 11d23'17.54"E, 54d 6'54.87"N)
Lower Left ( 656099.007, 5998782.140) ( 11d23'17.17"E, 54d 6'48.47"N)
Upper Right ( 656347.387, 5998980.140) ( 11d23'31.21"E, 54d 6'54.60"N)
Lower Right ( 656347.387, 5998782.140) ( 11d23'30.84"E, 54d 6'48.20"N)
Center ( 656223.197, 5998881.140) ( 11d23'24.19"E, 54d 6'51.54"N)
La última prueba fue utilizar GeoTiff con una compresión JPEG interna, pero obtenemos:
gdalwarp -of GTiff \
-co COMPRESS=JPEG \
-co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512\
CF006135.TIF CF006135_IJPG.TIF
Creating output file that is 12419P x 9900L.
Warning 6: Driver GTiff does not support BLOCKSIZEX creation option
Warning 6: Driver GTiff does not support BLOCKSIZEY creation option
Processing input file CF006135.TIF.
....
Entonces, ¿a dónde ir desde aquí? La página lib del controlador JP2000 Jasper de GDAL enumera algunos parámetros para crear la imagen jp2000 con opciones de bloqueo:
Encoding parameters, directly delivered to the JasPer library described in the JasPer documentation. Quoted from the docs:
``The following options are supported by the encoder:
imgareatlx=x Set the x-coordinate of the top-left corner of the image area to x.
imgareatly=y Set the y-coordinate of the top-left corner of the image area to y.
tilegrdtlx=x Set the x-coordinate of the top-left corner of the tiling grid to x.
tilegrdtly=y Set the y-coordinate of the top-left corner of the tiling grid to y.
tilewidth=w Set the nominal tile width to w.
tileheight=h Set the nominal tile height to h.
prcwidth=w Set the precinct width to w. The argument w must be an integer power of two. The default value is 32768.
prcheight=h Set the precinct height to h. The argument h must be an integer power of two. The default value is 32768.
cblkwidth=w Set the nominal code block width to w. The argument w must be an integer power of two. The default value is 64.
cblkheight=h Set the nominal code block height to h. The argument h must be an integer power of two. The default value is 64.
pero la pregunta es, ¿cuál usará qgis?
