Administrar datos de elevación: Parte 2: Diseño y plan de administración de datos

La audiencia para este flujo de trabajo es principalmente los administradores de datos de imagen dentro de una organización quienes deben hacer que los datos de elevación sean accesibles para varias comunidades de usuarios. Este flujo de trabajo supone que el administrador de datos de imagen está utilizando ArcGIS Desktop para administrar los datos y ArcGIS Server para distribuir los datos como uno o más servicios de imágenes, pero este flujo de trabajo también es aplicable para administrar y distribuir los datos de elevación solo en ArcGIS Desktop.

Este flujo de trabajo está diseñado para tratar datos de elevación de ráster basados en celdas. Los datos de punto en 3D (por ejemplo, LAS) y los formatos de dataset de terreno se deben convertir a datasets ráster para que se puedan utilizar en este flujo de trabajo.

Éste muestra el diseño general de la administración de datos de elevación. Cada uno se analizará a continuación.

1. Almacenamiento de datos (tamaño, requisitos y ubicaciones).
2. Preparar datos (puede requerir procesamiento previo).
3. Crear un dataset de mosaico para colección (origen).
4. Crear un dataset de mosaico para colección (principal).
5. Crear diferentes datasets de mosaico para visualización, análisis, acceso de usuarios y publicación (de referencia).

Almacenamiento de datos

El almacenamiento de datos no se analiza aquí, pero requiere de planeamiento dependiendo de sus requisitos. Para algunas especificaciones acerca de la arquitectura de su sistema, vea las diapositivas de la presentación de la Conferencia internacional de usuarios de Esri 2011: Arquitectura del sistema para servicios de imágenes grandes.

Pero es importante mencionar la organización de los datos. Lo ideal es que organice sus datos en carpetas agrupadas por producto. Por ejemplo, mantenga los datos SRTM en una carpeta y los datos de 1/3 arcsegundo NED en otra carpeta. Verá en los pasos (Parte 3) la manera en que esto ayudará al descargar datos, en QA/QC y en el mantenimiento a largo plazo.

Uso de los datos

Este flujo de trabajo hace énfasis en tres diferentes modos de utilizar los datos de elevación. La mayoría de los usuarios finales simplemente necesitan ver visualizaciones de la topografía para satisfacer sus necesidades, mientras que un porcentaje más pequeño de usuarios desean ver los resultados del análisis topográfico. El porcentaje más pequeño de usuarios, como ingenieros, tienen un requisito para acceder a los valores de elevación reales para hacer sus propios análisis.

Es importante entender las diferencias e implementar el modo de uso adecuado para cada uno de estos usuarios, ya que la deficiencia y respuesta del sistema se puede afectar en gran medida. Los diferentes modelos de uso a los que se hará referencia repetidamente son el uso del visor, uso de los resultados de análisis y uso de valores de datos.

Modelo de uso 1: uso del visor

Los usuarios necesitan ver representaciones de los datos de elevación. Por consiguiente, el administrador de datos debe crear productos de visualización apropiados en el servidor, después proporcione esas vistas a los usuarios. Esto se refiere al grupo de usuarios más grande, pero de menor demanda técnica, en muchos casos el público general, que necesitan tener acceso fácil a cualquier número de productos relativamente simples basados en datos de elevación. Los ejemplos incluyen:

• Una imagen sombreada o de relieve sombreado: para incluir en un mapa topográfico o mapa base
• Una imagen representando una pendiente: para planeamiento urbano, susceptibilidad a derrumbes, etc.
• Una imagen representando una orientación: para agricultura, delineación y administración de hábitat natural, modelado de clima, etc.

Desde luego, para usuarios con ArcGIS, al proporcionarles acceso a los datos de elevación, la aplicación puede generar en sí esos productos.

Modelo de uso 2: uso de los resultados de análisis

Los usuarios definen los parámetros y una región de interés para el análisis del servidor de los datos de elevación, después de recuperar los resultados. Esto se refiere a un grupo de usuarios que necesitan tener acceso a una variedad de productos analíticos que se pueden generar en el servidor. Los resultados por lo general son mapas o entidades discretas que luego se proporcionan al usuario sin transmitir los datos de origen. Los ejemplos incluyen:

• Cálculo y producción de mapas planos de inundación: para FEMA, compañías de seguro, gobierno de ciudades o condados, bienes raíces y uso público
• Usos en el manejo de desastres: para planificación de evacuación, mitigación de inundaciones y superposición basada en la Web de datos de inundaciones actuales para toma de decisiones en tiempo real
• Cálculos de cuenca visual para el análisis de visibilidad y línea de visión: para determinar lo que se puede ver desde una ubicación, establecer torres de telefonía celular y equipo de comunicaciones en microondas o planificar cortes claros
• Operaciones militares: para rutas de seguridad de las tropas y vulnerabilidad del francotirador
• Planificación industrial: para perfiles de viento y visibilidad para ubicaciones de granjas de viento o diseño de presas hidroeléctricas
• Calculo de curvas de nivel cartográficas: para visualizar en un mapa
• Cálculos de perfiles a lo largo de líneas rectas o segmentos de líneas: para rutas de conducción de ingeniería y cálculos de presión, planificación de carreteras o costos de extracción y planificación de carreteras para recolección de árboles

Para estas aplicaciones, el usuario por lo general no necesita los valores de elevación reales. Al solo distribuir estos productos, es posible que los requisitos de ancho de banda disminuyan ligeramente debido a que el tamaño de los datos será menor. Por ejemplo, los valores de elevación sin formato son 32 bits, mientras que la cuenca visual puede tener un resultado de 1 bit a 8 bits.

Modelo de uso 3: Uso de valores de datos

Los usuarios necesitan tener acceso a los valores de elevación. Esto se refiere a un usuario que necesita los datos de elevación originales en un formato digital para admitir cálculos numéricos (se supone que en una aplicación de escritorio o de Web de cliente). Por ejemplo

• Como entrada en un proceso secundario: para la ortorrectificación de imágenes
• Como entrada en sus propios procesos o modelos de datos: para crear curvas de nivel o completar análisis de flujo de agua para uso en diseños hidrográficos de sistemas de irrigación o modelado de inundaciones

De los tres modelos de uso, este es el más costoso en términos de tiempo y recursos en el servidor debido a que a menudo requiere que se ingresen y transmitan una cantidad de datos mucho mayor.

Requisitos

Para proporcionar los datos apropiados y tener acceso a los modelos de uso anteriores. Esta lista no incluye todos los requisitos, solamente es una introducción a algunos requisitos específicos importantes para los datos de elevación. Después debe decidir si estos requisitos son aplicables en su organización y debe tomar las decisiones adecuadas respecto a la implementación apropiada.

• Distribuir una imagen, el resultado o los datos
• Proporcionar el acceso interno, por intranet o Internet
• Proporcionar uno o más modelos o representaciones de elevación
• Proporcionar acceso a 1, 10, 100 ó 1 millón de usuarios
• Proporcionar acceso a los datos de origen
• Muchas fuentes de datos, administradas como una
• Acceso limitado a la fuente y la administración
• Es necesario que se pueda actualizar o reemplazar el contenido fácilmente

Descargar y exportar datos

Es importante que los administradores de datos de imagen y los usuarios finales entiendan que cualquier muestra de datos de elevación cambiará los datos. Por ejemplo, si un dataset se visualiza en una resolución diferente a la resolución máxima, en una proyección o alineación de píxeles diferente, los datos se volverán a muestrear. No es inusual sobremuestrear un dataset de elevación. Por ejemplo, al acercarse a una escala de 1:1,000 de una cuenca visual creada a partir de un dataset de espaciado de publicación de 5 metros, esto es demasiado cerca.

Para algunas aplicaciones, es posible que los usuarios necesiten tener acceso a los valores numéricos en una región de interés (uso de valores de datos). Hay dos métodos para proporcionar los valores de datos numéricos a un cliente: exportar o descargar.

Exportar se refiere a transmitir valores de datos en un área especificada por el usuario, que se volvió a muestrear para la resolución o proyección apropiada. Descargar se refiere a transmitir los valores de datos originales (resolución máxima, sin volver a muestrear), por lo general dentro de un área especificada. Debe estar claro que descargar puede resultar en la transferencia de un volumen muy grande de datos desde el servidor al cliente (especialmente si los datos cubren un área muy grande y contienen varios datasets). Por consiguiente, se deben implementar restricciones apropiadas para asegurarse de que el usuario y el sistema están preparados para el resultado, como establecer un límite en la cantidad máxima de datos a transferir o el diseño de una aplicación Web con una advertencia.

Fuentes de datos

A continuación encontrará una lista de los datos de ejemplo que se utilizarán en este flujo de trabajo. Estos datos pueden tener profundidades de bits, por lo general 16 bits o flotante, con signo o sin signo.

Este flujo de trabajo supone que el administrador de datos está utilizando datos almacenados localmente en la organización.

Datos	Descripción
GTOPO	GTOPO es un dataset de elevación global con resolución de 30 arcsegundos (aproximadamente 1 km), disponible para descargar en http://www1.gsi.go.jp/geowww/globalmap-gsi/gtopo30/gtopo30.html.
SRTM	La Misión topográfica Radar Shuttle (SRTM) son datos de elevación en una escala casi global que se adquieren de Space Shuttle para generar la base de datos topográficos digitales de alta resolución más completa de la Tierra. Disponible en http://srtm.usgs.gov/index.php.
NED 10, NED 30	El National Elevation Dataset (NED) fue creado por el USGS para los EE.UU. Los datos del NED están disponibles a nivel nacional en resoluciones de 1 arcsegundo (alrededor de 30 metros, "NED 30") Y 1/3 arcsegundo ( alrededor de 10 metros, "NED 10"). Vea http://ned.usgs.gov/.
LIDAR	Los datos LIDAR se pueden obtener de diversas fuentes. En este caso en particular los datos los proporcionó el Sistema Regional de información del suelo de Oregón (RLIS) y se convirtieron a DEM y DSM.

Organización y servicios de administración de datos (productos)

Un objetivo clave es asegurarse de que todos los datos, independientemente de la extensión, se administren y distribuyan como una unidad única. Una opción (la cual a menudo ocurre con el paso del tiempo, a medida que una organización crece y se completan los proyectos individuales) es administrar los datos de diferentes áreas geográficas como datasets separados. Sin embargo, ArcGIS proporciona la capacidad de administrar colecciones de datasets muy grandes de manera eficiente, reduciendo los costos de creación y mantenimiento que antes resultaban de la duplicación de datos y sobrecarga de administración innecesaria.

Organización de datasets de mosaico

El dataset de mosaico es la estructura de datos óptima para administrar, visualizar y publicar su colección de datos de elevación, debido a que este puede administrar todas las diferentes resoluciones y formatos de archivos ráster, y los archivos se mantienen en su formato original en el disco. Además, este cuenta con varias opciones para visualizar y procesar los datos de elevación, como la realización dinámica de mosaicos que permite la mejor resolución para visualizar en escalas apropiadas, así como, funciones utilizadas para procesar los datos y crear varios productos sin copiar los datos de origen.

Las funciones específicas para los datos de elevación son Sombreado, Relieve sombreado, Orientación y Pendiente.

Es favorable separar los datasets de mosaico en dos tipos: aquellos que se utilizan principalmente para administrar y aquellos que proporcionan otras representaciones de datos (como sombreado) y se publican. Esta división puede facilitar la organización. Usted puede administrar sus imágenes en un dataset de mosaico, pero utilice otro dataset de mosaico para compartir o distribuir (publicar) el contenido.

A continuación encontrará una vista general de los diferentes tipos de datasets de mosaico y lo que pueden proporcionar:

• Origen: utilizado para administrar imágenes. Suele contener una colección de imágenes parecidas. Puede utilizar varios datasets de mosaico de origen para administrar distintas colecciones, como SRTM y NED. Se pueden publicar directamente o (más a menudo) utilizar como el origen de otros datasets de mosaico.
• Principal (o derivado): utilice para compilar varios orígenes en un dataset de mosaico único. El origen de un dataset de mosaico principal suele ser uno o varios datasets de mosaicos de origen pero también puede incluir otras imágenes o servicios.
• Referenciado: un tipo único de dataset de mosaico que se utiliza principalmente para compartir o publicar imágenes. Se crea al utilizar un dataset de mosaico como entrada y no permite que se editen los elementos de la tabla, por lo tanto, mantiene las entradas seguras de alteraciones. A menudo se utiliza para proporcionar salidas procesadas de manera diferente del las entradas del dataset de mosaico principal o de origen.

Los datasets (derivados) de origen y principales son nombres simbólicos utilizados para ayudar a transmitir un entendimiento de la estructura organizacional de los datasets de mosaico, mientras que un dataset de mosaico de referencia es una forma físicamente diferente de un dataset de mosaico.

Sus datos de elevación se pueden almacenar en carpetas que usted o el proveedor de datos organice, pero se administrarán y distribuirán utilizando uno o más datasets de mosaico y servicios de imágenes. Los datos incluidos en un dataset de mosaico de origen usualmente se determinan por tener el mismo número de bandas y profundidades de bits. En este caso, esto se determina por la profundidad de bits y el producto. Por ejemplo, los datos derivados LIDAR se pueden organizar en un dataset de mosaico de origen y los SRTM en otro. Esto ayuda a mantener organizados los datos y permite separar datos con diferentes unidades verticales. Por ejemplo, los datos LIDAR se miden en pies y los SRTM se miden en metros. Además, le permite refinar las huellas, cuando sea necesario, o controlar los NoData que pueden ser únicos para cada producto.

Los datasets de mosaico de origen se combinarán entre sí utilizando el dataset de mosaico principal. Se puede agregar algunas funciones a algunos de los orígenes para garantizar que los datos presenten la misma información, como la conversión de pies a metros o de elipsoidal a ortométrico. (Para la mayoría de requisitos, se recomienda crear y mantener un dataset de mosaico con altura del terreno ortométrica como el servicio principal en el que se compilen los demás).

Servicios y productos finales

Se pueden crear varios datasets de mosaico referenciados a partir del dataset de mosaico principal con el fin de proporcionar los siguientes servicios de datos de elevación recomendados:

• Altura del terreno ortométrica
• Altura de superficie ortométrica: si los datos de elevación de superficie (DSM) están disponibles (se mostrarán edificios, cubierta forestal, puentes, etc.)
• Altura del terreno elipsoidal
• Para visualizaciones
  • Sombreado
  • Relieve sombreado
  • Pendiente
  • Orientación (utilizado para visualización y análisis)

Si la comunidad de usuarios necesita más de una corrección geoide, probablemente el administrador de datos desee publicar geoides como servicios de imágenes, exponiendo opciones apropiadas para los usuarios.

Consideraciones de océanos

En todos los casos, el administrador de datos debe decidir cómo representar los océanos. La elección adecuada dependerá de las aplicaciones que los datos deben admitir. Las opciones incluyen:

• Océano es elevación con un valor 0
• Océano es NoData
• Los océanos se representan con datos batimétricos

Para la mayoría de aplicaciones, se acepta representar cualquier nivel del mar con 0. Si el mar se define como NoData, entonces la ortorrectificación en cualquier área NoData producirá un error. Un método simple para rellenar con valores cero es agregar una resolución muy baja, imagen de simulación mundial en el dataset de mosaico, donde todos los valores de los píxeles son 0. Después, cuando los valores en los datos, tales como el SRTM, son NoData, se mostrará el valor 0 en la imagen de simulación.

Si el administrador de datos elige incluir datos batimétricos habrán valores de elevación negativos en los océanos que permitirán visualización del suelo oceánico. Esto permite flexibilidad en términos de cómo varios servicios pueden proporcionar (mostrar) los datos; una aplicación cliente podría mostrar un relleno azul para el agua donde la elevación sea menor que 0, y en la misma área, una aplicación de cliente diferente puede proporcionar la elevación de subsuperfice como terreno sombreado.

Vistas generales

En un nivel básico, las vistas generales del dataset de mosaico son similares a las pirámides de dataset ráster. Son imágenes que tienen una resolución más baja, creadas para aumentar la velocidad de visualización y reducir el uso del CPU debido a que se examina una cantidad menor de rásteres para visualizar la imagen en mosaico. Sin embargo, difieren en gran medida porque se pueden controlar muchos de los parámetros utilizados para crearlas. Las puede crear para cubrir solo un área específica o solo en resoluciones específicas. Se crean para permitir una visualización de todos los rásteres que se encuentran en el dataset de mosaico completo, no solo para cada ráster. Las vistas generales generalmente comienzan donde se detienen las pirámides ráster, pero puede especificar un tamaño de píxel base en el cual se generarán las vistas generales si prefiere no utilizar todas las pirámides ráster.

El administrador de datos debe considerar el mejor enfoque para las vistas generales. Las vistas generales se pueden crear a partir de los datos de proyecto, pero si hay disponibles datasets de resolución más baja de orígenes alternativos, como GTOPO, ETOPO y GMTED2010, se recomienda utilizarlos. El resto de este flujo de trabajo se basa en este enfoque, generar un servicio de imágenes de una región grande compuesta de varios datasets en diferentes resoluciones espaciales diferentes (así que generalmente no existen requerimientos para las vistas generales).

Para obtener más información, consulte Vistas generales de datasets de mosaico.

Metadatos

Existen varias propiedades que los administradores de datos deben comprobar en lo que respecta a todos los datos de elevación. El administrador de datos debe revisar y decidir qué componentes son importantes mantener así como qué campos de metadatos mostrar a los usuarios de los datos. Para fines de garantía de calidad y configuración del sistema, se recomiendan utilizar los metadatos que se enumeran a continuación.

Los metadatos que el administrador de datos debe verificar incluyen:

• Propietario o fuente de datos.
• Copyright.
• Sistema de coordenadas horizontales (proyección, datum y unidades).
• Datum vertical (modelo específico, observando si es elipsoidal u ortométrico) y unidades (pies o metros).
• Exactitud horizontal (típicamente se mide como CE90 o CE95, pero también se puede informar como error RMS o RMSE).
• Exactitud vertical (típicamente se mide como LE90).
• Resolución (espaciado de muestra almacenado en el archivo de datos y no es el mismo de la exactitud horizontal de los datos).
• Tipo de superficie de elevación (DEM frente a DSM).
• Cómo se define NoData en este dataset:
  • ¿Hay áreas de NoData?
  • Si la respuesta es sí, ¿está representado por un valor único?
  • ¿Está NoData limitado a los bordes de los datasets o hay agujeros de NoData dentro de los datos válidos?
  • Algunos productos tienen clases de entidad asociadas que definen las regiones vacías. Verifique si esas áreas se rellenaron con un valor y si es un valor NoData.
• ¿Los datos eran muestras de otro origen?
• Fecha de adquisición de los datos sin procesar.
• Fecha en que se completó el QA/QC, quién lo completó y qué métodos o estándares se utilizaron.
• ¿Los datos se pueden publicar o están restringidos (los datos pueden estar patentados o clasificados, libres para publicación pública)?

Para campos de metadatos únicos, puede que sea necesario agregarlos manualmente a la tabla de atributos del dataset de mosaico, como las exactitudes verticales y horizontales. De esta forma, los usuarios pueden consultar esta información fácilmente en el dataset de mosaico.

Sugerencia:

Vale la pena crear una lista de los productos (o subproductos) que está utilizando, debido a que puede necesitar modificar los datos en el dataset de mosaico, como la función Aritmética para convertir de una unidad a otra.

Optimización del formato

La optimización del formato no siempre es necesaria, pero es necesaria cuando los datos no están en un formato óptimo o compatible. La siguiente es una lista de algunas recomendaciones que admiten el procesamiento previo de datos de elevación al compilar una colección única o publicarla como un servicio.

• Conversión de datos de punto o TIN a un formato ráster. Hay varias herramientas de geoprocesamiento que puede elegir dependiendo del origen. Vea el conjunto de herramientas A ráster o el conjunto de herramientas Conversión de 3D Analyst.
• Para la conversión de datos LIDAR a superficies de elevación en ArcGIS 10.0, vea el blog: Soluciones LIDAR en ArcGIS parte 2: Crear DEM y DSM de ráster a partir de un punto LIDAR grande.
  Nota:

  En ArcGIS 10.1, no será necesario convertir los archivos LAS y los datasets de terreno a datasets ráster. Serán compatibles directamente con los dataset de mosaico.

• El formato óptimo para los datos de elevación es el de valores de punto flotante de 32 bits con compresión LZW almacenado en un formato TIFF en teselas. La compresión LZW no tiene pérdidas, es rápida y coloca los datos en teselas dentro de una carpeta y los valores NoData no ocupan espacio en el formato ráster.
• La recomendación general de Esri es no convertir los datos de elevación de su formato original a menos que el formato del archivo no sea eficiente y afecte el rendimiento del servidor. Por ejemplo, si cualquiera de lo siguiente es verdadero los datos se deben convertir antes de agregarlos al dataset de mosaico:
  • Si los datos de elevación se almacenan en un formato de archivo ineficiente, como ASCII XYZ (ineficiente para leer)
  • Si los archivos de datos de elevación son grandes (número de filas o columnas > 5000) y los datos no están en teselas o no tienen pirámides y el rendimiento del servidor es importante

En algunos casos, deseará ejecutar una comprobación del rendimiento antes de convertir sus datos para determinar si son aptos o se pueden optimizar con la conversión. Por ejemplo:

• Si el original está almacenado como JPEG 2000, debe tener en cuenta que se requiere tiempo para la descompresión, la cual puede tener un impacto importante en el rendimiento. Para un mejor rendimiento, es posible que necesite convertir los datos a TIFF en teselas.
• Si los datos originales están en el formato de cuadrícula de Esri, es mejor convertir si la escalabilidad es importante en un entorno de varios procesos.

Conversión de archivos

Si convierte los archivos de un formato a otro, sin necesidad de cambios en la profundidad de bits u otras propiedades del dataset, utilice la herramienta Ráster a otro formato (varios). Si debe hacer cambios en alguna de las propiedades, utilice la herramienta Copiar ráster. Al aplicar esta herramienta a varios datasets, puede hacer clic con el botón derecho en la herramienta y hacer clic en Lotes o escribir una secuencia de comandos para ingerir varios datasets. En cualquier caso, se deben establecer los entornos. Puede hacerlo en el nivel de la aplicación si lo está aplicándolo a varias herramientas o en el nivel de la herramienta.

Pasos:

1. Acceder al cuadro de diálogo Entornos.
   • Desde el menú principal, Haga clic en Geoprocesamiento > Entornos.
   • En la herramienta, haga clic en el botón Entornos.
2. Expanda la sección Almacenamiento de rásteres.
3. Active Crear pirámides.
   1. Haga clic en la flecha de la lista desplegable Técnica de remuestreo de pirámides y, a continuación, en BILINEAR.
   2. Haga clic en la flecha de lista desplegable Tipo de compresión de pirámide y en LZW.
4. Active Calcular estadísticas.
   1. Escriba 1000 para los factores de omisión x e y.

   Este valor se deriva de dividir el número de columnas por 1,000.

5. Haga clic en la flecha de lista desplegable Compresión y haga clic en LZ77.
6. Compruebe que el ancho y el alto del Tamaño de tesela sea 128.

Proyección

Si la proyección no está definida para cada dataset, utilice la herramienta Definir proyección. Para obtener más información, vea el blog. Mi imagen está en el punto incorrecto.

Por lo general, los archivos no se deben reproyectar.

Crear pirámides

Si los datos no incluyen pirámides y las teselas son grandes (con el número de filas o columnas mayor que 5.000), se recomienda crear pirámides. Para determinar si un archivo tiene pirámides, haga clic con el botón derecho en la ventana Catálogo o en la tabla de contenido, a continuación, haga clic en Propiedades y busque en Información de ráster de pirámides.

Cuando crea pirámides para varios datasets, utilice la herramienta Crear pirámides y estadísticas. Utilice las configuración del entorno arriba indicada.

Las pirámides requieren espacio adicional en disco y se escriben para archivos separados con una extensión .ovr.

Nota:

Ninguno de los datos utilizados en este flujo de trabajo tiene pirámides. Esto se debe principalmente a que se integrarán y utilizarán varias resoluciones (de ese modo se evita la necesidad de reducir las resoluciones de los datos de origen) y a la estructura en teselas de los datos (no hay ningún archivo individual extremadamente grande).

FWTools

Sugerencia:

Si el número de archivos de datos es mayor que 100.000 y se crean nuevas pirámides, es posible que prefiera escribir pirámides dentro de los archivos de datos para evitar la creación de demasiados archivos extras. Para hacerlo, se recomienda utilizar la utilidad FWTools que no se incluye en ArcGIS.

Puede descargar FWTools de http://fwtools.maptools.org y después ejecutar los siguientes comandos:

gdal_translate.exe -of Gtiff -co "TILED=YES" -co "COMPRESS=LZW" Input.xxx Output.tif gdaladdo.exe -r average -ro --config TILED YES --config PHOTOMETRIC_OVERVIEW LZW output.tif 2 4 8 16

Para imágenes de 16 bits, inserte -co NBITS=12 antes de Input.xxx.

Si los archivos que crea son de más de 4GB, inserte BIGTIFF=YES o BIGTIFF=IF_NEEDED antes de Input.xxx.

Crear estadísticas

Las estadísticas son necesarias para que el dataset ráster o dataset de mosaico realice algunas operaciones de geoprocesamiento o determinadas tareas en las aplicaciones de ArcGIS Desktop, como aplicar un aumento de contraste o clasificar datos. En este flujo de trabajo, no hay necesidad de crear estadísticas para cada fuente de datos ya que no se mostrará o utilizará ninguna propia, además, no se crearán funciones o productos que dependan de las estadísticas de los datasets individuales. Las estadísticas se generarán de los datasets de mosaico para propósitos de visualización.

Para obtener más información sobre estadísticas, vea Estadísticas del dataset ráster.