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

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?

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.

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.

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

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.

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.

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.

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!

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.

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

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.

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.

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é.

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.

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.

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.