Super :)
Je ne connaissais pas !

Bonjour,

Merci pour vos commentaires et les ressources complémentaires que vous avez apporté.

Mathieu, je reviendrais par contre sur le fait que tu as soulevé :

"Je peux vous assurer qu'il existe de nombreux projets en production aujourd'hui, mettant en oeuvre des solutions à partir de SDI"

Je pense, peut être à tort, que ce sont des projets sur mesures réalisés dans un cadre bien spécifique. Dans ce billet, j'essayais de me placer dans la situation d'un administrateur SIG qui aurait à charge de gérer l'ensemble des flux de données entrants et sortants.

Bien évidemment, cela ne remet pas en cause l'utilité des ETL. Le manque de connecteurs aux formats de données n'est pas un élément bloquant pour la pérennité de ces outils. Cette limite devrait, je le pense, rapidement être levée. A quand un portage de GDAL/OGR en Java ;)

Bonjour,

Quelques précisions sur l'outil SDI sont disponibles ici [1].
Sinon j'aimerais revenir sur la conclusion de l'article, sur laquelle je ne suis pas vraiment d'accord avec l'argument avancé concernant le fait de ne pas utiliser ces outils en production. Je ne pense pas que la diversité des formats géographiques supportés ne soit un gage de qualité pour l'outil, et donc un garant de sa stabilité en environnement de production. De plus, ces outils disposes aujourd'hui d'un certain nombre de formats incontournables en géomatique et permettant de réaliser bon nombre d'opérations et de traitements standards de la donnée. Je peux vous assurer qu'il existe de nombreux projets en production aujourd'hui, mettant en oeuvre des solutions à partir de SDI.

Cordialement,
Mathieu

[1] http://www.talendforge.org/wiki/doku.php?id=sdi:mainpage

Bonjour,
en effet c'est facile : il suffit de déclarer un second marqueur.

var marker2 = new google.maps.Marker({
  position: myLatlng2,
  map: map,
  title: "Marker 2!"
});

Merci
J'ai pu réaliser mon premier test avec map script avec succès grâce à votre tutoriel.

Non mais je n'opposais pas les deux méthodes en fait.

J'émettais juste la réserve qu'en général le cartographe ne décide pas mais tente d'amener les informations nécessaires à la prise de décision, avec parfois une part de subjectivité, et tu as raison les erreurs sont toujours possibles.

Et que dans le processus collaboratif, il faut à mon sens conserver cette vision des couches d'informations nécessaires à la prise de décision. La différence que je vois mais tu y as sans doute bien plus réfléchit que moi, c'est que cela permet ensuite collaborativement d'avoir l'ensemble des informations nécessaires et de travailler sur ce processus itératif dont tu parles avec la possibilité de s'affranchir ou non de certaines contraintes (car parfois il faut faire des compromis) et ainsi d'avoir une méthode de travail plus souple qui permet peut être de faire ressortir des solutions auxquelles on ne serait pas arrivé dans un processus plus figé.

Pour résumer je dirai que le travail amont du cartographe reste, c'est à dire qu'il va rechercher toutes les informations nécessaires à tel projet, les représenter, etc, simplement au lieu de créer une carte figée, ce sont les superpositions de couches qui définiront une zone décisionnelle que les décideurs pourront faire ensuite varier ensemble et décider au final l'implantation d'un bâtiment. Quitte à émettre différentes hypothèses.

Intéressant ce billet.

Ca laisse un champs de réflexion intéressant.

Ceci dit concernant les pratiques que tu évoques est ce exactement comme cela que ça se passe ?
Pour avoir bossé dans des collectivités territoriales, je n'ai jamais proposé une carte décidant à la place des décideurs. Si je reprends ton exemple de centre commercial, je pense que le but de la carte est de définir les contraintes juridiques, pratiques ou autres existantes, ce sont ces contraintes qui peuvent proposer une zone potentielle où la décision pourrait être prise.
En tout cas ce sont des informations également nécessaires à la géocollaboration sous peine de géocollaborer pour rien ensuite, mais il est vrai que ça laisse une vision plus dynamique si les décideurs ont toutes les informations nécessaires en temps réels, ils peuvent librement simuler plusieurs scénaris en s'affranchissant éventuellement de certaines contraintes pour y trouver le meilleur compromis.

Ludo

Je n'ai jamais manipulé l'API de GeoPortail, je suppose que celle-ci surcharge openLayers.

Il faudrait voir comment étendre les fonctionnalités du GeoPortail.

Arnaud

Bonjour,

J'ai essayé de mettre ce tuto en application avec l'API Géoportail(béta 1.04) qui utilise OpenLayers, mais lors de la création de l'objet ttips j'ai l'erreur "OpenLayers is not defined". Y-a-t-il des adaptations à faire à "toolTips.js" pour l'utiliser avec l'API Géoportail ? Dans le code de "toolTips.js" il y a en commentaire "@requires OpenLayers/Control.js" et "@requires OpenLayers/Utils.js", que signilfie "@requires", je ne trouve pas d'explication ni dans la doc que j'ai ni sur internet ?

Merci d'avance pour votre expertise.

Jean-Luc.

Tout à fait, les POI sont intégralement chargés et à partir d'un millier de points, ça peut commencer à ramer un peu.

I think you are wrong. It's illusory to believe that open source does not and can't generate money, quite the contrary. Moreover OpenGeo is just an all in one package to make things easier. Each element can still be downloaded separately