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

46898 items (0 unread) in 88 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

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