Vous consultez notre ancien site web, accédez au nouveau site sur www.openstreetmap.fr
Agrégateur de flux
Installer la librairie OpenLayers sur votre serveur
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.gzOn décompresse l'archive dans le répertoire courant
tar xvfz http://www.openlayers.org/download/OpenLayers-2.10.tar.gzIl 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
OpenLayers et les projections
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
mapfishapp: la forge dédiée
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.
Utiliser OpenLayers et OpenStreetMap : la carte minimale
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.
Revue de presse de la semaine
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".
Revue de presse du 29 Octobre 2010
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[Mashup] Les morts en Iraq
[Détente] Fix GPS
Pourquoi l'« ouverture » des données de Rennes Métropole est insuffisante
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û faireLe 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.
Several OSGeo projects can communicate with each other...
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...
Calculateur d'espace disque pour tuiles OpenStreetMap
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.
[Matériel] RBT-2300 HS, recherche un remplaçant
Community Updates... les nouvelles
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....
geOrchestra fait le plein d'OpenStreetMap
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 classesPierre 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 geOrchestraLes 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 :
- 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.
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.
Mapfishapp : sélecteur WMS
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.
Le million ! Le million !
MapQuest utilise OpenStreetMap
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 :
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/
geOrchestra aux journées finistériennes du libre 2010
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 BretagneGeOrchestra 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
Vidéo du visualiseur
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 !
Les Autoroutes de France
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
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.svgCommenç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"?>'; 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.