Planet Georezo » Benjamin Chartier

Un Planet est un site Web dynamique qui agrège le plus souvent sur une seule page, le contenu de notes, d'articles ou de billets publiés sur des blogs ou sites Web afin d'accentuer leur visibilité et de faire ressortir des contenus pertinents aux multiples formats (texte, audio, vidéo, Podcast). C'est un agrégateur de flux RSS. Il s'apparente à un portail web.
Vous pouvez lire le billet sur le blog La Minute pour plus d'informations sur les RSS !

Feeds

61043 items (0 unread) in 112 feeds

Dans la presse

Du côté des éditeurs

Toile géomatique francophone

Géomatique anglophone

Blogs GeoRezo.net

Autres planets

Planet OSGeo

Abonnez vous à cette page (RSS) !

Benjamin Chartier

19 avril 2013
6:35
TileMill et UTF-8
sur Benjamin Chartier

Travaillant depuis quelques temps à la production d’un fond cartographique basé sur OpenStreetMap et Natural Earth j’ai été confronté à l’exploitation de shapefile encodé en latin1 plutôt que UTF-8. Par défaut, TileMill et Mapnik considèrent que les shapefiles sont encodés en UTF-8. La solution pour exploiter les shapefiles de Natural Earth encodés en Latin1 est expliquée ici et là. Il faut dire que c’est un sujet évoqué très rapidement dans la doc de Mapnik ici.
11 avril 2013
21:06
D’autres projections
sur Benjamin Chartier

Pour poursuivre la série des projections : Which world map projection is correct?
C’est en anglais, moins dynamique, la projection de Peters n’est pas représentée mais au moins Peters est cité.
02 avril 2013
10:50
Projections et D3
sur Benjamin Chartier

Une jolie démonstration des capacités de la bibliothèque javascript d3.js : Map Projection Transitions.

Via GIS Lounge.
10 février 2013
9:57
Distance entre deux points
sur Benjamin Chartier

Une de mes connaissances m’a récemment demandé si j’avais un outil pour calculer la distance entre deux points à la surface du globe. Ce qui m’est venu de plus simple à l’esprit : 23.5S 46.4W to 56.8N 60.6E (cf. ici pour d’autres calculs simples de géodésie sur WolfgramAlpha).
28 janvier 2013
20:57
GPKG
sur Benjamin Chartier
En fin d’année dernière, j’évoquais les travaux de l’OGC visant à définir un format de données : GeoPackage (cf. ici). L’OGC a lancé un appel public aux commentaires sur ces spécifications qui courre jusqu’au 7 février prochain (cf. ici et là).

En résumé, ce format se veut être un conteneur universel de données géographiques puisqu’il permet de stocker à la fois des données vectorielles et maillées (dont des tuiles organisées sous forme de pyramides d’images) dans un fichier unique interrogeable en SQL (sans toutefois nécessiter l’usage d’un serveur). Je n’ai pas lu l’intégralité du document mais j’ai noté quelques points intéressants :
- L’implémentation de référence proposée dans ses spécifications est basée sur SQLite, SpatiaLite, GEOS, PROJ.4. Intéressant de voir une fois de plus qu’une solution libre se positionne comme une implémentation de référence d’un standard de l’OGC ;
- MapBox a contribué (dans une mesure que je ne sais pas évaluer) à la rédaction de ces spécifications. Rappelons que MapBox promeut un format partageant certaines caractéristiques avec GeoPackage : MBTiles (ce dernier est basé sur SQLite mais pas SpatiaLite semble-t-il) ;
- Encore une fois, ce projet de standard est développé par des acteurs ayant une activité importante dans le domaine militaire ou de la sécurité. C’est intéressant de voir à quel point ces acteurs sont très intéressés par l’interopérabilité et les standards ouverts.
22 janvier 2013
10:13
Recueil de cartes interactives
sur Benjamin Chartier

Juste une petite redirection vers un article référençant quelques exemples de cartes interactives intéressantes d’un point de vue graphique :
16 Inspiring Examples of Interactive Maps in Web Design.
03 janvier 2013
7:55
Toujours chez Packs Pub
sur Benjamin Chartier

J’ai remarqué que la description et la table des matières d’un autre bouquin de chez Packt Publishing mentionnent la problématique de l’indexation et de la recherche géospatiales : Apache Solr 3 Enterprise Search Server.

Pour info, Solr est une solution serveur basée sur Lucene dont le but est d’indexer des documents, des contenus et de réaliser des recherches performantes. Lucene est intégré dans les catalogues GéoSource et GeoNetwork par exemple.

Je ne sais pas si leurs bouquins sont à la hauteur mais cela montre déjà que l’exploitation de l’information géographique est une problématique de plus en plus courante chez ce type d’éditeurs.
7:40
Bouquin sur GeoServer
sur Benjamin Chartier

Le site de Packt Publishing annonce la sortie pour janvier 2013 d’un ouvrage consacré à GeoServer, en anglais :
GeoServer Beginner’s Guide.
25 décembre 2012
22:44
Nouvelles de l’OGC
sur Benjamin Chartier
Je n’assiste plus aux réunions de l’OGC. Néanmoins, j’essaie de rester à l’écoute de ce qui peut concerner cet organisme et ses travaux :
- Daniel Morissette nous conjure de ne pas passer à WMS 1.3.0 mais de rester sur la version 1.1.1 : Don’t « upgrade » to WMS 1.3.0 unless you really have to, stick to 1.1.1. Bon, le plus intéressant réside dans les commentaires de cet article. En effet, il semblerait que certains souhaitent ajouter une opération aux services WMS pour qu’ils décrivent de quelle manière ils gèrent l’ordre des axes des systèmes de coordonnées ;
- Certains membres de l’OGC élaborent, dans le cadre des derniers test-beds de l’OGC, un projet de standard intitulé GeoPackage qui peut être vu comme une alternative au format Shapefile : OGC Draft GeoPackage Specification – Finally the Shapefile Format Replacement? Ce travail s’appuie sur les capacités de SQLite à stocker des données de type vecteur et raster. Intéressant.
23 décembre 2012
9:13
u{Map} alpha
sur Benjamin Chartier

En lisant les archives du mois de décembre de la liste talk-fr d’OpenStreetMap (cf. ici), je suis tombé sur une application fort intéressante (mais en version alpha pour l’instant) permettant de publier simplement des cartes basées sur OpenStreetMap : u{Map}.

C’est libre, basé sur Django et Leaflet. Que du bon, en somme.
03 novembre 2012
18:28
Microdata et géo
sur Benjamin Chartier

En faisant le tour des technologies qui gravitent autour de HTML 5, j’ai découvert Microdata (cf. ici et là). Le principe : l’ajout de tags (des métadonnées) dans le code HTML pour ajouter une touche sémantique utilisable principalement par les moteurs de recherche. Microdata est présenté comme une sorte de successeur des Microformats.

Le point qui m’a intéressé est que certains des schémas définis pour Microdata concernent la localisation : GeoCoordinates et GeoShape (la liste des schémas est disponible ici). Ces formats sont très rudimentaires puisqu’ils ne supportent que des longitudes, latitudes et altitudes (sans référence à un quelconque système de coordonnées).

Il pourrait être intéressant que les navigateurs reconnaissent automatiquement ces tags pour afficher une micro carte géographique lorsque l’utilisateur passe la souris sur le bloc contenant ces informations géolocalisées.
02 novembre 2012
10:37
Quid du futur de Flex pour la géomatique ?
sur Benjamin Chartier

Jusqu’ici j’étais persuadé que Flex allait mourir tranquillement dans son coin en raison du manque de support de Flash sur différentes plates-formes mobiles. En faisant un rapide tour du web, je m’aperçois que les choses sont moins claires que ce que je pensais, même si de toute évidence Flash (ainsi que Silverlight d’ailleurs) n’a pas le vent en poupe.

Pour rappel, Adobe a annoncé l’arrêt du développement du player Flash pour les plates-formes mobiles. Adobe a également confié le développement du SDK Flex à une communauté open source (Adobe Flex devient Apache Flex). Adobe continue à promouvoir Flex (en particulier en continuant à développer Flex Builder) mais parie sur HTML 5 sur le long terme. Pour en savoir plus : ici et là (on peut noter que l’auteur de cet article n’apprécie guère HTML5/javascript).

Aujourd’hui, ESRI promeut Flex et Silverlight et continue à investir dans ses API Flex et Silverlight (cf. ici, ici, encore ici et là). Du côté des projets libres, OpenScales est toujours basé sur Flex même si une démo d’une application HTML 5 & WebGL est dispo.

Grosso modo, j’ai l’impression que les éditeurs de solutions basées sur Flex ne veulent pas communiquer autour de l’avenir de Flex pour éviter de prendre à contre-pied leurs utilisateurs actuels. Cela ressemble à un mélange de prudence et de déni de la réalité (c’est sans doute excessif mais, pour me défense, je suis convaincu du déclin de Flash et Flex). Je dois reconnaître que la communication d’ESRI n’est pas aisée du fait du manque de clarté d’Adobe (Microsoft ne fait guère mieux) et qu’il est courageux de soutenir ces technologies en ce moment (à moins qu’il ne s’agisse d’inconscience).

Personnellement, je préférerais qu’on nous présente une vision à long terme un peu ambitieuse plutôt que des discours dont le principal but est visiblement de rassurer les actuels utilisateurs.

Et donc, quid du futur de Flex pour la géomatique ? Et bien, j’ai l’impression que tout le monde fait des efforts pour que Flex ne meurt pas trop vite même si personne ne sait si cela durera longtemps. Flash et Flex ne sont pas de mauvaises technologies (loin de là) mais force est de constater qu’HTML 5 dispose de plus de soutien. Etant donné que je n’ai pas une vision claire et ambitieuse de ce que devrait être le web et la géomatique mobile des prochaines années, j’aurais tendance à parier (avec une certaine forme de prudence donc) sur HTML 5.
20 septembre 2012
14:55
TileMill 0.10.0
sur Benjamin Chartier

Va falloir que je pense à migrer vers cette nouvelle version : TileMill 0.10.0.
11 septembre 2012
9:14
D3
sur Benjamin Chartier

Je ne connaissais pas D3.js. Très intéressant pour créer des graphiques interactifs à partir de données complexes. Jetez un œil à ceci.

Via le flux de b_b sur SeenThis.
10 septembre 2012
14:48
MySQL, un vrai moteur de base de données géospatiale ?
sur Benjamin Chartier
Il semblerait que MySQL 5.6 implémente de mieux en mieux Simple Feature de l’OGC : auparavant MySQL ne savait pas réellement comparer deux géométries ; il comparait simplement leurs rectangles englobants.

Pour plus d’info :
- MySQL inches closer to PostGIS with support of true spatial relationship functions ;
- What Is New in MySQL 5.6 (cf. paragraphe commençant par « OpenGIS »).
Via Slashgeo
9:08
QMap
sur Benjamin Chartier

Un petit nouveau dans la galaxie de QGIS : QMap (cf. l’annonce ici). Je ne l’ai pas encore essayé mais ça me parait déjà intéressant : travail hors-ligne et capacité de synchronisation (mais pas encore avec des bases de données relationnelles libres – dommage), saisie des attributs via des formulaires et annotations manuelles de la carte. Côté système d’exploitation : Windows.
31 août 2012
16:42
Guide de gestion des catalogues de métadonnées INSPIRE
sur Benjamin Chartier

Le CNIG vient de publier un nouveau guide à l’usage des administrateurs d’infrastructures de données géographiques : Le guide de gestion des catalogues de métadonnées INSPIRE. Il est aussi disponible dans le wiki du GeoRezo ici.
11:15
Mapnik 2.1
sur Benjamin Chartier

La version 2.1 de Mapnik vient de voir le jour. Plein de bonnes choses en perspectives. En plus, TileMill 0.10 (pas encore disponible) devrait supporter cette nouvelle version.

cf. ici
26 juillet 2012
0:06
Interface de Skobbler
sur Benjamin Chartier
Hier, j’ai ajouté dans cet article une référence vers une appli web qui me plait beaucoup : Skobbler.

J’en refais la pub aujourd’hui pour une foule de raisons :
- le fond carto OSM me plait beaucoup ;
- l’IHM de l’appli est vraiment plus sympa que celle du site officiel d’OpenStreetMap ;
- on y trouve un calculateur d’itinéraires basé sur OSM ;
- la consultation carto est motorisée par Leaflet.
24 juillet 2012
22:47
Systèmes de coordonnées
sur Benjamin Chartier

Depuis un certain temps je me pose une question qui parait assez simple : quels systèmes de coordonnées un portail géographique régional français doit-il supporter pour l’affichage de données (je ne parle pas des systèmes de coordonnées qui peuvent être utilisés au niveau des bases de données sources ni des données téléchargées par les utilisateurs) ?

Au cours d’une discussion que j’ai eue aujourd’hui avec Gaël Musquet a été mentionné un projet d’OpenStreetMap France de mise en place d’un serveur de tuiles OpenStreetMap plus léchées que les tuiles Mapnik que l’on voit depuis des années (des graphistes seraient prêts à travailler sur la définition des styles). Cela m’a particulièrement intéressé car j’aimerais bien que des données OpenStreetMap graphiquement attractives (genre GéoBretagne ++) puissent être utilisées comme fond de carte dans le futur portail régional picard. J’ai donc demandé si le Lambert 93 serait supporté. Réponse de Gaël Musquet : c’est la première fois qu’on lui fait cette demande.

Je suis surpris mais pas complètement. J’ai l’impression que les projections Lambert 93 et celles imposées par INSPIRE ne concernent que les autorités publiques mais ne présentent que peu d’intérêt pour les développeurs d’applis web. Finalement, est-ce que les collectivités territoriales et les services de l’état doivent s’embêter avec les systèmes tels que Lambert 93 et les projections basées sur ETRS 89 pour respecter la réglementation ou est-ce qu’elles ne feraient pas mieux de faire comme Google et utiliser sa projection ? Personnellement, je serais tenté de fournir des tuiles dans ces 3 systèmes de coordonnées afin de satisfaire le maximum d’utilisateurs et d’applis web. Je serais preneur d’avis sur le sujet…

Pour information, les services WMTS du Géoportail v3 (je ne parle pas des autres services) proposent uniquement la projection Google (EPSG:3857).
02 juillet 2012
21:50
WMTS et QGIS
sur Benjamin Chartier

QGIS 1.8 est sorti il y a quelques jours. Au lieu de vous parler des trucs qui sont dedans (cf. article de Nicolas Rochard), je vais vous parler d’un truc qui n’y est pas encore : le support de WMTS.

Il devrait cependant arriver bientôt : cf. ce message de la liste de diffusion des développeurs de QGIS et ce message sur l’un des Google Groups de geOrchestra (que vous pourrez visualiser si vous êtes membre de ce groupe :(
25 juin 2012
11:42
Comparateur de fonds carto
sur Benjamin Chartier

Pour compléter l’article précédent, voici un comparateur de fonds carto pratique :
Map Compare de Geofabrik.

via OpenGeoData
19 juin 2012
19:16
Jolis fonds carto dérivés d’OpenStreetMap
sur Benjamin Chartier
Ces derniers temps, quelques initiatives visant à produire des fonds carto sympas ont vu le jour. Il est intéressant de noter que ces fonds carto utilisent presque tous les données d’OpenStreetMap et le moteur de rendu Mapnik.

Voici ceux qui m’ont particulièrement marqué :
- Fond Watercolor chez Stamen ;
- Fond Toner chez Stamen ;
- Fond d’iPhoto d’Apple ;
- TopOSM (carte basée sur OpenStreetMap et des données de l’USGS) ;
- Carte routière de MapQuest ;
- Fond carto utilisé par GéoBretagne et CRIGEOS ;
- Fonds carto de Vizzuality donnant l’impression d’être tracé au Bic (cf. article de Geotribu) ;
- Fond expérimental créé pendant le dernier code sprint de Mapnik et utilisant les capacités de lissage sous forme de courbes de Bézier ;
- Fond carto créé par Flickr (cf. ici) ;
- Fond carto de Skobbler ;
- Fonds carto proposés dans MapBox. Je n’ai pas trouvé de lien vers la description de ces fonds. Vous pouvez les visualiser en actionnant les boutons « Paris », « New York », « Tokyo » et « London » sur cette page.
~~J’avais aussi repéré un fond carto donnant l’impression d’être tracé au Bic. Malheureusement, je ne l’ai pas retrouvé. Si vous avez le lien quelque part, je suis preneur.~~ (merci à Pierre et Arnaud pour le lien)

Évidemment, tous ces fonds sont disponibles sur toute l’Europe, en Lambert93 et ETRS89 ! J’déconne…
11 juin 2012
19:01
Etienne Daho et les SIG
sur Benjamin Chartier

Décidément, les SIG se cachent là où on ne les attend pas. Tenez, dans les paroles de « Des Attractions Désastre » d’Étienne Daho :
[…] Les flèches que Cupidon m'a décrochées N'étaient que des haches dans le dos Et si j'ai rampé tout en bas J'ai surfé aussi tout là haut […]

C’est un peu hermétique pour moi, mais bon.
15 avril 2012
21:28
Jolie carto et Python
sur Benjamin Chartier

Aujourd’hui, je ne vous parle pas d’une nouvelle bibliothèque de développement cartographique en Python. Désolé. Je fais juste un peu de pub pour un petit jeu de stratégie développé en Python et dont le graphisme est très réussi : Unity of command.
09 avril 2012
22:42
WFS 2.0 dans GeoServer
sur Benjamin Chartier

La version bêta de GeoServer 2.2 a été annoncée vendredi dernier ici. Cette version inclut un travail réalisé par OpenGeo pour l’IGN, l’année dernière : l’implémentation de WFS 2.0 dans GeoServer. Cette version de ce standard est déjà très intéressante en soi. Le fait qu’elle est recommandée pour les services de téléchargement directs d’INSPIRE et que l’IGN l’utilisera dans la version 3 du Géoportail la rend encore plus intéressante.

Petite remarque au passage : Il aurait été sympa que le communiqué publié vendredi mentionne que ce travail a été réalisé en collaboration avec CS et Neogeo Technologies. Pour ma part, j’ai réalisé les contrôles de conformité du travail d’OpenGeo.
22:26
Satisfaction
sur Benjamin Chartier
J’aime bien penser que je ne fais pas toujours des trucs qui ne servent à rien ou mal foutus. Je préfère encore plus quand ce sont les autres qui me le disent. Cette semaine, j’ai découvert deux citations de mon travail :
- Yves Jacolin lors d’une présentation de WFS (orientée vers la version 2.0) donnée au cours de Rencontres SIG la Lettre ;
- Une de mes applis est mentionnée sur le site de MapServer : Inspire Tester (cf. en bas de cette page).
J’aime bien que l’on cite mon travail. J’aime bien aussi que l’on me remercie ou me félicite. Cela ne coute pas très cher et me fait plaisir. Alors, lâchez-vous…
31 mars 2012
15:27
SVG Cleaner
sur Benjamin Chartier

À mes heures perdues, je réalise des icônes avec Inkscape. L’inconvénient de cet outil est qu’il produit du code SVG assez lourd et pas optimisé du tout. Je me suis donc lancé dans l’écriture d’un script en Python pour nettoyer le code SVG de toutes ses aberrations et autres informations inutiles. Ça marche pas trop mal mais c’est un peu pénible à maintenir : gérer toutes les subtilités de SVG est loin d’être évident. Pour soulager ma peine, des développeurs se sont lancés dans l’écriture d’un programme similaire, plus ambitieux et pourvu d’une IHM : SVG Cleaner.

Sur le papier, c’est l’outil idéal (pour mon besoin). Malheureusement, j’ai l’impression qu’il ne réalise pas l’ensemble des traitements annoncés. Je vais surveiller les prochaines sorties de cet outil en espérant pouvoir jeter bientôt mon script à la poubelle. Outre le fait qu’il ne semble pas faire tout ce que j’attends de lui, ce programme a un défaut qui va m’empêcher d’y contribuer : les traitements sont réalisés en Perl !

Libre Graphics World fait un suivi régulier de cet outil (en anglais) : ici.
24 mars 2012
8:33
À force de tourner les pages…
sur Benjamin Chartier

… je vais finir par arriver à la fin du bouquin. Voilà, j’écris un nouveau chapitre de ma vie professionnel : j’ai rejoint le Conseil Régional de Picardie le 1er mars dernier pour donner un coup d’accélérateur à la mise en place d’un portail géographique régional (GéoPicardie).
08 avril 2011
9:25
Fin programmée pour OWS Search Engine
sur Benjamin Chartier

La petite application OWS Search Engine que j’ai écrite pour rechercher des services type OGC va bientôt ne plus fonctionner. La raison : l’API Yahoo! Search BOSS va bientôt devenir payante.
01 août 2010
22:32
Une page se tourne
sur Benjamin Chartier

Je vais mettre ce blog en pause. Je ne compte pas m’arrêter de vous faire part des sujets qui m’intéressent ; je le ferai sur le blog de Neogeo, en compagnie de Guillaume Sueur et François-Xavier Prunayre. Je vous donne donc rendez-vous à l’adresse suivante : [www.neogeo-online.net]
05 juillet 2010
10:47
CSS 3
sur Benjamin Chartier
Après HTML 5, vous vous posez peut-être des questions sur CSS 3. Voici quelques liens pour vous donner une idée des capacités de cette nouvelle version :
- CSS3 Click Chart : une série d’exemples joliment présentés ;
- CSS3 Previews : une série d’exemples moins bien présentés mais accompagnés des sources et plus illustratifs pour les développeurs ;
- CSS Properties Index : la liste des propriétés CSS. On s’aperçoit d’une explosion du nombre de propriétés avec la version 3.
Étant donné que ce standard n’est pas encore dans son état définitif et qu’il n’est pas complètement implémenté par les différents navigateurs web actuels, certains exemples peuvent ne pas s’afficher correctement chez vous.

Et enfin, pour vous aider à faire la transition en douceur, voici quelques conseils fournis par Impressive Webs : CSS3 Best Practices.
26 juin 2010
18:05
Les nouveautés de HTML 5
sur Benjamin Chartier

Il va bien falloir se mettre à HTML 5 un de ces jours. Pour vous aider dans cette tâche, vous pouvez consulter ce document du W3C fort intéressant : HTML5 differences from HTML4. Il décrit les différences entre HTML 5 et HTML 4.

D’autres documents utiles et abordant d’autres aspects d’HTML ont été également annoncés par le W3C ici. Notez que ces documents ne sont pas des versions finales mais des ébauches.
25 juin 2010
12:37
Yahoo! PlaceFinder : un service de géocodage
sur Benjamin Chartier

Yahoo! a annoncé, il y deux jours, la sortie d’un nouveaux service à destination des développeurs en remplacement de Yahoo! Maps Web Services Geocoding API : Yahoo! PlaceFinder.

Il s’agit d’un service de géocodage et de géocodage inverse. Un de ses intérêts est d’utiliser les identifiants géographiques de Yahoo! GeoPlanet dont il peut être un complément utile.
11 juin 2010
23:44
Une carte en HTML
sur Benjamin Chartier

En septembre 2009, je vous parlais d’une idée émise au sein du groupe de travail Mass Market de l’OGC : définir une balise HTML <geomap> qui demanderait au navigateur web d’afficher une carte (cf. ici). L’idée suit son cours. GéoTribu nous fournit une démonstration de faisabilité de la chose : là.
16:14
Des icônes dédiées à l’information géographique
sur Benjamin Chartier

Un petit lien vers des icônes conçues pour être utilisées dans des applications géographiques : Vista Style GIS/GPS/MAP Icon Set.
Elles ne sont ni libres ni gratuites.

Via WebResourcesDepot.
18 mai 2010
15:40
Compatibilité de requêtes spatiales
sur Benjamin Chartier

J’ai lu avec beaucoup d’intérêt le document suivant : Etude des bases de données spatialisées (via GéoTribu). Si le stockage de données vectorielles dans une base de données relationnelle vous intéresse, vous devriez lire ce document. Il ne vous expliquera pas comment vous y prendre mais présentera de manière relativement accessible les principales différences entre 3 solutions largement utilisées aujourd’hui : Oracle 10g (Spatial et Locator), PostGIS et MySQL.

L’aspect le plus intéressant (pour moi) réside dans l’analyse du respect des standards de l’OGC (notamment Simple Feature Access – Part 2: SQL Option). Ce document date de 2007 mais son contenu semble toujours d’actualité. Son auteur (Nicolas Ribot) identifie un certain nombre de divergences entre les standards de l’OGC et l’implémentation d’Oracle. Ces divergences résident essentiellement sur la manière dont certaines fonctions et prédicats spatiaux sont nommés. Cela a pour conséquence de rendre des requêtes SQL non portables d’un système à un autre (au moins depuis et vers Oracle). C’est bien expliqué dans le document en question.

Il y a un point (mineur me direz-vous) pour lequel je ne rejoins pas l’analyse de l’auteur. Il réside dans la phrase suivante : « L’adhésion des systèmes à la norme OGC (partielle pour MySQL) ne garantit donc pas une compatibilité complète des requêtes spatiales ». Cette phrase n’est pas fausse en soi. En effet, on est plus ou moins fréquemment confronté à des incompatibilités qui sont dues à des ambiguïtés des standards. Cela dit, le problème dont il est question ici n’est pas un problème d’interprétation des standards (qui sont très clairs à mon avis dans le cas qui nous intéresse) mais plutôt un manque de profondeur dans la lecture des standards par Oracle ou bien une volonté délibérée de ne pas les respecter (ce qui peut se comprendre). Il semble évident qu’il s’agit de la deuxième solution quand on sait que l’éditeur de la majorité des standards de la famille Simple Feature est John R. Herring et qu’il travaille pour… Oracle !

Les choses sont probablement plus compliquées qu’il n’y parait car on ne peut pas dire que M. Herring représente à lui tout seul Oracle, ni que l’ensemble des exigences de ces standards soit le fruit du travail d’Oracle. Cependant, le fait que ce soient les développeurs de PostGIS (ainsi que ceux de JTS et GEOS) qui respectent le mieux ces standards alors qu’ils n’ont pas participé à leur élaboration (enfin, je crois) me laisse plutôt perplexe. Cela me laisse espérer que l’interopérabilité entre systèmes peut être atteinte s’il existe une réelle adhésion aux standards.
16 mai 2010
22:56
Relations spatiales
sur Benjamin Chartier
Vous avez peut-être déjà rencontré des termes tels que « crosses », « overlaps », « contains » et « touches » en manipulant des outils tels que Oracle, PostGIS, GEOS, JTS ou encore les ArcObjects. Ces termes désignent des relations spatiales entre géométries. Ces notions, bien que intuitives, sont normalisées. Elles sont en effet définies dans un document de l’OGC intitulé Simple feature access – Part 1: Common architecture.

Les définitions de ces termes s’appuient sur une formulation mathématique assez hermétique au premier abord mais finalement assez pratique : la matrice de Clementini ou notation DE-9IM (Dimensionally Extended Nine-Intersection Model). Un exemple : la relation « disjoint » s’écrit selon cette notation sous la forme [FF*FF****]. Pour en savoir plus sur cette matrice vous pouvez vous référer à la spécification de l’OGC susnommée ainsi qu’à l’article de Christian Strobl suivant : Dimensionally Extended Nine-Intersection Model (DE-9IM). D’autres articles sont également référencés dans une bibliographie recueillie par Sean Gillies ici (cette liste couvre d’autres sujets que la matrice de Clementini).

Si vous voulez jouer avec ces notions, deux outils assez faciles d’accès sont disponibles :
- JTS Test Builder (dont il est question dans cet article de PerryGeo) ;
- de9im de Sean Gillies pour les amateurs de Python (cf. cet article)
Je disais plus tôt que les relations spatiales définies dans Simple Features de l’OGC sont intuitives. En fait, non. Vous devez vous méfier des apparences. Deux exemples :
- D’après la définition de « contains » établie par l’OGC, un polygone ne contient pas sa limite. Pour mieux comprendre le problème, je vous invite à lire cet article de Martin Davis : Quirks of the « Contains » Spatial Predicate ;
- Certaines implémentations de ces relations spatiales, vont au-delà de la définition établie par l’OGC en apportant des ajustements. Si vous regardez la définition de « crosses » dans la documentation de GEOS (cf. ici) vous trouverez ceci : « The SFS defined this predicate only for P/L, P/A, L/L, and L/A situations. JTS extends the definition to apply to L/P, A/P and A/L situations as well, in order to make the relation symmetric ».
Un sujet simple… en apparence.
09 mai 2010
21:25
Cédric Moullet vous parle de WMTS
sur Benjamin Chartier

Pour en savoir un peu plus sur WMTS, jetez un œil à cet article de Cédric Moullet (surtout si vous utilisez TileCache) : From TileCache to WMTS.

Pour ma part, j’ai noté que je ne suis pas le seul à penser qu’utiliser WMTS via des requêtes SOAP ou KVP est idiot. D’ailleurs, il me semble que les contributeurs principaux de cette spécification n’étaient pas très chauds pour que ces types de requêtes soient décrites dans les spécifications.

Si la manière dont collaborent l’OSGeo et l’OGC vous intéresse, vous pouvez lire le message suivant : TMS and WMTS. Aujourd’hui, cette collaboration n’est pas très active et certains regrettent le peu d’implication de l’OSGeo au sein de l’OGC et le manque de sollicitation de l’OSGeo par l’OGC sur le sujet de WMTS alors qu’un standard du même type avait déjà été écrit par les membres de l’OSGeo (pour mémoire : Tile Map Service Specification).
05 mai 2010
22:00
Potlatch 2
sur Benjamin Chartier

L’outil de saisie en ligne Potlatch d’OpenStreetMap s’apprête à passer à la version 2. Outre quelques évolutions fonctionnelles majeures du côté de la simplicité de la saisie et de l’apparence des objets en cours de saisie (cf. ici), une petite évolution du côté du langage semble avoir lieu. La première version est écrite en ActionScript (un langage cousin de JavaScript utilisé par la plate-forme Flash d’Adobe). La prochaine version semble exploiter la plateforme de développement Flex (technologie libre d’Adobe). Cela ne l’empêche pas d’être toujours majoritairement écrite en ActionScript 3.
01 mai 2010
21:17
Support de WMTS dans gvSIG mini 0.2 !
sur Benjamin Chartier

La version 0.2 de gvSIG Mini pour Android supporte WMTS (cf. ici) ! Plutôt une bonne nouvelle pour WMTS même si cela reste un support très discret.

Pour l’instant, WMTS est plutôt intimiste. Regardez ici pour avoir une idée du nombre de services WMTS référencés par Yahoo! Regardez là pour l’équivalent chez Google. Pas fameux, hein ?

Via Slashgeo.
24 avril 2010
21:38
Nouvelle version d’OpenLayers
sur Benjamin Chartier

Avec sa toute dernière version (annoncée hier ici) OpenLayers supporte enfin la version 1.3 de WMS. J’ai l’impression que la principale difficulté pour franchir ce cap a été de trouver une solution pour prendre en compte l’ordre des coordonnées d’un certain nombre de systèmes de coordonnées de l’EPSG (cf. ici et là). Pour l’instant, OpenLayers considère que pour l’ensemble des systèmes de coordonnées dont l’identifiant est compris entre 4000 et 5000 l’ordre est latitude puis longitude (EPSG:4326 – alias WGS84 – rentre donc dans ce cadre). Je ne suis pas sûr que cela soit très robuste. Cela dit, cela fonctionnera très certainement pour avec la définition de WGS84 donnée par le registre de l’EPSG.

Ce n’est pas la seule nouveauté concernant l’interopérabilité : OpenLayers 2.9 apporte son lot de nouveautés concernant SOS (Sensor Observation Service) et CS-W (Catalogue Service for the Web).
14 avril 2010
9:48
Futur de Mapnik
sur Benjamin Chartier
À l’occasion de WhereCamp 2010, les différentes parties prenantes de Mapnik se sont réunies pour discuter des évolutions de Mapnik (cf. ici). Les points qui ont attiré mon attention concernent :
- La volonté d’aboutir à un serveur WMS performant et capable d’assurer une bonne montée en puissance. Pour cela, la participation au prochain FOSS4G WMS shootout 2010 est envisagée ;
- Le désir de supporter nativement les feuilles de styles Cascadenik. Cela offrirait aux utilisateurs une alternative aux fichiers de configuration XML de Mapnik : des feuilles de styles CSS.
06 avril 2010
8:52
Des nouvelles de Symbology Encoding (suite)
sur Benjamin Chartier

Comme en écho à l’un des mes précédents articles (cf. ici), l’équipe de GeoServer annonce le support de feuilles de styles CSS comme une alternative aux documents SLD :Styling GeoServer Layers with CSS.
05 avril 2010
10:56
Gephi
sur Benjamin Chartier

Un petit lien vers une application (en licence GPL) de visualisation et d’analyse de graphes : Gephi. Je ne sais pas si c’est très utile dans le domaine de la cartographie. Je me souviens d’avoir vu chez Ionic Software (ERDAS maintenant) une application qui était utilisée en interne pour visualiser le contenu d’un catalogue CS-W ebRIM (contenu qui a tendance à vite devenir complexe). J’imagine que l’on peut trouver d’autres applications à ce genre d’outils. Visualiser une base de données s’appuyant sur un modèle topologique (genre OpenStreetMap ou VMap) ? Visualiser les relations entre toponymes d’un extrait de GeoPlanet ?

Côté standards, cet outil permet d’exporter les graphes en SVG et PDF. Il sait également lire des fichiers avec l’extension .gml. En fait, il s’agit du format GraphML et non GML (Geographic Markup Language).

Via Digital Urban.
03 avril 2010
9:54
Des nouvelles de Symbology Encoding
sur Benjamin Chartier
Les choses bougent du côté de Symbology Encoding (noté également SE par la suite), même si ce n’est pas à une vitesse phénoménale :
- GeoServer propose de nouvelles fonctions qui permettent d’appliquer un style graphique non pas à la géométrie des objets vecteur mais à leurs géométries transformées. Pour en savoir plus, vous pouvez jeter un œil ici, là et encore là. D’un point de vue cartographique, l’apport de ces fonctions est indéniable. D’un point de vue de l’interopérabilité, mon jugement est plus mitigé. Ces fonctions ont été conçues par l’équipe de GeoServer comme des extensions à SLD 1.0 alors que l’OGC est passé depuis quelques années maintenant à Symbology Encoding 1.0 et que d’autres fonctions de transformation des géométries semblent se préparer pour SE 2.0. On se retrouve donc avec deux solutions qui semblent diverger. C’est dommage ;
- Le groupe de travail MeteOcean DWG de l’OGC étudie en se moment la capacité de réaliser des cartes météorologiques à l’aide de Symbology Encoding. Les règles de rédaction de ces cartes peuvent être assez complexes. La version actuelle de SE n’est pas très adaptée à ce type de représentation. Si vous voulez en savoir plus, vous pouvez consulter les présentations réalisées sur ce sujet lors des dernières réunions de l’OGC à Frascati ici, en particulier le document suivant : SLD/SE MDWG needs. Espérons que les besoins des communautés météorologique, climatologique et océanographique fassent avancer les spécifications de SE ;
- De son côté, le groupe de travail SLD/SE planche sur la version 2.0 de SE (et non la version 1.2 comme prévu initialement). Ses principales nouveautés devraient concerner la cartographie thématique et les représentations complexes d’objets linéaires (telles que celles utilisées sur les cartes maritimes). Pour avoir une idée de la feuille de route de ce groupe, vous pouvez consulter la page suivante : Styled Layer Descriptor and Symbology Encoding 1.2 SWG.
Il n’en reste pas moins que l’usage de SLD/SE n’est pas une obligation pour réaliser de belles cartes. On peut toujours utiliser des solutions non standardisées et/ou non interopérables. Par exemples :
- Les fichiers .map de MapServer : ici et là. Notez également l’existence de fichiers au format XML :XML Mapfiles ;
- Les fichiers de paramétrage de Mapnik (cf.ici) ou les CSS pour Mapnik (cf. là) ;
- Geo Style Sheet (GSS) :ici et là.
02 avril 2010
23:14
Bien commencer un projet en Python
sur Benjamin Chartier

Sean Gillies nous propose un long article (ou un court didacticiel, selon le point de vue) consacré à la création d’un projet en Python : Bootstrapping a Python project. Au programme : installation de Python dans un bac à sable, versionnement, tests unitaires et création du paquet de distribution.
9:48
Encore du nouveau du côté de GeoPlanet
sur Benjamin Chartier
Yahoo! a mis à jour GeoPlanet. Une des principales nouveautés est l’intégration d’équivalences (concordance dans la terminologie de GeoPlanet) entre différents identifiants géographiques (WOEID, INSEE, IATA, ICAO…). Pour démontrer l’intérêt de la chose, une petite application web existe : Geosetta.

Pour en savoir plus :
- La liste des identifiants supportés en plus du WOEID propre à GeoPlanet : ici ;
- L’annonce faite sur le blog des Geo Technologies de Yahoo! : là.
26 mars 2010
9:07
MapProxy
sur Benjamin Chartier

MapProxy est projet de serveur proxy s’interfaçant entre des serveurs WMS, TMS (il est intéressant de constater que le projet de Web Map Tiling Service de l’OGC n’est pas supporté) d’un côté et des applications supportant WMS, TMS et KML de l’autre. Intéressant. D’autant plus intéressant que ce projet est développé en Python et permet quelques petites choses comme l’application de marques en filigrane sur les images et la reprojection des données.

J’aurais bien aimé que cette solution permette de gérer les droits d’accès, un peu comme ce que proposent les Web Security Services de 52 North. Cela viendra peut-être.
14 mars 2010
9:18
YQL Geo Library (suite)
sur Benjamin Chartier

En complément de mon article précédent, vous pouvez jeter un œil ici. Vous y trouverez une présentation fort intéressante (faite par l’auteur de YQL Geo Library) de la problématique de géolocalisation.
13 mars 2010
9:42
YQL Geo Library
sur Benjamin Chartier

YQL Geo Library est une bibliothèque JavaScript exploitant les capacités de YQL ainsi que d’autres technologies pour apporter des capacités de géolocalisation à vos applications web.

Via Slashgeo et WebResourcesDepot.
07 mars 2010
16:50
GeoJQuery
sur Benjamin Chartier

Un nouveau projet est en train de prendre forme : GeoJQuery (cf. ici et là). Une liste de diffusion de l’OSGeo consacrée à ce projet vient également d’être créée (cf. ici).

L’objectif du projet : faire quelque chose de similaire à GeoExt mais sur la base de jQuery au lieu de Ext JS.
28 février 2010
12:34
GeoPlanet + YQL + YUI = GeoPlanet Explorer
sur Benjamin Chartier

Un petit exemple de ce que l’on peut réaliser avec trois technologies de Yahoo! (GeoPlanet, YQL et YUI) : GeoPlanet Explorer. Pour avoir des explications et le code de cette application, vous pouvez jeter un coup d’œil ici.
16 février 2010
17:32
Pour se familiariser avec HTML5
sur Benjamin Chartier

Si vous cherchez à mieux comprendre ou maitriser HTML5, je vous propose la lecture suivante (en anglais) : Dive Into HTML5. Attention, il s’agit d’un livre et non d’un simple article.
14 février 2010
19:23
Global Spatial Data Infrastructure Cookbook
sur Benjamin Chartier

Le Global Spatial Data Infrastructure (GSDI) propose un wiki (en anglais) intéressant consacré aux problématiques de la mise en œuvre d’infrastructures de données géospatiales : SDI Cookbook.

Via OGC Network.
03 février 2010
23:25
Des recherches spatiales avec Lucene
sur Benjamin Chartier

Lucene est un projet porté par la fondation Apache et qui a pour objectif de développer des technologies d’indexation de documents et de recherches textuelles. La panoplie Lucene couvre un large éventail de solutions : du kit de développement de bas niveau jusqu’au serveur de recherche prêt à l’emploi.

Solr, la solution d’indexation et de recherche dédiée aux entreprises, dispose de capacités de déploiement (recherche distribuées et réplication d’index) et de recherche très intéressantes : facetted search (je n’ai pas trouvé de traduction pour ce terme), tri des résultats en fonction de la pertinence (scoring), surlignage des termes recherchés, indexation de documents au format Word, PDF, recherche de documents similaires. Quelques exemples de requêtes sont présentées ici. Ces caractéristiques en font une solution de choix pour implémenter les fonctions de base d’un moteur de recherche.

Il se trouve que Lucene intègre depuis peu (depuis la version 2.9 apparemment) des capacités d’indexation et de recherche spatiale. Pour des explications plus approfondies quant à ces nouvelles capacités, je vous conseille la lecture de l’article suivant : Location-aware search with Apache Lucene and Solr.

Voilà un outil qui combine des recherches textuelles et spatiales. Plutôt intéressant donc.
01 février 2010
18:40
XQuery and XPath Full Text
sur Benjamin Chartier

Le W3C a annoncé (cf. ici) une mise à jour d’un document qui me parait pour le moins intéressant dans un contexte où l’on a besoin de faire des recherches complexes sur des documents XML : XQuery and XPath Full Text 1.0 Use Cases.

Il s’agit d’une description des cas d’utilisation d’un standard qui m’avait échappé complètement jusque-là : XQuery and XPath Full Text 1.0. Au programme : recherche de chaines de caractères, support de métacaractères, utilisation de thésaurus, dictionnaires et taxinomies, tri des résultats en fonction de la pertinence (pour ne citer que les capacités qui me semblent les plus intéressantes).

Étonnant à quel point cela ressemble aux besoins de nombre d’utilisateurs de catalogues.
28 janvier 2010
9:29
Performances des services WMS
sur Benjamin Chartier

Chris Tweedie a publié sur son blog, en fin d’année dernière, une série de tests comparant les performances de GeoServer, MapServer et ERDAS Apollo pour la diffusion de données raster sous différents formats : Image Server Benchmark. C’est la première fois, il me semble, que l’on publie les résultats d’un comparatif de la solution d’ERDAS aux serveurs libres que sont GeoServer et MapServer.

Les résultats sont intéressants. Ils sont d’autant plus intéressants que l’exercice mené pour le FOSS4G de Sydney (WMS Performance Shootout 2009) était bien décevant : absence d’ERDAS et d’ESRI (qui devaient y participer), résultats quasiment identiques pour MapServer et GeoServer et satisfécit général de la communauté libre géospatiale. Des résultats qui ne pouvaient pas réellement motiver les développeurs de MapServer et GeoServer à améliorer les performances de leurs outils préférés.

L’étude de Chris Tweedie apporte de nouveaux éléments qui ne manqueront pas de relancer une compétition qui s’enlisait quelque peu. Il faut dire que la solution d’ERDAS semble avoir des performances souvent supérieures à celles de GeoServer et MapServer. Certains esprits chagrins peuvent penser que le comparatif est biaisé (Chris Tweedie travaille pour ERDAS). Personnellement, je n’en ai aucune idée. Afin de rendre cette étude moins subjective et d’en ouvrir le champ, son auteur propose aux bonnes volontés d’y participer : So I’ve been thinking .. Une initiative bienvenue.

En parallèle, le site officiel d’ERDAS annonce fièrement « Since launching ERDAS APOLLO, we have unashamedly broadcast that we are the fastest, most powerful geospatial enterprise system for managing and delivering massive amounts of imagery. » (cf. ici).
27 janvier 2010
10:00
D’autres retours d’expérience sur la base de données de Google App Engine
sur Benjamin Chartier
Dans un précédent billet (Petit retour d’expérience sur la base de données de Google App Engine), je vous faisais part de mon retour d’expérience mitigé concernant le datastore de Google App Engine. Je me suis dit que quelques liens supplémentaires vous permettraient d’avoir une vue moins partiale de la chose. En voici quelques uns :
- Doing search on App Engine : un article donnant des solutions pour contourner l’incapacité de la base de données de Google App Engine à réaliser des recherches « full-text ». Google a annoncé que cette capacité de recherche sera ajouté, mais il faudra être patient : « This is a major undertaking and this will not happen soon, even by the most generous definition of soon » (cf. ici) ;
- La liste des restrictions donnée par la documentation de Google : Restrictions on Queries ;
- How BuddyPoke Scales on Facebook Using Google App Engine : le retour d’expérience des développeurs d’une application. Très instructif (pas seulement pour la base de données de Google App Engine) ;
- Getting to know more about DataStore : une série de présentations (dont certaines de Google) qui traitent, au moins en partie, de l’utilisation et de l’optimisation de la base de données de Google App Engine.
En somme, l’architecture et les limitations de la base de données de Google App Engine sont bien réelles et nécessitent une attention toute particulière. On remarquera que les points faibles les plus criants (de mon point de vue) concernent les domaines qui ont fait la réputation de Google (les moteurs de recherche et la cartographie de masse). Plutôt déroutant, non ?
20 janvier 2010
10:10
Mapnik 0.7
sur Benjamin Chartier

Mapnik 0.7 vient juste de pointer le bout de son nez : Release 0.7.0.

Parmi les modifications apportées on trouvera une meilleure maitrise de l’écriture des textes le long de géométries linéiques (avec gestion de l’alignement transversal et longitudinal, de la distance inter-lettres et inter-lignes, de l’opacité du texte…) ainsi qu’un enrichissement des possibilités offertes pour dessiner les petits symboles que l’on peut apposer sur les routes (ShieldSymbolizer dans la terminologie de Mapnik – désolé, il existe peut être un terme français convenu dans le domaine de la cartographie pour ces symboles).
19 janvier 2010
22:49
Petit retour d’expérience sur la base de données de Google App Engine
sur Benjamin Chartier

Le stockage de données dans Google App Engine repose sur une base de données pour le moins très différente des SGBDR traditionnels (cf. ici). La conception de cette base de données en fait un outil adapté aux systèmes distribués et donc possède de très intéressantes capacités de déploiement et de montée en charge.

Sa conception oblige à penser autrement le stockage des données, mais aussi la manière dont sont réalisées les manipulations des données (requêtes, modification du modèle de données, transactions, transfert de données). Passer du monde des bases de données relationnelles à ce type de base de données n’est pas aisé. D’autant moins aisé qu’un certain nombre de restrictions et de contraintes (probablement nécessaires pour assurer de bonnes performances dans un environnement distribué) apparaissent au fur et à mesure que l’on creuse la documentation (en passant, je trouve cette dernière un peu légère). Exemples de contraintes : une transaction ne peut être réalisée sur n’importe quel ensemble d’enregistrements ; une requête ne peut retourner que 1000 enregistrements ; une requête de mise à jour ne peut pas être réalisée sur plus de 500 enregistrements à la fois.

Néanmoins, une fois les mécanismes et contraintes assimilés, l’utilisation de ce type d’outil peut être agréable… à moins que l’on cherche à y stocker des données géographiques et à réaliser des requêtes dessus. Aujourd’hui, Google App Engine ne propose qu’un seul type spatial. Il s’agit de GeoPtProperty qui représente une paire (latitude, longitude). Rien d’autre. Pas de possibilité de réaliser des requêtes géographiques sur des objets surfaciques par exemple. Aujourd’hui, la seule initiative visant à permettre de réaliser des requêtes géographiques sur autre chose que des points dans Google App Engine consiste à utiliser les principes de Geohash (cf. ici pour l’implémentation dans Google App Engine). Cela reste assez sommaire même si cela peut être suffisant pour un certain nombre d’applications.

Je ne pense pas que Google ait prévu un meilleur support de l’information géographique bien que la question du stockage des données semble être l’une des principales questions qui concernent Google App Engine lors des prochaines séances de Google I/O : Building high-throughput data pipelines with Google App Engine, Data migration in App Engine, Next gen queries.
15 janvier 2010
10:08
Symbology Encoding
sur Benjamin Chartier

Cela fait un petit bout de temps que j’essaie de faire le message suivant : SLD (Styled Layer Descriptor) n’est plus un format de description de règles de représentation graphique.

Si vous jetez un œil aux publications sur le sujet (ici, là et encore là) vous verrez que SLD est présenté comme tel. Il est vrai que SLD 1.0 était à la fois un profil d’implémentation de WMS (ajoutant quelques opérations à la spécification WMS) et un langage de description de règles de représentation graphique au format XML. Depuis 2006, SLD 1.1 n’est plus qu’un profil de WMS. Le langage au format XML est, quant à lui, devenu Symbology Encoding 1.1 (SE). Le problème vient probablement d’une certaine inertie au niveau des outils qui implémentent les standards de l’OGC. Très peu d’entre eux ont été mis à jour pour tenir compte de SE. Je suis convaincu que la majorité des développeurs ayant implémenté SLD 1.0 n’est pas au courant de l’existence de SE 1.1. Pour les autres, ils sont probablement dubitatifs quant à l’intérêt d’implémenter cette « nouvelle » spécification de l’OGC.

Il n’en reste pas moins que les références mentionnées plus haut sont de bonnes introductions à ~~SLD~~ Symbology Encoding.
09 janvier 2010
10:32
SVG et Microsoft
sur Benjamin Chartier

Après l’implication de Google au sujet de SVG (cf. ici et là), c’est au tour de Microsoft : ce dernier rejoint le groupe de travail qui rédige les spécifications de ce format d’illustration graphique vecteur (cf. ici et là).
24 décembre 2009
11:19
900913
sur Benjamin Chartier

Certains d’entre vous connaissent peut-être le système de coordonnées utilisé par Google Maps et consorts sous le joli nom de EPSG:900913. Je n’avais jamais remarqué que ce numéro s’épèle de manière similaire à « google » (merci à Arnulf Christl) :
900913
googlE

Néanmoins, même si ce numéro est reconnu et utilisé par certains systèmes, il ne fait pas partie du registre de l’EPSG. Le code officiel pour cette projection est EPSG:3857 (cf. ici et là). Son nom plus poétique est « WGS 84 / Pseudo-Mercator » ou « WGS 84 / Popular Visualisation Pseudo-Mercator ».
23 décembre 2009
15:17
De l’utilisation de données géographiques sur le terrain
sur Benjamin Chartier

Je me permets de réagir à un article récemment publié (cf. Unfamiliar Ground – via got geoint?) concernant la qualité des données employées en Afghanistan par les militaires américains. Son auteur prend pour exemple les données DTED (modèle numérique de terrain) produites à partir de données SRTM (dont la résolution planimétrique est de 30 m) pour reprocher leur médiocre adaptation aux besoins du terrain. Cette résolution serait insuffisante pour avoir une idée correcte de la nature du terrain sur lequel les soldats évoluent. Cette résolution semble, en effet, pouvoir cacher des ravins et des bosses dont la taille serait inférieure à 30 m. Certes, mais est-ce uniquement du côté de la résolution des MNT que l’on doit chercher une solution aux difficultés des soldats à anticiper la nature du terrain et de s’y orienter ? Je ne pense pas.

En effet, on ne peut pas demander à un MNT de fournir autre chose que l’altitude du sol. Certains des obstacles mentionnés par l’auteur ne peuvent pas être identifiés sur un tel jeu de données : de la végétation impénétrable (« impassable vegetation ») par exemple. J’imagine que les obstacles auxquels ces soldats s’intéressent le plus sont probablement ceux qui pourraient figurer sur des cartes topographiques : bâtiments, haies, murs, ravins, fossés, talus, broussailles, cours d’eau… Ces obstacles pourraient également être présents sur un Modèle Numérique de Surface mais, a priori, ce n’est pas l’objet d’un MNT.

Par ailleurs, on ne peut pas limiter la question de la qualité des données à la seule résolution planimétrique. La précision (géométrique et sémantique), l’actualité et l’exhaustivité sont, sans aucun doute, des éléments à ne pas négliger quand on fournit des données à des militaires.

Pour atteindre un niveau de qualité satisfaisant pour les hommes du terrain, dans un pays qui évolue vite comme l’Afghanistan, dont les paysages sont très différents des nôtres et dont le patrimoine cartographique est sans doute pauvre, il semble inévitable d’aller sur place pour compléter et corriger des données topographiques qui auraient été préalablement produites à partir de cartes plus anciennes ou d’imagerie aérienne/spatiale. En effet, l’imagerie est bien souvent insuffisante pour appréhender la nature des bâtiments et associer des noms à des objets pourtant visibles (à moins de disposer de sources d’information aussi riche que Google Street View par exemple).

Il ne fait aucun doute que la production de données géographiques peut tirer profit de la connaissance du terrain qu’en ont ceux qui y sont. C’est d’ailleurs l’une des forces de projets tels que Google Map Maker et OpenStreetMap (deux initiatives visant à produire une cartographie globale en impliquant les utilisateurs eux-mêmes). Mais les modèles de production proposés par ces deux projets ne sont pas forcément non plus la solution miracle. Une des questions qui se pose pour l’avenir de la cartographie est de rendre la production de données géographiques plus réactive tout en assurant la maitrise d’un certain niveau de sa qualité. Qualifier les données avant de les distribuer est un frein à la réactivité des productions et l’actualité des données. Aujourd’hui, la qualification des données produites dans le cadre d’OpenStreetMap est un facteur limitant leur utilisation dans des contextes professionnels exigeants.

Par ailleurs, il ne suffit pas d’avoir des données dont la qualité est excellente. Il faut également savoir les interpréter (à la fois par un être humain et par les systèmes informatiques qu’il utilise). Ce n’est pas facile tant l’intelligence et l’age des systèmes, les cultures des différents acteurs et leurs niveaux d’expertise sont variables. Il n’est pas facile pour les personnes qui spécifient les modèles de données d’anticiper les différentes configurations du terrain qui devront être modélisées. Il n’est pas facile pour les producteurs de données de se mettre à la place des systèmes et des utilisateurs, afin se figurer leurs attentes non exprimées. Il n’est pas non plus facile pour les acteurs du terrain de comprendre les informations contenues dans les jeux de données. Qui ne s’est jamais perdu en lisant un plan ?

(Cet article a été refondu le 31 décembre 2009 afin de recentrer son propos sur la question de la qualité des données géographiques et de supprimer des références maladroites)
19 décembre 2009
19:12
Mapnik pour Mac
sur Benjamin Chartier

L’installation de Mapnik sur Mac n’a jamais été aussi simple : New Mapnik OS X Framework Installers.
18:40
Un guide d’introduction aux travaux de l’ISO/TC 211
sur Benjamin Chartier

Pour ceux qui voudraient mieux cerner l’objet des différentes normes et spécifications publiées par l’ISO/TC 211 (le comité technique en charge des travaux relatifs à l’information géographique de l’ISO), il existe un guide d’une centaine de pages accessible sur le site du TC211 : ISO/TC 211 Standards Guide.
13 décembre 2009
15:07
Raphaël
sur Benjamin Chartier

Raphaël est une bibliothèque libre JavaScript dédiée à la manipulation d’objets graphiques vectoriels. Je vous encourage à jeter un œil aux démos afin d’avoir une idée de ses capacités.

Via Christian Spanring.
11:38
OpenScales 1.1
sur Benjamin Chartier

La version 1.1 d’OpenScales est sortie depuis quelques jours (cf. annonce sur GeoRezo).

Il est intéressant de voir l’émergence d’un nouveau client cartographique libre au moment où l’hégémonie d’OpenLayers parait quelque peu écrasante (cf. There is no alternative to OpenLayers…? et End of life for Community Mapbuilder), même si les liens de parenté entre OpenScales et OpenLayers sont évidents.

Un projet d’une envergure et d’une vitalité certaine sur un créneau très intéressant. À suivre donc…
08 décembre 2009
12:37
TileMill : un outil de production de tuiles en masse
sur Benjamin Chartier

TileMill a pour objectif de produire en masse des tuiles à l’aide de Mapnik. Sa particularité est de se déployer sous l’infrastructure en ligne d’Amazon. L’intérêt réside dans la capacité à instancier plusieurs serveurs dans un laps de temps court pour produire rapidement une quantité importante de tuiles avec un aspect graphique soigné.

Via le site de Dane Blakely Springmeyer
30 novembre 2009
10:32
L’OGC et SOAP (encore)
sur Benjamin Chartier

Vous le savez peut-être : les spécifications d’interface de services web publiées par l’OGC doivent intégrer un profil SOAP (à moins de justifier son absence et que cette justification soit acceptée par l’OGC). Logiquement, les groupes de travail actuels s’efforcent d’intégrer SOAP dans leurs travaux. Malheureusement, l’OGC rencontre une petite difficulté à l’heure actuelle : trouver des rédacteurs et des relecteurs qui maitrisent suffisamment cette technologie et qui veuillent bien consacrer suffisamment de temps pour aider les groupes de travail à l’élaboration de leurs standards. En quelques mois, les rédacteurs de WMTS et ceux de WCS 2.0 se sont heurtés à cette difficulté. Je n’en suis pas très surpris et m’étonne encore de cette volonté affichée de supporter coute que coute ce protocole. Un peu plus de pragmatisme ferait du bien.
28 novembre 2009
12:06
Un wiki pour les standards géospatiaux : Geostandards
sur Benjamin Chartier

Un certain nombre d’entreprises et d’organismes (dont l’ISO TC 211 et le CEN) contribuent, depuis août 2009 apparemment, à une initiative intéressante : la mise en place d’un wiki consacré aux standards de l’information géographique. Au programme : INSPIRE, métadonnées, Sensor Web Enablement, etc.

Le wiki est là.
17 novembre 2009
9:02
Quelques conseils pour rédiger des standards
sur Benjamin Chartier

Adam Bosworth a écrit un article dans lequel il partage son expérience quant à la rédaction de standards : ici. Son point de vue est intéressant.

À vrai dire, les différents conseils qu’il donne me paraissent tout à fait raisonnables… tout en semblant difficiles à atteindre si on essaie de les transposer à un organisme tel que l’OGC (au moins pour certains de ces conseils). En particulier, Adam Bosworth attire notre attention sur la complexité des standards, et de sa relation directe avec la taille du groupe de travail, comme cause probable de leur non adoption : « The odds of failure are at least the square of the degrees of complexity of the standard. It may also be the square of the size of the committee writing the standard. »

Il prône également le libre accès aux standards : « Make the spec itself free, public on the web, and include lots of simple examples on the web site. » Comment ne pas penser aux normes de l’ISO ?

Une lecture très intéressante pour ceux qui s’intéressent ou s’impliquent dans des travaux de normalisation.
16 novembre 2009
8:27
Deuxième atelier sur l’utilisation des standards SIG/OGC en météorologie
sur Benjamin Chartier

Le deuxième atelier sur l’utilisation des standards SIG/OGC en météorologie (2nd workshop on the use of GIS/OGC standards in meteorology) qui se tiendra du 23 au 25 novembre à Toulouse s’annonce comme une réunion intéressante en complément des réflexions de l’OGC dans les groupes de travail MetOcean et WCS, sans oublier l’initiative visant à standardiser CF-netCDF.
8:16
Oslandia
sur Benjamin Chartier

Un petit lien vers le blog d’une jeune société touchant aux SIG libres : ici.
12 octobre 2009
10:21
Cartographie et daltonisme
sur Benjamin Chartier

Une initiative intéressante de l’Ordnance Survey pour les personnes qui souffrent d’une anomalie de la vision des couleurs est relayée par The Map Room : Ordnance Survey Announces Colour-Blind Mapping. La carte reproduite sur le site de The Map Room vous parait peut-être laide. Cela dit, elle est plus lisible pour un daltonien. Rappelons que 8% de la population masculine souffre de ce type d’anomalie, ce qui n’est pas franchement négligeable.

Pour en savoir plus sur le daltonisme, vous pouvez commencer par jeter un œil à Wikipedia.
10:09
Une liste de projets SIG libres
sur Benjamin Chartier

Bruce Bannerman a établi une liste de projets SIG libres sous la forme d’une carte heuristique. Cette liste, bien que probablement incomplète, est très intéressante. Elle est maintenant disponible sur le site de l’OSGeo (cf. ici et là). Elle devrait donc s’enrichir au fur et à mesure des apports des membres de l’association.
08 octobre 2009
10:00
Un peu de pub pour Python
sur Benjamin Chartier
L’utilisation de Python (comme langage de développement) est assez répandue dans le monde de l’information géographique libre (Python est également utilisé dans des solutions commerciales comme ArcGIS). Quelques exemples :
- la manipulation ou l’indexation de données géographiques (cf. GDAL/OGR in Python, GeoJSON, Shapely et Rtree) ;
- la réalisation d’extensions pour QGIS (cf. là) ;
- le développement d’applications web (cf. MapFish par exemple) ;
- le développement et l’exploitation de services OWS (cf. A quick quide to getting up and running with PyWPS, OWSLib et CowsFramework).
Une liste de modules Python ayant un rapport avec l’information géographique est disponible ici.

Notez bien que l’on n’est pas obligé de faire des développements barbares et barbants avec Python. On peut aussi produire des paysages urbains avec Blender par exemple : Suicidator City Engine – Free Procedural City Script for Blender.
9:29
2 présentations sur Yahoo! Placemaker
sur Benjamin Chartier

Au cours de FOWA (Future of Web Applications – une conférence ayant eu lieu à Londres), Gary Gale a réalisé 2 présentations dont les supports sont maintenant disponibles sur SlideShare : Place not Space; Geo without Maps et Geocoding and Geoparsing are Easy (le titre de cette dernière présentation semble être ironique).

Via Yahoo! Developer Network Blog.
05 octobre 2009
18:05
Traitement de données géographiques en Python
sur Benjamin Chartier

Un petit lien vers un cours sur le traitement de données géographiques en Python écrit en anglais par Chris Garrard et disponible sur le web : Geoprocessing with Python using Open Source GIS. Ce cours s’appuie essentiellement sur GDAL et OGR.

Via la liste de diffusion OSGeo-Discuss.
03 octobre 2009
12:00
SVG et Google
sur Benjamin Chartier

Comme indiqué plus tôt ici et là, Google confirme son implication dans la promotion de SVG : SVG at Google and in Internet Explorer. Un article intéressant précisant l’intérêt que présente ce format d’image vectorielle pour Google.

Vous remarquerez en passant que la vidéo au bas de l’article montre la future fonction de Wikipedia pour naviguer au sein d’une image (fonctions de zoom et déplacement panoramique). L’interface de cet outil ressemble furieusement à celle d’OpenLayers !
02 octobre 2009
8:30
Serveur SIG virtualisé
sur Benjamin Chartier

Il y a 1 an j’évoquais une machine virtuelle proposant un certain nombre de solutions libres SIG prêtes à l’emploi (cf. ici). Ce principe a été étendu à des serveurs libres orientés SIG (PostgreSQL, PostGIS, GeoServer, Mapserver, Deegree and Geonetwork…) : GISVM Server.
01 octobre 2009
21:36
Unofficial Python GIS SIG
sur Benjamin Chartier

Un petit coup de pouce pour un tout nouveau groupe de discussion sur Python et les SIG (cf. ici et là).
8:49
J’avais presque oublié CGM
sur Benjamin Chartier

Cela faisait longtemps que je n’avais entendu parler de CGM (un format d’illustrations graphiques plus tout jeune maintenant, notamment utilisé par des applications militaires). Ce format peut être utilisé par exemple pour définir des symboles d’objets ponctuels cartographiques. CGM et SVG sont quelques fois comparés.

Le W3C essaie de lui donner un coup de jeune avec une nouvelle version intitulée WebCGM (cf. ici et là). Ce n’est pas juste un coup de jeune. Il s’agit surtout d’améliorer l’interopérabilité en limitant le nombre de profils divergents de CGM.
28 septembre 2009
21:12
HTML 6 et l’OGC
sur Benjamin Chartier

HTML 5 n’est pas encore entré dans les mœurs qu’une discussion s’est initiée au sein du groupe de travail Mass Market de l’OGC concernant la version suivante : HTML 6.

L’objet de cette discussion concerne la pertinence de l’ajout d’une balise géographique (<geomap> en l’occurence) dont le but serait de déclarer la présence d’une carte géographique dans une page web. Charge ensuite au navigateur de la créer et de gérer ses interactions avec l’utilisateur. Le principe de cette balise serait finalement quelque chose d’équivalent à ce qu’est la balise <video> de HTML 5 pour le contenu vidéo. Intéressant. À suivre donc.

Je vous rappelle que le groupe de travail Mass Market de l’OGC de travail n’est pas réservé aux membres de l’OGC. Pour en savoir plus allez ici.

← Geotribu neogeo →

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Carte des membres Sites amis	Annuaire Agenda Biblio Netvibes Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Carte des CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

Feeds

Benjamin Chartier