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

23

¿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?

George
fuente
Me encanta esta discusión. Sé que es un hilo viejo, pero la información es ORO. Trabajo para Esri como Product Manager de productos para desarrolladores. Cuido de ArcGIS Runtime SDK (Java, Android, Qt) y ArcObjects SDK para Java. En primer lugar, puedo empatizar con el dolor. En segundo lugar, me gustaría saber si las API web y las API ArcGIS Runtime han ayudado a mitigar los puntos débiles en el uso de la Plataforma, o solo en general. Supongo que manejar montones y montones de datos sigue siendo un desafío, pero ¿está mejorando ... ahora 5 años después? Los servicios, tanto en línea como en el portal, son cada vez más robustos. Are t
Hola Eric, bienvenido a GIS.SE. Siempre es bueno ver a los empleados de la compañía de software participar en la comunidad. Somos un poco menos foro de discusión aquí y preguntas y respuestas más específicas. Es posible que desee ver el recorrido . Tenemos un chat para conversaciones, aunque no se usa mucho. También puede echar un vistazo a nuestro sistema de etiquetado. Con eso, puede centrarse en la actividad de preguntas recientes sobre un tema en particular, como las API y los SDK que menciona.
Chris W
Del mismo modo bienvenido a GIS SE Eric! Mientras observa un poco más el sitio, espero que comprenda rápidamente de qué se trata Stack Exchange y cuán diferente es su formato de preguntas y respuestas enfocado de un foro de discusión. Es precisamente lo que esperaba que los Foros de debate de ArcGIS se convirtieran en su revisión más reciente. Sin embargo, no juzgue su valor en estas primeras preguntas y respuestas que, a pesar de su popularidad, no es un gran ejemplo de cómo los usuarios pueden venir aquí buscando una respuesta, y en unos minutos identifique la misma pregunta y lea su respuesta sin tener que para digerir una discusión de ida y vuelta.
PolyGeo

Respuestas:

22

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.

nw1
fuente
44
Soy estadístico y tengo quejas muy similares sobre los productos ESRI. Mi teoría demasiado optimista es que, debido a que las computadoras probablemente se aplicaron a las estadísticas antes de SIG, el software SIG está a unos diez años detrás del software estadístico (en su fase SAS / SPSS) y que un programa o pila de código abierto verdaderamente sobresaliente está al borde de estallar Tal vez ya lo ha sido: han pasado años desde que tuve la oportunidad de jugar con programas que no son ESRI.
Matt Parker el
2
Voy a intervenir para sacudir virtualmente mi puño en Redlands con el resto de ustedes y transmitirles una anécdota ilustrativa: prácticamente cualquier llamada de API a las API de trama de Spatial Analyst (en ese momento) fallaría con un COM genérico "Error no especificado "Si algo salió mal. Desesperado por solucionar el problema, terminé conectando strace a ArcGIS.exe y, enterrado en las llamadas al sistema, descubrí (drumroll) que se escribían mensajes de error útiles y detallados de la década de 1980 en el equivalente de windows de / dev / null.
Dan S.
13

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.

Hugo Estrada
fuente
10

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

dassouki
fuente
Networkx para shp ya existe para su información, p . Ej. Networkx.github.io/documentation/latest/reference/… Para vector + raster, vea PostGIS raster extension trac.osgeo.org/postgis/wiki/WKTRaster
ThomasG77
El mayor problema de +1 son las fuentes de datos confiables. Muchos estados contratarán pasantes universitarios para trabajos de verano para recoger las coordenadas de las carreteras y otras cosas, y generalmente no verifican ni auditan los errores (ni siquiera muestras de ello), y el resultado ahora es que el DOT de Nueva Jersey dice que un el camino es 500 pies más corto que Google y OSM dice que es. Maldita sea
nada es necesario el
8

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.

Vinko Vrsalovic
fuente
6

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.

jswise
fuente
Esto tendría que ser lo más importante para mí.
Nathan W
2
Esto es menos importante para mi. Si bien lo mejor para el desarrollador es invertir en su propio futuro y evitar el "trabajo malgastado", creo que los fines justifican los medios, y cualquier tecnología que haga el trabajo es la mejor opción. Tener una idea clara de lo que necesita entregar es más importante que cómo llegar allí.
mwalker
5

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.

wilsongis
fuente
3

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!

Vidar
fuente
2

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.

BlinkyBill
fuente
2

# 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)

revs mkadunc
fuente
2

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.

CrazyEnigma
fuente
1

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.
Chintan Pathak
fuente
0

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.

Dandy
fuente
0

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.

Eric Palakovich Carr
fuente
La mayoría hemos tenido que comprarlo a los vendedores, que realizan estudios de terreno reales y conversión de otras fuentes. En el tercer mundo, obtener datos abiertamente del Gobierno es una PITA
Devdatta Tengshe
-1

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.

conjunto vacio
fuente
2
@emptyset: soy un geógrafo que se convirtió en desarrollador. No creo que mis resultados sean "embarazosos" en el mejor de los casos. Tengo muchas más habilidades de desarrollo que otros colegas que tienen experiencia en TI, incluida una mejor comprensión y USO de los conceptos de OOP, conceptos y reglas de bases de datos, etc. Por supuesto, no estoy de acuerdo con su respuesta: P
George Silva
1
@George: Y no estoy diciendo que hayas dicho lo contrario, solo señalo que para ser un gran desarrollador debes saber cuánto apestas. Al menos lo intento.
Vinko Vrsalovic
2
+1 En numerosas ocasiones me han pedido que "solo arregle los errores" en una Big Ball of Mud en.wikipedia.org/wiki/Big_ball_of_mud escrito por uno o más analistas. Algunos de los peores códigos fueron escritos por algunos de los analistas más inteligentes. A menudo, los inteligentes no aprecian la belleza de la simplicidad. A menudo, la falla es con la administración: el analista puede darse cuenta del valor de la refactorización, pero no puede justificar pasar tiempo cambiando el código que no está roto.
Kirk Kuykendall el
3
Para el corolario, puede que tenga la mala suerte de trabajar con desarrolladores de software que se ven obligados a trabajar como profesionales de SIG. Soy muy cauteloso con cualquier persona, de cualquier campo, que solo se dé cuenta de las cosas a medida que avanzan en SIG. Soy un analista que explora el desarrollo, y espero y quiero que la gente desconfíe de mi código. Cualquier desarrollador que sienta que lo está haciendo bien en SIG, probablemente no. :-)
matt wilkie
3
-1 - declaración muy amplia que es demostrablemente falsa y algo ofensiva. Como Matt W implica arriba, generalmente es mejor tener una persona de SIG que viene a la codificación que al revés porque hay muchos más recursos para ayudarlo a aprender la codificación e implementar las mejores prácticas que las que hay en SIG
dmbrubac
-1

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.

Rodolfo Moreno
fuente