Estoy manipulando y procesando rásteres globales a una resolución de 30 m. El tamaño total de la trama suele ser [1,440,000 560,000]. Tengo acceso a una supercomputadora, así que he escrito un código que me permite dividir los rásteres globales en fragmentos manejables, realizar algunos cálculos en paralelo y escribirlos en el disco con bastante rapidez.
Sin embargo, me he topado con un muro cuando se trata de mostrar resultados. Por lo general, construyo una trama virtual de mosaicos que cubren el globo y lo coloco en QGIS. Pero es increíblemente lento (minutos para cargar, si lo hace). Y si trato de desplazarme o hacer zoom, son otros muchos minutos. Mi primer enfoque para resolver este problema fue construir vistas generales usando gdaladdo. Sin embargo, estos tardan una eternidad en construirse (como en días), lo que no conduce al desarrollo de algoritmos. Aquí hay una lista de las cosas que he intentado y por qué / cómo fallaron.
construir vistas generales en el vrt. Como se mencionó anteriormente, esto lleva más de 2 días para completar 8 niveles. Eso es inaceptable para mis propósitos.
construir vistas generales en los mosaicos individuales, luego de alguna manera fusionarse en un vrt que contenga las vistas generales. Puedo construir vistas generales en los mosaicos bastante rápido (supercomputadora), pero no he podido volver a fusionarlos. Lo intenté:
2a. gdal_merge en los mosaicos con vistas generales, pero las vistas generales no se conservaron (o al menos no fueron reconocidas por QGIS) en el tiff de salida.
2b. gdalbuildvrt en los mosaicos con vistas generales, pero como arriba, las vistas generales no se conservaron. [Esto no es correcto, ver edición].
2c. También probé un híbrido de construcción de vistas generales para los mosaicos para los niveles 1-6 y construcción de los niveles 7-8 directamente en el vrt (básicamente la opción 2b), pero todavía me lleva una eternidad solo para estos dos niveles. Hice algunas pruebas y ver que las vistas generales de baldosas se utilizan realmente para construir una visión general de VRT, pero sigue siendo del orden de un día para completar las visiones generales sobre la VRT.
Así que espero que alguien aquí tenga algunas sugerencias sobre dónde debería ir después. Aquí hay algunas opciones que estoy considerando:
Crear manualmente las pirámides globales yo mismo. Tengo cuidado de recombinarlos en un archivo .ovr, ya que supongo que será complicado.
Use un servidor de mapas (Geoserver). Sé muy poco sobre esto y me preocupa que no supere los obstáculos de tiempo al tiempo que agrega complejidad a mi proceso.
Divida el dominio por continentes o alguna otra región. Yo realmente quiero evitar esta opción.
Puede preguntar "¿por qué necesita ver el mundo entero con una resolución de 30 m?" Un ejemplo: tomo una máscara de píxeles de agua (globalmente) y la esqueleto para encontrar ríos y realizar mediciones. Mi algoritmo de esqueletización requiere un poco de ajuste (para poda de ramas, eliminación de bucles, limpieza general, etc.), y la salida es necesariamente de 30 m. Como los ríos y los paisajes son diversos en todo el mundo, necesito poder desplazarme para ver los efectos de los cambios que he implementado.
También revisé QGIS para asegurarme de que no haya ninguna configuración con la que pueda jugar para renderizar enormes rásteres más rápido, pero no vi nada. A falta de comprar unidades SSD, creo que está funcionando lo más rápido posible. (Mis discos duros tienen E / S de ~ 250 MB / s).
Descubrí que construir vistas generales en mosaicos individuales, luego construir un vrt aparentemente mantiene las vistas generales: la sección "Pirámide" de QGIS en los metadatos para el archivo está vacía, pero en la sección "Dimensiones" hay una entrada para cada nivel de visión general (por ejemplo, X 720000, Y 140; X 360000, Y 70, etc.). Entonces me equivoqué sobre 2b.
También encuentro que si solo extraigo todos los mosaicos en QGIS, se procesa en menos de un minuto, mientras que si extraigo el vrt que hace referencia a los mosaicos, toma> 5 minutos (no sé cuánto tiempo exactamente desde que maté el proceso).
Hice algunas pruebas en una computadora con un SSD, y descubrí que podía cargar, mostrar y renderizar los vrts globales (sin vistas generales) con éxito y a un ritmo aceptable. He ordenado una SSD PCIe de 1TB con la esperanza de que me permita hacer lo mismo en mi computadora. Se actualizará con los resultados.
I also tried a hybrid of building overviews for the tiles for levels 1-6 and building levels 7-8 directly on the vrtque se siente igual que el orden que recomienda y, naturalmente, ese es el correcto. Yo mismo no calcularía 2 4 8 ... vistas generales para el VRT si los mosaicos individuales los tienen para ahorrar tiempo y espacio en disco. Luego, un ROI pequeño encontraría vistas generales de un par de mosaicos y eso debería ser lo suficientemente rápido.Respuestas:
Parece que tiene dos preocupaciones principales: la identificación de VRT es lenta con la exploración y es lenta para generar vistas generales.
Si bien estoy seguro de que GDAL VRT solía ser lento para mí y para mi MapServer hace muchos años, es posible que la situación haya cambiado. Hice una capa de prueba con 10000 imágenes aéreas (tamaño de imagen / mosaico de 10000x10000 a 12000x12000 píxeles) y ahora GDAL VRT es en realidad más rápido que el índice de forma de archivo nativo de MapServer y sirve con la computadora de prueba 6 mosaicos (256x256) por segundo en una prueba simple con 1 hilo donde GetMaps siempre alcanza el primer nivel de visión general. Mosaic con 10000 imágenes sigue siendo bastante pequeño y supongo que en mi prueba Linux tenía todo el archivo VRT en la memoria caché. ¿Cuántas imágenes tienes en tu VRT?
El siguiente capítulo puede contener información antigua, leer responsablemente:
Existe alguna evidencia de que VRT es lento cuando contiene una gran cantidad de imágenes. Eso es porque VRT es un índice en formato XML y no es compatible con el índice espacial, lo que lleva a un escaneo completo de todo el archivo XML cada vez. No hay nada que pueda hacer para mejorar eso con GDAL simple, incluso ha habido una discusión sobre la implementación del índice espacial para VRT http://osgeo-org.1560.x6.nabble.com/gdal-dev-Don-t-we- have-any-ideas-for-GSoC-2017-td5309810.html .
Si está dispuesto a instalar un nuevo software, la solución más fácil podría ser utilizar MapServer con tileindex http://www.mapserver.org/optimization/tileindex.html . Si crea un tileindex con gdaltindex http://www.gdal.org/gdaltindex.html y crea un índice para el tileindex también con shptree http://www.mapserver.org/utilities/shptree.htmlentonces MapServer debería poder acceder muy rápidamente a todos los archivos de imagen que tenga. Cree vistas generales para mosaicos individuales y sirva la capa a través de WMS para QGIS y ha resuelto la primera parte del problema pero no el problema con las vistas generales globales. Incluso si ha creado vistas generales para los mosaicos individuales, será lento abrir miles de archivos de imagen para cubrir un área grande y, por lo tanto, debe limitar el número de archivos creando imágenes de vista general que cubran un área más grande. Eso es lo que ya ha intentado hacer construyendo vistas generales para el agujero VRT con gdaladdo.
No conozco ninguna herramienta preparada en el mundo GDAL / MapServer para crear pirámides globales automáticamente. Puede convertir mosaicos del VRT global en un conjunto de imágenes con un tamaño de píxel más grande escribiendo un script que ejecute gdal_translate http://www.gdal.org/gdal_translate.html con un deslizador -prowjin o -srswin. Luego, puede combinar los mosaicos resultantes en una nueva capa de vista general con gdalbuildvrt o gdaltindex.
Debido a que también considera usar GeoServer, recomendaría tener un botín en el script gdal_retile http://www.gdal.org/gdal_retile.html que está escrito para manejar su caso. También podría ser posible usar los mosaicos que gdal_retile crea directamente como vistas generales con QGIS construyendo VRT sobre ellos. Sin embargo, el primer problema con archivos VRT enormes y lentos permanecería.
fuente
Bien, resolví mis dos problemas ... principalmente comprando un SSD NVMe. Mi lectura / escritura en disco pasó de 125 MB / s a 1200 MB / s.
Programáticamente, hay algunas cosas que puede hacer para ayudar a su velocidad de lectura / escritura. Primero, considere el tamaño de bloque de su tiff. Si está utilizando un tiff rayado, cuando hace zoom a una región en particular, el software SIG tendrá que leer cada fila completa de la región, incluidas las partes del tiff que no se mostrarán, para mostrar la región. Por ejemplo, si hace zoom en una región de 256 x 256 píxeles, si tiene un tiff rayado, el software tendrá que leer al menos 256 bloques (uno por fila). Si tiene un tiff en mosaico (en mosaico a 256 x 256), el número máximo de bloques que deben leerse es 4 (y un mínimo de 1). Entonces, lo primero que puede hacer es asegurarse de que está utilizando un tiff en mosaico (opción de creación TILED = YES en gdal),
En segundo lugar, un enfoque híbrido para las vistas generales parece funcionar bien. Si puede paralelizar sus operaciones, puede agregar vistas generales a los mosaicos individuales con bastante rapidez, pero esto solo lo beneficiará para resoluciones más pequeñas que su mosaico. Creé descripciones internas de los niveles 2 4 8 16 32 y 64 en los mosaicos individuales. Luego, cree un VRT y cree vistas generales de los niveles 128, 256 y 512 en el VRT (tenga en cuenta que estos son para conjuntos de datos globales con una resolución de 30 m; sus niveles cambiarán dependiendo del número de píxeles en su tiff). El tiempo total para crear vistas generales individuales es del orden de minutos (depende de cuántos hilos puede ejecutar y cuántos mosaicos tiene), pero la creación de vistas generales en el VRT todavía es del orden de una hora. La mejora en el tiempo de ejecución sobre mi publicación inicial se debe al SSD y a la creación de menos niveles en el VRT.
En tercer lugar, puede jugar con la opción GDAL_MAX_DATASET_POOL_SIZE al crear vrts como se describe al final de esta página . Establece el número máximo de tiffs para mantener en la memoria a la vez.
En cuarto lugar, descubrí que la compresión con PACKBITS proporciona los tiempos de visualización más rápidos. Los archivos no son tan pequeños como LZW, pero es una compensación que podrías estar dispuesto a hacer.
El resultado es un VRT que se carga rápidamente y se desplaza / hace zoom casi sin problemas.
fuente