ReLucBlog

Evolution de la caractérisation de l'occupation du sol

Données OCSOL PACA 1999 et 2006

La région Provence Alpes Côte d'Azur (PACA), qui a ouvert son portail OpenData, a mis à disposition les données d'occupation du sol de 1999 et 2006, élaborées à partir d'images satellitaires Landsat 7 ETM et selon une méthode commune. Conjointement à ces données vecteurs, une charte graphique OCSOL est mise à disposition. Nous avons utilisé cette charte pour caractériser les différentes catégories d'éléments structurant les 2 sources de données.

Les résultats sont les suivants :

• Pour les données OCSOL 1999

• Pour les données OCSOL 2006

Données comparatives OCSOL PACA : 1999 et 2006

Accompagnant les données OCSOL 1999 et 2006, la région PACA met aussi à disposition dans le cadre de son portail OpenData l'Évolution de l'Occupation du sol en PACA entre 1999 et 2006.

Avant de s'intéresser à la représentation graphique de cette comparaison, nous nous sommes tout d'abord intéressés à l'extraction de l'information à traiter. En effet, le fichier ".dbf", base de données qui contient les attributs des objets de la source de données vecteurs, présentait les données qui nous intéressaient pour cette comparaison dans une seule colonne, comme le montre l'illustration suivante :

Nous avons alors traité cette information afin de différencier les objets représentant une évolution de l'occupation des sols entre 1999 et 2006. Pour ce faire nous avons ouvert le fichier ".dbf" avec LibreOffice, pour dans un premier temps, diviser cette unique colonne en deux. Nous avons ensuite effectué les étapes suivantes :

1. Nous avons copié le contenu de la colonne dans un éditeur de texte ;
2. Nous avons effectué l'opération rechercher le tiret inférieur "_" pour le remplacer par le point virgule ";" pour tous les éléments;
3. Nous avons copié le résultat ;
4. Nous sommes ensuite revenus sur le fichier .dbf pour y coller le résultat. Au moment d'insérer les lignes dans le fichier, LibreOffice a demandé quel était l'élément de séparation des données. Nous avons indiqué le point-virgule ";" et il a collé dans deux colonnes distinctes

chaque valeur séparée par un ";" :

Pour faire ressortir l'information de différence lorsqu'elle existe, entre les données de 1999 et celles de 2006, nous avons choisi de créer une dernière colonne pour accueillir le résultat du calcul logique suivant :

si(A1=B1;"0";"1")

qui signifie : si ( donnee1999 = donnee2006 ; alors le résultat = 0 ; sinon il = 1)

Pour la mer, nous avons utilisé ce même calcul, avec une demande de résultat différent, pour faire ressortir l'élément : si ( donnee1999 = donnee2006 ; alors le résultat = 3)

Voici le résultat de ce calcul :

Ce type de classification nous a permis de déterminer 3 postes de légende :

1. Catégorie OCSOL inchangée ["0"] ;
2. Catégorie OCSOL modifiée ["1"] ;
3. Mer méditerranée ["3"].

Nous avons appliqué la symbologie "catégorisée" proposée par QGIS en définissant deux tonalités contrastantes pour les postes 1 et 2, en privilégiant une couleur manifeste pour le poste 2 :

Voici les résultats cartographiques :

Publication sur le Web avec LizMap

Enfin, afin que tout le monde puisse profiter de cette réalisation, nous avons publié ces données avec la charte graphique appliquée. Nous avons tout de même dû modifier la mise en forme graphique des données d'évolutions.

Pour la publication Web, nous avons décidé de ne conserver que les objets vectoriels qui présentaient une évolution de l'occupation du sol entre 1999 et 2006. Une fois cela fait nous avons changé leur représentation en dessinant le contour et en remplissant la surface de hachure noir. Il est ainsi facile d'identifier les zones ayant évolué et d'observer la classe d'occupation 1999 ou 2006.

Le résultat est accessible ici :
http://demo.3liz.com/lizmap/index.php/view/map?repository=opendata&project=paca_ocsol

Cette année les Rencontres SIG La Lettre avaient lieu début avril du 3 au 5 et comme chaque année à l'ENSG. Le mercredi 4 avril fut consacré à l'OpenData, le matin, et au crowdsourcing, l'après-midi, ce fut donc la principale journée de rencontres et de discussion autour de l'OpenData et d'OpenStreetMap.

De plus l'organisation des Rencontres SIG La Lettre avait décidé de monter un stand OpenData, pour permettre au delà des présentations d'avoir un lieu de rencontre et de discussion autour de l'OpenData. Ce stand fut animé par des structures ayant exploité des sources de l'OpenData (Codega Studio, Mobigis, Handimap, 3Liz) mais aussi par les membres d'OpenStreetMap France.

Comme vous pouvez le constater sur la photo ci-dessus, le stand semblait plus consacré à OpenStreetMap qu'à l'OpenData, pourtant de nombreuses discussion autour de l'OpenData eurent lieu sur ce stand, et la photo a été prise le jeudi 5 avril.

Mais avant de parler d'OpenData, commençons par OpenStreetMap (OSM).

La première impression est que le projet est de plus en plus connu, ou plutôt que de plus en plus de personne en ont entendu parler, mais dans les fait peu connaissent vraiment le projet. OSM reste pour beaucoup un service cartographique à la Google Maps. D'où la surprise lorsque l'on présente des réalisations comme la carte de cyclabilité du centre de Lille ou la carte touristique de la ville d'Orange, mais aussi l'intérêt d'un service comme LizWatch ou OSMTransport.
Par contre ceux qui avaient eu le temps de se documenter sur OSM sont venu sur le stand pour obtenir des précisions sur les modèles de relation et les outils permettant d'exploiter les données OSM.
Enfin l'atelier, Master Class, OpenStreetMap intitulé Utilisation des données OSM dans un SIG a fait salle comble avec une majorité de personnes découvrant le projet.

Cette année fut donc un bon cru avec de nombreux contributeurs présents :

• Michaël Douchin (kimaidou)
• Emilie Laffray (melaskia)
• Nicolas Moyroud
• Chritian Quest
• Jean-Louis Zimmermann (zimmy)

On a même pu voir passer et saluer partir-en-vtt.

Un bon cru aussi parce qu'OSM et OpenData font bon ménage.

Sinon au cours de ces rencontres de nombreuses questions ont été soulevées :

• Pourquoi faire de l'OpenData ?
• Faut-il mettre en place des APIs ?
• Quels interactions avec OSM ?
• Quels données mettre à disposition sous licence libre ?

Les réponses ne sont pas toujours évidentes mais mérites d'être posées.

Traduction du billet de Frederik Ramm sur osm.gryph.de

OpenStreetMap est souvent perçu par les observateurs extérieurs comme la Némésis de Google. Ou peut-être, sans délire de grandeur, un compétiteur. Lorsque je dois présenter OpenStreetMap en un seul paragraphe, j'utilise très souvent l'expression "à la différence de, par exemple, Google Maps". Et il est probable que cette expression puisse faire croire aux OpenStreetMapers que google est l'ennemi.

Mais l'est-il-vraiment ?

Nous avons toujours eu de bon rapports avec Google. Ed Parsons, Spécialiste du géospatiale chez google, et Steve Coast se connaissent depuis un certain temps ; Steve a fondé OpenStreetMap après avoir été frustré par la politique de licence de l'agence national cartographique britannique, l'Ordnance Survey. A cette époque Ed était le directeur technique de l'Ordnance Survey, et devait fréquemment défendre le modèle économique de l'Ordnance Survey face aux nouveaux entrants tel que nous. (Certaines sources affirment qu'il était tout autant frustré que nous vis à vis de la politique de l'Ordnance Survey.) En 2006, Steve a d'ailleurs réalisé une interview d'Ed pour le blog OpenGeoData. En 2007, Ed (maintenant chez Google) a fait le discours d'ouverture du State Of The Map (SOTM) de Manchester, et il fut l'invité et le conférencier de nombreuses autres de nos conférences, il a d'ailleurs écrit suite au SOTM 2011 "Très bon week-end au State Of The Map, OpenStreetMap semble être un projet très mature maintenant".

Google a sponsorisé des SOTM, nous a octroyé des places chaque année de puis 2008 au sein de son programme Summer of Code, et Google a même participé à notre premier tour de table pour l'équipement serveur en 2009 en tant que plus gros donateur avec 5 000 £ - snas même que nous ayons eu besoin de lui demander.

Mais pas seulement, technologiquement, nous profitons du sillon tracé tous les jours par Google. C'est grâce à Google si nous pouvons utiliser OpenLayers pour créer une carte dynamique au sein d'une page Web que tout le monde peut instantanément consulter. La projection que nous utilisons tous pour couper les nœuds gordiens des SIG et faire du Web mapping pragmatique, c'est Google. Le format de données peu encombrant que nous utilisant de plus en plus pour nos données géographiques est basé sur le format Protocol Buffer (pbf) de Google. Et la liste est encore longue. Je ne pense pas qu'OpenStreetMap ait plus profité du support d'une autre société de façon directe ou indirecte que celui de Google. Personnellement, j'ai pus décrire facilement OpenStreetmap grâce aux comparaisons avec Google Maps : "C'est comme Google Maps, sauf que tout le monde peut le modifier, et que vous pouvez télécharger et ré-utiliser les données."

Il y eu quelques cas dans le passé d'intégration de données OpenStreetMap à Google Maps, qui ont généralement été résolus sans qu'il y ai trop de bruit grâce à une communication rapide et conviviale avec la direction, et pour ce que j'ai pus voir, ces problèmes provenait toujours de fournisseurs ou d'utilisateurs de MapMaker impatients. Inversement, depuis le début et encore maintenant des contributeurs à OpenStreetMap franchissent la ligne et créent de la données à partir de Google Maps, données que nous supprimons rapidement sans que, à ma connaissance, nous n'ayons jamais reçu de menaces des avocats de Google.

Je ne suis pas un infiltré de Google mais je pense qu'il est juste de dire que leur ordre du jour est d'aider, et de surveiller, la circulation de l'information sur internet, et ainsi récolter de nombreuses informations sur ce que les pré-Facebook appelle la "sphère privé" et ainsi vendre de la publicité. Google lit vos emails, non pas parce qu'ils sont dangereux, mais parce que vous avez choisi d'utiliser leur très bonne solution d'e-mail à laquelle vous avez accès gratuitement. Google lit même des documents internes à la Foundation OSM (OSMF) avant même que vous et moi n'y ayons accès (si c'est prévu) parce que l'OSMF utilise Google Docs. Je reconnais volontiers que je suis un peu effrayé de leur omniprésence et quasi-omniscience, mais cela n'en fait pas pour autant notre ennemi. Je suis sûr que Google aimerait distribuer les données OpenStreetMap et voir les gens les consommer, ce qu'il font déjà. Il semble que les termes de notre licence ne s'appliquaient pas à eu jusqu'à maintenant mais je ne peux pas guère les blâmer ; J'ai entendu dire, que d'autres grands acteurs ont des projets prêt à être lancé dès qu'OpenStreetMap aura changé de licence, car ils craignent l'actuelle CC-by-SA.

Nous avons approché Google à plusieurs reprises car nous aimerions utiliser leur imagerie aérienne, la couverture et de la qualité du service Google est souvent meilleure que ce que nous avons avec Bing, en vain. Leur ligne officielle est qu'ils n'ont pas de licence permettant d'obtenir des données à partir de cette imagerie, ce qui sonne un peu creux vis-à-vis des données issues de MapMaker - mais je suis prêt à leur donner le bénéfice du doute; qui peut dire quels sont les règlements obscurs qui ont été mis en place par les avocats en propriété intellectuelle. Leur imagerie "StreetView" nous serait également utile dans certains cas, et même si nous n'avons pas un OK franc et clair, nous avons pus utiliser dans certains cas particuliers ces images.

Nous n'essayons pas d'être "meilleur que Google Maps". Nous ne pourrons jamais l'être, nous manquons de conteneurs de matériels informatiques pour cela. Google a récemment fait les gros titres en indiquant qu'il allait faire payer son API cartographique pour les usages intensifs, déclenchant un léger mouvement switch2osm ; mais la vérité est que si vous voulez la qualité du service que vous obtenez à partir de Google, avec leur CDN, leur haute capacité de charge et leur redondance, à partir d'une configuration basée sur OpenStreetMap, vous ne pourrez pas l'obtenir pour moins chère. OpenStreetMap n'offrira jamais de service d'imagerie aérienne ou tout autre fonctionnalité considéré comme acquise par les utilisateurs de Google.

Ce qu'OpenStreetMap souhaite être, c'est une alternative aux données géographiques acquise par les gouvernement ou produite commercialement. C'est pourquoi nous sommes plus des concurrents de NavTeq ou TéléAltlas que de Google. Oui, Google est en train de produire ces propres données, mais seulement parce qu'ils ont souffert des mêmes règles qu'OpenStreetMap lorsqu'il a été lancé : l'abscence de données que l'ont peu acquérir pour un prix décent.

Deux de nos administrateurs de la Fondation OpenStreetMap, Steve Coast et Mikel Maron, ont dans le passé craché un peu de venin sur la direction générale de Google; il y eu des actes de vandalisme qui tous deux ont été reconnu par Google et pour lesquels il était complice ou tout du moins négligent, Mikel a alors utilisé son blog personnel pour fortement critiquer la stratégie de Google dans les pays en développement qu'il a perçu comme un affront au mouvement OpenData. Google a également récemment conclu un accord avec la Banque mondiale qui, si ils sont appliqués comme indiqué, irait à l'encontre de l'engagement de la Banque mondiale envers l'OpenData, ce qui entraina plus de critiques de Mikel et d'autres.

Google est une organisation comme toutes les autres organisations ; ils ne sont pas exemptés de la règle qui dit que si vous n'êtes pas vigilent, les dirigeants prêt à tout pour atteindre les sommets, quelque soit leur un agenda personnel ou la manière d'atteindre de tel ou tel objectif, choisiront toujours la manière permet de maximiser leur bonus, sans se soucier de ce qui est bon. Il est important que nous surveillons Google afin de lui des données des coup de coudes de temps en temps. Mais dans le grand schéma des chose, dans la grande enceinte du "les données produites par la foule dans un esprit de ruche à but mondiale et collective Contre les données cathédrales contrôlées par les gouvernements et le profit", Google est du même côté que nous. Plus encore, peut-être, que d'autres organisations qui rivalisent ingéniosité pour nous plaire.

LizMap est une solution complète de publication de cartes sur internet. Elle est basée sur le logiciel Quantum GIS (QGIS), et son serveur cartographique QGIS Server.

LizMap est constituée de 2 élements complémentaires :

• une application à installer sur un serveur : le client web LizMap, qui génère les cartes web dynamiques. Il a été réalisé autour de QGIS Server à l'aide du framework PHP5 Jelix, de jQuery et OpenLayers ;
• un plugin python pour QGIS, qui permet de configurer ses cartes à partir de projets QGIS et de les synchroniser via FTP.

Cette première version de LizMap, disponible sur le hub QGIS, a été réalisée avec le soutien :

• d'Alisé Géomatique
• du PNR des Ballons des Vosges

Concept

Nous avons conçu LizMap pour faciliter le travail de l'utilisateur. Nous pensons qu'il doit pouvoir se concentrer sur son métier, la représentation de données spatiales, et non devenir un programmeur avancé.

Tout le travail de construction, de configuration de la carte et de sémiologie se fait directement dans QGIS. L'utilisateur n'a pas de fichier de configuration à éditer, il utilise l'interface conviviale du plugin LizMap pour modifier les options générales de la carte et celles liées aux couches. Une fois son projet enregistré sous QGIS, il suffit de synchroniser de manière automatique les données entre le poste de travail et le serveur.

Le client web LizMap prend alors le relais pour construire automatiquement une carte identique à celle du projet QGIS. L'organisation des couches d'information et l'apparence sur l'interface web sont identiques à ceux du projet QGIS. Il est ainsi aisé pour un administrateur sans connaissances techniques liées au Web, de construire et de faire évoluer plusieurs cartes thématiques de manière visuelle via QGIS, depuis son ordinateur, avec un retour visuel immédiat de l'impact de ses choix.

Fonctionnement

Une interface Web basée sur du HTML/CSS/Javascript
Au lieu de concevoir l'interface Web seulement en JavaScript comme le propose certains frameworks, nous avons choisi de nous appuyer sur une base HTML, mise en forme avec du CSS et améliorer par du JavaScript. L'apparence de l'interface Web peut ainsi être facilement modifiée par les développeurs ou designers Web (couleurs, positionnement des fenêtres,etc.).

Des cartes interactives riches
Carte plein écran, arbre des couches avec légende intégrée, popup affichant les données des objets cartographiques, carte miniature de localisation, outils de navigation (zoom, déplacements, etc.).

Seuils de visibilité
Si une couche ou un groupe de couches a été défini comme invisible à une échelle donnée, il apparaîtra inactif et grisé (il est également possible de les masquer en modifiant la CSS).

Intitulés des couches
Dans le plugin LizMap à l'aide du champ "titre", il est aisé de donner un nom intelligible aux couches de la carte interactive et, parallèlement, de conserver le nom original de la couche dans le projet QGIS. Par exemple, une couche appelée "xy_arbre22" peut-être visualisée en ligne sous la dénomination "Arbres remarquables".

Regroupement de couches
Il est possible de définir l'affichage d'un groupe de couches sous QGIS comme couche unique dans l'application Web LizMap.

Définition des échelles de la carte
Il est possible de spécifier les échelles accessibles à l'utilisateur de la carte web (via une liste d'échelle définie ou une résolution minimum et maximum).

Mode aperçu de la carte
Si un projet local comporte un groupe de couches "Overview", celles-ci seront affichées sous forme d'une carte miniature nommée "aperçu" pour permettre à l'utilisateur de situer sa vue.

Fonds de plan optionnels
Si l'utilisateur ne dispose pas de fonds référentiels pour ses données, il lui est possible d'utiliser un ou plusieurs fonds Google ou OpenStreetMap.

Application multi-projets et multi-dépôts
Une seule application Web LizMap peut utiliser plusieurs projets conservés dans de multiples dossiers sur le serveur. Ceci doit-être défini lors de la configuration de l'application.

Synchronisation des données via FTP
Le plugin LizMap permet d'envoyer facilement tous les fichiers du projet sur le serveur (projet, données, configuration). Il utilise une synchronisation en mode "miroir", ce qui permet de n'envoyer que les fichiers qui ont été modifiés, afin d'économiser des ressources et du temps de transfert.

Utilisation possible de serveur de cache (Mapcache, Tilecache)
LizMap peut utiliser en option des couches de données qui auraient été mises en cache. Le plugin permet de préciser quelles couches sont mises en cache.

Quelques exemples

LizMap est utilisée par le PNR des Ballons des Vosges, afin de publier une version Web de la charte graphique de la carte du Parc. Cette version a été adaptée et mis en forme en fonction des demandes du PNR. La mise en œuvre de la publication a été réalisée en partenariat avec Alisé Géomatique qui, par ailleurs, exploite en interne LizMap, pour soumettre certains de ses résultats cartographiques.

Vous pouvez aussi consulter nos démonstrateurs :

• Les données Alaska du projet QGIS
• Montpellier - Transports
• OpenData Rennes

Nous devrions d'ailleurs publier toutes nos réalisations autour de l'OpenData à l'aide de LizMap.

Le futur

Le projet LizMap ne fait que commencer et nous avons quelques évolutions en tête que nous souhaiterions réaliser. Par exemple, l'implémentation du WFS dans QGIS Server, et du WFS-T fait partie de ce plan d'amélioration. Donc nous souhaiterions :

• Ajouter une fonctionnalité d'impression
• Ajouter la gestion des droits d'accès aux cartes
• Mieux gérer l'interrogation des données vectorielles
• Ajouter la possibilité de définir un outil de zoom sur objet vectoriel
• Ajouter un outil de requête et sélection d'objets vectoriels
• etc...

Pour le moment aucun planning précis n'est défini, mais si certaines évolutions vous intéressent, nous pouvons en étudier un.