33 votos

¿Busca opciones para el ETL (Extracción, Transformación y Carga) espacial?

Estoy interesado en los pros y los contras de varias herramientas ETL (extraer, transformar, cargar) espaciales. Si has utilizado los elementos que aparecen aquí (o añades los tuyos propios), busco tus opiniones y experiencias. En particular, me gustaría ver comparaciones de usabilidad de:

No es necesario hacer una revisión de TODO el software mencionado. Si usted tiene experiencia con uno de ellos, será muy beneficioso para tomar una decisión sobre la dirección a seguir.

Ejemplo: Estoy buscando crear una función de conversión de esquemas que me permita seleccionar la capa de entrada, crear una traducción, y la salida a un nuevo esquema predefinido. En el mejor de los casos, después de crear la secuencia de comandos de traducción, me gustaría tener un formulario interactivo donde pueda "mapear" los campos de mi capa de entrada a la capa de salida (es decir, la capa de salida tendrá un campo llamado "Dirección", ¿cómo se llama en la capa de entrada?)

Algunos se mencionaron en las preguntas y respuestas en ¿Qué herramientas existen para cargar los datos del GIS en una base de datos?

Y aquí hay un par de artículos relacionados que he encontrado.

24voto

Swinders Puntos 1042

Para un proyecto reciente que trabaja con varios GB de datos espaciales, comencé la carga de datos / reproyecciones con FME. Funcionó bien, pero hay una curva de aprendizaje.

Al final del proyecto estaba usando scripts de Python para automatizar los procesos de reaminación. FME se puede programar con scripts, pero si tienes los fundamentos de Python, ¿por qué complicar más las cosas? Python te da una flexibilidad total y con cada script de importación que escribes tus conocimientos de Python mejoran.

Los siguientes paquetes de Python me resultaron muy valiosos a la hora de trabajar con transformaciones de datos:

  • PyProj
  • GeoPy
  • Shapely
  • xlrd para importar datos de hojas de cálculo de Excel
  • pyobdc para conectarse a las bases de datos
  • SQLAlchemy para ejecutar sentencias SQL y trabajar con bases de datos

Si tienes una formación de desarrollador / programador te recomendaría usar Python, si prefieres trabajar con una GUI (que además puede generar bonitas imágenes para la documentación) te recomendaría FME.

17voto

Scott Saad Puntos 247

Esta pregunta ha sido convertida a la Wiki de la Comunidad y a la wiki bloqueada porque es un ejemplo de pregunta que busca una lista de respuestas y parece ser lo suficientemente popular como para protegerla del cierre. Es debe ser tratada como un caso especial y no debe ser vista como el tipo de pregunta que se fomenta en este, o cualquier sitio de Stack Exchange pero si deseas contribuir con más contenido, siéntete libre de hacerlo editando esta respuesta. de hacerlo editando esta respuesta.


Sólo hablaré de lo que he visto en un contexto profesional. Una estudiante mía trabajó con una empresa encargada de recibir, validar e integrar enormes cantidades de datos espaciales, de una fuente bien conocida (TeleAtlas) en su SIG. Utilizó varios flujos de trabajo utilizando FME, haciendo verificaciones y transformaciones muy complicadas sobre la marcha, de un formato a otro, como la selección de características, la verificación de la topología, la eliminación de duplicados, etc. El flujo de trabajo fue capaz de procesar automáticamente los conjuntos de datos entrantes.

Estuve en un jurado para un informe de prueba viva (lo siento, traducción de google de "soutenance de rapport de stage"), donde el estudiante describió otro flujo de trabajo FME como este, pero esta vez para validar los conjuntos de datos regionales enviados al nivel nacional para su integración en la base de datos nacional de riesgos. La principal diferencia es que en este último ejemplo los conjuntos de datos estaban en muy diversos formatos de archivo, raster y vectorial, escalas y estilos.

Por último, he probado Spatial Data Integrator, el ETL de código abierto basado en Talend Open Studio. Las características eran numerosas, aunque menos que las de FME, pero creo que las principales diferencias estaban en la documentación y la facilidad de uso de la creación del flujo de trabajo. A menudo me vi obligado a modificar el código fuente java de los componentes del flujo de trabajo. Pero era una versión anterior de SDI, y las deficiencias que describo aquí son algo habitual en los proyectos de código abierto en sus inicios, y no podemos comparar al mismo nivel el software propietario bien perfeccionado y los jóvenes contendientes de código abierto.

10voto

rkthkr Puntos 6651

Me encanta el código abierto, pero FME gana fácilmente a los ETL de código abierto por lo que veo. En realidad es bastante barato para el mantenimiento y el apoyo también (al menos en comparación con la mayoría de otras soluciones corporativas que tenemos para las cosas).

Si busca traducciones entre formatos, entonces OGR puede hacerlo (con algunas tuberías en GDAL para las transformaciones). Por supuesto, eso es línea de comandos .

Para modelado visual más allá de los enumerados en el comentario de "posible duplicado", están trabajando en un constructor de modelos QGIS/SEXTANTE; vídeo de prueba de concepto: https://www.youtube.com/watch?v=LTUu-I2ouqU

(No, no trabajo para Safe, sólo soy un cliente relativamente satisfecho).

8voto

Raoul Puntos 1113

La mayoría de las operaciones sencillas pueden realizarse con estas utilidades de código abierto

  • ogr2ogr para el vector
  • gdal_translate y gdalwarp para raster

Obtener FWtools http://fwtools.maptools.org/ y probarlo.

8voto

Diskilla Puntos 166

Lo hice una comparación de varias herramientas hace un año que también contiene la mayoría de las opciones mencionadas en este hilo.

Como respuesta más directa, uso mucho FME debido a su versatilidad. Sin embargo, cuando trabajo con estructuras de datos complejas como en CityGML, INSPIRE GML o modelos de bases de datos más grandes, uso HALE una aplicación de código abierto desarrollada para ETL y, en particular, para la armonización.

enter image description here

Actualmente (a partir de la versión 2.9.0) se compara con FME (2014 SP1) de la siguiente manera:

  • HALE tiene un menor número de formatos (HALE: 20, FME 200) y transformadores (HALE: 30+, FME: más de 400), pero muy buen soporte para todos los dialectos XML/GML
  • HALE previsualiza los resultados de la transformación de forma interactiva en un mapa y en vistas de tabla, y valida los resultados directamente
  • HALE es generalmente mucho más rápido, ya que se mantiene el contexto local para cada atributo, ahorrando un montón de FeatureMergers, por ejemplo
  • HALE es de código abierto y se utiliza en producción desde 2010
  • HALE utiliza una interfaz de usuario de mapeo declarativo, lo que conduce a un menor número de entradas de usuario requeridas en comparación con los enfoques de procedimiento

Hay que tener en cuenta que llevo bastantes años en el equipo de HALE.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X