Il n'existe pas de connecteur Novasys Geoplatform Mapping Service pour OpenLayers. Plutôt que de le faire, il serait plus intéressant de faire en sorte que la GeoPlatform parle “OGC WMS”, de sorte que tout client conforme OGC WMS (pas seulement OpenLayers) puisse consommer des cartes. Il s'agit donc de créer un proxy WMS qui interface une ou plusieurs méthodes Mapping Service de la GeoPlatform. Il est souhaitable de simplifier l'objectif, par exemple ce proxy ne traite que les requêtes en méthode GET (bien évidemment, le paramètre STYLES ne fait pas de sens dans ce cas de figure).

Pour finaliser ce travail, il s'agira de montrer l'utilisation de ce WMS proxy dans le cadre d'une application de webmapping ou tout autre client conforme OGC WMS. Ici, ce client sera basé sur OpenScales avec mise en oeuvre du fichier de configuration (“XML runtime configuration to get dynamic maps from a single SWF”)…

Après les interventions de Larissa et Quentin, on peut imaginer un mashup du service de consultation geoadmin et de services de la GeoPlatform Novasys (searching, routing et POI). Il s'agit d'implémenter par exmeple un scénario recherche d'adresse avec affichage des résultats (combiner GetAddressesFromSelection, GetPositionFromAddress = les points-adresse pour l'adresse recherchée). Ensuite, parmi les résultats de recherche d'un départ et d'une arrivée, calculer et afficher les trois profiles de route (GetRoute). En option, on peut imaginer recherches les stations-service le long des itinéraires et les afficher avec les roadbooks des routes calculées.

L'idée est d'avoir une approche différente et d'aller plus loin que la v1 de cette application (http://carto.iict.ch/profiler). Actuellement, Profiler est application permettant de tracer un itinéraire sur une carte et d'en donner le profil altimétrique. Tous les éléments client/serveur sont fortement couplés dans cette première version. Une approche à base de service serait à privilégier :

• créer un service web qui pour un itinéraire donné produit le profil
  • il faut définir le format de l'entrée (GPX, GeoJSON, WKT ?)
  • il faut définir le format de la sortie pour absorber la nouvelle information altitude
• créer une application webmapping possible qui consomme ce service
  • une première version consiste à :
    • saisir un itinéraire
    • solliciter le service
    • mettre en forme le résultat (généré un graphique altimétrique)
    • afficher le résultat
  • une seconde version permet en plus d'activer une riche interaction entre le graphique altimétrique et l'itinéraire (en positionnant le pointeur sur un point de la ligne, on voit immédiatemment le point altimétrique du graphique)

Production de cartes de charge de réseau routier

La société Greenmonkeys, (anc. Klaxonne) fait la promotion de la mobilité partagée (e.g. covoiturage). Un prototypage a été réalisé. L'objectif consistait à cartographier la charge du réseau routier si tous les étudiants de la HEIG-VD s'y rendaient quotidiennement en voiture. Exemple de carte.

Sur le plan des données, la fabrication de ce type de carte nécessite un jeu d'adresses d'origine (e.g. domicile) et une destination (e.g. lieu de travail). Il faut ensuite pouvoir géocoder les adresses, calculer les itinéraires et agréger les données de résultat pour les représenter.

Le prototype actuel a passé par 10 étapes:

1. Acquisition des données routières OpenStreetMap
2. Insertion dans PostGIS (osm2pgrouting)… (debug)
3. Opérations sur la topologie…
4. Détermination des “coûts” (attribut type routier)
5. Acquisition, nettoyage de données adresses
6. Géocodage des données adresses (Gmaps, Geonames, Yahoo…)
7. Association adresses (lon/lat) aux nœuds routiers les plus proches
8. Calcul des plus courts chemins
9. Agrégation des réponses
10. Représentation

Quelques-unes des difficultés rencontrées sont consignées dans ce document.

L’objectif de ce projet consiste à « industrialiser » la production de cartes de charge de réseau routier, en exploitant l'API de Novasys. Les 4 premières seraient désormais inutiles (nous disposerions de données actualisées en permanence). les étapes 6 et 7 seraient rationalisées.

• StatHES II (http://carto.iict.ch/stathes)
• CityGML explore (state of the art) with a Paleo background…
• Tileindex Loader OrbisGIS plugin (http://www.gdal.org/gdaltindex.html)
• OSM MapLoader OrbisGIS plugin
• Premiers pas vers wpsPAL
• Premiers pas vers Joomla OGC Viewer
• Premiers pas vers CartoExploreur
• Premiers pas vers Greenmonkey…
• FME Server experiment (…)