Le portail francophone de la géomatique

J'ai parcouru la liste : il y a des formations générales aux logiciels SIG, mais quelles sont les formations apprenant à programmer en Java en utilisant les API d'un SIG avec les  API GIS qui prédominent aujourd'hui ? (GeoTools ? GeoAPI ?, autre ?).
Toute la difficulté consiste à découvrir les objets et méthodes qu'elles proposent. Comment les mettre en œuvre de bonne manière. Elles sont souvent peu ou mal documentées, et à mon sens, il faut vraiment qu'un programmeur SIG passe les billes à un autre (dans le cadre d'une formation, justement) pour pouvoir s'en sortir. Seul, devant des javadocs inexistantes et deux sources d'exemples, on est très vite bloqué : On ne voit pas l'esprit, la philosophie de ce qui est proposé, ni les bonnes pratiques qui vont avec.

Dernière modification par grunt (Fri 19 September 2014 10:54)

La première formation que tu proposes vise à programmer un afficheur de cartes, ce n'est pas exactement cela que je recherche.
Ce que je demande n'est pas du tout évident, je le sais bien. Je vais essayer d'illustrer ainsi :

Quand on suit une formation sur un outil SIG (GeoConcept, ArcGis, MapInfo, QGIS...) on apprend à créer des cartes, faire des agrégats, de la rasterisation / vectorisation, du géoréferencement, de l'analyse, et beaucoup d'autres choses que j'oublie. J'ai suivi un cours, et il faut bien plusieurs dizaines d'heures avec de bons conseils parce que bien sûr, on pourrait prendre un guide sur Internet et profiter des forums de discussions, mais ce serait nettement plus fastidieux.

Quand on suit une formation Java, on suit également un enseignement qui apprend à se servir des bases du langage, des bases de données, à bâtir un site web, des services SOAP, REST, EJB ou Spring, et j'en passe, et là aussi il faut une formation importante pour parvenir à être assez à l'aise. Certes, les purs auto-dictactes qui n'ont utilisé que les livres et se sont formés sur le tas existent, mais ils y ont consacré une énergie démesurée.

Mettre Java et le monde des SIG en rapport, c'est réclamer que des programmes analysent des cartes, en produisent de différentes natures, extraient, créent, simulent, selon des règles élaborées. Nous avons besoin de programmer lorsque les opérations manuelles ou semi-automatisées que l'on peut faire avec son logiciel SIG ne suffisent plus et que l'on désire un traitement capable d'étudier des situations et d'agir en conséquence de manière complexe, variable ou répétitive, dans des conditions particulières et même parfois dégradées (où une source de données sera incomplète, par exemple, et qu'il faudra pallier avec une autre, ou faire face à d'autres aléas), et un déclenchement dans des situations précises.

Et parvenir à faire cela réclame une expertise à part entière, distincte de celle de maîtriser seulement un SIG ou de maîtriser seulement Java, et elle réclame d'y consacrer un grand nombre d'heures, à la suite d'un enseignement dédié que je recherche.

Dernière modification par grunt (Sun 21 September 2014 17:43)

Je suis proche de faire ce constat également !
Mais j'espérais que peut-être par le biais de ce forum, il y aurait quelques directions pour me détromper. Bien sûr, tout ce qui est dit ici est possible, mais lourd et source d'erreurs et de découragement. Car du coup, on en revient à la documentation que l'on peut trouver à droite et à gauche et à des séries d'expérimentations personnelles. L'esprit pionnier a du bon, mais il est aussi source d'impasses : ce que j'étudierai ne sera pas ce qu'un autre aura pris le temps d'observer, et en fin de compte, cela fait seulement quelques centaines de personnes en France dotées de la capacité de programmer des logiciels autour des SIG en Java, mais dont on ne peut être sûr qu'elles auront un tronc de connaissances commun.

Cela dit, la situation n'est pas inexplicable. Jusqu'à il y a peu, rien n'était normalisé en terme d'API géographiques. Et chaque éditeur d'un logiciel veillait à avoir sa propre API, fût-elle incompatible avec les autres. L'interopérabilité étant le dernier souci, l'enseignant qui aurait consacré ses efforts à enseigner la programmation avec GeoTools se serait retrouvé à les refaire entièrement pour ArcGis (avec d'autres joies et d'autres déboires) et n'aurait pas trouvé rentable d'y consacrer autant de temps.

Dernière modification par grunt (Mon 22 September 2014 11:38)

Il me semble que c'est pour ça qu'il y a des cursus longs de type ingénieur en géomatique, ou technicien supérieur (2 ans, dans ce dernier cas, dans lequel certains diplômés peuvent évoluer vers un poste de programmeur Java).

Même l'école 42 a un cursus long, en 3 ans :
https://fr.wikipedia.org/wiki/42_%28%C3 … #Programme
avec une prolongation optionnelle vers une 4e et une 5e année.

@ChristopheV :
Java n'a jamais été très facile pour l'impression. Ça a peut-être changé depuis mes anciennes expérimentations, mais je m'en souviens peu commode.

"ArcGis par exemple c'est .Net ..."
Néanmoins un SDK Java et son API sont proposés : https://developers.arcgis.com/java/api-reference/

@Pascal Boulerie :
La partie Java ne me pose pas de problèmes (je suis déjà Ingénieur Informaticien Java). C'est la partie accaparation d'une nouvelle API qui est à prendre de manière différente selon les logiciels proposés qui est source de difficulté. geotools et geotoolkit vont l'un et l'autre proposer deux jeux d'API différentes de celles d'ArcGis, par exemple. De sorte que si j'aboutis suivant le cheminement proposé par ChristopheV, ce que j'aurais appliqué pour une de ces API devra ensuite être reproduit sur une autre en trouvant pour chaque fonctionnalité unitaire que j'aurai su mettre en œuvre son équivalent. L'absence de standardisation poussée entre les API verrouille le développeur. Pour transiter de l'une à l'autre, il doit réaliser une migration. Et bien sûr, c'est dissuasif.

10 000 euros. Oui... dès qu'il y a le mot "spécialisé" derrière Mastère, ça entonne vite le chant du tiroir-caisse. Néanmoins, la formation est attrayante !

Bonjour,

Peut-être regarder du coté de FDO.

Bonjour

Feature Data Object

http://fdo.osgeo.org/