Revue des blogs en français

Voici quelques semaines, Steve Coast, le fondateur d'OpenstreetMap, a quitté son rôle dans l'entreprise qu'il avait créé.

Personne ne comprenait trop bien la décision , puis l'histoire s'est tassée.. et c'est aujourd'hui qu'il vient de révéler une partie de ses plans :

Steve est embauché chez Microsoft et plus précisément au département Bing Map...

Tiens tiens...Bing Map...

En même temps, Steve et Bing annoncent que les photos aériennes utilisées par Bing Map dans le monde entier sont maintenant à la disposition de OpenStreetmap.

Bien que la communauté OSM a déjà accès à certaines images satellites comme Yahoo par exemple, celles-ci son souvent dépassées, peu complètes et peu précises....

Ici, avec bing map, tout n'est pas parfait mais c'est clairement un gros plus pour la communauté.

Après Mapquest, CloudMade, voici que microsoft soutient Openstreetmap... de superbes signes de vitalité!

Pas encore de détails pour l'intégrations aux éditeurs (le support est déjà prévu dans plusieurs mais pas encore déployé),

certaines précisions sont encore attendue avant de lancer le grand "Feu vert" !

1e Rencontre européenne en France

La Fing, l’ePSIplateform, la Métropole de Rennes, la Région Bretagne, e-megalis et le GFII organisent une journée d’échanges autour des bonnes pratiques d’ouverture et de réutilisation des données publiques. Participez à la première rencontre européenne organisée en France, en français et en anglais (traduction simultanée).

Le rendu actuel des réserves naturelles dans mapnik fait que lorsque qu'une réserve est composée de terres émergées et de surface aquatique la limite entre les deux est peu intuitif à la lecture de la carte. J'ai ouvert un ticket ce jour pour proposer un nouveau rendu à base d'image hachurée sur fond transparent.

Le rendu actuel donne ce résultat :

et le nouveau celui-ci

Pour de plus grandes images vous pouvez consulter cette comparaison entre les deux rendus que je vous invite à commenter ici.

Utiliser une librairie JavaScript distante est une dépendance dangeuresue pour un site web, en cas de problème sur le site OpenLayers les cartes sur vos sites ne seraient plus affichées, pour éviter cela nous allons voir comment installer la librairie à la racine de votre serveur web.

La librairie sera installée à la racine du serveur web dans un répertoire nommé opl210.

Première étape récupérer l'archive sur le site, ici nous la sauvegardons dans la racine du serveur.

wget http://www.openlayers.org/download/OpenLayers-2.10.tar.gz

On décompresse l'archive dans le répertoire courant

tar xvfz http://www.openlayers.org/download/OpenLayers-2.10.tar.gz

Il ne nous reste qu'à copier les fichiers nécessaires dans le répertoire opl210.

cp OpenLayers-2.10/OpenLayers.js opl210/ cp -r OpenLayers-2.10/img/ opl210/ cp -r OpenLayers-2.10/theme/ opl210/

Nous pouvons désormais supprimer l'archive OpenLayers-2.10.tar.gz et le répertoire OpenLayers-2.10 qui ne sont plus utiles.

Nous utiliserons maintenant dans notre page html la librairie locale en indiquant dans les headers l'emplacement de celle-ci :

<script type="text/javascript" src="/opl210/OpenLayers.js"></script>

Inutile de préciser où sont stockées les images et les styles utilisés, la librairie les cherche par défaut dans le répertoire/url où celle-ci se trouve. Dans le prochain billet nous verrons lors de la personnalisation de la carte comment indiquer des répertoires différents afin de pouvoir organiser les fichiers à son habitude.

NB : le fichier readme.txt contient une erreur sur l'emplacement du fichier OpenLayers.js ne pas s'y fier, j'ai ouvert un ticket pour corriger cette erreur

La mise en oeuvre de ce billet est consultable dans : local.html

Dans ce deuxième billet consacré à Openlayers nous allons aborder les sytèmes géodésiques et les projections. Sans entrer dans les détails il faut savoir que la représentation de la terre qui est ronde sur une feuille de papier plane représente un casse tête depuis des siècles à tous les cartographes, pour faire cela au mieux (avec le minimum de déformations) on a inventé les systèmes géodésiques et les projections cartographiques.

Quand vous utilisez un GPS dans votre voiture, en randonnée ou en vélo la position que vous lisez sur l'écran est exprimée en longitude et latitude dans le système géodésique WGS 84. L'EPSG qui se charhe de référencer les différents systèmes lui a attribué le numéro 4326, les codes EPSG sont une référence pour les outils manipulant des données géographiques comme Postgis ou OpenLayers, ils sont d'ailleurs utilisés par aussi par l'Open Geospatial Consortium.

Tout serait simple si OpenLayers utilisait ce système pour référencer les tuiles qui composent la carte, mais OpenLayers utilise le système 900913, car c'est ce système qui est utilisé lors de la création des tuiles, nous devons donc l'utiliser pour positionner notre carte, comme nous l'avons fait dans le précédent billet. Je reviendrais plus tard sur les origines du système 900913, les habitués de l'écriture cowboy pourront déjà faire des recherches sur le moteur éponyme.

Un peu de pratique maintenant et positionnons notre carte avec des données WGS 84. Dans notre précédent exemple nous avons centré la carte sur la position 30000,580000, position exprimée dans le système 900913.

var center = new OpenLayers.LonLat(30000,5800000);

Afin de pouvoir spécifier center dans le système WGS 84 nous allons créer 2 objets de projection avec la classe OpenLayers.Projection, un objet pour le WGS 84 en utilisant son code EPSC 4326, et un pour le système attendu par OpenLayers 900913.

var projFrom = new OpenLayers.Projection("EPSG:4326"); var projTo = new OpenLayers.Projection("EPSG:900913")

Nous allons donc cette fois pourvoir définir notre centre avec une coordoonée en longitude est de 0.2694 approximatif, et une latitude nord de 46.1224.

var center = new OpenLayers.LonLat(0.269494585,46.1224893);

Il ne nous reste plus qu'à tranformer notre point center avec la fonction transform pour obtenir un point nommé cproj que l'on pourra utiliser pour positionner la carte.

var cproj = center.transform(projFrom, projTo);

Le contenu de center est transformé d'un système de projection source projFrom dans un système destination projTo, ce qui nous permet d'obtenir dans la variable cproj une position exprimée dans le système 900913, il ne nous reste plus qu'à utiliser cette position pout centrer la carte.

map.setCenter(cproj, 5);

La mise en oeuvre de ce billet est consultable dans : projections.html

Avec la stabilisation de mapfishapp 1.0, le module de visualisation de GeOrchestra fait maintenant l'objet d'une section dédiée sur la forge. Sur http://csm-bretagne.fr/redmine/projects/mapfishapp, retrouvez les anomalies/évolutions spécifiques au visualiseur, les sources,

Ce projet est "public": il suffit de s'enregistrer sur la forge pour accéder aux trackers. Pour obtenir un profil de contributeur, nous contacter sur info at georchestra point org.

Ce billet est le premier d'une série sur la vulgarisation d'OpenStreetMap et OpenLayers. Nous allons voir ici qu'il est très simple aujourd'hui d'inclure une carte nabvigable dans une page web.

Le code de ce billet est mise en oeuvre dans : minimal.html

L'intégration d'une carte dans une page web consiste à ajouter une balise <div> avec un id nommé ici map. L'initialisation de la carte se fera au chargement de la page, pour cela on ajoute un appel à la fonction javascript init() dans la balise <body>.

<body onload="init()"> <div>Démonstration de carte openstreetmap minimale</div> <div id="map"></div> </body>

Dans l'en-tête de la page on définira la fonction init() comme suit. Dans cette première approche on se contente d'une carte simple que l'on positionne sur un point définit au niveau de zoom 5. Dans un prochain billet on verra comment utiliser un système de coordonnées plus commun.

<script type="text/javascript"> function init(){ // Création d'un objet map var map = new OpenLayers.Map('map'); // Ajout d'un calque en utilisant le rendu par défaut map.addLayer( new OpenLayers.Layer.OSM() ); // Création du point central de la carte à partir //de coordonnées géographiques var center = new OpenLayers.LonLat(30000,5800000); // Positionnement de la carte sur le point central, // au niveau de zoom 5 map.setCenter(center, 5); } </script>

Les propriétés visuelles de la carte, sa taille et la bordure noire sont définies comme pour tout objet html par une feuille de style CSS directement en utilisant l'identifiant de l'objet <div>.

#map { width: 600px; height: 400px; border: 1px solid black; }

Nous avons maintenant une carte dans notre page web sur laquelle il est possible de se déplacer, de modifier le niveau de zoom, de faire glisser à la souris et bien d'autres choses encore. Les connaisseurs reconnaîtront le rendu utilisé dans cet exemple, c'est le rendu réalisé par mapnik, utilisé sur le portail OpenStreetMap. Rendu que nous n'avons pas choisi et que nous verrons comment changer dans un prochain billet. Vous pouvez maintenant intégrer dans votre CMS à base de logiciel libre une carte à base de données libres.

Commençons cette revue de presse avec OpenStreetMap. Ce projet de cartographie collaborative qui fait de plus en plus parler de lui a été à l'honneur lors des 12èmes Journées du Logiciel Libre (JDLL 2010). A cette occasion, Nicolas Moyroud a présenté "comment réaliser une carte pour le Web avec OpenLayers et OpenStreetMap" et "Apprendre à contribuer au projet OpenStreetMap avec JOSM".

en lire plus

Introduction: 

Commençons cette revue de presse avec OpenStreetMap. Ce projet de cartographie collaborative qui fait de plus en plus parler de lui a été à l'honneur lors des 12èmes Journées du Logiciel Libre (JDLL 2010). A cette occasion, Nicolas Moyroud a présenté "comment réaliser une carte pour le Web avec OpenLayers et OpenStreetMap" et "Apprendre à contribuer au projet OpenStreetMap avec JOSM". Ses supports sont librement téléchargeables sur son site internet.

icone_news: Mots-clés: Open SourceheatmapOSMGeoRDP

La Ville de Rennes et Rennes Métropole ont récemment mis en place un entrepôt accessible à tous de données publiques leur appartenant. On trouve sur ce site www.data.rennes-metropole.fr des informations concernant les transports, les données de la base « Guide Vivre à Rennes » ou des informations du Système d'Information Géographique (SIG) de la Ville de Rennes et de Rennes Métropole.

Cette ouverture des données est largement mise en avant par Rennes Métropole et la Ville de Rennes, avec un concours de 50.000 € de prix, une couverture médiatique comme cet article de Télérama ou la réception d'un « prix européen e-démocratie » lors du World e.Gov Forum.

L'ambition affichée est de « permettre aux usagers, aux développeurs, aux entreprises de s’approprier et de retravailler les données mises à disposition pour créer de nouveaux services utiles au grand public. » En tant que développeur et contributeur à la communauté des logiciels et œuvres Libres, je ne ne peux qu'adhérer à cette vision des choses. Permettre à quiconque d'utiliser des données publiques et les réutiliser dans d'autres œuvres est pour moi crucial.

Donc, comme tout bon utilisateur potentiel, je me suis précipité sur les conditions d'utilisation[1]. Et là j'ai été plutôt surpris ! En particulier l'article 4, « Obligations du Réutilisateur » précise :

Conformément à l’article 12 de la Loi, le Licencié s’engage à ce que les Informations ne soient pas altérées ni leur sens dénaturé. Le Licencié veillera à respecter l'intégrité des données, et notamment à ne pas les dénaturer et/ou tronquer. L'insertion de commentaires doit être clairement distinguée du contenu du concédant.

En d'autres termes, il m'est impossible de réutiliser les données dans d'autres œuvres composites, car en les intégrant je vais très certainement « dénaturer ou tronquer » les données. Un comble pour des données soit disant « ouvertes » ! Notez bien au passage que l'article 12 de la loi n°78-753 du 17 juillet 1978 précise bien que « Sauf accord de l'administration, la réutilisation des informations publiques est soumise à la condition que ces dernières ne soient pas altérées, que leur sens ne soit pas dénaturé et que leurs sources et la date de leur dernière mise à jour soient mentionnées. » Donc un accord de l'administration peut permettre une réutilisation plus libre des données.

Prenons un exemple concret : imaginons que je veuille ré-intégrer la « localisation des points d'apport volontaire des déchets ménagers » dans la carte libre OpenStreetMap. Cette carte est ouverte, enrichie en permanence par des volontaires à l'échelle planétaire et Rennes y est très bien cartographiée. La localisation des conteneurs à déchets y serait très utile, ce serait un geste citoyen. Et pourtant avec la licence actuelle, c'est impossible. Je devrais forcément transformer les données pour les intégrer. Et comme la carte OpenStreetMap doit pouvoir être redistribuée et modifiable par n'importe qui, il m'est impossible d'y intégrer des données ayant de telles contraintes de contrôle d'intégrité.

Ce que Rennes Métropole aurait dû faire

Le plus drôle dans cette histoire, c'est que d'autres acteurs ont tout compris. Rennes Métropole et la Ville de Rennes ne font que recopier ces acteurs, mais en faisant tout de travers par cette licence inadéquate !

L'article de Télérama est éclairant sur ce point. Outre OpenStreetMap, Antoine Mairé y cite l'exemple des villes anglo-saxones qui ont ouvertes leur données, comme l'initiative anglaise Data.gov.uk. Mais quand on regarde les conditions d'utilisation de Data.gov.uk, on y lit que la personne réutilisant les données a le droit :

de copier, publier, distribuer et transmettre les données ;

d'adapter les données ; (le point crucial !)

d'exploiter commercialement des données, en combinant par exemple ces données avec d'autres données ou en l'incluant dans votre produit ou application.

La Ville de Rennes et Rennes Métropole aurait dû utiliser une licence inspirée des licences d'œuvres libres comme Creative Common BY ou BY-SA permettant à quiconque de transformer et intégrer les données. Sans ces conditions, les données « ouvertes » de Rennes Métropole sont inutilisables dans d'autres œuvres ou programmes, à l'opposé même du but initial de permettre aux usagers de s'approprier les données.

Peut-être qu'un jour nous aurons des données réellement ouvertes, et réellement réutilisables ! En attendant, passez votre chemin, il n'y a rien à voir sur data.rennes-metropole.fr.

Notes

[1] Lisez les, elles sont courtes et plutôt lisibles.

A la question "geOrchestra, c'est quoi", il est souvent difficile de donner une réponse concise. Répondre "une infrastructure de données spatiale" n'apporte rien de très concret.

Un article wikipedia sur l'Open Source Geospatial Foundation présente un croquis fort intéressant. On y retrouve GeoServer, GeoNetwork, OpenLayers... dialoguant en bidirectionnel grâce aux normes OGC. La légende : Several OSGeo projects can communicate with each other, plusieurs projets OSGeo peuvent communiquer entre eux.

This file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported, 2.5 Generic, 2.0 Generic and 1.0 Generic license.

Ce schéma résume parfaitement l'approche engagée par les IDS comme EasySDI ou geOrchestra: l'essentiel est de contribuer aux briques fondamentales, de les valoriser et de démultiplier leurs possibilités en les intégrant entre elles sans les dévoyer. geOrchestra se positionne très favorablement sur ce schéma :

• intégrer GeoServer, GeoNetwork, OpenLayers (ça c'est fait !)
• délivrer des formats comme GeoRSS, KML pour s'interfacer avec Google Earth, WorldWind (réalisé par GeoServer)
• proposer une interface transactionnelle par WFS (réalisé par GeoServer)
• ajouter une strate d'optimisation par cache qui absorbe une partie de la charge (réalisé par GeoWebCache)
• ajouter des datastores majeurs comme OpenStreetMap (fait !)
• enfin, faciliter la fabrication d'applications composites sans a-priori technologique pour desservir des besoins pointus à faible coûts. L'API mapfishapp est un bon début...

L'espace disque est un aspect important de la mise à disposition de carte sur Internet. Si vous travaillez sur une zone finie du globe il est intéressant de connaître rapidement l'espace disque nécessaire à la génération à priori de l'ensemble des tuiles que vous allez servir. Confronté régulièrement à cette problématique j'ai fait un tableur (OpenOffice) pour calculer l'espace disque et le nombre de tuiles pour une zone donnée (bounding box pour les intimes). La taille moyenne de la tuile est mésurée sur un serveur de production avec le rendu mapnik par défaut, les tuiles prises en compte sont des tuiles consultées par des humains et non un extrait statistique de l'ensemble des tuiles, ceci afin de donner plus de sens à la valeur moyenne. Ce tableur est publié ici sous licence GPL v3.

Hello à tous,

Voilà quelques semaines maintenant que j'écris, pour la communauté OpenStreetmap, un petit compte rendu des discussions et nouvelles autour de Osm.
Tous le monde n'ayant pas forcement le temps ni l'envie de suivre les nombreuses et bruyantes mailing lists.

Alors que je viens de publier le 11ième opus de la série, je viens aussi de rendre disponible un flux rss des nouvelles.

Ce flux, disponible à l'adresse http://feeds.feedburner.com/OSM_Community_Updates . Il est directement extrait depuis le wiki où se trouvent les articles.

Il n'est évidemment pas encore parfais, mais n'hésitez pas à faire vos remarques que j'étudierai et que j'essaierai de satisfaire

Vous remarquerez aussi que les nouvelles sont très rarement traduites, uniquement par manque de temps.
N'hésitez donc pas à proposer votre aide pour la traduction ou tout autre tâche que vous estimer intéressante (une news à ne pas manquer par exemple).

Merci encore et bonne lecture....

On ne présente plus OpenStreetMap, le projet de données libres qui rivalise avec les fournisseurs de données propriétaires. La suite d'outils OpenStreetMap utilisant postGIS, ses données sont donc naturellement exposées aux services OGC et IDS comme geOrchestra.

Le souhait de livrer les composants geOrchestra accompagnés de données abondantes, libres et prêtes à l'emploi pourrait voir le jour. Grâce à mapserver-utils de Thomas Bonfort et aux contributions de Pierre Mauduit, il est possible de fabriquer des rendus de haute qualité, exposés en WMS ou WFS, et dans les projections utilisées par les SIG.

mapserver-utils a décortiqué la sémiologie des cartes OpenStreetMap pour en ensuite construire une suite de styles mapserver. Des initiatives similaires existent dans le monde geoserver.

170 classes

Pierre Mauduit a réutilisé ce travail pour produire trois styles visibles sur qualitystreetmap.org : osm, google et bing. Ils offrent un rendu agréable et homogène à toutes les échelles grâce à plus de 170 classes décrites.

Intégration dans geOrchestra

Les données "france" d'OpenStreetMap comptent 11,2 millions d'objets. La problématique est de conserver un niveau de performance acceptable tout en ne compromettant pas l'interopérabilité de la solution.

• import initial des données : téléchargement sur geofabrik au format osm.bz2. Bien noter la référence temporelle du lot téléchargé, cette information sera utilisée pour mettre en oeuvre les mises à jour périodiques. Chargement dans la base postGIS avec osm2pgsql compilé depuis les sources (le paquet lenny est obsolète).

• optimisation de la base en fonction des classes : on crée un index sur les attributs utilisés pour la classification.

• publication en WMS. On utilise la bibliothèque AGG et mapserver compilé avec l'option --with-experimental-png qui divise la taille des tuiles par 2 ou 3 grâce à l'optimisation (invisible) de la palette.

• tuilage avec geowebcache. Le test portant sur la projection EPSG:2154, on choisit d'utiliser pour grille de tuilage l'emprise maximale proposée par cette projection et on prend les seuils de zoom (<scaleDenominators> en terminologie geowebcache). Voici la grille utilisée :

<!-- france lambert 93 --> <gridSet> <name>EPSG:2154</name> <srs> <number>2154</number> </srs> <extent> <coords> <double>-357823.2365</double> <double>6037008.6939</double> <double>1313632.3628</double> <double>7230727.3772</double> </coords> </extent> <alignTopLeft>false</alignTopLeft> <scaleDenominators> <double>559082263.928571464</double> <double>279541131.964285732</double> <double>139770565.982142864</double> <double>69885282.991071432</double> <double>34942641.495535716</double> <double>17471320.747767858</double> <double>8735660.373883929</double> <double>4367830.186941965</double> <double>2183915.093470982</double> <double>1091957.546735491</double> <double>545978.773367746</double> <double>272989.386683873</double> <double>136494.693341936</double> <double>68247.346670968</double> <double>34123.673335484</double> <double>17061.836667742</double> <double>8530.918333871</double> <double>4265.459166936</double> <!-- <double>2132.729583468</double> --> <!-- <double>1066.364791734</double> --> </scaleDenominators> <metersPerUnit>1</metersPerUnit> <tileHeight>256</tileHeight> <tileWidth>256</tileWidth> </gridSet>

• paramétrage des expires : on se contente d'envoyer au client un délai d'expiration de plusieurs jours. Geowebcache permettrait de régler ce délai pour chaque seuil de zoom.

Le résultat

La vidéo suivante illustre (imparfaitement) le rendu d'openstreetmap à toutes les échelles.

amp;width=400&height=300" />

Avec le processus de téléchargement, de mise à jour et de rendu des données, OpenStreetMap, geOrchestra se dote d'un référentiel cartographique libre, performant, prêt à l'emploi dans les projections utilisées par les SIG. En attendant de découvrir toutes les possibilités offertes par cet apport, on ne peut que remercier la communauté des mappers et les contributeurs qui ont aidé au montage. GeoBretagne bénéficie déjà du fond OpenStreetMap.

Camptocamp a intégré un nouveau et pratique sélecteur de serveur WMS pour mapfishapp. Il est composé d'une liste de serveurs, la sélection d'un serveur déclenche un getCapabilities et liste les couches du serveur. La liste des serveurs provient d'un flux JSON ressemblant à ceci :

{ servers: [ {"name": "GeoLittoral", "url": "http://geolittoral.application.equipement.gouv.fr/wms/metropole"}, {"name": "GeoBretagne.fr", "url": "http://geobretagne.fr/geoserver/wms"} ] }

Le fichier de conf javascript permet de modifier l'origine de ce flux avec le paramètre GEOR.custom.WMS_LIST_URL. Cette fonctionnalité est disponible à partir du build #17.

Hello à tous, Voici une superbe nouvelle pour la promotion d'osm. En effet, la société mapquest à décider de rendre disponible son service de carte basé sur openstreetmap.

Ils en profitent également pour lancer les sites localisés suivant :

• http://open.mapquest.de
• http://open.mapquest.fr
• http://open.mapquest.it
• http://open.mapquest.es

Ce nouveau service mentionne évidemment d'où viennent les données et invite également à corriger les problèmes.

Il supporte le routage pour voiture ainsi que quelques options comme : éviter les péages, éviter les autoroutes, ...

Il permet aussi, comme le fait google map, de faire un "glisser-déposer" de sa route afin de modifier le chemin souhaité et de rajouter des points de passages.

Pour la recherche des lieux, le service utilise nominatim un petit peu customisé par un utilisateur de la communauté.

Et tout ça est évidemment disponible à travers une interface de programmation... plus d'info sur http://developer.mapquest.com/

source

JFL 2010 : que ce soit par intérêt pour le monde du libre, par curiosité sur le projet ou pour une explication sur les dessous techniques, nous serons très heureux de vous y rencontrer à l'occasion d'une conférence-débat.

Lundi 4 octobre à partir de 20h à la maison des associations, 53, impasse de l'Odet à Quimper (s'y rendre)

GeoBretagne vers GeOchestra, un exemple de développement OpenSource en Bretagne

GeOrchestra est la plateforme technique de GeoBretagne, partenariat entre acteurs publics en Bretagne permettant de mutualiser des données géographiques. GeOrchestra devait d’une part répondre aux objectifs de réutilisabilité, de pérennité et d’intéropérabilité, et d’autre part s’appuyer sur les principes de mutualisation, partage et subsidiarité. La communauté et l’outil GeOrchestra sont ainsi nés, trouvant dans l’opensource une traduction naturelle de ces exigences. Cette communauté GeOrchestra a vu le jour en septembre 2009 sur la forge Adullact (http://adullact.net/projects/georchestra/). Celle-ci permet d’accéder aux documents descriptifs technique et fonctionnel du projet, au planning des développements en cours, aux codes sources et à une version de démonstration. Tous les utilisateurs et/ou contributeurs peuvent ainsi se rapprocher de l’équipe d’animation pour travailler ensemble et en complémentarité.

A ne pas manquer :

• Logiciels libres et collectivités territoriales par François Elie, président de l'adullact, le 27/09
• OpenStreetMap, présentation et atelier le 20/10
• tous les autres

Cette vidéo présente le visualiseur mapfishapp et l'utilisation des styleur et requêteur.

amp;width=400&height=300" />

Les étapes suivies dans cette démo et les dessous techniques :

• 00:10 - déplacements et recentrage de la carte

les tuiles constituant chaque couche sont fabriquées par des services WMS et affichées par mapfishapp. Le chargement par tuile permet de travailler avec une grande surface d'affichage, et soulage le travail du serveur lorsque les fonds sont prétuilés - c'est le cas ici pour les photographies aériennes. Le service en ligne geonames est utilisé pour recentrer la carte sur un toponyme. geonames est une base de données en ligne librement accessible et contenant plus de 7 millions de toponymes sur le monde entier.

• 00:25 - sélection des couches raster

mapfishapp peut ajouter des couches provenant de services WMS dont on connaît l'adresse, ou de couches WMS référencées dans un catalogue de données interrogeable par le protocole CSW. L'utilisateur peut régler l'opacité de chaque couche. L'ensemble peut ensuite être sauvegardé dans un fichier au format Web Map Context, et être rechargé ultérieurement.

• 00:36 - fabrication d'un style personnalisé

la couche est interrogée par WFS:describeFeatureType pour en récupérer les attributs. Un document SLD est ensuite fabriqué puis stocké sur le serveur mapfishapp. Lorsque la couche est réclamée au serveur WMS, celui-ci télécharge d'abord le document SLD puis fabrique une carte personnalisée en fonction des filtres et styles.

• 02:44 - sélection géographique

le requêteur fabrique des requêtes WFS géométriques et/ou attributaires. Il reçoit un flux GML qui est ensuite affiché en vecteur sur la carte et en valeurs dans un tableau. Il est possible de sélectionner des objets sur la carte, ils sont alors surlignés dans le tableau, et vice-versa.

Les commentaires sont ouverts !

Je me suis lancé dans la génération automatique de cartes, sous la forme de fichiers .svg directement générés à partir de requêtes SQL sur la base mondiale d’OpenStreetMap. Et voilà le résultat :

Données © OpenStreetMap & contributeurs – cc-by-sa 2.0 & ODbl

Requêtes SQL

Attachons une base pour y mettre les nouvelles tables sans modifier la base « Planet » originale :

?View Code SQL1 ATTACH DATABASE 'boundaries.sqlite' AS boundaries;

Suppression d’un historique et création d’une nouvelle table contenant tous les contours (du monde) :

?View Code SQL1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 DROP TABLE IF EXISTS boundaries.contour; CREATE TABLE boundaries.contour AS SELECT w.id AS id_way, ( SELECT LineFromText('LINESTRING(' || group_concat(X(n.coord) || ' ' || Y(n.coord)) || ')', 4326) FROM node AS n JOIN way_nodes AS wn ON wn.id_node=n.id WHERE wn.id_way=w.id ) AS geometrie FROM ( SELECT DISTINCT * FROM ( SELECT w.id FROM way AS w JOIN way_tags AS wt1 ON wt1.id_way=w.id JOIN tag AS t1 ON wt1.id_tag=t1.id AND t1.key="admin_level" AND t1.value="2" UNION SELECT w.id FROM way AS w JOIN way_tags AS wt1 ON wt1.id_way=w.id JOIN tag AS t1 ON wt1.id_tag=t1.id AND t1.key="natural" AND t1.value="coastline" ) EXCEPT SELECT w.id FROM way AS w JOIN way_tags AS wt1 ON wt1.id_way=w.id JOIN tag AS t1 ON wt1.id_tag=t1.id AND t1.key="maritime" AND (t1.value="yes" OR t1.value="true") ) AS w;

Dans certains cas, il existe des Ways sans contenu :

?View Code SQL1 DELETE FROM boundaries.contour WHERE geometrie IS NULL;

La colonne geometrie doit être déclarée comme spatiale et recevoir un index (MBR en mémoire) :

?View Code SQL1 2 SELECT RecoverGeometryColumn('boundaries.contour', 'geometrie', 4326, 'LINESTRING', 2); SELECT CreateMbrCache('boundaries.contour', 'geometrie');

Envoi des prochaines sortie dans le fichier « .svg » :

?View Code SQL1 .output routes.svg

Commençons la génération du fichier proprement dite par l’entête du fichier :

?View Code SQL1 2 3 4 5 SELECT '<?xml version="1.0"?&gt;'; SELECT '<svg viewBox="100 -7200 1200 1200" xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny">'; SELECT '<title>Les autoroutes de France</title>'; SELECT '<desc>La France des Autoroutes</desc>';

Le trait de cote de fait en recherchant les élément du contour inclus dans la BBOX [-10, 40, 15, 52] (en degrés WGS84). Les tracés sont ensuite projetés en Lambert 93 (SRID 2154) puis simplifiés, avant d’être passés d’une échelle du mètre au kilomètre (ce dernier point évite simplement d’avoir des coordonnées de très grandes valeurs) :

?View Code SQL1 2 3 4 5 6 7 8 9 SELECT <path d="' || AsSVG(ScaleCoords(Simplify(Transform(geometrie, 2154), 2000.0), 0.001)) || '" fill="none" stroke="black" stroke-width="2" />' FROM boundaries.contour WHERE rowid IN (SELECT rowid FROM boundaries.cache_contour_geometrie WHERE mbr = FilterMbrIntersects(-10, 40, 15, 52) );

Le dessin des autoroutes se fait par superposition de deux traits (rouge large et jaune étroit). La sélection est faite par les relations type='route' et network='FR:A-road'.

?View Code SQL1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 SELECT (SELECT '<path d="' || AsSVG(ScaleCoords(Simplify(Transform(LineFromText('LINESTRING(' || group_concat(X(n.coord) || ' ' || Y(n.coord)) || ')', 4326), 2154), 1000.0), 0.001)) || '" fill="none" stroke="red" stroke-width="9" />' FROM node AS n JOIN way_nodes AS wn ON wn.id_node=n.id WHERE wn.id_way=rm.id_member ) || ' ' || (SELECT '<path d="' || AsSVG(ScaleCoords(Simplify(Transform(LineFromText('LINESTRING(' || group_concat(X(n.coord) || ' ' || Y(n.coord)) || ')', 4326), 2154), 1000.0), 0.001)) || '" fill="none" stroke="yellow" stroke-width="3" />' FROM node AS n JOIN way_nodes AS wn ON wn.id_node=n.id WHERE wn.id_way=rm.id_member ) FROM road AS r JOIN relation_members AS rm ON r.id_relation=rm.id_relation AND rm.type=2 JOIN way as w ON w.id=rm.id_member WHERE r.network='FR:A-road';

Enfin, clôture du fichier .svg :

?View Code SQL1 SELECT '</svg>';

Et voilà.

Le code source de cette page est dans le Domaine Public.

L'intégration continue des composants geOrchestra est en ligne grâce à Hudson.

Hudson est un outil simple et performant d'intégration continue. Branché sur le dépôt svn de geOrchestra, Hudson construit maintenant quotidiennement les branches du visualiseur mapfishapp et propose en téléchargement les archive war résultantes. Sont actuellement disponibles :

• le trunk, sur lequel camptocamp porte les corrections de bugs et évolutions,
• la branche dreal-bretagne-work, qui propose une surcouche facilitant la configuration et l'internationalisation, et qui reste synchro avec le trunk.

Vous pouvez souscrire au flux RSS pour être mis au courant des derniers builds.