Revue des blogs en français

Un petit message pour faire un bilan de cette première (du moins on l'espère) carto party avec des enfants de l'école Ar Milad à Lanvénégen (http://osm.org/go/erI6jclSK--), le vendredi 14 octobre dernier.

Le cadre de l'intervention : nous avons proposé cette activité sur une matinée à l'école dans le cadre d'une opération 'Semaine sans écrans" afin de montrer aux enfants qu'il y avait tout un tas d'activités à faire près de chez soit et qui nécessite une part de cerveau
disponible ...

Les préparatifs 

1 - une carte de la commune via MapOSMatic (http://www.maposmatic.org) qui s'est avérée illisible imprimée en A3 donc nous avons fait des zooms (toujours en A3) en couleur afin de pouvoir montrer aux enfants l'état actuel de la "couverture" de la commune. 

2 - Des Walkings-papers (http://walking-papers.org) pour se rendre sur le terrain et avoir des cartes (3 secteurs) avec déjà du contenu afin de n'avoir que des ajouts simples à faire. Un support cartonné pour pouvoir écrire dessus, un crayon, une gomme. 

3 - Des GPS simples ( 3 Garmin nüvi série 200) pour pouvoir géolocaliser des lieux précis (arbres, point de collecte, ...) 

4 - Des cartes IGN de la région, du département, du secteur 

5 - Une 1/2 journée de libre 

Le déroulement 

Accueil en classe, présentation de la cartographie (quelque chose de simple et d'assez ludique pour leur donner envie de participer au jeu) et du projet Openstreetmap (là aussi quelque chose de simple) et du déroulement de la matinée. 

-> Une sortie à l'extérieur : collecte des informations sur les arbres que j'ai décliné en "éléments naturels" (merci ZYMMY), les numéros des maisons et les noms de rues et enfin un groupe pour les informations "publiques" (qui concerne la population) comme les points d'apport volontaire (ici on a des cagettes pour mettre les sacs jaunes), les bornes à incendie, les toilettes publics, ... 

-> Une partie retranscription sur ordinateur : Assisté d'un énorme TBI (tableau blanc interactif) avec lequel on s'est vraiment éclatés !

Je recommande cet usage et je veux bien que le père Noël m'en apporte un ! :o) Je m'égare ... 

Retranscription donc via Potlatch 2 afin d'ajouter (super simple) les adresses et numéros des maisons, les ajouts de rues, chemins, les parkings. 

Un peu plus galère pour les arbres (les enfants avaient les coordonnées GPS des arbres mais via Potlatch 2 ce n'est pas une information pertinente !) mais cela a été retouché ensuite via JOSM 

JOSM ? Installé sur l'ordinateur mais pas assez simple d'accès pour des enfants de primaire. A voir pour des collégiens ! 

-> Une discussion autour des cartes, de la cartographie, des GPS, du géocaching ... Là on a pu aborder des sujets intéressants ! 

Déjà demandez à des gamins de placer leur village sur une carte du département ! Whaouuu ... ils n'y connaissent rien ! C'est ahurissant
! 

Ensuite regarder en détails les informations de ces cartes pour faire ressortir l'effet de péremption des données ... 

Une carte imprimée en 2005 ne correspond plus à ce que je vois dehors ! 

Openstreetmap : c'est un outil développé par une communauté de personnes qui désirent participer à la construction de leur territoire en apportant, chacun à son niveau, sa contribution pour que LA carte corresponde à NOTRE réalité. 

Je fais exprès pour les majuscules, je ne hurle pas mais souligne le message que les gamins ont semble t'il bien capté ! 

La cartographie avec quoi ? 

Le GPS c'est génial pour attire l'attention mais aussi pour détourner l'attention ! Donc pas facile à gérer, heureusement l'instit est là pour que chacun puisse l'avoir en main, l'utiliser, ... 

Les walking-papers, parfait en noir et blanc,
permettent d'apporter des notes, de faire des points, des croix, des traits ... mais je ne les utilisent pas ensuite en les renvoyant en
scans mais plutôt comme collecte de données. Et même sous le célèbre brouillard/crachin Breton on arrive à relire les infos. Cela veux dire clairement qu'il faut éviter les crayons feutres qui dégoulinent dès la moindre goutte d'eau. Le crayon bic ? Je ne suis pas convaincu ! 

LE TBI ? Trop top ! Franchement demander à un gamin de tracer une route sur un tableau avec ses doigts et qu'en 2 ou 3 coups de doigt sur le tableau cela se transforme en petite rue ou en chemin creux sur la carte moi j'ai trouvé ça merveilleux ! 

Et au vu des sourires de
certains enfants je pense que je n'étais pas le seul à rêver un peu ce matin ! 

En conclusion :
Je prépare le tirage A3 de ce que l'on a pu mettre à jour aujourd'hui afin de l'offrir à tous les enfants de la classe pour qu'ils en
gardent un souvenir concret ... 

Tout en soulignant que cette carte peu encore évoluer et qu'ils peuvent, si ils en ont envie, s'occuper de
LEUR carte, là bas pas très loin de chez eux ... 

Et on espère aussi pouvoir poursuivre ce genre d'action ...

Les résolutions fixes proposées par les services tuilés sont un obstacle à l'interopérabilité. Une solution se profile côté client dans OpenLayers.

Extrait traduit d'un article CampToCamp (voir le billet).

Jusqu'à aujourd'hui, OpenLayers ne permettait pas l'affichage d'une couche tuilée dans des résolutions non supportées par le service de tuilage de la couche. Si une carte était chargée à une résolution que le service de tuilage ne supportait pas, alors des tuiles non existantes étaient réclamées et des images cassées étaient affichées sur la carte.

A l'occasion dd'un contrat avec Swisstopo, Camptocamp a travaillé à faire évoluer cette situation pour rendre possible l'affichage de couches tuilées à des résolutions non supportées par le service de tuilage. La logique est simple: lorsque la carte est positionnée sur une résolution non supportée par le service de tuilage, OpenLayers réclame les tuiles de cette couche dans des résolutions moindres, et redimensionne la div de la couche en utilisant le facteur d'échelle resolution_moindre/resolution_carte.

Parfaire le patch a été une petite épreuve, mais il a été finalement fusionné avec la branche développement d'OpenLayers. Un exemple de cette fonctionnalité est disponible en ligne. Testez-le !

Merci à Swisstopo pour avoir financé ce travail. Et remerciements spéciaux à Andreas Hocevar pour son aide et support, et pour le patch “positionnement de tuile basé sur pourcentages" sur lequel ce travail est fondé.

L'association la ville à vélo présente sa carte des aménagements cyclables de Lyon.
Basé sur les données d'OpenSreetMap et rendu avec Maperitive.

http://carte.lavilleavelo.org/

Voili, voilou. On avance doucement mais sûrement. Mais Paris est ainsi fait que c'est un euphémisme de dire que les arrondissements périphériques sont bien plus grands et peuplés que ceux du centre. Le découpage des arrondissements dessine un joli escargot et je suis maintenant dans la dernière grande boucle.
Tiens, au passage, un problème intéressant: les arrondissements portent normalement un nom et pas seulement un numéro. Nom que l'on peut voir ici : http://fr.wikipedia.org/wiki/Arrondissements_de_Paris#Description . Pourtant, il semblerait que par habitude (ou convention ?), toutes les cartes affichent les numéros d'arrondissements et que ces noms ne soient au final jamais utilisés en cartographie. Comment les intégrer dans OSM sans violer cette convention ? Si nous les mettons dans les tags "name", nous verrons alors s'afficher une carte qui ne respecte pas ni les habitudes ni les usages courants de la cartographie mais aussi ceux de la vie courante. Alors comment concilier "usage courant", "pratiques usuelles de cartographie" et "balisage du nom officiel des arrondissements" ? Peut-être en mettant ces noms dans le tag "official_name" ?

Sinon, pour ces deux arrondissements, l'activité se suit et se ressemble. J'ai toujours une grande satisfaction lorsque je découvre des rues mal orthographiées, mal placées ou même carrément manquantes dans OSM, ce qui est devenu heureusement très rare. Parfois, il existe des petites différences entre cadastre, panneau de rue et plans officiels de la ville de Paris. Dans ces rares cas, là aussi, je privilégie la version officielle de la ville de Paris même si elle diffère du terrain et je laisse la version alternative dans un tag "alt_name" pour le cas où quelqu'un ferait une recherche par exemple.

La ville de Saint Pierre n'a pas été à proprement parlé édité depuis longtemps. J'ai entrepris d'y remettre un peu d'ordre et finaliser la structure principale des chemins et des surfaces.
Seulement, Saint Pierre n'est pas du tout ma région et je suis quasi incapable de dire la structure exact des voies principales interne à la ville j'ai donc besoin d'aide.
Si vous avez des infos ou désirez participer à la remise en forme de la ville, soyez sympa de me contacter à travers ce fil ou, si vous décidez d'intervenir directement de m'informer aussi qu'on ne croise pas méchamment les effluves.

Merci.

Note: Utilisation du tag expérimental "Parking Lane" et de "Parallele Ways" pour la définition des surfaces.

Et c'est reparti !
Cette semaine quelques démos Raster assez bluffantes sur OpenLayers, un parseur de Shapefile en Javascript, une nouvelle version de MapProxy, ou encore un possible futur service OSM, OpenMetaMap.

Bonne lecture !

en lire plus

Non, geOrchestra n'a pas été porté sur mobile (mais ça vient). Cet écran présente la superposition d'un flux WMS (PLU, parcelles cadastrales) avec un fond bing maps, le tout sur une tablette Asus/Android. Ceci grâce à l'application Locus disponible sur l'android market en versions gratuite et pro. D'une stabilité remarquable et regorgeant de fonctions pratiques (openstreetmap offline, réalité augmentée, interface avec les logiciels de navigation...), Locus permet de belles démos d'interopérabilité.

Dans quelques jours, l'API Yahoo sera fermée. Yahoo recommande à ses utilisateurs de se tourner vers celle de Nokia. Et dans un ticket d'OpenLayers on trouve :

Finally, the GoogleNG layer violates the overall intent of the terms of service that to use the tiles, you've got to use the whole map interface. The whole point is that you can't use the tiles directly.. Traduction: Finalement, la couche google viole l'esprit des conditions d'utilisation pour l'utilisation des tuiles, vous devez utiliser l'interface google maps complète. Le fait est que vous ne pouvez utiliser les tuiles directement.

La consommation directe des tuiles google par OpenLayers, une voie pressentie pour le support gmaps dans geOrchestra sans embarquer toute l'API Google, n'est donc plus possible. Dans les conditions d'utilisation de google maps, on lit en effet :

(a) No Access to Maps API(s) except through the Service. You must not access or use the Maps API(s) or any Content through any technology or means other than those provided in the Service, or through other explicitly authorized means Google may designate. For example, you must not access map tiles or imagery through interfaces or channels (including undocumented Google interfaces) other than the Maps API(s).

Le ticket 1590 prévoit que geOrchestra utilise les fonds google ou autres car ce besoin a été plusieurs fois exprimé : google couvre la terre entière, donc des périmètres d'étude bien éloignés de la zone INSPIRE... Mais ces évolutions|abandons|subtilités de licence posent question.

Il apparaît risqué d'investir sur des API dépendantes d'une décision du fournisseur, cf Google may, at any time, terminate its legal agreement with you or cease providing all or any part of the Service immediately without any notice if:...(d) providing the Service could create a substantial economic burden as determined by Google in its reasonable good faith judgment. Une lecture critique des conditions d'utilisation s'avère dans tous les cas indispensable avant d'engager les développements.

En investissant principalement sur les normes OGC, on se met à l'abri de ces risques.

Introduction

Pour ce tutoriel, nous allons essayer de faire une application de A à Z - enfin presque :

en lire plus

Voilà un billet rapide avec les dernières stats (oui oui j'adore ça...)

Au 23/06/11 Nous avons :

91037.82 km de 'motorway', 'residential','unclassified','tertiary','secondary','primary','living_street','trunk'

soit 2062,85km en plus depuis le 13/05

soit encore ~51 Km de route en plus chaque jour

nous avons aussi:

108011.89 km de 'motorway', 'residential','unclassified','tertiary','secondary','primary','living_street','trunk','track'

soit 3618,87 km en plus depuis le 13/05

soit encore ~90 Km de route (+semi carossables) en plus chaque jour.

En avril 2010 j'ai réalisé une première carte des éoliennes en france, cette carte utilise un fichier de données GML comme source de données. Afin de pouvoir réaliser une carte mondiale des éoliennes en particulier et des sources d'énergie en général j'ai mis en place une instance GeoServer avec une base de données Postgis comme source.

Ceci m'a permis de réaliser cette nouvelle carte de couverture mondiale qui recense aujourd'hui 40 781 éoliennes au plan mondial.

Cette carte sera mise à jour une fois par semaine dans un premier temps puis quotidiennement si la puissance machine le permet.

Lancée par Liness et supportée par le RERS de Courcouronnes, je participe le 25 juin prochain 14h30 à une présentation OpenStreetMap et à petite Mapping Party à suivre.

.entry .olMapViewport img { max-width: none; }#map_1 {padding: 0; margin: 0;}#map_1 img{padding: 0; margin: 0;border:none;margin-top:0px;margin-right:0px;margin-left:0px;margin-bottom:0px;}/* = limit) { return OpenLayers.Util.getImagesLocation() + "404.png"; } else { x = ((x % limit) + limit) % limit; return this.url + z + "/" + x + "/" + y + "." + this.type; } }var lonLat = new OpenLayers.LonLat(2.41480350494385,48.6289510130882).transform(map.displayProjection, map.projection);map.setCenter (lonLat,17);var markers = new OpenLayers.Layer.Markers( "Marker" );map.addLayer(markers);var data = {};var currentPopup;data.icon = new OpenLayers.Icon("http://freeroute.fr/wp-content/plugins/osm/icons/wpttemp-green.png", new OpenLayers.Size(24,24), new OpenLayers.Pixel(0, -24));var ll = new OpenLayers.LonLat(2.41480350494385,48.6289510130882).transform(map.displayProjection, map.projection); var feature = new OpenLayers.Feature(markers, ll, data);feature.closeBox = true;feature.popupClass = OpenLayers.Class(OpenLayers.Popup.FramedCloud, {"autoSize": true, minSize: new OpenLayers.Size(150,150),"keepInMap": true } );feature.data.popupContentHTML = "RERS Courcouronnes
1, Place du Printemps
91080 Courcouronnes";feature.data.overflow = "hidden";var marker = new OpenLayers.Marker(ll,data.icon.clone());marker.feature = feature;var markerClick = function(evt) { if (this.popup == null) { this.popup = this.createPopup(this.closeBox); map.addPopup(this.popup); this.popup.show(); } else { this.popup.toggle(); } OpenLayers.Event.stop(evt);};marker.events.register("mousedown", feature, markerClick);markers.addMarker(marker);map.addPopup(feature.createPopup(feature.closeBox));})(jQuery)/* ]]> */ Ordre du jour

1. Introduction
   1. Présentation d’OpenStreetMap
      La raison d’être d’OSM et la base de données (cf. la FAQ)
   2. Licences et données libres
      Licences CC-BY-SA 2.0 et ODbL (en cours)
   3. Les objets stockés et leur caractérisation :
      • Le Node (point) :
        C’est l’élément de base, le seul ayant des coordonnées géographiques dans le repère WGS84 (longitude et latitude en degrés).
      • le Way (ligne brisée) : 
        Suivant les usages, le way représente une ligne ou une surface fermée (polygone). Il est composé de Nodes (ordonnés).
      • la Relation :
        Regroupe des éléments (Nodes, Ways & Relations) avec des rôles (ordonnés).
      • les Tags (attributs) : {key = valeur}
        Il s’agit de paires clé/valeur caractérisant chaque élément. Les tags sont uniques pour un élément donné. Si plusieurs valeurs sont admissibles, elles seront séparées par un « ; ».
2. La Mapping Party
   1. Choisir les éléments à cartographier
   2. Présentation de Walking Papers
   3. Sur le terrain…
   4. Numérisation des résultats et injection dans les éditeurs
      Exemples de scans dans le sud de Courcouronnes :
      • Scan – Lien pour Potlatch
      • Lac et Parc : Scan – Lien pour Potlatch
      • NAFSEP : Scan – Lien pour Potlatch
3. La saisie dans OSM
   1. Le Wiki
   2. Les sources de données libres
   3. Les principaux éditeurs (Potlatch & JOSM)
   4. Aller plus loin dans JOSM
4. Utiliser OSM
   1. Une constellation de services
      • Les Composants d’OSM
      • Mapnik
      • Open MapQuest
      • CloudMade
      • Transport en Commun : ÖPNV-Karte
   2. Intégrer les cartes et les données avec OpenLayers

Références

• Agenda du Libre
• Liness

Comme tous les vendredis, continuons notre exploration du monde GeoWeb.

en lire plus

Nous allons mettre en oeuvre une méthode génération de tuile à la volée en utilisant l'outil TileCache sur une distribution Debian Squeeze. Le principe de TileCache exposé ici et de servir par Apache un cgi qui va générer une tuile en utilisant le moteur de rendu mapnik et la stocker sur le disque pour ne pas avoir à la regénérer à chaque appel. La procédure part d'une installation minimale de la dernière version stable de Debian à savoir Squeeze.

Première étape, installer quelques outils de travail qui ne sont pas liés au sujet qui ici nous importe mais dont nous aurons besoin. Cette action se fait avec l'utilisateur root évidemement, chaque futur changement d'utilisateur unix sera clairement explicité.

apt-get install subversion wget unzip bzip2 apache2

Sans trop détailler cette partie nous allons installer une base de données spatiale.

apt-get install postgresql postgis postgresql-8.4-postgis osm2pgsql

Si votre environnement par défaut n'utilise pas une locale en UTF-8 vous aurez à recréer votre cluster postgres, pour cela détruisez l'actuel (toutes données seront perdues) et recréé le par défaut en UTF-8. Les trois commandes suivantes supprime le cluster actuel, créé le nouveau et le démarre.

pg_dropcluster --stop 8.4 main pg_createcluster 8.4 main --locale fr_FR.UTF-8 pg_ctlcluster 8.4 main start

Pour les manipulations purement postgresql on travaille toujours avec l'utilisateur unix postgres, On passe donc sous cet utilisateur

su - postgres

On vérifie que le cluster est par défaut en utf-8 avec la commande :

psql -l

La colone encoding doit indique 'UTF8'

On créée un utilisateur sans privilèges particulier qui sera utilisé plus loin dans la configuration de mapnik.

createuser -S -D -R -P render

on considère dans la suite du billet que vous affectez ici le mot de passe 'render' à cet utilisateur ; dans la vrai vie personne n'ose faire une chose pareille évidemment :-)

Création de la base de données nommée render, que l'on affecte à l'utilisateur "render"

createdb -O render render

Les trois commandes suivantes servent à spatialiser la base. Cela permet de stocker et manipuler les objets géométriques directement avec des primitives postgres.

createlang plpgsql render psql -q -d render -f /usr/share/postgresql/8.4/contrib/postgis-1.5/postgis.sql psql -q -d render -f /usr/share/postgresql/8.4/contrib/postgis-1.5/spatial_ref_sys.sql

Les 3 commandes précédentes doivent être siliencieuses en cas de succès.

On rend la propriété des objets créés à notre utilisateur "render" (les commandes ont été lancées avec le user "postgres")

psql -d render -c 'ALTER TABLE geometry_columns OWNER TO render' psql -d render -c 'ALTER TABLE spatial_ref_sys OWNER TO render' psql -d render -c 'ALTER VIEW geography_columns OWNER TO render'

Il nous reste à effectuer l'installation du moteur de rendu mapnik et à charger le fichier de données dans la base de données Désormais nous allons travailler avec un utilisateur dédié au rendering

Retour en root pour installer la paquets nécessaires

apt-get install python-mapnik mapnik-utils

et création d'un utilisateur lambda

adduser render

On passe sous cet utilisateur render pour la suite.

su - render

Installation de mapnik depuis le dépôt svn officiel d'openstreetmap dans le répertoire /home/render/mapnik

svn co http://svn.openstreetmap.org/applications/rendering/mapnik

Toutes les informations nécessaires au rendu ne sont pas stockées dans la base de données, une partie est utilisée depuis des fichiers de formes appelés Shapefiles. On trouvera par exemple dans ceux-ci le contour des continents, qui contrairement aux autres données dans OSM bougent bien peu. Avant de pouvoir faire nos rendus nous allons donc les récupérer grâce à un script bash qui télécharge les fichiers nécessaires et les décompresse dans le répertoire courant :

cd mapnik && bash get-coastlines.sh

Là vous pouvez aller prendre un café, un sandwich ou une entrecôte suivant le débit de votre liaison internet. Le total des fichiers réléchargés dépasse les 450Mo.

A cette étape nous nous rappochons d'OpenStreetMap et allons récupérer les données pour les charger dans notre base. Nous récupérons le fichier pour la région Basse-Normandie, à vous d'adapter pour coller à votre besoin. Les deux sources de fichiers d'export les plus utilisés aujourd'hui sont Geofabrik et Cloudmade, arbitrairement nous utiliserons Cloudmade.

wget http://downloads.cloudmade.com/europe/western_europe/france/basse-normandie/basse-normandie.osm.bz2

Le chargement des données dans la base se fait avec le logiciel osm2pgsql, celui-ci utilise en entrée un fichier de données (comme celui fraichement téléchargé) et un fichier de style qui permet de filtrer les clés sur les objets en fonction de ce que l'on veut afficher sur notre carte. Le packaging de debian évoluant moins rapidement que les tags dans OSM nous allons légèrement adapter le fichier de style ajoutant la clé 'addr:housename' au fichier de style pour que notre démonstration fonctionne.

cp /usr/share/osm2pgsql/default.style . echo 'node,way addr:housename text linear' >> default.style

Longue étape, le chargement des données se fait avec la commande :

osm2pgsql -s -S default.style -d render basse-normandie.osm.bz2

là encore pour pouvez aller vous ressourcer en alcaloïde méthylxanthine ,

Avec les sources de mapnik est distibué le style utilisé pour le rendu sur le site openstreetmap.org autant l'utiliser. Étant assez complexe il est découpé en plusieurs fichiers xml qu'il faut réassembler en spécifiant la connexion à postgresql qui sera utilisée pour le rendu. Cela se fait en utilisant le script pyhton generate_xml.py de la façon suivante :

./generate_xml.py --host=localhost --port=5432 --user=render --password=render --dbname=render osm.xml > osm-local.xml

Le fichier osm-local.xml sera celui utilisé au final par mapnik, il fait tout de même 9682 lignes, on voit bien l'intérêt du découpage.

J'en profite pour féliciter ceux qui sont arrivés jusque ici et les rassurent aussi, on voit le bout.

Si on fait le point, nous avons nos données de stockées dans la base et le moteur de rendu est installé et configuré, ne nous reste donc plus qu'à passer au sujet principal de ce billet, à savoir TileCache :

Installation se fait au travers du paquet eponyme

apt-get install tilecache

La configuration s'effectue dans le fichier dans /etc/tilecache.cfg auquel nous ajouterons juste une section finale composée de :

[osm] type=Mapnik mapfile=/home/render/mapnik/osm-local.xml spherical_mercator=true tms_type=google

Cette simple configuration conclue l'installation et il ne nous reste qu'à tester l'ensemble

Par défaut TileCache va stocker les tuiles générées dans /tmp/tilecache à vous d'adapter au besoin. Dans un prochain billet on verra le cache des tuiles directement dans Memcached.

Ma machine de test s'appelle geti que vous remplacerez dans l'url suivante par le nom de votre machine

L'appel de cette url devrait vous afficher la ville de Cherbourg

http://geti/cgi-bin/tilecache.cgi/1.0.0/osm/12/2029/1395.png

Vous reconnaitrez facilement la forme de l'url que vous pourrez utiliser avec Leaflet par exemple.

Pour tester plus en avant votre installation vous pouvez récupérer un fichier simple de test disponible sur mon serveur, adaptez le nom de la machine dans le code et placez le fichier à la racine de votre site web, vous disposerez d'une carte navigable avec des tuiles générées à la volée !

wget http://carto.quiedeville.org/leaflet/article-test.html

Bugs, problèmes, mécompréhension, les commentaires sont ouverts.

Dans un précédent billet j'évoquais les possibilités de réduction de taille de la librairie OpenLayers, avoisinant le méga de données en natif je trouve cette librairie un peu trop gourmande. En réduisant au maximum les fonctionnalités j'arrivais à une taille de 154Ko ce qui permettait d'afficher des tuiles issue d'OpenStreetMap et d'avoir les fonctionnalités de déplacement et de zoom de base.

Si la problématique de la taille est primordiale dans votre déploiement de carte ligne vous serez intéressé par la nouvelle librairie Leaflet que vient de publier Cloudmade. Conçue pour les applis web et mobiles Leaflet ne pèse à ce jour que 64Ko. On ne retrouve que les fonctions de bases, mais déjà bien assez pour la plupart des cartes vues sur le web. Les fonctions de bases sont présentes avec en plus des possibilités d'ajout d'objets géometriques et les interactions minimales pour ouvrir les classiques popups. Publiée sous licence BSD le code est disponible sur Github, vous pourrez y signaler des bugs éventuels ou demander des nouvelles fonctionnalités sur la page de suivi d'anomalie.

Même si tous les exemples utilisent comme source le service MApzen de Cloudmade, il est possible d'utiliser n'importe quel serveur de tuile. J'ai fait une carte sommaire de la Bretagne avec les tuiles OSM standards, je suis assez emballé de la rapidité d'affichage,

Je vous invite à laisser en commentaire vos impressions et éventuellement à débattre de ses avantages/inconvénients par rapport à OpenLayers ; dont on attend la version 2.11 dans les jours/semaines à venir.

Hello à tous,

j'ai eu l'occasion de tester un peu osm2pgsql (le produit qui permet de mettre les données OSM dans une DB postgis).

Une fois la db crée, postgis et hstore (pas obligatoire) installé, une commande et 2h de patience et hop votre db est chargé et prête à toutes vos folles analyses

Alors voici 2-3 truc que je trouvais sympa à partager :

Au 06.05.2011

88528,25 km de 'motorway', 'residential','unclassified','tertiary','secondary','primary','living_street','trunk'

103780,37 km de 'motorway', 'residential','unclassified','tertiary','secondary','primary','living_street','trunk', 'track'

5132062 noeuds

Au 13.05.2011

88974.97 km de 'motorway', 'residential','unclassified','tertiary','secondary','primary','living_street','trunk'

104393.020 km de 'motorway', 'residential','unclassified','tertiary','secondary','primary','living_street','trunk', 'track'

5216883 noeuds

Évolution :

• Une augmentation de 446,72 km de routes (sans track) donc à peu près 63,81km /jour
• Ou une augmentation de 612,64 km de routes avec "track" donc 87,5 km/jour.
• En comptant que le réseau routier belge compte 118414km de routes, il manque 29440 km dans OSM,
• En comptant sur une croissance kilométrique constante, il faudra encore 461 jours au projet pour mapper la belgique entière
• Un ajout de 84821 noeuds donc 12 117 noeud par jours .

Répartition du type de routes :

• living_street => 268 ==> 269 km
• trunk => 1332 ==> 1316 km
• motorway => 3466. ==> 3465 km
• primary => 5484 ==> 5503 km
• secondary => 7235 ==> 7220 km
• tertiary => 11972 ==> 11998 km
• track => 15252 ==>15418 km
• unclassified => 25065 ==> 25379 km
• residential => 33704 ==> 33822 km

Unmapped Places :

Comme d'habitude les endroits peu ou pas mappé en Belgique (présence de nœuds à proximité du village) est répertoriée à cette adresse : http://bmaron.net/osm_stats/unmappe... et sur une carte : http://bmaron.net/osm_stats/unmappe...

En gros les stats pour 1 mois :

• Pas Cartographiées : 230 => 117
• Peu Cartographiées : 457 => 390

(sur à peu près 4970 lieux)

à se rythme il faudra près 32 jours pour finir les villes pas cartographiées et 6 mois pour les villes pas mappées du tout

Bref il reste encore pas mal de travail, mais globalement le projet avance à une vitesse faramineuse!

Un amis me demandais l'autre jour s'il était possible de voir facilement les rues non nommées depuis potlatch.

Bien qu'il existe le rendu noname de cloudmade, il n'est pas mis à jour très souvent et n'est pas directement disponible dans potlatch.

Alors j'ai pris mes 2 petites main et j'ai fait mon premier Mapcss file... Et oui il est possible de faire son propose style dans potlatch mais aussi dans josm ou dans d'autres outils avec un "standard" très très proche du css pour le web.

Le fichier de style fait tout de suite 3 lignes et ne fais que reprendre le style par défaut en ajoutant une magnifique couleur rouge pour les rues non nommées.

Un fichier crossdomain.xml plus loin, voici comment l'ajouter dans votre potlatch :

Commencez par ouvrir potlatch, puis cliquez sur Map Style et Edit.

Ensuite Ajouter le style avec l'url suivante : http://osm.bmaron.net/styles/pot.css

Fermez la fenêtre et choisissez le dans la liste (Bouton Map Style).

Voici le résultat =)

N'hésitez pas à voir la source du style et découvrez comme c'est simple de le modifier! ....

Le lundi 7 mars dernier, j'ai fait une présentation de MapOSMatic, un site web permettant à chacun de faire son plan de ville à partir des données d'OpenStreetMap :

• présentation générale du site ;
• comment nous avons fait pour faire ce logiciel ;
• comment ça marche derrière la page web ;
• quelques infos sur la prochaine version.

Les transparents sont maintenant disponibles, en version PDF ou les sources LaTeX.

Une remarque sur l'origine du nom, puisqu'on nous demande toujours pourquoi on a utilisé un nom pareil. ;-) MapOSMatic = « Map » pour carte en anglais + « OSM » pour OpenStreetMap + le suffixe « atic » comme dans automatique. Simple non ? :)

Qu'est-ce qu'un WPS (Web Processing Service) ? "Un service de traitement Web donne accès à des calculs et à des modèles qui traitent des données à référence spatiale. Un service de traitement Web peut être configuré pour offrir tout type de fonctionnalité SIG à des clients reliés à un réseau, ce qui comprend l'accès à des calculs et/ou à des modèles de calcul préprogrammés qui s'appliquent à des données à référence spatiale. Un tel service peut offrir des calculs aussi simple que la soustraction d'un ensemble de nombres à référence spatiale d'un autre ensemble (p. ex., pour calculer la différence entre le nombre de cas d'influenza entre deux saisons) ou aussi compliqué qu'un modèle de changement climatique mondial." Source : http://www.geoconnections.org/fr/communities/developers/standards/web_processing_service . Concrètement... Une équipe d'AGROCAMPUS OUEST - INRA (Institut National de la Recherche Agronomique) a testé des services WPS. Ceux-ci concernent l'accès à des modèles de calcul sur des bassins versants. Mieux qu'un long discours, nous vous proposons de retrouver ci-dessous le fruit de leur travail sur cette vidéo et de découvrir comment avec QGIS, on peut très simplement utiliser toute la puissance de calcul de services WPS :

Get your own valid XHTML YouTube embed code

Merci à Hervé Squividant pour cette vidéo et ce travail.

Une perspective est de pouvoir implémenter cette architecture dans geOrchestra.

Le Conseil Général du Pas-de-Calais vient de publier un MAPA relatif développement d'une application métier basée sur Georchestra afin de répondre aux besoins de son Centre Départemental d'Archéologie (http://archeologie.pasdecalais.fr).

Objet du marché : Développement, intégration, maintenance, hébergement du Système d'informations Archéologiques du Conseil Général du Pas-de-Calais et prestations associées basé sur l'outil libre Georchestra.

Téléchargement des pièces : Les pièces du dossier sont mises à disposition sur le portail internet du CG62 (https://marches.local-trust.com/index.php5?page=entreprise.EntrepriseDetailConsultation&refConsultation=767&orgAcronyme=cg-62).

Date limite de réception des offres : 1er mars 2011, à 16 heures.