¿Cuáles son sus mayores desafíos como desarrollador de SIG?

¿Cuáles son sus mayores desafíos al desarrollar software SIG?

¿Es codificación? ¿Es entender conceptos de cartografía / geografía / etc. (como proyecciones)? U otras dificultades?

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

1. No hay una API única para hacer lo que quieres hacer. Solo un lío confuso de API que pueden o no funcionar para sus propósitos: ¿ArcObjects, Python, REST, SOAP, ADF, ST_Geometry operadores?
2. Todas las API están vinculadas a una pieza de software costosa y costosa que preferiría no colocar en el núcleo de su aplicación.
3. Poca oportunidad para un diseño verdaderamente creativo. ¿Estructuras de datos geoespaciales orientadas a objetos? Olvídalo. A pesar de todo lo que se habla sobre "objetos" y "clases de entidad", todavía estás trabajando con tablas tontas mediadas por middleware caprichoso.
4. El software tiene errores, los mensajes de error son engañosos y la documentación está incompleta. La resolución de problemas casi siempre es prueba y error. Acostumbrarse a él.
5. La gestión de datos geoespaciales utilizando métodos de bases de datos relacionales es casi imposible. Casi he tenido que abandonar cualquier SQL / DDL porque me metieron en problemas con el middleware (sí, estoy hablando de ArcSDE). Es una pena tirar todo un conjunto de habilidades. Simplemente abra ArcCatalog, apunte, haga clic.

Como puede ver, tengo una perspectiva bastante negativa en la escena de desarrollo de ESRI. Para aquellos que provienen de un entorno geográfico, estoy seguro de que las posibilidades son bastante emocionantes. Pero para alguien como yo que ama 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 limitante y poco satisfactorio. 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 continúe innovando.

Grandes cantidades de datos. Poder encontrar la forma correcta de extraer grandes cantidades de datos utilizando la tecnología web ha sido un desafío. Podemos tener muchos datos y un rendimiento deficiente, o mostrar muchos menos datos, pero potencialmente transmitir la información incorrecta.

No soy un desarrollador de SIG; Sin embargo, soy un modelista SIG:

Desafíos:

• Recopilación, agregación, desagregación, fusión y división de datos : obtengo datos de varias fuentes para diferentes proyectos; El mayor problema suele ser obtener todos los datos para la misma parcela / área geográfica. Por lo general, tengo que usar algunas de las técnicas mencionadas anteriormente 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 un desarrollador; Repito que no soy un desarrollador: cuando ustedes, gente encantadora, hablan de SOAP, SHAMPOO, REST, GIS-T Indexes, etc., esto significa mucho para ustedes. Para mí sobre todo es jerga. Por lo general, tengo una gran curva de aprendizaje o una subida empinada para hacer algunas de las cosas simples.

• La brecha entre FOSS y el software propietario: me encantan QGIS y postgis hasta 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 todas las campanas y silbatos. Para ser justos, todos estos problemas podrían resolverse si hubiera un paquete networkx para archivos shp.

• Problema de múltiples disciplinas: estoy bien versado en técnicas de modelado de transporte; Sin embargo, apesta al modelado demográfico y, por lo que puedo decir, tengo que usar herramientas sofisticadas de R para hacer mis datos. Entonces, el problema SIG es que el SIG es un campo multidisciplinario que es difícil de sobrevivir por sí solo.

• Falta de herramientas y software bien establecidos para pasar del uso de la tierra de imágenes al uso de la tierra de vectores: preveo un futuro en el que una herramienta analizará la imagen de satélite GEOEYE y comparará los usos de la tierra con una base de datos de vectores (tal como está construida)

• A veces es más rápido hacer cosas en Excel / "su programa favorito de hoja de cálculo va aquí: a veces quiero hacer un análisis de tránsito, es mucho más rápido tomar los datos y ponerlos en Excel, hacer que las fórmulas funcionen, luego volcar los datos en postgis como un archivo csv y regenerar el mapa. Tal división, especialmente en el mundo OpenSource, debería manejarse mejor.

De todos modos, puede que no te haya respondido correctamente; Solo desearía estar bien versado en lo que respecta a la programación SIG para poder sobresalir en el modelado SIG

Las cosas más importantes, y generalmente las más difíciles en mi experiencia, son:

1. obtener los datos correctos para el trabajo
2. haga que se muestre en la proyección adecuada (y que todas las capas estén de acuerdo). Especialmente cuando provienen de diferentes fuentes
3. diseñar una aplicación utilizable Es fácil y tentador poner muchas campanas y silbatos que solo confundirán a los usuarios

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

Para mí, el mayor desafío es decidir qué herramientas usar para un proyecto determinado. ¿Código abierto o propietario? Python o .NET? ¿Basado en la web o en el escritorio? Respondo estas preguntas de manera diferente para diferentes proyectos, y estoy seguro de que la gente las hará todas en este sitio. Mucho de esto se reduce a preferencias personales y a tratar de adivinar lo que ESRI y Microsoft admitirán en el futuro.

Mi problema es sobre el caballo y el agua. En muchos casos desarrollamos y / o presentamos soluciones realmente buenas para nuestros clientes, pero no importa cuán elegante sea la solución, es absolutamente inútil si nadie se toma el tiempo de usarla. En algunos casos, hemos podido aliviar esto haciendo que nuestro trabajo se base en el usuario (encuesta de problemas, conversación sobre soluciones antes del desarrollo), pero en algunos casos esto aún no es suficiente.

Creo que el desafío más difícil es lograr que la administración entienda los SIG y algunos usuarios tampoco lo entienden. La percepción es que GIS se trata de hacer un mapa; que un mapa es el único resultado de cualquier compromiso SIG. No puedo decir lo frustrante que encuentro esto: el nivel de ignorancia es enorme, y lo toman los tomadores de decisiones clave.

Eventualmente, sin embargo, siendo algunos de los pioneros expertos y programadores de SIG, eventualmente se convertirá en gerencia y finalmente podremos realizar algunos proyectos de SIG decentes.

La otra cosa difícil como programador de SIG: debe comprender tantas tecnologías diferentes, Java, .Net, bases de datos, software ESRI u otros proveedores, es decir, MapInfo, redes, seguridad, tecnología web, etc. ¡Es un trabajo casi imposible a veces!

Tratar con personas de un entorno de encuestas que no entienden las técnicas y metodologías profesionales de desarrollo de software, pero debido a que se enseñaron a sí mismas cómo codificar avenue / VB, piensan que eso es todo.

# 3 de la respuesta de Vinko :

diseñar una aplicación utilizable Es fácil y tentador poner muchas campanas y silbatos que solo confundirán a los usuarios.

Votaría por la respuesta completa, pero por el hecho de que la usabilidad es solo el tercer elemento de su lista y no creo que los dos primeros sean tan desafiantes.

La usabilidad es donde están la mayoría de mis problemas y donde paso la mayor parte del tiempo de diseño / desarrollo, descubriendo cómo diseñar una interfaz de usuario inteligente y efectiva, pero manteniéndola intuitiva para que los usuarios no se confundan con ella, por ejemplo:

• Cómo ajustar el estilo (y elegir las capas) de un mapa interactivo para mostrar la información relevante y evitar el desorden que a menudo se presenta al mostrar demasiados datos (por ejemplo, mediante la agregación automática de entidades de puntos); Sé que esto es lo que la cartografía ha tratado de resolver durante siglos, pero el problema solo empeora con los mapas digitales / interactivos.

• Cómo hacer un posicionamiento automático de la vista del mapa en función de la consulta / selección de características del usuario

• Resaltando las características 'seleccionadas': muestra el resaltado brevemente, resalta todo el tiempo que se selecciona una característica, desmarca el resaltado cuando la tabla (o lista) de selección pierde el foco ... Cómo resaltar ambas consultas resultados de una tabla y la fila seleccionada dentro de esa tabla (sin tener demasiados botones de alternancia)

• Mostrar información adicional en listas de capas o entidades, por ejemplo, la visibilidad de una capa / estilo aplicado / tipo de geometría, estado / clase de entidad ... Esto se vuelve aún más complicado en caso de que se muestren diferentes tipos de entidad en la misma lista (supongo que es por eso Google y Bing Maps utilizan un filtro bastante pesado de los resultados de búsqueda)

• Edición eficiente: ajuste, cierre de polígonos, agregar / mover / eliminar puntos, sin tener muchos botones de barra de herramientas.

• Cómo diseñar (e implementar) una interfaz de consulta amigable para el usuario para consultas de geometría, y aún más desafiante, una interfaz para consultas que incluye tanto atributos como geometría; sin hacer que el usuario escriba algo parecido a SQL.

• Cómo diseñar algo como un portapapeles para características / geometrías para evitar tener que 'elegir' continuamente una característica del mapa para usarla en consultas, ediciones ...

Creo que el SIG es un campo especialmente desafiante en el aspecto de usabilidad, porque:

• La ubicación es el contexto universal y generalmente el más natural para cualquier información, por lo que siempre hay demasiada información disponible para mostrar

• Al tener la información mostrada en un mapa, uno se siente fácilmente tentado a subestimar la importancia de las partes de la interfaz de usuario que no son SIG

• La industria ha descuidado tradicionalmente el aspecto de usabilidad del software SIG, y se salieron con la suya porque el mapeo digital fue visto como un oficio técnico con una curva de aprendizaje lenta y había conceptos mucho más difíciles de aprender que cómo usar la interfaz. Esto significa que cualquiera que intente diseñar una interfaz SIG para el no experto tiene que inventar sus propios principios que están condenados a ser confusos (un buen ejemplo sería 'Mis mapas' de Google o 'Mis lugares' de Bing Maps)

Uno de los mayores desafíos para el desarrollo de SIG basado en la web es cómo se entregan los datos y cuánta eficiencia puedo obtener al entregar los datos de cierta manera. El mayor obstáculo es que es muy difícil escribir código para algo que requiere que un humano lo modifique. Muy raramente ve técnicas de generalización para datos vectoriales utilizados a grandes escalas. La mayoría de las veces tiene que ajustar los rangos de escala para activar y desactivar las capas.

Esta pregunta surgió en mi búsqueda en Google de desafíos en SIG, y tengo ganas de contribuir aquí.

Otro vínculo que me pareció relevante fue este documento.

Resumiendo lo que se dice allí y mis propios puntos de vista, creo que los mayores desafíos (sin ningún orden en particular son):

• Interfaz de usuario: con el host de opciones de interfaz de usuario, es un desafío para el desarrollador optimizar la oferta para adaptarse a todos los dispositivos. Basado en el tacto vs escritorio vs portátil. La idea de DE presentada por Gore, que cuenta con auriculares portátiles con pantalla, guantes con control de dirección y reconocimiento de voz, es un futuro elegante.
• Estandarización: con los estándares para el almacenamiento y recuperación de datos, podríamos tener geo-bases de datos que descansen en la nube y permitan la obtención de información en la ejecución para que una exploración y uso de SIG se pueda hacer sin problemas.
• Uso de datos: los tomadores de decisiones siempre están presionados por el tiempo. Si una herramienta es para ayudarlos, debe hacerlo de una manera fácil, rápida y sin problemas. Parece que el SIG no se ha entregado en este frente y esa es una de las razones por las que todavía no es una palabra de moda.
• Datos: los datos son variados, dispersos y ruidosos. Incluso para organizaciones con incentivos claros en un SIG en tiempo real, la agregación de datos es un obstáculo aún demasiado grande para prever la entrada.
• Esfuerzo coordinado: el SIG es multidisciplinario. Todo niño lo sabe. La gerencia se da cuenta de eso en la primera diapositiva. Aunque tales proyectos multidisciplinarios y multidepartamentales son raros.

Cuando se trata de codificación, siento que pierdo demasiado tiempo en soluciones alternativas. Para las proyecciones, me llevó un par de meses comprender los procesos y las matemáticas, ya que en mi opinión hay poco material publicado útil sobre el tema. Los documentos EPSG y OGC sobre el tema me ayudaron a entenderlo después de algunas lecturas, a pesar de que a veces parecen ser copias el uno del otro. Sin embargo, el mayor problema que tengo como desarrollador independiente es que no puedo evitar tropezar con las personas que necesitan trabajo especializado para el desarrollo de aplicaciones web médicas, industriales o incluso simples, incluso ahora. Con la industria de SIG, parece casi imposible encontrar una manera de ingresar al mercado.

Soy un principiante completo en tecnologías SIG, descubriendo las cosas a medida que avanzo. Y dado que tengo fondos limitados, estoy tratando de evitar el uso de productos ESRI y hacer cosas completamente con herramientas de código abierto.

Dicho esto, las cosas más difíciles para mí hasta ahora han estado relacionadas con la recopilación de datos. Hay muchos artículos sobre cómo manipular y mostrar los datos, y muchas herramientas para facilitarle la vida. Pero sigo caminando en la oscuridad cuando se trata de recopilar datos.

No tengo idea de lo que hacen los profesionales para buscar y recopilar datos. Algo me dice que hay una manera más fácil de obtener datos que data.gov y google.

Puede ser desafortunado verse obligado a trabajar con analistas de SIG que se han convertido en desarrolladores de software.

Es fácil esperar que un desarrollador de software competente capte los conceptos de SIG y los deje pasar por la API y, en general, resolver las cosas sin mucha ayuda. Lo mismo no es cierto de tomar un analista de SIG y esperar que recoja el desarrollo de software.

Los resultados son vergonzosos , en el mejor de los casos. Si tienes experiencia trabajando con malos desarrolladores , entonces imagina que es peor código que cualquier cosa que el peor programador haya desarrollado.

Hay algunas compañías para las que puede trabajar que no entienden eso.

El mundo SIG se está expandiendo hacia el usuario común, a menos que los primeros años en que el SIG solo haya sido tratado por ingenieros, arquitectos o la comunidad científica. En el caso de que la aplicación SIG esté hecha para el usuario común, el desafío es combinar adecuadamente las tecnologías en las que el SIG se trata más como una tecnología (en este caso, un desarrollador con un poco de comprensión de la tecnología SIG es suficiente). Sin embargo, en el caso de que la aplicación esté hecha para la comunidad especializada, el desafío es más complejo porque además de unir las tecnologías es necesario buscar algoritmos existentes para cumplir con los requisitos, de lo contrario, aún peor tendríamos que desarrollar estos algoritmos. En este caso, una combinación de ingeniero y desarrollador es el trabajador apropiado.