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 for Desktop para administrar los datos y ArcGIS for 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 for Desktop.
Este flujo de trabajo pretende abordar los datos de elevación basados en celda de ráster y los datos de punto 3D almacenados como archivos LAS (el dataset LAS y los formatos de dataset de terreno también se pueden 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.
- Almacenamiento de datos (tamaño, requisitos y ubicaciones).
- Preparar datos (puede requerir procesamiento previo).
- Crear un dataset de mosaico para captura (origen).
- Crear un dataset de mosaico para captura (principal).
- 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 obtener información sobre una metodología de diseño que describe un sistema de información geográfica satisfactorio, consulte las Estrategias de diseño del sistema de Esri
.
Uno de los aspectos que cabe mencionar es 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 descritos en la Parte 3 cómo esto puede servirle de ayuda en la carga datos, en la garantía de calidad y el control de calidad (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 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 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 y después proporcionar 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 necesita tener acceso fácil a 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 que representa 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 se proporcionan al usuario sin transmitir los datos de origen. Los ejemplos incluyen:
- 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
- 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
- Planificación industrial: para perfiles de viento y visibilidad para ubicaciones de granjas de viento o diseño de presas hidroeléctricas
- Cálculo 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). Los ejemplos incluyen:
- 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 cambia 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 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 la extracción de los datos dentro de una extensión específica y referencia espacial. Exportar puede proporcionar los valores de datos sin procesar, una versión remuestreado de ellos, o una versión transformados como un sombreado o pendiente de la imagen. 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 adquiere 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 pueden proceder de diversas fuentes. En este caso en particular los datos los proporciona el Sistema Regional de información del suelo de Oregón (RLIS). |
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 capturas de datasets muy grandes de manera eficiente, reduciendo los costes 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 captura 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, 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.
Normalmente, es aconsejable dividir 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. Puede administrar sus imágenes en un dataset de mosaico y utilizar 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 captura de imágenes parecidas. Puede utilizar varios datasets de mosaico de origen para administrar distintas capturas, 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): utilizado 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 de 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 pueden 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 muestran edificios, cubiertas forestales, 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 depende de las aplicaciones que los datos deben admitir. Entre las opciones se incluyen las siguientes:
- 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 genera un error. Un método fácil para rellenar con valores cero es agregar una imagen de simulación mundial y resolución muy baja en el dataset de mosaico, donde todos los valores de los píxeles son 0. A continuación, 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 permiten la 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 subsuperficie 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 de menor resolución creadas para aumentar la velocidad de visualización y reducir el uso de la CPU, dado que se examinan menos rásters para mostrar 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).
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, usted puede consultar esta información fácilmente en el dataset de mosaico.
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 captura ú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. Consulte el conjunto de herramientas A ráster o el conjunto de herramientas Conversión de 3D Analyst.
- Los archivos LAS, el dataset de LAS y los datasets de terreno no se deben convertir a los datasets ráster. Se admiten directamente en el 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 algo 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 los archivos se convierten 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, haga 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.
- Acceder al cuadro de diálogo Entornos.
- En el menú principal, Haga clic en Geoprocesamiento > Entornos.
- En la herramienta, haga clic en el botón Entornos.
- Expanda la sección Almacenamiento de rásteres.
- Active Crear pirámides.
- Haga clic en la flecha de la lista desplegable Técnica de remuestreo de la pirámide y, a continuación, en BILINEAR.
- Haga clic en la flecha de lista desplegable Tipo de compresión de la pirámide y en LZW.
- Marque Calcular estadísticas.
- 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.
- Haga clic en la flecha de lista desplegable Compresión y haga clic en LZ77.
- Compruebe que el ancho y el alto del Tamaño de tesela son 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, consulte el blog Mi imagen está en el punto incorrecto.
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, haga clic en Propiedades y, a continuación, 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 la 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.
FWTools
Descargue FWTools de http://fwtools.maptools.org y ejecute 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 creados son de más de 4 GB, 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 for 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.