¿Cuáles son sus mayores retos como desarrollador de SIG?

Question

¿Cuáles son sus mayores retos a la hora de desarrollar software SIG?

¿Es codificación? ¿Se trata de entender conceptos de cartografía/geografía/etc (como las proyecciones)? ¿O de otras dificultades?

Answer 1

Hablo desde mi experiencia como desarrollador que cayó en la escena del desarrollo de ESRI/GIS hace casi 5 años:

1. No existe una única API para hacer lo que usted desea. Sólo un embrollo de APIs que pueden o no funcionar para sus propósitos: ArcObjects, Python, REST, SOAP, ADF, operadores ST_Geometry?
2. Todas las API están vinculadas a una pieza de software engorrosa y cara que preferirías no colocar en el núcleo de tu aplicación.
3. Pocas oportunidades para un diseño realmente creativo. ¿Estructuras de datos geoespaciales orientadas a objetos? Olvídelo. A pesar de toda la palabrería sobre "objetos" y "clases de características", sigues trabajando con tablas tontas mediadas por un middleware caprichoso.
4. El software tiene fallos, los mensajes de error son engañosos y la documentación es incompleta. La resolución de problemas es casi siempre por ensayo y error. Acostúmbrese a ello.
5. Gestionar datos geoespaciales con métodos de bases de datos relacionales es casi imposible. He tenido que abandonar prácticamente cualquier SQL/DDL porque me meten en problemas con el middleware (sí, estoy hablando de ArcSDE). Es una pena tirar por la borda todo un conjunto de habilidades. Basta con abrir ArcCatalog, apuntar, hacer clic.

Como se puede deducir, tengo una visión bastante negativa de la escena de desarrollo de ESRI. Estoy seguro de que las posibilidades que ofrece son muy interesantes para los geógrafos. Pero para alguien como yo, a quien le encantan las bases de datos relacionales, la programación orientada a objetos y las oportunidades abiertas para soluciones creativas, el desarrollo de SIG con ESRI es muy restrictivo e insatisfactorio. Es una pena, porque la gente de la vieja escuela me dice que solía ser un entorno superior, antes de la alineación con Microsoft. Espero sinceramente que la comunidad de código abierto siga innovando.

Answer 2

Grandes cantidades de datos. Encontrar la forma correcta de extraer grandes cantidades de datos utilizando la tecnología web ha sido todo un reto. Podemos tener muchos datos y un rendimiento deficiente, o mostrar muchos menos datos, pero transmitiendo potencialmente una información errónea.

Answer 3

No soy desarrollador SIG, pero sí modelador SIG:

Desafíos:

• Recopilación, agregación, desagregación, fusión y división de datos: Obtengo datos de varias fuentes para distintos proyectos; el mayor problema suele ser conseguir todos los datos de la misma parcela/zona geográfica. Normalmente tengo que utilizar algunas de las técnicas mencionadas en cada conjunto de datos, para tener una muestra coherente para el proyecto. Esto aumenta las probabilidades de error y diluye nuestra precisión.

• No soy desarrollador; repito que no soy desarrollador: Cuando ustedes, gente encantadora, hablan de SOAP, SHAMPOO, REST, GIS-T Indexes, etc. esto significa mucho para ustedes. Para mí es sobre todo jerga. Suelo tener una gran curva de aprendizaje o una subida empinada para conseguir hacer algunas de las cosas sencillas.

• La brecha entre el software libre y el software propietario: Me encanta QGIS y postgis a la muerte, literalmente, los tengo instalados en cada máquina, sin embargo, cuando quiero hacer un análisis basado en el transporte, tengo que recurrir a TransCAD o EMME2/3. Cada uno cuesta alrededor de $ 15.000 con las campanas de la demanda. Cada uno de ellos cuesta unos 15.000 dólares, con todas las campanas y silbatos. Para ser justos, todos estos problemas podrían resolverse si existiera un paquete networkx para archivos shp.

• Cuestión de disciplinas múltiples: Conozco bien las técnicas de modelización del transporte; sin embargo, se me dan fatal los modelos demográficos y, por lo que sé, tengo que utilizar sofisticadas herramientas de R para conseguir mis datos. Así que el problema de los SIG es que son un campo multidisciplinar en el que es difícil sobrevivir por uno mismo.

• Falta de herramientas y programas informáticos bien establecidos para pasar del uso del suelo con imágenes al uso del suelo con vectores: Preveo un futuro en el que una herramienta analizará la imagen de satélite GEOEYE y comparará los usos del suelo en ella con una base de datos vectorial (as built)

• A veces es más rápido hacer las cosas en Excel/"tu programa de hojas de cálculo favorito va aquí": A veces quiero hacer el análisis de tránsito, es mucho más rápido para agarrar los datos ponerlos en Excel, hacer el trabajo de fórmulas, a continuación, volcar los datos de nuevo en Postgis como un archivo CSV y regenerar el mapa. Tal división, especialmente en el mundo OpenSource debe ser mejor manejado.

En cualquier caso, puede que no te haya respondido correctamente; sólo me gustaría estar bien versado en programación SIG para poder destacar en modelado SIG.

Answer 4

Las cosas más importantes, y normalmente las más difíciles según mi experiencia, son:

1. obtener los datos adecuados para el trabajo
2. conseguir que se muestre en la proyección adecuada (y que todas las capas coincidan.) Especialmente cuando proceden de fuentes diferentes.
3. diseñar una aplicación utilizable. Es fácil y tentador poner un montón de campanas y silbatos que sólo confunden a los usuarios.

Creo que el punto 1 será más fácil en los países desarrollados, pero esa no es mi experiencia.

Answer 5

Para mí, el mayor reto es decidir qué herramientas utilizar para un proyecto determinado. ¿Código abierto o propietario? ¿Python o .NET? ¿Basado en web o de escritorio? Mi respuesta a estas preguntas varía según el proyecto, y estoy seguro de que la gente las planteará todas en este sitio. En gran medida, se trata de preferencias personales y de adivinar lo que ESRI y Microsoft ofrecerán en el futuro.