Quels sont vos plus grands défis en tant que développeur SIG?

23

Quels sont vos plus grands défis lors du développement de logiciels SIG?

Est-ce du codage? Comprend-il des concepts de cartographie / géographie / etc. (comme les projections)? Ou d'autres difficultés?

George
la source
J'AIME cette discussion. Je sais que c'est un vieux fil, mais les informations sont GOLD. Je travaille pour Esri en tant que chef de produit des produits de développement. Je m'occupe des SDK ArcGIS Runtime (Java, Android, Qt) et des SDK ArcObjects pour Java. Tout d'abord, je peux comprendre la douleur. Deuxièmement, j'aimerais savoir si les API Web et les API ArcGIS Runtime ont contribué à atténuer les problèmes liés à l'utilisation de la plate-forme, ou simplement en général. Manipuler beaucoup et beaucoup de données est toujours un défi, je suppose, mais ça va mieux ... maintenant 5 ans plus tard? Les services, à la fois en ligne et sur le portail, deviennent plus robustes. Sont t
Salut Eric, bienvenue sur GIS.SE. C'est toujours bon de voir les employés des éditeurs de logiciels participer à la communauté. Nous sommes un peu moins un forum de discussion ici et des questions-réponses plus spécifiques. Vous voudrez peut-être consulter la visite . Nous avons un chat pour les conversations, bien qu'il ne soit pas très utilisé. Vous pouvez également jeter un œil à notre système de marquage. En utilisant cela, vous pouvez affiner l'activité récente des questions sur un sujet particulier, comme les API et les SDK que vous mentionnez.
Chris W
Bienvenue également au GIS SE Eric! En parcourant davantage le site, j'espère que vous comprendrez rapidement en quoi consiste Stack Exchange et à quel point son format de questions / réponses est différent d'un forum de discussion. C'est précisément ce que j'avais espéré que les forums de discussion ArcGIS deviendraient dans leur refonte la plus récente. Cependant, veuillez ne pas juger de sa valeur sur ces premières questions et réponses qui, malgré sa popularité, ne sont pas un excellent exemple de la façon dont les utilisateurs peuvent venir ici à la recherche d'une réponse, et en quelques minutes identifiez la même question et lisez sa réponse sans avoir pour digérer une discussion dans les deux sens.
PolyGeo

Réponses:

22

Parlant de mon expérience en tant que développeur tombé sur la scène du développement ESRI / GIS il y a près de 5 ans:

  1. Il n'y a pas d'API unique pour faire ce que vous voulez faire. Seul un désordre d'API qui peut ou non fonctionner pour vos besoins: opérateurs ArcObjects, Python, REST, SOAP, ADF, ST_Geometry?
  2. Toutes les API sont liées à un logiciel lourd et coûteux que vous préférez ne pas placer au cœur de votre application.
  3. Peu d'opportunités pour un design vraiment créatif. Structures de données géospatiales orientées objet? Oublie. Malgré toutes les discussions sur les "objets" et les "classes d'entités", vous travaillez toujours avec des tables stupides médiées par un middleware capricieux.
  4. Le logiciel est bogué, les messages d'erreur trompeurs et la documentation incomplète. Le dépannage est presque toujours un essai et une erreur. Habituez-vous.
  5. La gestion des données géospatiales à l'aide de méthodes de bases de données relationnelles est presque impossible. J'ai à peu près dû abandonner tout SQL / DDL car ils me causent juste des problèmes avec le middleware (oui, je parle d'ArcSDE). C'est dommage de jeter un ensemble complet de compétences. Ouvrez simplement ArcCatalog, pointez, cliquez.

Comme vous pouvez le constater, j'ai une vision assez négative de la scène du développement ESRI. Pour ceux qui viennent d'un milieu géographique, je suis sûr que les possibilités sont assez excitantes. Mais pour quelqu'un comme moi qui aime les bases de données relationnelles, la programmation orientée objet et les grandes opportunités de solutions créatives, le développement de SIG avec ESRI est très contraignant et peu satisfaisant. C'est dommage car la foule de la vieille école me dit que c'était un environnement supérieur, avant l'alignement avec Microsoft. J'espère sincèrement que la communauté open source continue d'innover.

nw1
la source
4
Je suis statisticien et j'ai des plaintes très similaires concernant les produits ESRI. Ma théorie trop optimiste est que, parce que les ordinateurs ont probablement été appliqués aux statistiques avant le SIG, le logiciel SIG a environ dix ans de retard sur le logiciel statistique (dans sa phase SAS / SPSS) et qu'un programme ou une pile open source vraiment exceptionnel est sur le point d'éclater. Peut-être que c'est déjà le cas - cela fait des années que je n'ai pas eu la chance de jouer avec des programmes non-ESRI.
Matt Parker
2
Je vais juste sonner pour secouer virtuellement mon poing à Redlands avec le reste d'entre vous, et transmettre une anecdote illustrative: à peu près tout appel d'API dans les API raster de Spatial Analyst (à l'époque) échouerait avec une erreur générique COM "non spécifiée" "si quelque chose tournait mal. Désespéré de résoudre les problèmes, j'ai fini par connecter strace à ArcGIS.exe et, enfoui dans les appels système, j'ai trouvé (drumroll) que des messages d'erreur utiles et détaillés des années 1980 étaient écrits dans l'équivalent Windows de / dev / null.
Dan S.
13

De grandes quantités de données. Être en mesure de trouver la bonne façon d'extraire de grandes quantités de données à l'aide de la technologie Web a été un défi. Nous pouvons soit avoir beaucoup de données et de mauvaises performances, soit afficher beaucoup moins de données, mais potentiellement transmettre des informations erronées.

Hugo Estrada
la source
10

Je ne suis pas développeur SIG; cependant, je suis un modélisateur SIG:

Défis:

  • Collecte, agrégation, désagrégation, fusion et fractionnement des données : j'obtiens des données de diverses sources pour différents projets; le plus gros problème est généralement d'obtenir toutes les données pour la même parcelle / zone géographique. Je dois généralement utiliser quelques-unes des techniques mentionnées ci-dessus sur chaque ensemble de données, pour avoir un échantillon cohérent pour le projet. Cela augmente les probabilités d'erreur et dilue notre précision.

  • Je ne suis pas développeur; Je le répète, je ne suis pas un développeur: quand vous, les gens adorables, parlez de SOAP, SHAMPOOING, REST, GIS-T Index, etc., cela signifie beaucoup pour vous. Pour moi, c'est surtout du jargon. J'ai généralement une grande courbe d'apprentissage ou une montée raide pour faire certaines choses simples.

  • L'écart entre les logiciels libres et propriétaires: j'aime QGIS et les postgis à mort; je les ai littéralement installés sur chaque machine; cependant, quand je veux faire une analyse basée sur le transport, je dois recourir à TransCAD ou EMME2 / 3. Chacun coûte environ 15 000 $ avec toutes les cloches et les sifflets. En toute honnêteté, tous ces problèmes pourraient être résolus s'il y avait un package networkx pour les fichiers shp.

  • Problème de disciplines multiples: je connais bien les techniques de modélisation des transports; Cependant, je crains la modélisation démographique, et pour autant que je sache, je dois utiliser des outils R sophistiqués pour obtenir mes données. Le problème SIG est donc que le SIG est un domaine multidisciplinaire qui est difficile à survivre par vous-même.

  • Manque d'outils et de logiciels bien établis pour passer de l'utilisation des terres par imagerie à l'utilisation des terres vectorielles: je prévois un avenir où un outil analysera l'image satellite GEOEYE et comparera les utilisations des terres en elle à une base de données vectorielle (telle que construite)

  • Parfois, il est plus rapide de faire des choses dans Excel / "votre programme de feuille de calcul préféré va ici: Parfois, je veux faire une analyse de transit, il est beaucoup plus rapide de récupérer les données, de les mettre en excel, de faire les formules, puis de vider les données dans postgis en tant que fichier csv et régénérer la carte. Un tel fossé, en particulier dans le monde OpenSource, devrait être mieux géré.

Quoi qu'il en soit, je ne vous ai peut-être pas répondu correctement; Je souhaite juste être bien familiarisé avec la programmation SIG pour que je puisse exceller dans la modélisation SIG

dassouki
la source
Networkx pour shp existe déjà pour info par exemple networkx.github.io/documentation/latest/reference/… Pour le vecteur + raster, voir l'extension raster PostGIS trac.osgeo.org/postgis/wiki/WKTRaster
ThomasG77
+1 le plus gros problème est la fiabilité des sources de données. De nombreux États embaucheront des stagiaires universitaires pour des emplois d'été pour collecter les coordonnées des routes et des trucs, et généralement pas d'erreurs vérifiées ou auditées (pas même des échantillons), et le résultat est maintenant que vous avez le New Jersey DOT disant qu'un la route est 500 pieds plus courte que Google et OSM le dit. Bon sang.
rien n'est nécessaire le
8

Les choses les plus importantes, et généralement les plus difficiles de mon expérience, sont:

  1. obtenir les bonnes données pour le travail
  2. faites-le apparaître dans la projection appropriée (et faites en sorte que toutes les couches soient d'accord).
  3. concevoir une application utilisable. Il est facile et tentant de mettre beaucoup de cloches et de sifflets qui ne feront que confondre les utilisateurs

Je pense que le point 1 sera plus facile dans les pays développés, mais ce n'est pas mon expérience.

Vinko Vrsalovic
la source
6

Pour moi, le plus grand défi est de décider quels outils utiliser pour un projet donné. Open source ou propriétaire? Python ou .NET? Web ou bureau? Je réponds à ces questions différemment pour différents projets, et je suis sûr que les gens les poseront tous sur ce site. Une grande partie de cela se résume à des préférences personnelles et à essayer de deviner ce que ESRI et Microsoft prendront en charge à l'avenir.

jswise
la source
Ce devrait être la chose la plus importante pour moi.
Nathan W
2
C'est moins important pour moi. S'il est dans l'intérêt du développeur d'investir dans son propre avenir et d'éviter le "gaspillage", je pense que la fin justifie les moyens, et quelle que soit la technologie qui fait le travail, c'est le meilleur choix. Avoir une idée claire de ce que vous devez livrer est plus important que la façon dont vous y arrivez.
mwalker
5

Mon problème concerne le cheval et l'eau. Dans de nombreux cas, nous développons et / ou présentons de très bonnes solutions pour nos clients, mais quelle que soit l'élégance de la solution, il est absolument inutile que personne ne prenne le temps de l'utiliser. Dans certains cas, nous avons pu atténuer cela en rendant notre travail basé sur l'utilisateur (enquête sur les problèmes, parler de solutions avant le développement), mais dans certains cas, cela n'est pas encore suffisant.

wilsongis
la source
3

Je pense que le défi le plus difficile est d'amener la direction à comprendre le SIG et certains utilisateurs ne le comprennent pas non plus. La perception est que le SIG consiste à faire une carte; qu'une carte est le seul résultat de toute fin de SIG. Je ne peux pas vous dire à quel point je trouve cela frustrant - le niveau d'ignorance est énorme, et il est détenu par les principaux décideurs.

Finalement cependant - nous étant certains des experts et programmeurs pionniers du SIG - deviendrons finalement de la gestion et nous pourrons enfin obtenir des projets SIG décents!

L'autre chose difficile en tant que programmeur SIG - vous devez comprendre tant de technologies différentes, Java, .Net, bases de données, logiciels ESRI ou autres fournisseurs, c'est-à-dire MapInfo, les réseaux, la sécurité, la technologie Web, etc. etc. C'est parfois un travail presque impossible!

Vidar
la source
2

Traiter avec des personnes issues de l'arpentage qui ne comprennent pas les techniques et les méthodologies de développement de logiciels professionnels, mais parce qu'elles ont elles-mêmes appris à coder avenue / VB, pensez que c'est tout ce qu'il y a à faire.

BlinkyBill
la source
2

# 3 de la réponse de Vinko :

concevoir une application utilisable. Il est facile et tentant de mettre beaucoup de cloches et de sifflets qui ne feront que confondre les utilisateurs.

Je voterais pour la réponse entière, mais pour le fait que l'utilisabilité n'est que le troisième élément de sa liste et je ne pense pas que les deux premiers soient si difficiles.

La convivialité est l'endroit où la plupart de mes problèmes se posent et où je passe la majeure partie du temps de conception / développement, à trouver comment concevoir une interface utilisateur intelligente et efficace, mais gardez-la intuitive afin que les utilisateurs ne soient pas confus par elle, par exemple:

  • Comment régler le style (et choisir les couches) d'une carte interactive pour afficher les informations pertinentes et éviter l'encombrement qui vient souvent avec l'affichage de trop de données (par exemple en utilisant l'agrégation automatique des entités ponctuelles); Je sais que c'est ce que la cartographie essaie de résoudre depuis des siècles, mais le problème ne fait qu'empirer avec les cartes numériques / interactives

  • Comment faire le positionnement automatique de la vue de la carte en fonction de la sélection de la requête / fonctionnalité de l'utilisateur

  • Mise en surbrillance des fonctionnalités `` sélectionnées '' - affichez-vous brièvement la surbrillance, faites-la surligner tout le temps qu'une fonctionnalité est sélectionnée, désactivez-la lorsque la table de sélection (ou la liste) perd le focus ... Comment mettre en surbrillance toutes les requêtes les résultats d'un tableau et de la ligne sélectionnée dans ce tableau (sans avoir trop de boutons bascule)

  • Afficher des informations supplémentaires dans des listes de couches ou d'entités, par exemple la visibilité d'une couche / le style / le type de géométrie appliqué, l'état / la classe d'une entité ... Cela devient encore plus compliqué si l'on a différents types d'entités affichés dans la même liste (je suppose que c'est pourquoi Google et Bing Maps utilisent un filtrage assez lourd des résultats de recherche)

  • Édition efficace: accrochage, fermeture de polygones, ajout / déplacement / suppression de points, sans avoir beaucoup de boutons de barre d'outils.

  • Comment concevoir (et implémenter) une interface de requête conviviale pour les requêtes de géométrie, et encore plus difficile, une interface pour les requêtes comprenant à la fois des attributs et la géométrie; sans faire le type d'utilisateur dans quelque chose qui ressemble à SQL.

  • Comment concevoir quelque chose comme un presse-papiers pour les entités / géométries pour éviter d'avoir à «sélectionner» en permanence une entité sur la carte pour une utilisation dans les requêtes, les modifications ...

Mon sentiment est que le SIG est un domaine particulièrement difficile en ce qui concerne la convivialité, car:

  • L'emplacement est le contexte universel et généralement le plus naturel pour toute information, il y a donc toujours trop d'informations disponibles pour l'affichage

  • Ayant des informations affichées sur une carte, on est facilement tenté de sous-estimer l'importance des parties non SIG de l'interface utilisateur

  • L'industrie a traditionnellement négligé l'aspect ergonomique des logiciels SIG, et ils s'en sont sortis parce que la cartographie numérique était considérée comme un métier technique avec une courbe d'apprentissage lente et qu'il y avait des concepts beaucoup plus difficiles à apprendre que comment utiliser l'interface. Cela signifie que toute personne essayant de concevoir une interface SIG pour le non-expert doit inventer ses propres principes qui sont voués à la confusion (un bel exemple serait `` My Maps '' de Google ou Bing Maps `` My Places '').

mkadunc
la source
2

L'un des plus grands défis du développement SIG basé sur le Web est la manière dont les données sont fournies et l'efficacité que je peux tirer de la livraison des données d'une certaine manière. Le plus grand obstacle est qu'il est très difficile d'écrire du code pour quelque chose qui nécessite un ajustement humain. Vous voyez très rarement des techniques de généralisation pour les données vectorielles utilisées à grande échelle. La plupart du temps, vous devez modifier les plages d'échelle pour activer et désactiver les couches.

CrazyEnigma
la source
1

Cette question est venue sur ma recherche google pour les défis dans les SIG, et j'ai envie de contribuer ici.

Un autre lien que je jugeais pertinent était ce document.

Résumant ce qui y est dit et mes propres opinions, je pense que les plus grands défis (sans ordre particulier sont):

  • Interface utilisateur: avec la multitude d'options d'interface utilisateur, il est difficile pour le développeur d'optimiser l'offre afin de l'adapter à tous les appareils. Touch vs vs desktop vs wearable. L'idée de DE telle que présentée par Gore, qui comprend un casque portable avec écran, des gants avec contrôle de direction et la reconnaissance vocale est un avenir de fantaisie.
  • Standardisation: avec des normes de stockage et de récupération des données, nous pourrions avoir des géo-bases de données qui reposent dans le cloud et permettre la récupération d'informations sur la course afin qu'une navigation et une utilisation SIG puissent être fluides.
  • Utilisation des données: les décideurs sont toujours pressés par le temps. Si un outil doit les aider, il doit le faire de manière fluide, facile et rapide. Le SIG ne semble pas avoir réussi sur ce front et c'est l'une des raisons pour lesquelles ce n'est toujours pas un mot à la mode.
  • Données: Les données sont variées, dispersées et bruyantes. Même pour les organisations ayant des incitations claires sur un SIG en temps réel, l'agrégation de données est un obstacle encore trop grand pour envisager l'entrée.
  • Effort coordonné: le SIG est multidisciplinaire. Chaque enfant le sait. La direction en est informée dans la première diapositive. Bien que de tels projets multidisciplinaires et multidisciplinaires soient rares.
Chintan Pathak
la source
0

En ce qui concerne le codage, je sens que je perds beaucoup trop de temps sur les solutions de contournement. Pour les projections, il m'a fallu quelques mois pour comprendre les processus et les mathématiques car il y a à mon avis peu de documents publiés utiles sur le sujet. Les documents de l'EPSG et de l'OGC sur le sujet m'ont aidé à me remettre en tête après quelques lectures, même s'ils semblent parfois être des copies les uns des autres. Le plus gros problème que j'ai en tant que développeur indépendant est que je ne peux pas m'empêcher de trébucher sur des personnes ayant besoin d'un travail spécialisé pour le développement d'applications Web médicales, industrielles ou même simples, même maintenant. Avec l'industrie SIG, il semble presque impossible de trouver un moyen d'entrer sur le marché.

Dandy
la source
0

Je suis un débutant complet dans les technologies SIG, je comprends les choses au fur et à mesure. Et comme mes fonds sont limités, j'essaie d'éviter d'utiliser des produits ESRI et de faire les choses entièrement avec des outils open source.

Cela dit, les choses les plus difficiles pour moi jusqu'à présent ont toutes été liées à la collecte de données. Il y a plein d'articles sur la manipulation et l'affichage des données, et plein d'outils pour vous faciliter la vie. Mais je suis toujours en train de marcher dans le noir quand il s'agit de collecter des données.

Je n'ai aucune idée de ce que font les professionnels pour trouver et collecter des données. Quelque chose me dit qu'il existe un moyen plus simple d'obtenir des données que data.gov et google.

Eric Palakovich Carr
la source
La plupart, nous avons dû l'acheter auprès de fournisseurs, qui effectuent des levés au sol et des conversions à partir d'autres sources. Dans le tiers monde, obtenir ouvertement des données du gouvernement est un PITA
Devdatta Tengshe
-1

Vous pourriez être malheureux d'être obligé de travailler avec des analystes SIG qui ont été convertis en développeurs de logiciels.

Il est facile de s'attendre à ce qu'un développeur de logiciels compétent prenne les concepts SIG et les laisse passer par l'API et généralement comprendre les choses sans grande aide. La même chose ne vaut pas pour prendre un analyste SIG et s'attendre à ce qu'ils prennent le développement de logiciels.

Les résultats sont embarrassants , au mieux. Si vous avez de l'expérience avec de mauvais développeurs , alors imaginez que c'est du code pire que tout ce que le pire programmeur a développé.

Il y a des entreprises pour lesquelles vous pouvez travailler qui ne comprennent pas.

ensemble vide
la source
2
@emptyset: Je suis un géographe devenu développeur. Je ne pense pas que mes résultats soient "embarrassants" au mieux. J'ai beaucoup plus de compétences en développement que d'autres collègues qui ont une formation en informatique - notamment une meilleure compréhension et utilisation des concepts de POO, des concepts et des règles de base de données, etc. Bien sûr, je ne suis pas d'accord avec votre réponse: P
George Silva
1
@George: Et je ne dis pas que vous aviez dit le contraire, soulignant simplement que pour être un grand développeur, vous devez savoir combien vous êtes nul. Au moins j'essaye.
Vinko Vrsalovic du
2
+1 À plusieurs reprises, on m'a demandé de "simplement corriger les bugs" dans une grosse boule de boue en.wikipedia.org/wiki/Big_ball_of_mud écrite par un ou plusieurs analystes. Certains des pires codes ont été écrits par certains des analystes les plus intelligents. Souvent, les plus intelligents ne parviennent pas à apprécier la beauté de la simplicité. Souvent, la faute vient de la direction - l'analyste peut réaliser la valeur de la refactorisation, mais ne peut justifier de passer du temps à changer le code qui n'est pas cassé.
Kirk Kuykendall
3
Pour le corollaire, vous pourriez avoir la malchance de travailler avec des développeurs de logiciels obligés de travailler en tant que professionnels SIG. Je me méfie énormément de quiconque, de n'importe quel domaine, se contente de comprendre les choses au fur et à mesure dans le SIG. Je suis un analyste qui explore le développement, et je m'attends pleinement - et je veux - que les gens se méfient de mon code. Tout développeur qui pense qu'il se débrouille très bien dans le SIG, ne l'est probablement pas. :-)
matt wilkie
3
-1 - déclaration très générale qui est prouvée fausse et quelque peu offensante. Comme Matt W l'indique ci-dessus, il vaut généralement mieux qu'une personne SIG vienne au codage que l'inverse, car il y a tellement plus de ressources pour vous aider à apprendre le codage et à mettre en œuvre les meilleures pratiques que dans le SIG
dmbrubac
-1

le monde SIG est élargi vers l'utilisateur commun, sauf dans les premières années où le SIG n'était traité que par des ingénieurs, des architectes ou la communauté scientifique. Dans le cas où l'application SIG est faite pour l'utilisateur commun, le défi est de mélanger de manière appropriée les technologies où le SIG est davantage traité comme une technologie (dans ce cas, un développeur ayant une petite compréhension de la technologie SIG suffit). Cependant, dans le cas où l'application est faite pour la communauté spécialisée, le défi est plus complexe car, en plus de rejoindre les technologies, il est nécessaire de rechercher des algorithmes existants pour répondre aux exigences, sinon pire encore, nous devrons développer ces algorithmes. Dans ce cas, un mélange d'ingénieur et de développeur est le travailleur compétent.

Rodolfo Moreno
la source