Le portail francophone de la géomatique

En droit français, il n'est pas coutumier d'inclure un glossaire des termes employés dans le texte. Celui ci-dessous a été retiré juste avant publication quoiqu'il soit issu du rapport du CNIG et a été validé par toutes les chaînes de signataires.

Je vous le propose ci-dessous car certains termes 'réalisation...) sont nouveaux pour beaucoup ou ont vu leur définition précisée :

Glossaire :

ellipsoïde : surface de révolution engendrée par une ellipse tournant autour de son petit axe, définie par le rayon équatorial et un paramètre d’aplatissement, et sensiblement géocentrique.

altitude : l'altitude d'un point est la coordonnée par laquelle on exprime l'écart vertical de ce point à une surface de référence proche du géoïde.

coordonnées géographiques : coordonnées bidimensionnelles constituées par le couple longitude et latitude.

géoïde : surface équipotentielle du champ de pesanteur terrestre proche du niveau moyen des mers.

précision : la précision mesure les fluctuations d’une série de mesures autour de son espérance mathématique.

réalisation : réalisation matérielle et numérique d’un système de référence abstrait. C’est le plus souvent un réseau de points physiques de la surface topographique (réseau géodésique, de nivellement, stations de géodésie spatiale…) avec les données numériques permettant d’en déterminer leurs coordonnées à une ou plusieurs époques.

représentation plane : système de représentation de la surface terrestre (ou planétaire) utilisé pour la réalisation de cartes.

système altimétrique : réalisation d’un système de référence vertical.

système de référence : ensemble d’informations dont le choix est nécessaire pour pouvoir déterminer numériquement un type de quantités, en plus des mesures physiques adéquates.

système de référence de coordonnées : ensemble constitué par un système de référence et un type de coordonnées associées.

système de référence terrestre : système de référence d’espace co-mobile avec la Terre dans son mouvement diurne dans l’espace.

système de référence verticale : système déterminé par le choix d’un géoïde, d’un type d’altitude et d’une unité d’altitude (mètre, pied…).

zéro hydrographique : niveau de référence verticale utilisée en hydrographie. Il est d’ordinaire choisi aussi voisin que possible du niveau des plus basses mers astronomiques.

Je cite : "Le décret modifie le système national de référence de coordonnées défini en application de l'article 89 de la loi n° 95-115 du 4 février 1995 modifiée d'orientation pour l'aménagement et le développement durable du territoire. Il donne une nouvelle définition des systèmes de référence terrestre utilisés par l'Etat, les collectivités locales et les entreprises chargées de l'exécution d'une mission de service public, identiques à ceux applicables dans le champ de la directive 2007/2/CE du Parlement européen et du Conseil du 14 mars 2007 établissant une infrastructure d'information géographique dans la Communauté européenne (INSPIRE).
Il renvoie à un arrêté des ministres chargés de l'environnement et de la défense la définition des réalisations matérielles et numériques de ces systèmes de référence (ces réalisations consistant le plus souvent en un réseau de points physiques de la surface topographique (réseau géodésique, de nivellement, stations de géodésie spatiale…) avec les données numériques permettant d'en déterminer leurs coordonnées à une ou plusieurs époques). Il prévoit les modalités de gestion et de publication des évolutions des systèmes de référence de coordonnées. Il prévoit la possibilité, à titre transitoire, d'utiliser d'autres systèmes en Martinique, en Guadeloupe, à Saint-Martin et à Saint-Barthélemy."

Merci au CNIG et en particulier à la commission Géopositionnement dont le rapport a été déterminant pour la rédaction de ces textes règlementaires.

Quelques éléments de réponses aux questions qui me sont parvenues en quelques minutes :
- le vrai enjeu était élargir le champ d'application obligatoire aux actes de l'administration (empêcher des décrets en Lambert zone, par exemple) tout en mettant à jour l'ancien décret sur les Antilles françaises. C'est fortement lié à la directive INSPIRE et au règlement n°1089/2010 cité plus haut.
- Nous en avons profité pour rendre le système plus robuste (décret plus stable) et plus facile à mettre à jour (avec un arrêté signé de seulement trois ministres : Environnement, Défense, Outre-mer).
- Sauf aux Antilles françaises, aucun changement pour les géomaticiens : ce sont les mêmes systèmes de coordonnées et projections associées.
- Aux Antilles françaises, changement de système de référence (on passe en ITRS) sur les 3 prochaines années. L'IGN est mandaté pour offrir son appui comme il l'a fait en métropole lors du passage en RGF93.

* décret n° 2019-165 du 5 mars 2019 relatif au système national de référence de coordonnées

* arrêté du 5 mars 2019 portant application du décret n° 2000-1276 du 26 décembre 2000 modifié portant application de l'article 89 de la loi n° 95-115 du 4 février 1995 modifiée d'orientation pour l'aménagement et le développement durable du territoire relatif aux conditions d'exécution et de publication des levés de plans entrepris par les services publics.

Ajout 11h35 :
- Je confirme : AUCUN CHANGEMENT SAUF POUR LES COLLEGUES AUX ANTILLES.
- Ces textes ont mis plusieurs mois à être publiés, ils sont sortis ce matin sans prévenir et nous n'avons pas pu communiquer dessus avant.

Géolocalisation en agriculture : que vont changer Galileo et Egnos ?

=>

For the past few months, Copernicus has been distributing Level 3A products for the Sentinel-2 mission as part of the S2GM (Sentinel-2 Global Mosaics) .

 

This ambitious project aims to provide monthly, quarterly or annual Level 3A products worldwide. The user defines his zone and period of interest and orders the product. The web site seems to be hosted by SInergise, and as everything done by this company, is easy and very straightforward to use.

 

The call for tender, with two or three million euros, was launched by the Copernicus program of the European Union two years ago. It required the use of ESA Level 2A official products obtained with Sen2Cor. For this reason, we decided not to participate because our Level 3A method, which calculates a weighted average of non-cloudy observations, requires very good cloud masks, which is not quite the case of Sen2cor products.

 

The tender was won by a consortium of Brockman Consult, Geoville and SInergise companies. To compensate for the poor quality of cloud detection, the authors of the S2GM product had to use a BAP method: "Best Available Pixel". This method chooses for each pixel the best date according to certain criteria (no cloud or shadow detected, minimum reflectance in the blue, maximum NDVI ...). This method minimizes cloud disturbances when clouds are not detected correctly, but also has the disadvantage of suddenly changing the date from one pixel to another, which causes artifacts and noise. Outputs are therefore composite products , which assemble pieces of images acquired for the different dates available over the period.

 

Theia Level 3 products are not composites, but syntheses, which use all cloudless observations of a single pixel over the entire monthly observation period to find the value that best represents the surface reflectance we would have had at the central date of the product. Theia's syntheses use the WASP (Weighted Average Synthesis Processor) chain, which calculates a weighted average of surface reflectances over a month, after atmospheric correction and detection of clouds obtained from Level 2A products generated by our MAJA channel , of course. If the clouds are badly detected, they enter into the synthesis and disturb it.

Comparison of a synthesis obtained with WASP + MAJA, with a composite product from S2GM + Sen2cor, on the Toulouse region, in October 2018. (Click on image to enlarge)

The animation provided above shows a full resolution comparison over Toulouse region, of a synthesis of WASP and of the corresponding composite of S2GM obtained on the same date in October 2018. We see very quickly that the composite of S2GM is very noisy, much more than the synthesis from WASP. It is quite often possible to locate the areas where the synthesis tool has chosen to change the date in its composite. You will also notice the appearance of many white dots, which are in fact pixels without clouds, but quite bright that Sen2Cor systematically classifies as clouds.

 

In short, provided you have a good level 2A product, syntheses can provide much better results than composites.

 

 

=>

Copernicus diffuse depuis quelques mois des produits de niveau 3A pour la mission Sentinel-2 dans le cadre du projet S2GM (Sentinel-2 Global Mosaics).

 

Ce projet très ambitieux a pour but de fournir, à l'échelle mondiale, des synthèses mensuelles, trimestrielles ou annuelles. L'utilisateur définit sa zone et sa période d'intérêt et commande le produit. Le site est très bien conçu et très évident à utiliser.

 

L'appel d'offres, doté de deux ou trois millions d'€uros quand même, avait été lancé par le programme Copernicus de l'Union Européenne il y a deux ans. Il imposait d'utiliser les produits officiels de niveau 2A de l'ESA, obtenus avec Sen2Cor. C'est pour cette raison que nous avons décidé de ne pas participer, car notre méthode de synthèse, qui calcule une moyenne pondérée des observations non nuageuses, a besoin de très bons masques de nuages, ce qui n'est pas tout à fait le cas des produits de Sen2cor.

 

L'appel d'offres a été remporté par un consortium composé des sociétés Brockman Consult, Geoville et SInergise. Pour compenser la piètre qualité de la détection des nuages, les auteurs du produit S2GM ont dû utiliser une méthode BAP : "Best Available Pixel". Cette méthode choisit, pour chaque pixel la meilleure date selon certains critères (pas de nuage ou d'ombre détecté, réflectance dans le bleu minimale, NDVI maximal...). Cette méthode permet de minimiser les perturbations nuageuses lorsque les nuages sont mal détectés, mais présente aussi l'inconvénient de changer brutalement de date d'un pixel à l'autre, ce qui cause des artefacts et du bruit. Les sorties sont donc des produits composites, qui assemblent des morceaux d'images acquis lors des différentes dates disponibles sur la période.

 

Les produits de Niveau 3 de Theia ne sont pas des composites, mais des synthèses, qui utilisent toutes les observations sans nuage d'un même pixel sur la période d'observation mensuelle en entier pour trouver la valeur qui représente le mieux la réflectance de surface qu'on aurait eu à la date centrale du produit. Les synthèses de Theia utilisent la chaîne WASP (Weighted Average Synthesis Processor), qui calcule une moyenne pondérée des réflectances de surface sur un mois, après correction atmosphérique et détection des nuages obtenus à partir de produits de niveau 2A générés par notre chaîne MAJA, bien sûr. Si les nuages sont mal détectés, ils entrent dans la synthèse et la perturbent.

Comparaison d'une synthèse obtenue avec WASP+MAJA, avec un produit composite issu de S2GM+Sen2cor, sur la région de Toulouse, en Octobre 2018. (cliquer sur l

L'animation fournie ci-dessus présente une comparaison sur la région de Toulouse, et à pleine résolution, d'une synthèse de WASP et du composite correspondant de S2GM obtenu à la même date en octobre 2018. On constate très vite que le composite de S2GM est très bruités, beaucoup plus que les synthèses issues de WASP. Il est assez souvent possible de repérer les zones où l'outil de synthèse a choisi de changer de date dans son composite. Vous remarquerez aussi l'apparition de nombreux points blancs, qui sont en fait des pixels sans nuages, mais assez brillants que Sen2Cor classe systématiquement comme nuages.

 

Bref, à condition d'avoir un bon produit de niveau 2A, les synthèses peuvent fournir de bien meilleurs résultats que les composites.

 

La légende est l’un des éléments essentiels d’une carte statistique. S’il est essentiel qu’elle soit présente sur le document cartographique, elle doit également être conçue de manière efficace, pour éviter les contresens dans l’interprétation des informations cartographiées.

1. L’importance de la légende d’une carte

La légende doit être claire et facilement compréhensible. Lorsqu’elle est bien conçue, elle permet de faire un lien direct entre le dessin des figurés perçus, les informations sous-jacentes et l’interprétation principale de la figure, telle qu’elle est souhaitée par l’auteur. Au-delà de la légende, la difficulté de réaliser une carte (plus généralement un graphique statistique) réside donc d’abord dans le choix de la méthode de traitement des données à appliquer en amont de la représentation proprement dite, ensuite dans leur formalisation (carto)graphique ; l’inadéquation de l’un de ces éléments se verra forcément dans la légende, et conduira au désormais célèbre #mapfail !

La l̩gende permet en effet de faire le lien entre les informations num̩riques, les informations g̩ographiques, et la mani̬re dont leur articulation est symbolis̩e sur un espace quelconque Рen utilisant les principes de la s̩miologie (carto)graphique Рpour une communication efficace du message v̩hicul̩ par la carte.

C’est ainsi grâce à la légende que l’on peut s’assurer que les variables rétiniennes mobilisées pour symboliser (carto)graphiquement les valeurs numériques sont bien celles qui assurent une transmission instantanée et convenable du message.

La légende est donc un élément crucial dans la compréhension de la carte. Elle permet par ailleurs de statuer avec quasi-certitude de son caractère erroné ou non.

Pour montrer le rôle joué par la légende, considérons une jolie carte mentionnée ce jour sur Tweeter (ici), donc sélectionnée (presque) au hasard !

1. Exemple d’application

La carte en question peut être visualisée ici.

1.1. La carte dans son contexte

"Consommation" du fond @OSM_FR à l'échelle mondiale (source : [https:]] ) pic.twitter.com/oCOWdEBEXX

— PanierAvide (@PanierAvide) February 26, 2019

Cette est mentionnée avec le message suivant : « la consommation du fond OSM [couche cartographique Open Street Map] à l’échelle mondiale Â».

Littéralement frappée par la part de bleu qui concerne toute l’Afrique et une partie de l’Asie en opposition à une partie de l’Europe de l’ouest, je porte rapidement mon regard sur la légende, élément fondamental de compréhension d’une carte thématique.

1.2. Focus sur la légende

La couleur bleue, la première de la gamme, est associée à la valeur zéro. Il n’y aurait donc aucune « consommation du fond OSM » en Afrique, notamment. Dans la foulée, je tagge cette carte en #mapfail ! ce qui permet d’alimenter automatiquement la petite base de données (déjà conséquente de #mapfail) d’un collègue.

Boris Mericksay dit ici n’être pas d’accord sur le fait que cette carte soit un #mapfail . Il précise à juste titre que la variable représentée n’est pas un stock … information qui n’est pas évidente au premier abord (voir la légende). Cela me conduit à revenir sur la légende, puis sur la carte.

2. Légende et commentaire de carte

Cette légende est composée de trois parties, que j’examine tour à tour en suivant l’ordre de lecture qui fut le mien afin d’esquisser l’introduction d’un commentaire (comme on le fait en géographie) de la carte.

2.1. Décortiquer la légende

Au centre :

Sachant que le ton bleu symbolise le zéro, j’observe ensuite la progression de la série de valeurs qui s’étend de 0 à 25 000. Ces valeurs sont représentées en aplats. Déformation professionnelle [renforcée par le fait que j’ai rappelé ça pas plus tard qu’hier soir à des étudiants géographes de L2] : je pense immédiatement : ‘ Caractère quantitatif absolu‘ <->  Variable rétinienne ‘valeur’ <- #mapfail ! n°1 ( variable visuelle Taille).  Et tagge cette carte sur Tweeter ici !

Je ne vois pas immédiatement qu’il s’agit en réalité d’une variable de rapport : Boris Mericskay a donc raison sur ce premier point, je le lui accorde. L’auteur de la carte indique par ailleurs sur un forum spécialisé ceci : the « map normalized to OSM consumption in bits per second per 1000 people, using estimated population per country from Natural Earth (the countries layer used). The outliers on the high end are micro-states, like the Vatican, with very high per capita usage ». [ cette carte est normalisée … en utilisant une estimation de la population par pays à partir de Natural Earth (la couche pays utilisée). Les valeurs aberrantes les plus élevées sont celles les micro-États, tels le Vatican où la consommation par habitant est très élevée.]

Cela étant, le défaut de légende qui a conduit à cette confusion aurait pu être évité <- #mapfail ! n°1 (défaut de légende)

Partie gauche

A ces valeurs sont associées une série d’aplats de couleurs nuancées et variées. Les caissons mobilisant la ‘valeur’ avec la ‘couleur’ sur deux tons (bleu / rouge), le tout en opposition colorée. Il ne semble pas voir sur le document que cette opposition correspond à une inflexion des valeurs, au franchissement d’un certain seuil – je ne connais pas ces données, je ne vois pas ce qui justifie cette opposition <- #mapfail ! n°2 (couleur / opposition colorée abusive)

Partie droite

A la droite de ces mêmes valeurs figurent une seconde série de valeurs : elles sont grisées, présentées en pourcentage (%).

J’observe la progression des valeurs et j’aperçois une segmentation de la série qui m’apparaît un peu, comment dire, ?… Je ne le sais pas. Disons qu’elle est empirique, fondée sur la connaissance que l’auteur à du terrain qu’il analyse, 63% correspond probablement à une valeur particulière – je ne connais pas ces données. La discrétisation est donc plutôt « sensible Â», elle pourrait correspondre à un « seuillage naturel » (mais je n’en sais rien).

Ces % étant disposés en face des valeurs des caissons, je suppose qu’ils représentent soit l’équivalent en % de l’ensemble de la classe de valeur correspondante – je le suppose, car ce n’est pas précisé -, soit une fréquence cumulée puisque les valeurs s’étendent de 0,0% à 100%. Cette seconde éventualité me semble plus probable que la précédente. C’est celle-là que je retiens.

Forte de cette petite lecture de la légende, à l’heure du déjeuner, je décide de revenir à la carte en elle-même pour essayer de l’interpréter.

2.2. Quelle interprétation de la carte ?

• les pays qui sont en jaune, c’est-à-dire eux situés dans la classe présentant la valeur 1500 contribuent à 81% de « Consommation du fond OSM à l’échelle mondiale », comme l’indique le tweet de départ. Cela n’est pas clair, d’autant moins que l’on serait dans l’hypothèse d’un % cumulé- mais je me fie ici à la seule représentation. Vue la gamme de couleurs, je ne peux en effet pas dire que les pays dont les couleurs s’étendent du bleu au jaune représentent 81% du total cumulé des connections… Prenons un autre exemple.
• les pays qui sont représentés en bleu (incluant notamment toute l’Afrique) présentent une valeur égale à 0 qui équivaut à moins de 63,6% – ou bien à, tout de même, 63,3% de la « Consommation du fond OSM à l’échelle mondiale », ce qui n’est pas rien. Donc la classe portant l’effectif de pays le plus important, portant 63% de l’information, est mélangée avec ceux où il ne se passe rien. Disons le autrement : les pays représentés en bleu présentent un « nombre de connexions » inférieur à 500 (ou plutôt à 499 ?) et correspondent à 63,6% (soit plus de la moitié) de la consommation du fond OSM.

On voit bien qu’un autre problème se dessine, avec cette difficulté de lecture. Sachant maintenant qu’il s’agit d’une variable de rapport (connexions pour 1000 personnes) , cette difficulté de lire/d’interpréter la carte est liée au mapfail ! n°2 mais avant cela, à un autre problème de position des bornes de ces classes <- #mapfail ! n°3 (discrétisation).

Si je ne connais pas les intentions initiales de l’auteur, j’observe manifestement un décalage entre la série statistique et sa représentation cartographique, lié à un mésusage des principes élémentaires qui fait que le message transmis m’apparaît difficile à appréhender.

A noter que le problème vient donc, comme très souvent en cartographie statistique, d’un défaut dans le traitement amont des données numériques. J’ajoute à cela que cette carte est par ailleurs très incomplète quant à sa conception et aux éléments d’habillage, mais il s’agit d’autres problèmes.

En guise de conclusion, cette carte ne transmet pas correctement l’information disponible. Et c’est bien dommage !.

A noter : une discussion sur l’amélioration de cette carte incluant les données, est ouverte sur Reddit (ici).

Billets liés :

Eviter un #mapfail

Le manifeste des cartographes

Françoise Bahoken

Géographe et cartographe, Chargée de recherches à l'IFSTTAR et membre-associée de l'UMR 8504 Géographie-Cités.

More Posts

Cet article Open data and terrorism risks est apparu en premier sur Veille cartographique 2.0.

Introduction The questions of the openness of data and the risk of terrorism are two different concepts. Data openness means making the largest possible amount of data available to all in a usable form. Data platforms open to the public have been set up to facilitate the exchange of information between state services. Even if […]

Cet article Open data and terrorism risks est apparu en premier sur Veille cartographique 2.0.

Les cartes de localisation permettent une vision plus globale de la zone d’étude représentée sur la carte principale

Le principe est très simple: ce sont deux cartes en une seule mise en page. La carte de localisation aura une caractéristique particulière: on figera l’étendue, les couches affichées et la symbologie de ces couches une fois pour toutes. La seule variable sera le rectangle d’emprise qui, lui, est géré par QGis lui-même.

Pour commencer, cliquez sur le menu Projet->nouvelle mise en page ou ouvrez le gestionnaire de mise en page et créez une nouvelle mise en page.

Dans la fenêtre de mise en page, ajoutez la carte principale (menu Ajouter un élément -> Ajouter carte) et la carte de localisation (idem)

Notez alors que la carte principale est nommée carte 1 et la carte de localisation carte 2.

Vous allez commencer par la définition de la carte de localisation:

1- dans la fenêtre cartographique de QGis, zoomez le contenu de la fenêtre au niveau que vous souhaitez voir dans la carte de localisation.

2- affichez seulement les couches que vous souhaitez voir dans la carte de localisation en désactivant l’affichage des autres couches.

3- Modifiez, si nécessaire, la symbologie des couches visibles. Par exemple, l’épaisseur des traits est généralement plus fin pour la carte de localisation que pour la carte principale.

4-Vérifiez dans le gestionnaire de mise en page que le résultat correspond à vos souhaits. Pour cela, en ayant sélectionné la carte 2, cliquez sur Mise à jour de l’aperçu dans le panneau Propriétés principales

Dans le panneau couches, cochez les cases Verrouiller les couches et Verrouiller le style des couches. Pour assurer qu’il n’y aura pas d’autre modification, cochez la case de verrouillage de carte 2 dans la fenêtre Éléments.

Votre carte de localisation est configurée.

Vous allez maintenant vous occuper de la carte principale. Mettez la en forme (zoom, symbologie, etc…)

Une fois terminée la mise en page de la carte principale, il ne vous reste qu’à relier les deux cartes pour que la carte de localisation affiche l’emprise de votre carte principale.

Pour cela déverrouillez la carte 2, cliquez sur elle pour la sélectionner, ouvrez le panneau Aperçus de votre carte de localisation.

Cliquez sur le bouton + pour ajouter un aperçu dans la liste d’aperçus. Il sera nommé Aperçu 1.

Pour paramétrer l’aperçu, il faut indiquer quelle emprise il faut afficher. Dans Cadre de la carte, sélectionnez Carte 1

Vous pouvez modifier le style de l’emprise (couleur, contour, etc) en ouvrant le Style de cadre

A partir de ce point, si vous changez l’emprise de la carte principale, l’emprise affichée sur la carte de localisation sera modifiée automatiquement pour la représenter.

L'enneigement est plutôt bon cette année dans les Alpes comme le remarque le chef du centre Météo-France des Alpes du Nord.

Aperçu positionnement de l'#enneigement dans les #Alpes : bon à très bon tous massifs - toutes altitudes. Fonte-tassement actuels: 2 à 4 cm/jour orientation Nord, plus de 5 cm/j orienté Sud. Fin février sans précipitations attendues: plus de neige versants Sud basses altitudes. pic.twitter.com/GKshIonoQB

— Serge Taboulot (@sergetab) February 18, 2019

Les cartes ci-dessous montrent la durée de l'enneigement dans le bassin de la Durance depuis le 01 septembre jusqu'à aujourd'hui pour les trois dernières années (soit une période de 172 jours). Elles ont été calculées à partir des produits neige Theia.

Durée de l'enneigement du 01 septembre au 19 février dans le bassin de la Durance à Serre-Ponçon. La durée moyenne d'enneigement sur tout le bassin est 52, 71 et 65 jours.

En voyant ces cartes, Pascal Dumoulin du Syndicat Mixte d'Aménagement de la Vallée de la Durance a fait ce commentaire :
"on retrouve les caractéristiques suivantes :
-2016-2017 relativement peu de neige, concentrée en haute altitude
-2017-2018 enneigement abondant même à basse altitude
-2018-2019 enneigement à basse et haute altitude, persistant à haute altitude grâce au froid"

 
Le graphique suivant fait à partir des données Theia confirme bien son analyse :
 

Durée d'enneigement moyenne par tranche d'altitude de 100m

Voici la situation actuelle à Serre-Chevalier au coeur du bassin versant de la Durance

Cet article Brexit : les étudiants du Master Géomatique à Londres pour le workshop annuel ! est apparu en premier sur Veille cartographique 2.0.

Chaque année, les étudiants du Master « Géomatique appliquée aux études urbaines et aux risques » de l’UCP se rendent dans la région de Londres pour travailler conjointement avec le Master de Géopolitique RHUL de l’Université de Londres. C’est dans le cadre d’un workshop d’une semaine que cette collaboration prend forme. Les étudiants travaillent de concert sur la sécurisation d’un giga événement […]

Cet article Brexit : les étudiants du Master Géomatique à Londres pour le workshop annuel ! est apparu en premier sur Veille cartographique 2.0.

The MUSCATE production centre will be offline for a week from February 25th to March 4th (or maybe the week after, please see Theia's RSS feed to see the exact date). This pause will be necessary to upgrade the processing centre to V2.5. As a result, we will not be able, for a week, to process Sentinel-2 data in real time, and hope it will not be too inconvenient to you. In case you need some data urgently, you can ask PEPS to produce MAJA L2A data for you during that period.

 

The main change regards the internal format used by MUSCATE for Sentinel-2 Level 2A products. This internal format is different from the external format that we distribute, and this results in unnecessary product format conversions, as well as the necessity to develop drivers for the various formats (internal and external) for the processors that use Sentinel-2 L2A data within MUSCATE. To enable this modification, it will be necessary to convert all the L2A data from the internal format to the external format, which will take a whole week.

 

MUSCATE V2.5 will bring other improvements, such as the integration of MAJA 3.1, with possibility to use Copernicus Atmosphere data, or a new version of LIS, the processor that delivers the snow maps.

MUSCATE  V2.6 is also ready and queuing to be installed, with MAJA 3.2, WASP and the possibility to process Venµs L2A data within MUSCATE and not externally on Venµs ground segent.

 

 

 

The snow cover is not always white. Sometimes it is orange, sometimes it is black. The images below were captured by Sentinel-2 in Prokopyevsk, Russia.

According to the Siberian Times the deposition of black dust on snow in February 2019 was due to the failure of a filtering system in a coal processing plant. Looking at the picture below, I have the feeling that this kind of event was not exceptional in Prokopyevsk this winter...

Source: Siberian Times 15 Feb 2019. Pictures from Kemerovo region by Orlovprklife, Willravilov, Typical Kemerovo

Thanks to François Tuzet for pointing this to me!

Cet article L’émergence des « deepfake » dans les flux d’informations numériques est apparu en premier sur Veille cartographique 2.0.

Avec le nombre croissant de flux d’informations partagées en masse sur les réseaux de communications numériques s’est accompagné avec la propagation de « fake news ». Cette expression, qui n’a pas d’équivalent en français, désigne principalement des fausses informations pouvant être propagées dans des buts différents. Certaines ont pour objectif de tromper le lecteur ou d’influencer son opinion sur un […]

Cet article L’émergence des « deepfake » dans les flux d’informations numériques est apparu en premier sur Veille cartographique 2.0.

Pour changer et pour nous reposer l’esprit, plutôt que d’aborder un sujet polémique, j’ai choisi d’évoquer une des plus grosses révolutions scientifiques ayant eu lieu au début du siècle dernier dans le domaine de la physique.

Vous l’aurez peut-être noté, la théorie de la relativité générale ne cesse de se confirmer. Il y a maintenant plus d’un siècle Albert Einstein a bouleversé les notions d’apparence très simples que sont le temps et l’espace pour expliquer des observations qui laissaient perplexes tous les scientifiques de l’époque. Il en a même profité pour en imaginer les conséquences au travers de phénomènes qui, à l’époque, n’avaient pas encore été constatés.

Ainsi, l’espace-temps est distordu par les masses. La théorie prévoit, notamment, l’existence de trous noirs. Un tel objet concentre une telle quantité de matière qu’il produit un champ gravitationnel si intense qu’aucune particule ne peut sortir de son horizon, quelle qu’en soit la vitesse. Cela s’applique également à la lumière (ce qui explique son nom). Dans ces conditions, il est difficile d’observer directement un trou noir. Néanmoins, les scientifiques ne manquent pas d’imagination pour les détecter :

• L’un des premiers effets observables utilisé a été les mirages gravitationnels. La trajectoire de lumière est incurvée par la présence d’objets très massifs. Ce phénomène a été prédit par Einstein et très rapidement vérifié par l’expérience au moment d’une éclipse. Plus l’objet est massif plus les rayons lumineux sont déviés. Il en résulte que l’image de certains astres peut nous parvenir déformée, voire dans des cas plus rares de plusieurs directions en même temps, si un trou noir est situé entre nous et eux.
• A défaut de pouvoir régurgiter quoi que ce soit un trou noir a la capacité d’absorber un astre qui se trouverait dans son voisinage. Avant d’atteindre son horizon, les énergies mises en jeu dans un tel évènement peuvent produire des rayonnements colossaux observables.
• En plus de ces rayonnements électromagnétiques, la théorie de la relativité générale prévoit également que des corps extrêmement massifs orbitant l’un autour de l’autre produisent des ondes gravitationnelles. L’existence de ces ondes a été confirmée pour la première fois en 2015 par des instruments mesurant les déformations de l’espace avec une précision inimaginable (expérience LIGO).
• Stephen Hawking a également émis l’idée qu’un trou noir pourrait laisser échapper des particules à la limite de son horizon. Ce rayonnement de Hawking résultant de phénomènes quantiques est d’une ampleur néanmoins très limitée et son observation pourrait ne jamais être réalisée.

Observer un trou noir n’est pas à la portée de n’importe quel instrument. Heureusement, l’ingéniosité de nos scientifiques nous permet d’ouvrir de nouvelles dimensions sur notre univers.

Clefs de lecture :

• trou noir : catalogue de données géographiques
• horizon : interface CSW
• orbitent l’un autour de l’autre : se moissonnent
• scientifique : spécialiste de la normalisation géospatiale
• astre absorbé : administrateur de données
• instrument (observateur) : utilisateur final
• observation : recherche couronnée de succès
• mirage gravitationnel, rayonnement de Hawking et onde gravitationnelle : effets des catalogues sur leur environnement

Le but de la fonction Atlas est d’automatiser la production d’une série de cartes. Vous créez un modèle, une série d’emprises et cette fonction produit automatiquement une carte par emprise.

Nous allons voir les notions nécessaires pour sa mise en pratique.

Tout d’abord, quand vous ouvrez un projet vierge, vous avez aussi un gestionnaire de mises en pages vide qui est créé.

Vous devez commencer par créer votre projet: charger les données dan s la fenêtre cartographique, affecter la symbologie voulu à chaque couche, etc.

Une fois ceci fait, vous allez créer la mise en page souhaitée avec le gestionnaire de mise en page. Vous allez disposer la ou les cartes, la légende, les titres et textes, une barre d’échelle, etc.

La seule chose à retenir à ce stade est que vous devez créer une mise en page qui puisse être utilisée pour chaque partie de votre zone de travail. Le plus simple est de zoomer sur une des cartes souhaitées et de mettre en forme la mise en page en utilisant toujours ce niveau de zoom. Travaillez comme si vous ne souhaitiez comme sortie que cette carte-là.

Une fois satisfait de votre mise en page, commence le véritable travail de constitution de l’Atlas.

Créer la couche maîtresse de l’Atlas.

Cette couche doit contenir les entités qui serviront à définir l’étendue de chaque carte de l’Atlas. Elle est obligatoirement de type polygone.

Les emprises vertes peuvent faire l’affaire. Chaque carte en sortie aura la même étendue et échelle. Mais la couche de communes peut tout aussi être utilisée. Dans ce cas, chaque carte sera centée sur une commune, à tour de rôle. Elles auront des échelles différentes ou vous pourrez configurer un paramètre déterminant une échelle commune à toutes les cartes.

Cette couche ne contient pas seulement les étendues de chaque carte de l’Atlas. Elle contient aussi toutes les variables associées à chaque carte. Par exemple, si vous souhaitez que chaque carte des emprises vertes ait un titre différent, il faudra un attribut de type texte pour chaque entité, contenant le texte à utiliser lors de la création de chaque carte.

Mise en place de la fonction Atlas

Dans le gestionnaire de mise en page, quand vous avez fini la mise en forme de votre sortie, cliquez sur l’onglet « Atlas »

Vous accédez au paramétrage de la fonction.

Cochez la case Générer un Atlas pour mettre en route la fonction.

Le panneau Configuration vous permet de configurer les options de fonctionnement de l’Atlas:

1- Emprise de la couche : sélectionnez la couche maîtresse de l’Atlas avec les emprises correspondantes à chaque carte.

2- L’option Cacher la couche de couverture empêche l’impression des entités de la couche maîtresse sur vos cartes.

3- Le Nom de la page est un attribut de la couche maîtresse qui sert à identifier les cartes au sein du gestionnaire de mise en page. Il n’est pas utilisé pour les sorties.

4- L’option Filtrer avec permet de créer un filtre sur la couche maîtresse. Ceci vous permet d’utiliser une seule couche maîtresse pour plusieurs Atlas différents, en sélectionnant par filtrage les entités à prendre en compte pour la génération des cartes.

5-L’option Ordonner par permet de déterminer la suite de cartes. Par défaut, si cette option n’est pas utilisée, les cartes seront produites selon l’ordre des enregistrements de la couche maîtresse.

Le panneau Sortie permet de donner la structure du nom de fichier de chaque carte, si vous souhaitez un fichier par carte. Vous pouvez aussi cocher la case de ne produire qu’un seul fichier avec l’ensemble des cartes. La première option s’applique par exemple à une série d’images png, tandis que la deuxième s’applique plutôt à un fichier pdf.

Visualisation de l’Atlas

Dans le menu du gestionnaire de mise en page, cliquez sur Atlas, puis sur Aperçu de l’Atlas. Les options du menu Première entité, Entité précédente, Entité suivante, Dernière entité sont alors activées. Elles vous permettent d’afficher dans la fenêtre du gestionnaire de mise en page chacune des cartes de l’Atlas.

Les autres options du menu vous permettent, une fois fini la configuration et paramétrage de l’Atlas, de réaliser les sorties souhaitées: cartes individuelles ou fichier unique

Mise en place des variables de l’Atlas

Vous pouvez personnaliser chacune des cartes de l’Atlas à travers des variables. Le besoin le plus classique est la personnalisation du titre de chaque carte.

Pour cela, vous devez créer un élément Titre dans votre mise en page. Dans la fenêtre de texte de l’élément, vous pouvez rentrer du texte classique et des références à un ou plusieurs attributs de votre couche maîtresse.

.Dans cet exemple on fait référence à un attribut nommé Titre2. Le fait de le délimiter par [% et %] l’identifie comme une variable à remplacer par une valeur au moment de la production de l’Atlas. Les variables sont aussi remplacées lors de la visualisation de l’Atlas avec l’Aperçu de l’Atlas.

Mais les variables ne se limitent pas aux élément textuels de la page. Vous pouvez utiliser partout dans QGis les variables de l’Atlas:

Cet article Cartographie des océans est apparu en premier sur Veille cartographique 2.0.

Les océans et leurs fonds marins sont encore des grands inconnus de notre planète. Notamment lorsque l’on sait que seulement 5% des abysses ont été étudiés. Cependant, ces espaces si peu accessible par l’Homme peuvent désormais être observés par les nouvelles technologies. En effet, à travers différents instruments de mesures les mers et océans peuvent […]

Cet article Cartographie des océans est apparu en premier sur Veille cartographique 2.0.

Cet article Interface AR de Google Maps : la nouvelle interface de navigation en réalité augmentée. est apparu en premier sur Veille cartographique 2.0.

Au fil des ans, Google Maps est passé d’un simple service de cartographie à une vraie solution de navigation gratuite, une alternative aux solutions GPS classique. Après le lancement en 2007 de Google street view permettant de visualiser en panorama à 360° un lieu situé sur une voie urbaine ou rurale, Google vient de franchir […]

Cet article Interface AR de Google Maps : la nouvelle interface de navigation en réalité augmentée. est apparu en premier sur Veille cartographique 2.0.

Cet article Le Géocube, le surveillant des glissements de terrain, des glaciers et des ouvrages d’art est apparu en premier sur Veille cartographique 2.0.

Le laboratoire d’optoélectronique, de métrologie et d’instrumentation (Loemi) de l’IGN a développé un récepteur GPS autonome ultra-compact, ultra-précis, nommé le Géocube. Fonctionnant en réseau, le Géocube révolutionne la surveillance des glissements de terrain, des mouvements des glaciers ou des ouvrages d’art. Le Géocube est un appareil très sensible. Il a plusieurs capteurs pouvant détecter, en […]

Cet article Le Géocube, le surveillant des glissements de terrain, des glaciers et des ouvrages d’art est apparu en premier sur Veille cartographique 2.0.

(English version below)

Dans le cadre du projet Simult’eau (partenaires : Arvalis, CACG, Chambres d’Agriculture du Tarn et des Hautes-Pyrénées, financement CASDAR) nous avons testé l’apport d’une utilisation combinée des images radar et optiques pour la cartographie des surfaces irriguées (maïs et soja) dans le Sud-Ouest de la France. Les résultats publiés dans Remote Sensing ( [https:]] ) ont révélé que l’utilisation d’images radar Sentinel-1 combinées aux images optiques (Landsat-8) permettait de détecter les surfaces irriguées plus précocément qu’avec les images optiques seules. En effet ces dernières sont souvent perturbées par la présence de nuages qui rendent la détection impossible à certaines périodes de l'année. Ce résultat, qui doit être confirmé par des études complémentaires (autres lieux et autres dates), est très encourageant. Il ouvre de nouvelles perspectives pour une gestion "optimisée" des ressources en eau notamment pour des organismes tels que la CACG (Compagnie d'Aménagement des Coteaux de Gascogne) ou les Organismes de Gestion Collective de l’eau (OUGC). Les cartes produites sont en libre accès sur le site Theia: [www.theia-land.fr] .

Ces recherches se poursuivent actuellement dans le cadre de la thèse de
Yann Pageot financée par le CNES, l'Agence de l'Eau Adour-Garonne et la CACG.

As part of the Simult'eau project (partners: Arvalis, CACG, Tarn and Hautes-Pyrénées Chambers of Agriculture, CASDAR funding), we tested the potential of the joint use of radar and optical images for mapping irrigated areas (maize and soybean) in southwestern France. The results published in Remote Sensing ( [https:]] ) revealed that the combined use of the radar and optical images improves the early classifications of the irrigated crops compared to classifications obtained using optical images only. Indeed during rainy periods, unlike radar images, the optical images are inexploitable due to cloud coverage. This result, which must be confirmed by further studies (in other places and for other dates), is very encouraging. It offers new perspectives for the water resource managers to reach a more sustainable water resources management. The maps produced are freely accessible on the Theia website: [www.theia-land.fr] .

This research is currently ongoing as part of Yann Pageot's PhD funded by CNES, the Agence de l'Eau and the CACG.

Cet article HERE lance son indice de mobilité urbaine est apparu en premier sur Veille cartographique 2.0.

Le fournisseur de cartographie de précision néerlandais HERE Technologies a mis en place le 22 novembre 2018 un outil de visualisation des données de mobilité dans 38 des plus grandes villes de monde. Cette plateforme, Urban Mobility Index, vise à approfondir la connaissance des professionnels et des citoyens sur la façon dont la ville se […]

Cet article HERE lance son indice de mobilité urbaine est apparu en premier sur Veille cartographique 2.0.

Cet article Les risques liés à l’ultra haut débit 5G est apparu en premier sur Veille cartographique 2.0.

La 5G est aujourd'hui autour de plusieurs tensions notamment autour de Huawei, groupe chinois de téléphonie, qui est l'un des grands acteurs de la 5G et dont plusieurs pays pensent que ce ne serait pas une bonne idée de confier le déploiement de la 5G à Huawei.

Cet article Les risques liés à l’ultra haut débit 5G est apparu en premier sur Veille cartographique 2.0.

Cet article Developing a tool for New Orleans’ transport system est apparu en premier sur Veille cartographique 2.0.

During the course of the 2018 Fall semester, the GIS master of Cergy-Pontoise university has developed potential suggestions to help New Orleans manage its exposure to risks and hazards. My team was in charge of the city's transport system. The article that follows details the tool we aimed to developed to fail the many hazards New Orleans is facing.

Cet article Developing a tool for New Orleans’ transport system est apparu en premier sur Veille cartographique 2.0.

The version 3.2.2 of MAJA cloud detection and atmospheric correction software has just been released! It brings a lot of improvements. It can be used to process Sentinel-2 data in four different manners that will be described below :

• as a free executable software for linux,
• as an on-demand production on PEPS
• included in Sen2Agri software
• downloading its products from Theia processing center.

Improvements

MAJA 3.2.2 brings a lot of improvements:

• MAJA 3.2 adapts to a bug from Sentinel-2 L1C products, which sometimes (but quite frequently) provides the detector footprints (DEFOO masks) in an incorrect order since October 2018. When this happened, MAJA crashed, but with MAJA 3.2.2, it is over.
• MAJA 3.2 still only works for linux systems, but not anymore for only with Red Hat and CentOS, as it is now provided with the complete set of necessary libraries. It was for instance successfully tested on Ubuntu systems.
• We have updated the water vapour LUT to cancel a bias we had for high water vapour contents. The improvement was already described in this post.
• We have slightly changed a few parameters for a stricter cloud detection, but the cloud mask will significantly improve with MAJA V3.3.
• If the option to use Copernicus Atmosphere Monitoring Service (CAMS) data is selected, the CAMS Aerosol Optical Thickness can be used not only to define the type of aerosol, as introduced in MAJA 3.1, but also as a default value with a low weight in the cost function. If MAJA does not find many suitable pixels to estimate the AOT, the CAMS value will have an influence, but in general, a large number of measurements are available in an image, and in that case, CAMS has no influence (except on the aerosol type, see below, V3.1). Finally, this improvement will be useful over snow covered landscapes, or bright deserts, of for images almost fully covered by clouds.

Left, without default CAMS value, right with default CAMS value, for neighbourhoods for which more than 50% of pixels can be used to estimate aerosols. In that case, use of CAMS does not really change the results.

Left, without default CAMS value, right with default CAMS value, for neighbourhoods for which less than 50% of pixels can be used to estimate aerosols. These situations correspond to a large proportion of snow or cloud covered pixels. Before version 3.2.2, these pixels were gap filled. A notable improvement is observed.

Free executable version

MAJA free executable version can be downloaded from CNES free software site. It has already been downloaded 800 times from this site. MAJA now works on any Linux workstation, with at least 8GB of RAM. We have tested it on Red Hat, Cent OS and Ubuntu. To run it and obtain all the necessary inputs and parameters, we advise to use our simple pyhon orchestrator Start_MAJA.py, which handles the processing of a whole time series of images for a given tile.

 

Start_MAJA.py has been updated, it is now available on CNES github repository. The script itself has been improved. Generation of DEM file is much easier as the parameters of each tile are generated thanks to the kml file provided by ESA (a contribution from Peter Kettig). We also enabled the script to work with zipped input files if you prefer to save disk space even if it may cost processing time.

On demand processing with PEPS

As already mentioned here, you may ask PEPS, the French collaborative ground segment, to process data with MAJA for you. Thanks to MAJA 3.2.2, we have solved several of the issues we had so far because of the errors in ESA L1C format (already mentioned above).

The user manual is available here, and a script to launch it via a command line interface is available on github. Here is an example of command line :

python ./peps_maja_process.py  -l Toulouse -a peps.txt -d 2017-11-01 -f 2017-12-01 -p prod_list_toulouse.txt

However, the current version is still a beta version. We should have an alpha version very soon which will be much more efficient in terms of computing resources, and will be able to produce for you up to a whole year of data, for a given tile, with just one command line to start.

Operational processing in MUSCATE processing center

As Theia's MUSCATE processing center is an operational service, every new version has to go through a large number of tests. Introducing MAJA 3.2.2 in MUSCATE processing center is complex, because we had to introduce a new interface with MAJA, using CAMS data. For this, we also have to take care of the fall-back strategies in case CAMS is not available.

We are currently doing the last tests in operational configuration before starting the production, and we hope to start the production very soon. And when we have controlled the real time production is OK, we will do a complete reprocessing, probably this summer; as we expect a large improvement in data quality.

MAJA processing within Sen2Agri

MAJA 3.2.2 will also be added in the next version of Sen2Agri system. Sen2Agri is a processing systems, which provides advanced tools to monitor agriculture at the scale of a country. All its products are based on Level 2A products obtained with MAJA.

 

Acknowledgements

This new version is the result of a LOT of work, with the contribution of

- CS-SI team, who develops the operational version of MAJA (many thanks to Aurelien Bricier and Benjamin Esquis)

- CNES team, who handles that development, organises the validation and contributes to Start-MAJA processor. Many thanks to Peter Kettig and Pierre Lassalle. They were helped in 2018 by Bruno Angeniol, from Cap Gemini.

- CNES image quality team (Camille Desjardins) with the help of Elsa Bourgeois from Cap Gemini, for the maintenance of the reference MAJA processor, and for validation and several improvements ncluding water vapour estimation.

- CESBIO team, Bastien Rouquie and myself, for the research part, including the use of CAMS data and the cloud mask adjusments.

36 600 communes : c'était la référence que j'avais depuis le tout début de mes études, il y a quelques années déjà ...

Voilà donc une référence à revoir : au 1er janvier 2019 nous en serions à 34 980 communes, disons 35 000 pour faire simple. En janvier 2016 je titrais sur 36 000. Le mouvement s'est depuis lors poursuivi.

Les comptes paraissent simples : déduire les communes fusionnées, 2 communes très souvent mais jusqu'à 22 pour le maximum, et rajouter le nombre de communes nouvelles. Mais les comptes ne sont pas si simples car :

• il y a eu des doubles fusions, c'est à dire des fusions de fusions. On parle aussi d'extensions de communes nouvelles.


• Et la procédure devient réellement officielle avec la parution d'un arrêté au journal officiel, ce qui parfois prend un certain temps.

Malgré les éléments de méthode qui avaient été publiés, il s'avère qu'un certain nombre de fusions ne respectent pas les règles de nommage que nous avions évoquées en novembre 2017. Ce sujet a été évoqué à la commission nationale de toponymie de juin 2018, le compte-rendu est disponible sur le site du CNIG.

Les ressources sur le sujet sont très nombreuses :

• L'AMF, association des maires de France, est très active sur le sujet et propose toute une série de documents au services des collectivités qui entreprennent une telle démarche : communes nouvelles : une dynamique confortée et d'avenir.


• Un article de Maire info de janvier 2017 décrypte le processus en cours et présente une carte sur laquelle il serait intéressant de rajouter les fusions 2018.


• Wikipédia récapitule la liste des communes concernées par année : Liste de communes nouvelles.


• Les acteurs du SIG suivent également ça de prés. En témoigne le dernier fil de discussion sur le millésime 2019. Vous y trouverez également plein de liens vers des ressources à jour.

J'en profite pour dire merci à ceux qui se mettent au service de tous pour tenir à jour ces bases. Car les contours communaux sont un référentiel essentiel en matière de cartographie mais également de statistiques.

Aujourd'hui je vous présente une magnifique et très utile cartothèque : la cartothèque du CGET (commissariat général à l'égalité des territoires). Celle-ci met à disposition du grand public un panel de cartes statiques, des posters à imprimer ou des cartes...

Il y a quelques semaines, nous annoncions la sélection d'une nouvelle zone de production de données Sentinel-2 au niveau 2A par Theia, au Sahel. La production a démarré, et Theia a déjà produit les tuiles de la zone UTM28 (à l'ouest). Les tuiles en vert foncé existaient déjà, mais nous avons rajouté celles en vert clair, qui permettent de couvrir l'ensemble du Sénégal, la Gambie,  une partie de la Guinée Bissau, de la Guinée, et le nord de la Sierra Leone.

 

Les données disponibles ont été traitées du premier janvier 2017 à hier, soit plus de deux ans de données. Les nouvelles données seront maintenant traitées en temps réel au fur et à mesure de leur arrivée.

Nous procéderons de même avec les différentes zones  de l'ouest vers l'est : UTM29, UTM30...

 

A seventh year begins for the "Séries temporelles" blog, and as usual, it is an opportunity to review its audience, and to get a little self-satisfaction. We usually publish this post early January, but it seems there was no January this year (or was I too busy ?). The blog is still receiving more visits every year, with a sharp growth this year : +35% of visits ...

Blog traffic from December 2012 to January 2019 (the trends were computed using the Theil–Sen estimator), computed by Simon Gascoin.

So, if we look at the trends on the plots above, the audience growth is remarkably linear, but if we sum-up everything per year, we see a sharp increase. The cause is that outlier in the top-right corner or each graph above, related to a big buzz in Japan for SImon's article about Xe-Namnoy lake dam failure in July, that flooded several villages, and killed too many people.

 

	2013	2014	2015	2016	2017	2018
Number of visits	13985	22928	34723	47773	57692	79243
Number of viewed pages	30922	46940	66947	89555	105846	131846

 

French visitors only counted for 25% of visits, much less than the other years. Japan ranked second with 16%,  United States ranked third, followed by European countries (UK, Germany, Italy, Spain) and by India, Canada and Morocco.

 

In 2018, contrarily to the other years, the authors list is very short, 95 % of the posts were written either by Simon Gascoin, who is specialized in catastrophies, hydrology and snow (which are often related), and myself, about optical data quality, Sentinel-2 and Theia's news. But we welcomed two new authors, Gerard Dedieu, who tells us about the Venµs satellite, and Vincent Thierion, about land cover, and Jordi Inglada contributed a few articles about machine learning. We are still missing an author to tell us about the results obtained with Sentinel-1 at CESBIO.

 

This blog is open, writing a post does not take long (the first one always more than the second and third ones), and we are waiting for you to contribute, even if you are not a CESBIO member. If you are a user of remote sensing time series, especially those from Theia, please tell us about your findings, results, hopes and regrets.

 

Here are the top ranking pages, after having removed the tags, author names, article lists, and summed French and English versions...

1	Xe-Namnoy lake dam failure	11213
2	Radiometric quantities : irradiance, radiance, reflectance	4433
3	Mapping flooded areas using Sentinel-1 in Google Earth Engine	3945
4	A python module for batch download of Sentinel data from ESA	3196
5	MACCS/MAJA, how it works	3160
6	The land cover classification for France in 2016 is available	2622
7	A seamless and cloudless Sentinel-2 image of France in July 2018	2277
8	The Sentinel-2 tiles, how they work ?	2131
9	THEIA’s L2A product format	2107
10	La production de cartes d’occupation du sol, comment ça marche?	1821
11	The product level names, how they work ?	1668
12	L’ortho-rectification, comment ça marche ?	1420
13	Using NDVI with atmospherically corrected data	1273
14	How to automatically download Sentinel data from PEPS collaborative ground segment	1101

 

What can we tell from that ?

• There was a huge buzz in Japan about Xe-Namnoy lake dam failure. We guess it comes from a highly visible website, which recommended this article (but our japanese is not fully fluent)
• The practical pages (download tools, codes, formats) , and the "how it works" series hold most of the first ranks
• Blog articles reporting an event may be momentarily successful, but their reading does not last too long, except if it is about GEE
• As for last two year, the example of using Google Earth Engine, published in 2016, attracts much more than articles that warn about its dangers (it's sad). As Simon said, we would have to quote GEE into each article title to get more traffic.
• Some pages in French have a higher attendance than their English translation, especially those on land use in France, which is normal. But this is also the case of ortho-rectification. Why ?
• The MACCS / MAJA description page is often visited, but I believe that 95% of my articles contain a link to this page ...

Cet article The use of technology to prevent heavy-weapon attacks est apparu en premier sur Veille cartographique 2.0.

While security has been a major issue over the past years in western countries, a large number of technologies have been developed and could help to fight terrorist attacks on different scales. In order to understand how we can use technology to prevent terrorist attacks, we will focus on two fictitious scenarios of heavy-weapon attacks […]

Cet article The use of technology to prevent heavy-weapon attacks est apparu en premier sur Veille cartographique 2.0.

L'IGN a mis en ligne un outil formidable pour comparer les photos aériennes des années 1950 avec des prises de vue récentes. Cela permet d'explorer à l'envi l'évolution des paysages, comme par exemple la reforestation des estives dans les Pyrénées (ici le secteur de l'étang de Lers, en 2016 et 1953).

 

 
Ou bien le retrait de la Mer de Glace:
 

 
... l'urbanisation des terres agricoles vers Marne la Vallée :
 

 
... l'envasement de la Baie du Mont-Saint-Michel :
 

 
Et bien sûr chacun pourra aller voir son quartier ! Voici le Cesbio (2016 vs. 1954) :
 

=>

Sentinel-1 is currently the only system to provide SAR images regularly on all lands on the planet. Access to these time series of images opens an extraordinary range of applications.
In order to meet the needs of a large number of users, including our needs, we have created an automatic processing chain to generate "Analysis Ready" time series for a very large number of applications. Sentinel-1 data is ortho-rectified on the Sentinel-2 grid to promote joint use of both missions.

 

 

S1Tiling was developed within the CNES radar service, in collaboration with CESBIO, to generate time series of calibrated, ortho-rectified and filtered Sentinel-1 images on any terrestrial region of the Earth. The tool benefits for the SAR ortho-rectification application from the Orfeo Tool Box. The resulting images are registered to Sentinel-2 optical images, using the same MGRS geographic reference. You will be able to access Sentinel-1 data acquired on Sentinel-2 31TCJ or 11SPC tiles.

This Python software, is based on the Orfeo Tool Box (OTB) image processing library, developed by CNES, as well as on the PEPS platform to access the Sentinel-1 data. It can be used on any type of platform, from a large computing cluster to a laptop (the fan will make some noise during processing). It is considerably faster than the ortho-rectification tool in SNAP, and can be easily used in script form. For any questions, please use the gitlab platform, rather than leaving comments to this article.

S1-Tiling works in several steps: it starts by downloading the images on PEPS mirror site, then calibrates and ortho-rectifies them on the Sentinel-2 grid, and finally applies a multi-temporal filtering of the speckle noise

S1Tiling is currently used for many applications, such deforestation detection in the Amazon, monitoring of rice crops in Southeast Asia or monitoring of water stocks in India.

In addition, this software is accessible as an on-demand processing service on the French PEPS collaborative ground segment, in order to make it easier for users to use.

Use S1-Tiling within PEPS

If you are allergic to the command line (that's a pity), you can use the on-demand processing features of PEPS, although it does not include the speckle filter yet. It's very simple.

1. First, connect to PEPS ( [https:]] )
2. Select the "explore" function
3. Query the catalogue to obtain the images you wish to process (don't forget to mention you want a GRD Sentinel-1 product). For each product that fits your criteria, click on the gearing icon
4. go to the processing page (gearing icon, top-right)
5. select Sentinel-1 ortho-rectification
6. select every product and start processing
7. just wait for a while

 

Cet article Les bizarreries de la carte des fuseaux horaires est apparu en premier sur Veille cartographique 2.0.

Suite à l’incompréhension des joueurs du célèbre jeu vidéo Fortnite lors de l’événement virtuel organisé pour le nouvel an 2019,  il me semble nécessaire de rafraîchir les esprits sur les fuseaux horaires. Comme l’a tweeté Mark Rein, co-fondateur d’Epic Games, ce n’est pas une nouveauté mais, au même moment, il n’est pas la même heure […]

Cet article Les bizarreries de la carte des fuseaux horaires est apparu en premier sur Veille cartographique 2.0.

Le pôle toulousain de recherche publique en télédétection est surtout connu sur la thématique forestière grâce à la mission BIOMASS, qui sera lancée vers 2021 et qui est portée par le CESBio, mais qui concerne surtout les forêts tropicales. L’objectif de cet article est de présenter les travaux en cours sur les forêts tempérées, dans le contexte de la France métropolitaine, qui sont portées en synergie par l’UMR Dynafor (collègues INRA, Ensat et EI Purpan) et par l’UMR CESBio. En effet, 4 thèses sont actuellement en cours dont 2 qui seront soutenues fin 2019. Le point commun à ces 4 thèses comme aux travaux qui les ont précédées est l’utilisation de séries temporelles, d’abord basse résolution (Modis), puis, depuis 2015, en haute résolution spatiale avec Sentinel 1 et 2 (‘S1’ et ‘S2’).

 

Figure 1. Différences de phénologie entre espèces de chênes.

Pour mémoire, les principaux travaux ont commencé avec les données Modis suite à la sécheresse de 2003 et aux mortalités importantes de douglas et de sapins dans la Montagne Noire et les monts de Lacaune (EI Purpan). Cette thématique, en lien avec les impacts du changement climatique, a été reprise dans les années 2010-2014 dans le cadre de l’OPCC (Observatoire Pyrénéen du changement climatique) et de la thèse de Jonas Lambert (dépérissement du sapin dans les Pyrénées). D’autres travaux, toujours sur les Pyrénées, ont porté sur les aspects cartographiques des forêts (classes feuillus et résineux puis classes plus détaillées des types forestiers), soit à basse résolution spatiale Modis (cf thèse E Cano, EI de Purpan ), soit avec quelques dates d’images Landsat 5 et 7 (Cesbio).

Depuis 2016, ce sont donc les séries temporelles à haute résolution spatiale S1 et S2 qui sont à l’honneur, sur les sujets de cartographie des peuplements (différenciation des espèces) comme de l’estimation de variables de structure des forêts (hauteur, volume…), après avoir exploré également l’apport des séries FORMOSAT-2 aux caractéristiques très similaires (publication).

 

Thèse n°1. Télédétection Hypertemporelle des Essences Forestières.

Nicolas KARASIAK, Dynafor (Oct 2016 à Oct 2019).

Thèse encadrée par : Claude Monteil (Dynafor), David Sheeren (Dynafor) et Jean-François Dejoux (CESBIO). Financement Ministère (MESR).

 

L’objectif de cette thèse est de mettre au point une démarche pour classer automatiquement les essences forestières sur de grandes étendues. L’hypothèse est que les séries temporelles de Sentinel2 permettent d’appréhender les variations saisonnières de la végétation (ce qu’on appelle en botanique la phénologie) et donc, prédire les différentes espèces. Voici un exemple simple de cet apport : pour séparer les feuillus qui perdent leur feuilles à l’automne alors que les résineux restent verts toute l’année, il est préférable d’avoir des dates hivernales dans sa série temporelle d’images satellite.

Pour vérifier cette hypothèse, un important suivi de terrain a été effectué sur 2 saisons entières, dans la zone OSR / VENµS au sud-ouest de Toulouse sur 7 espèces de feuillus différents (chêne sessile, chêne rouge, saule, robinier, frêne, peuplier et bouleau ; 2 placettes par feuillus). Les différentes mesures de terrain sont analysées en relation avec les variations d’informations obtenues sur les séries de données Sentinel2. Les écarts de saisonnalité entre ces 7 espèces de feuillus ont été significatifs, ce qui permet d’évaluer l’apport de la phénologie dans la cartographie des essences. Il s’agit maintenant de comprendre jusqu’à quel point le signal reçu par le satellite est influencé par l’évolution saisonnière de l’arbre (ouverture/fermeture de la canopée, coloration et chute des feuilles). D’autres axes de recherches sont explorés dans cette thèse, comme (i) la valorisation de 9 années d’archives Formosat sur cette zone OSR (2006 à 2014) : test et analyse des stabilités de classification entre années, analyse des problèmes d’autocorrélation spatiale ; (ii) étude de la transférabilité des modèles  et de leur capacité prédictive sur de grands territoires (adaptation de domaine).

La figure 1 illustre la différence de phénologie entre deux espèces de chênes (Chêne des marais à gauche, et Chêne sessile à droite). Les écarts de phénologie peuvent être importants à certaines périodes de l'année. Ce cas concret montre la complexité de cartographier les essences depuis un satellite : parfois les écarts entre deux espèces d'un même genre sont plus importants comme c'est le cas sur ces photos qu'entre deux genres différents (un chêne et un bouleau par exemple).

 

Figure 2. Evolution de la canopée des forêts au fil de l'année.

La figure 2 illustre l’évolution de la canopée des forêts au fil de l'année. En été, elle sera la plus dense, ce qui signifie que le signal reçu par le satellite ne sera que peu ou pas affecté par le sous-bois. Cependant, au printemps ou en hiver les végétations qui se situent sous les arbres dominants seront d'autant plus visibles, ce qui signifie par exemple que les fougères ou le fragon peuvent influencer le signal de l'image.

 

Thèse n°2. Estimation et suivi de la ressource en bois en France par valorisation de séries temporelles optique et radar.

David MORIN, CESBio, (Oct 2016 à Oct 2019).

Thèse encadrée par : Gérard Dedieu et Milena Planells (CESBio).

Financement Ademe-CNES.

 

L'objectif de cette thèse est de mettre en place et évaluer une méthode pour l'estimation et la cartographie de variables de structure des forêts (biomasse, surface terrière, diamètre moyen, hauteur, densité d'arbres, etc.) avec des images satellites en libre accès ayant une couverture nationale (cf Spot6/7, Theia Geosud, France) ou globale (Alos, S1, S2). Les premiers résultats sur des plantations de pin maritime dans les Landes sont très prometteurs, avec des erreurs de 10 à 25 % selon les variables. Ces résultats sont en train d'être confirmés sur des forêts plus complexes avec des mélanges de feuillus et conifères. La chaîne de traitement est mise en place sur la base de logiciels open-source et de traitements semi-automatiques.

 

Une originalité de cette thèse est est l’utilisation combinée de de séries temporelles optique et radar (Sentinel1 et 2) et de données annuelles radar (Alos) et optique à haute résolution spatiale (Spot6 ou 7 à 1,5m ou 6 m de résolution).

	Signal	Resolution	Frequency	Coverage
ALOS-2 (JAXA)	SAR L-band	25m	Annual	Global
Sentinel-1 (ESA)	SAR C-band	10-20m	Weekly	Global
Sentinel-2 (ESA)	Optical Vis-NIR-SWIR	10-20m	Weekly	Global
Spot-6/7 (CNES)	Optical Vis-NIR	1.5-6m	Annual	France

 

De nombreuses informations peuvent être extraites à partir de ces images :

• le coefficient de rétrodiffusion radar en bande L (ALOS-2) : avec une longueur d'onde de ~27cm, les ondes traversent la canopée et fournissent des informations sur la structure des troncs et des grosses branches,
• le coefficient de rétrodiffusion radar en bande C (Sentinel-1) : avec une longueur d'onde de ~5cm, les ondes pénètrent moins dans la canopée mais donnent des informations sur la structure du houppier (feuilles et petites branches),
• les données optique (Sentinel-2 et Spot-6/7) donnent des informations sur la pigmentation des feuilles au sommet de la canopée (activité de la végétation) et son évolution dans l'année grâce aux séries temporelles de Sentinel-2,
• à partir des différentes images à 10m, 6m ou 1,5m de résolution spatiale on peut extraire des indices de structure spatiale (chaque pixel est décrit par l'organisation des pixels voisins), ce qui donne des informations sur la structure des houppiers et de la forêt.

 

L'estimation des variables de structure forestière (biomasse, surface terrière, diamètre moyen, hauteur, densité d'arbres, etc.) est basée sur des algorithmes d'apprentissage automatique entre les données de référence (mesurées sur le terrain) et les données satellitaires. La figure 1 montre la validation de ces estimations pour la surface terrière (BA basal area, Fig.1a) et le diamètre moyen à 1m30 (DBH, Fig.1b) pour différentes essences dominantes dans des forêts des Landes, d'Orléans et de Saint-Gobain (près de Compiègne).

 

(a)

(b)

Figure 1. Basal Area and DBH validation scatterplots. SVR used with features types from Sentinel-1, Sentinel-2, ALOS-PASAR and Spot-6.

 

Une fois ces modèles construits et validés, l'objectif est de spatialiser ces informations sur les forêts où nous n'avons pas de mesures. La Figure 2 montre un exemple de carte de la biomasse sur le site d'étude des Landes. Le modèle est appliqué sur les données satellitaires avec un masque « conifères » à partir de la carte Occupation du sol THEIA ‘OSO’ 2016.

Figure 2. Aboveground biomass (AGB) map covering the Landes site area. Pixel level application of the SVR (Support Vector Regression) with features types from Sentinel-1, Sentinel-2, ALOS-PASAR and Spot-6. Non coniferous pixels are masked using the 2016 land cover map (Inglada, 2016)

 

Sur les autres sites et essences, les résultats montrent que la précision est meilleure lorsqu'on différencie les essences dominantes pour construire les modèles. Une étape de classification sera donc nécessaire pour obtenir cette information et appliquer les modèles par essences. Ce travail se fera à partir des séries temporelles Sentinel-1 et Sentinel-2, avec un algorithme d'apprentissage automatique de type Random Forest. Il bénéficiera aussi des avancées de la thèse de Nicolas KARASIAK.

 

Thèse n°3. Identification et suivi des peupleraies sur de grands territoires.

Yousra HAMROUNI, DYNAFOR, (Oct 2017 à Oct 2020).

Thèse CIFRE encadrée par : Claude Monteil, Véronique Chéret et David Sheeren (Dynafor) en collaboration avec le CNPF/IDF (Eric Paillassa)

Financement Conseil National du Peuplier.

 

Le peuplier est la première essence de feuillus plantée en France. Il est exploité pour la qualité de son bois et sa croissance rapide. Actuellement, le rythme de mise à jour des données cartographiques nationales est insuffisant pour le suivi de cette ressource, le peuplier étant une essence à cycle court (15  ans). L’arrivée des satellites Sentinel-1/2 offre une bonne opportunité d’étudier les capacités de la télédétection à localiser les peupleraies et suivre leur évolution.

 

L'objectif de cette thèse est de détecter les plantations sur de grands territoires et de les caractériser (classes d’âges, phénologie). A terme, il s’agira aussi de suivre les peuplements et de détecter les coupes.

Les premiers résultats obtenus montrent une performance de classification élevée, avec une bonne capacité à transférer le modèle appris d’un site populicole à l’autre, en l’enrichissant et en l’adaptant progressivement. L’apport des données radar en complément des données optiques s’avère limité pour la détection proprement dite mais les séries Sentinel-1 devraient révéler tout leur potentiel pour  différencier les jeunes plantations des plus âgées et cartographier les coupes.

A terme, l’objectif est d’enrichir le produit annuel THEIA Occupation du sol (‘OSO’) en y ajoutant une nouvelle classe Peuplier au sein des feuillus.

 

 

Thèse n°4. Jean-Philippe Denux, EI Purpan - DYNAFOR. à venir.

 

 

Contexte de ces travaux de recherche.

L’ambition de ces thèses est de mettre au point des méthodes et des démarches reproductibles pour produire de manière spatialisée, régulière (chaque année…) et peu coûteuse (car le plus automatique possible) des couches d’information utiles (distinction des essences forestières, variables de structure des forêts…) aux scientifiques thématiciens (climat, carbone, cycle de l’eau, biodiversité, paysage...) et aux gestionnaires de la forêt. A terme, ce serait donc la possibilité de mettre à jour de nombreuses informations forestières sur tout le territoire.

Les organismes techniques et professionnels de la forêt et des scientifiques de plusieurs laboratoires ont été associés et informés par ces travaux. Plusieurs spécialistes de l’ONF, CNPF-IDF, ONF, INRA… participent aux différents comités de pilotage de ces 4 thèses.

Les liens avec les organismes sont divers. Outre la définition des sujets et des problématiques, et l’apport d’expertises, ces organismes peuvent largement aider ces travaux en fournissant des données de terrain géoréférencées. Ce point constitue souvent un verrou crucial. La filière peuplier d’une part, l’INRA de Bordeaux et l’ONF ont été les principaux contributeurs en données de références terrain et nous les remercions vivement. Après ces thèses, la possibilité de disposer des données des placettes IFN-IGN sera particulièrement utile pour poursuivre et valider ces travaux.

Ces travaux ont aussi de nombreux liens avec les CES et produits THEIA (réflectances, ‘OSO’ Occupation du sol, Forêts bien sûr, humidité des sols, etc…), comme utilisateurs de produits THEIA mais aussi de par les perspectives d’amélioration des produits actuels ou futurs ‘(‘OSO’ Occupation du sol, biomasse des Forêts…). Ces résultats pourront peut-être aussi aider à certaines productions comme la production de la base de données des forêts v2 gérée par l’IGN.

 

Au moins 2 publications sont prévues dans chaque thèse ; les 1ères publications vont être soumises en février ou mars 2019. Les soutenances des 2 premières thèses auront lieu fin 2019 à Toulouse. Afin de favoriser la diffusion des résultats, il est envisagé d’organiser une journée de valorisation/transfert fin 2019 ou début 2020 dans le cadre de l’ART Occitanie. De plus, CESBio et Dynafor souhaitent continuer cette dynamique de recherche par de nouveaux projets ou thèses.

 

Petite question sur ISO 19115 et 19139 : est-ce que ces standards sont compatibles avec la Loi pour une République numérique ?

Cette dernière demande aux administrations publiques d’utiliser des formats ouverts et facilement réutilisables.

ISO 19115 est un standard payant (198 francs suisses). Pas super ouvert ça !

Si ISO 19139 était facilement réutilisable nous n’aurions investi autant de temps et d’argent à nous réunir en commissions pour comprendre ISO 19139, pour faire des choix sur telle ou telle option de ce standard pour encoder telle ou telle information (ne serait-ce que le choix de tel ou tel type de structure pour encoder un identifiant par exemple) sachant pertinemment que ces choix sont parfaitement incompréhensibles par le commun des géomaticiens, pour développer et mettre à jour GéoSource, pour sensibiliser, former et reformer les administrateurs de données géographiques et pour, finalement, arriver toujours au même constat : ça ne marche pas. Si ISO 19139 était facilement réutilisable on devrait trouver un quelques clics sur la toile quelques tutos pour faire ses métadonnées en deux coups de cuillère à pot. Les problèmes d’interopérabilité récurrents entre catalogues et applications clientes sont pour l’essentiel dus à la complexité de son modèle et sa capacité à encoder une même information de multiples manières. Problème déjà rencontré avec GML (dont ISO 19139 reprend une partie). Je vous encourage d’ailleurs à (re)lire l’article d’Even Rouault qui illustre très bien la complexité de la chose. Autre exemple de la complexité d’ISO 19139 : lisez le chapitre du guide du CNIG (auquel j’ai contribué) consacré aux contraintes légales (à comparer aux attendus du modèle DCAT en la matière par exemple).

J’ai tendance à penser qu’aucune des conditions requises par la Loi pour une République numérique concernant les caractéristiques des formats à utiliser n’est remplie par ISO 19115/19139…

=>

​Sentinel-1 est actuellement le seul système à fournir des images SAR régulièrement sur toutes les terres de la planète. L'accès à ces séries temporelles d'images ouvre un champ d'application hors du commun.

Afin de répondre aux besoins d'un grand nombre d'utilisateurs, dont les nôtres, nous avons créé une chaîne de traitement automatique permettant de générer des séries temporelles "prêtes à l'emploi" pour un très grand nombre d'applications. Les données Sentinel-1 sont ortho-rectifiées sur la grille Sentinel-2 pour favoriser l'usage conjoint des deux missions.

 

 

S1Tiling a été développé au sein du service radar du CNES, en collaboration avec le CESBIO, pour générer des séries temporelles d'images Sentinel-1 calibrées, ortho-rectifiées et filtrées, sur n'importe quelle région terrestre de la Terre. Il s'appuie sur l'application d'ortho-rectification d'images radar de l'Orfeo Tool Box. Les images obtenues sont superposables aux images optiques Sentinel-2, car elles utilisent le même référentiel géographique MGRS. Vous pourrez donc accéder aux données Sentinel-1 acquises sur les tuiles Sentinel-2 31TCJ ou 11SPC.

 

Ce logiciel, écrit en Python, s'appuie sur la librairie de traitement d'images Orfeo Tool Box (OTB), développée par le CNES, ainsi que sur la plate-forme PEPS pour l'accès aux données Sentinel-1. Il est utilisable sur tout type de plate-forme, allant du grand cluster de calcul au PC portable (dont le ventilateur fera un peu de bruit à l'occasion du traitement). Il est considérablement plus rapide que l'outil analogue existant dans SNAP, et peut être facilement utilisé  sous la forme de script.  Pour toute question, merci d'utiliser la plateforme gitlab, plutôt que de laisser des commentaires en dessous de cet article.

S1-Tiling travaille en plusieurs étapes : il commence par télécharger les images sur le miroir PEPS des données Copernicus, puis il les étalonne et les ortho-rectifie sur la grille Sentinel-2, et enfin applique un filtrage multi-temporel du bruit de speckle.

S1Tiling est actuellement utilisé pour de nombreuses applications, comme par exemple la détection de la déforestation en Amazonie, le suivi des cultures de riz en Asie du Sud-Est ou la surveillance des stocks d'eau en Inde.

De plus, cette chaîne est accessible en tant que service de traitement à la demande sur le segment sol collaboratif Français PEPS, afin d'en faciliter l'usage aux utilisateurs.

 

Utilisation dans PEPS

Si vous êtes allergique aux lignes de commande (c'est bien dommage), vous pouvez utiliser les fonctions de traitement à la demande de PEPS. La version sur PEPS n'inclut pas encore le filtrage du speckle, mais le travail est en cours. C'est tout simple à utiliser :

1. Vous vous connectez sur PEPS ( [https:]] )
2. Vous choisissez la fonction explorer
3. Vous cherchez les images à télécharger avec les critères explicités dans l'image jointe (spécifiez bien le niveau de produit GRD, et Sentinel-1). Pour chaque produit qui vous intéresse, vous cliquez sur l’icône avec les engrenages
4. Vous allez dans la fonction traitements (avec les engrenages, en haut à droite)
5. Vous choisissez votre traitement
6. Vous cliquez sur chaque produit à traiter et vous lancez le traitement
7. Il n'y a plus qu'à attendre et à télécharger.

 

With this final article, we get to the end of this
series. After setting up the Postgres / Postgis database, we
configured Geoserver to assist the results of pgrouting into a WMS lux.
All that’s left doing, is to   create
an html page with openlayers to be able to enter the starting and ending points
and to view the calculated route.

Obviously there is a way to execute a complex application.
But here we will remain on something quite modest.
We will display an OpenStreetMap basemap, and allow the user
to click on this map to define the starting point. When a
second point is clicked, it is considered to be the desired point of arrival.
The page sends the request to the Geoserver WMS stream to
retrieve a vector feature representing the calculated route by pgrouting
  and, finally, we will post it on the map.

To conclude, we will add a button to reset the map, a message
line to keep up-dated the current user, and an image to indicate the status of
the transfer between the server and the application.

 Text of the html page

Let’s take
a closer look into the different parts of the code.

Regarding the first, as the classic:

< style >
#map {
width: 100%;
height: 800px;}

We define  the map size
on our page: it will occupy the full width of the page and will be 800 pixels height.

<div id = « map
« > </ Div>
<div id = « desc
> Click on the map to set the starting point – click
again to set the end point – the route will be plotted </ div>

<div align = ‘center
»> <Img src = « 0.png
»Id = « picture
»Width = »60″
height = « 60 »> </ div>

<button id = »clear
« > Clear </ button>

We insert the div of the map, below a line of text will be
used as a message area, and an image to indicate the transfer status and below
a Clear button that will reset the page. The
image 0.png is an empty image.

We find the reference at the openlayers library used:

<script src = « [openlayers.org]
« > </ Script>

and then the creation of our map:

var map = new ol.Map ({
target: ‘map’,

layers: [
new ol.layer.Tile ({
source:
new ol.source.OSM ()})],
view: new ol.View ({

center: [-500000, 6172000],

zoom: 12}),

controls: ol.control.defaults
({
attributionOptions: {

collapsible:
false }
})});

We load the OpenStreetMaps layer in our map, center the
display on the EPSG coordinates: 3857 from the center of our area of ​​interest,
define the range displayed initially with the zoom factor (12) and finally the
desired controls .

The rest of the code refers to the points of departure and
arrival.

We create two features to accept these points

// The points of departure and arrival.

var startPoint = new ol.Feature ();

var destPoint = new ol.Feature ();

Then, we define a vector layer to display the points

// The vector layer used to display start and end
points .
var vectorLayer = new ol.layer.Vector ({

source: new ol.source.Vector ({
features: [startPoint, destPoint]})
});

map.addLayer ( vectorLayer);

We create a params variable with some fixed parameters of our
request being sent to Geoserver, the name of the Geoserver layer to query and
the desired format to receive the result.

var params = {
LAYERS: ‘pgrouting: itinerary’,
FORMAT: ‘image / png’
};

Then, we release a function of coordinates transformations.
OpenStreetMap works in spherical Pseudo-Mercator coordinates
(EPSG : 3857 ). But our PostGis data is in
geographic coordinates (EPSG : 4326 ).

When we get the click on the map, the coordinates will be
3857. We will have to transform to 4326 before sending the
request to Geoserver.
//
The coordinate transformation function from the EPSG: 3857

// towards EPSG:
4326 .
var transform = ol.proj.getTransform (‘EPSG:
3857′, ‘EPSG: 4326’);

Now we set up the event listening the click in our map.
This
part of the code will be activated when the user clicks on the map.

// Set up a listening on the events of the card.

map.on ( ‘click’, function (event) {

When the start point is empty, it indicates that this is the
first click on the map and that it is the starting point that must be filled in.

if (startPoint.getGeometry () == null) {

// First click.
startPoint.setGeometry ( new ol.geom.Point
(event.coordinate));

If, on the other hand, the start point has already been renamed,
we are in the presence of the second click. Therefore,
we will inform the destPoint:
} else if (destPoint.getGeometry () == null) {

// Second click.
destPoint.setGeometry ( new ol.geom.Point (event.coordinate));

And we go straight to the process of submitting the request
to Geoserver.

We transform the coordinates of the two clicked points:

// Transformations of coordinates from that of the map
(EPSG: 3857)
// to that of the server (EPSG: 4326).

var startCoord = transform
(startPoint.getGeometry (). getCoordinates ());
var destCoord = transform (destPoint.getGeometry ().
getCoordinates ());

and we build the string with the parameters x1, y1, x2 and y2
needed by our Geoserver layer (see previous article)
var viewparams = [
‘x1:’ + startCoord [0], ‘y1:’ + startCoord [1],

‘x2:’ + destCoord [0], ‘y2:’ + destCoord [1]

];

Now, we have all the necessary elements to build the message
to be sent to Geoserver. We add this message in a variable
source.

params.viewparams = viewparams.join ( ‘;’);

var source = new ol.source.ImageWMS ({

url: &lsquo [http:] // localhost: 8080 / geoserver / pgrouting /
wms’,
params: params

And we send the request to Geoserver asking to add the result
in a new Image layer (we have asked the return as a png image a little higher)
to be displayed in our map

result = new ol.layer.Image ({
source: source

Since the query is not instantaneous, it is better to keep
the user informed of what is happening without forcing him to stay in front of
a seemingly frozen screen.

The following lines display a message text and an image
showing that the request is in progress, and when the transfer is complete,
indicating whether it has been successful or not.

source.on ( ‘imageloadstart’, function () {

document.getElementById ( ‘
desc « )
.InnerHTML = « loading…
« ;
document.getElementById ( ‘
picture « )
.Src = « tree_loading.gif
« ;
});
source.on (‘imageloadend’, function () {

document.getElementById ( ‘
desc « )
.InnerHTML = »Finished OK!
« ;
document.getElementById ( ‘
picture « )
.Src = « OK.jpg
« ;
});
source.on (‘imageloaderror’, function () {

document.getElementById ( ‘
desc « )
.InnerHTML = « fault!
« ;
document.getElementById ( ‘
picture « )
.Src = « no.png
« ;
});

We load the layer in our map:

map.addLayer ( result);

Finally, we process the click with the Clear button:

var clearButton = document.getElementById (‘clear’);

clearButton.addEventListener (‘click’, function (event) {

// Reset the entities « 
start »And«
destination ».

startPoint.setGeometry ( null);

destPoint.setGeometry (null);
document.getElementById ( ‘
desc « )
.InnerHTML = Click on the map to set the
starting point – click again to set the finishing point – the route will be
drawn « ;
document.getElementById ( ‘
picture « )
.Src = « 0.png
« ;
// Remove the result layer.
map.removeLayer ( result);
});

By emptying the startPoint and destPoint entities , by adding
the homepage and the blank image blank and deleting the vector layer contained
in the previous route.

We can open this page in our browser and see the application operate:

We can open this page in our navigator and see the application.

Cet article Comment cartographier l’environnement écologique « biodiversité » dans les projets urbains? est apparu en premier sur Veille cartographique 2.0.

L’étendue des sciences en lien avec l’écologie L’écologie est un terme assez contemporain qui renvoie à l’étude d’une espèce quelconque dans son milieu naturel. Dans une perception large c’est la science des conditions d’existences. Le philosophe allemand pro-darwiniste Ernst Haeckel en 1865 décrit l’écologie comme «  l’étude de l’interaction entre les organismes vivants et leur […]

Cet article Comment cartographier l’environnement écologique « biodiversité » dans les projets urbains? est apparu en premier sur Veille cartographique 2.0.

Cet article The use of GIS as a countermeasure against terrorist bomb attacks est apparu en premier sur Veille cartographique 2.0.

In the case of a bombing attack, software can help to identify vulnerable places, analyze the threat, simulate an attack, evaluate the damage caused by a bomb, specify evacuation measures or rescue organizations, and also mitigate damage. The type of software used is mainly GIS. The identification of vulnerability requires the collection of several types […]

Cet article The use of GIS as a countermeasure against terrorist bomb attacks est apparu en premier sur Veille cartographique 2.0.

Cet article Une cartographie des loyers parisiens selon les stations de RER est apparu en premier sur Veille cartographique 2.0.

L’accessibilité aux transports en commun détient une place importante sur la variabilité du prix de l’immobilier. Après l’édition de sa carte des valeurs locatives de bureaux par station de métro à Paris (4ème édition en juillet 2018), le cabinet de conseil en immobilier d’entreprise Cushman & Wakefield publie pour la 2ème fois la carte des valeurs […]

Cet article Une cartographie des loyers parisiens selon les stations de RER est apparu en premier sur Veille cartographique 2.0.

Cet article The « Shazam » of plants and animals est apparu en premier sur Veille cartographique 2.0.

 Who, during a walk, has never wondered about the name of a certain flower, a certain grass, a certain tree? Today, the answer is in your pocket, or rather in your phone. It’s possible to do almost anything with a smartphone: call, send emails, surf the net, play… Now you can also identify plants, flowers […]

Cet article The « Shazam » of plants and animals est apparu en premier sur Veille cartographique 2.0.

Cet article vGIS Utilities : une application innovante est apparu en premier sur Veille cartographique 2.0.

VGIS Utilities correspond à une application de réalité augmentée qui permet de visualiser des réseaux de canalisations situées sous terre.

Cet article vGIS Utilities : une application innovante est apparu en premier sur Veille cartographique 2.0.

We have discussed in previous articles how to set up the network data
for pgrouting and how to develop a wrapper to search the route between two
points.

Here we will discuss how to set up Geoserver to provide the result of
the wrapper as a WMS or WFS layer to be used in a web page using OpenLayers 3
(next article) .Among all the Postgres / Postgis / Geoserver / OpenLayers
chain, this part is, still, the simplest. We simply have to set up a Workspace,
a   Data Warehouse, and a layer using the wrapper SQL query developed in
the previous article.

Setting up a workspace

For the entire Geoserver setting up, you must log in as administrator to
the administration interface.

Once logged in, click Workspaces in the Data
module (left menu) and click Add New Workspace.

Fill in the two fields with a name for the workspace (here pgrouting)
and the domain address [pgrouting.org),] then click the Send
button .

Setting up a data warehouse

Click Warehouses in the Data module on the left menu and
click Add New Warehouse.

On the list of Vector data sources, select PostGIS

The warehouse configuration page opens  

In the workspaces list select the workspace that has just been created:
pgrouting, and give a name to your data source (here itineraries ).

Fill in the correct connection details for your Postgres database: the
database is the name of your Postgres database containing the network tables, a
username and login password. Avoid using the postgres username for obvious
security reasons. Create a username with rights only on the data necessary for
your application.

The rest of the information can be left the same.

Click the Save button . You will have the
configuration page of a new layer.  

Click
on Configure a new SQL view

Assign a name to the display and enter the last sql query that we tested
in the previous article:

SELECT ST_MakeLine (route.geom) FROM (SELECT geom
FROM pgr_route_entreAetB (‘ways’,% x1%,% y1%,% x2%,% y2%) ORDER BY seq) AS
route

But at this stage you do not need to enter true coordinate values: we
replace them with variables. The values ​​of these variables will be WMS or WFS
parameters that will be received.

In SQL View Settings, click Guess
Settings From SQL .  

You must enter default values. They will be used in case of request
without coordinates.

Enter the following string   ^ -? [\ d.] + $ in Regular
Validation Expression. The user will,only, be entitled to enter numbers in
the variables.

In Attributes , click Refresh .

Modify the geometry type to match the geometry returned by the sql query
(in this case a LineString) as well as the return SRID (here 4326).

Click Save .

It only remains to set up the rest of the parameters for the layer. In
our case it is enough to make sure that the native SRIDs and data are the needed
for our application.

For native SRID, as explained when setting up
the network tables, pgrouting works exclusively in 4326 (latitude / longitude).
On the other hand, in our WEB page (which we have not discussed yet) we will
use OpenStreetMap as a base map. Therefore, we need to set up the Geoserver
output in EPSG: 3857 (the SRID used by OSM).

Do not forget to change CRS management into a CRR re-projecter
from native to the CRS stated .

Click Emprises -> Based on Data and   Calculated
on native emprises to complete the layer configuration.

Click Save .

Make sure you have everything set up by clicking
Layer Preview and selecting OpenLayers. You must get the route between the
points you entered as default points:  

You have completed the Geoserver setting up.

You may have heard about the tailings dam collapse at Feijão mine in Brumadinho, Brazil. The disaster occurred two days ago on Jan 25 and at least 58 people were found dead, while 300 are still missing. A Sentinel-2 acquisition was planned for today, therefore tonight I checked the EO Browser to see if the mud flow was visible.

Before/after images of Brumadinho mudflow from Sentinel2 imagery (false color composite using the near-infrared band)

Bingo! I just needed to tinker a bit with QGIS to get an independent estimate of the mudflow area... From the EO Browser I downloaded the near-infrared band of the two above images, because the near-infrared band makes it easy to distinguish the vegetation from other surfaces and I computed the normalized difference: (Before-After)/(Before+After).

Normalized difference of the NIR bands of Jan 07 and Jan 27 images (band 8)

I converted this grayscale image to a binary image using a threshold of 0.2, vectorized the result and manually edited the polygon especially in the lower part of the deposit where a thin cloud cover dampens the contrast between both images. Then I displayed the polygon over the Openstreetmap layer... This is when I noticed that the mudflow deposit was already present in Openstreetmap!

Openstreetmap snapshot near Brumadinho on 27 Jan 2019

Using the QuickOSM plugin for QGIS, I downloaded the OSM vector data and extracted the "mudflow" polygon. Its attribute table indicates: "source:image: Sentinel Satellite S2-L1C 2019-01-27 at sentinel-hub.com". Its area is 2.9778 sq. km. My polygon has an area of 2.9585 sq. km.

The extent of the Brumadinho mudlfow by myself and from OSM

It means that someone, somewhere, has updated OSM using today's Sentinel-2 image... That's an impressive example of how open data like Sentinel-2/Copernicus data can serve collaborative projects and emergency mapping.

Oh by the way! This is how it looks in Google Maps:

Google Maps snapshot near Brumadinho on 27 Jan 2019

Here in southwest France ski lovers did not really enjoy the beginning of the snow season... But how does it compare to the previous years? Using Sentinel-2 and Landsat-8 data, we computed the snow cover duration since September 01 until January 20 for the past three snow seasons in the Alps and Pyrenees.

Snow cover duration (in days) from 01 September of year N-1 to 20 January of year N

On January 04, Météo-France reported that "the snow cover was very deficient for the season in the Pyrenees. The lack of snow at 1,500 meters is not unusual in early January, as recently observed in 2017 or 2016. The lack of high altitude snow is rather more remarkable, as the value of 42 cm measured at the Lake of Nivôse station d'Ardiden (Haute-Bigorre, 2445 m) is the lowest since 1996, previous record of 48 cm in January 2016."

Indeed we can see that the snow cover duration patterns are similar in 2017 and 2019, with lower values in the high elevation areas in 2019.

 
In the Alps the beginning of the snow season was less sad. In fact, the snow conditions were close to the normal according to Météo-France, but still far from those of the exceptional winter 2017-2018. Some artifacts are visible in the 2018 map. In particular the snow near the Pô valley in the southwestern corner of the pictures is an artifact due to snow-cloud confusions in this area (we will try to fix this in the future).

However things are changing fast... Since January 20 the snow just kept on falling in the Pyrenees!
Edit on 26 Jan: a clear-sky Sentinel-2 image was acquired today

Après les chutes de #neige très importantes de cette semaine dans les #Pyrénées !! via satellite #sentinel2 pic.twitter.com/PYqZqjiskg

— Meteos (@Meteos_) January 26, 2019

pgRouting includes a
function
called
pgr_drivingDistance
, that, together with three others functions , pgr_withPointsDD
, pgr_alphaShape and pgr_pointsAsPolygon , can be used to establish which
paths
have
a certain cost versus a starting or arrival
point .

The area surrounding these paths
is
designated
as
a
catchment area . pgr_drivingDistance , in
conjunction
with pgr_pointsAsPolygon is often
used
to determine coverage requirements for a service or to determine optimal
locations for new facilities.

For example , if you have
a
fire
station, you must determine
all
parts of the city that can be reached
within five minutes. A reverse
problem would be to find all parts of the city
where
the residents could drive
to
a hospital within five minutes.

The
function that calculates the paths for both problems
is
called
pgr_drivingDistance
because it is often used
when
the cost is measured as driving
time . However, the costs are not necessarily
  limited to a time or a
distance.
For
this type of application , knowing all routes towards
or
from a given point is not very useful.  It
is here where the functions   pgr _alphaShape and
pgr_pointsAsPolygon come into play. The
pgr_alphaShape use as input a set of x, y
coordinates and returns a set of x, y which correspond to the vertices of a
polygon that includes all the input points.
pgr_pointsAsPolygon
is
similar
to pgr_alphaShape , it uses as input a set of coordinates x, y, but instead of
returning another
series
of points, returns a polygon   that  surrounds all input
points . Internally, it uses the pgr_alphaShape function .

Using pgr_drivingDistance

Let’s take the case of a
fire
station and search the area covered in 5 minutes. The
order sql corresponding to these
criteria
can be translated by the following:

SELECT * FROM pgr_drivingDistance
(‘SELECT gid as id, source, target, cost_s
as cost, reverse_cost_s as reverse_cost
FROM public.ways ‘, 25736, 300, true)

In the SELECT clause we use
the cost of a section in
seconds
(cost_s), and indicate the reverse_cost_s because even fire trucks cannot drive
against traffic. 25736 is
the node corresponding to the fire station, 300
is
the forecasted cost (5 minutes x 60 seconds ), and the true
value indicates that the graph is
directional
(takes into account the forbidden driving
sense ).

The result of the query returns
6948 nodes that are in within
5 minutes from the fire station. By cons the result of the query
having
no geometry , we can not visualize them in QGis.

You have to modify the query as
follows:

SELECT * FROM pgr_drivingDistance
(‘SELECT gid as id, source, target, cost_s
as cost, reverse_cost_s as reverse_cost
FROM public.ways ‘, 25736, 300, true) as JOIN
ways_vertices_pgr on di.node = ways_vertices_pgr.id

We perform a join with the node table (
ways_vertices_pgr ) and the result of the query includes
the geometries :   

We can see the
result in QGis:

How to create
the
catchment
area
with
pgr_pointsAsPolygon

To create the catchment area, we use
the former query as sql
of the function pgr_pointsAsPolygon , by
creating
a polygon in output that we can load in QGis:
SELECT 1 As id,ST_SetSRID(pgr_pointsAsPolygon(
$$ SELECTdi.seqAS id, ST_X
(v.the_geom) AS x, ST_Y (v.the_geom) As y
FROMpgr_drivingDistance(SELECTgidAs id, source, target,
cost_sAS cost,reverse_cost_sASreverse_cost
FROMpublic.ways», 25736, 300, true
) AS di INNER JOINpublic.ways_vertices_pgrAS v ONdi.node= v.id $$
), 4326) Asgeom;

pgr_pointAsPolygon uses the id, x, and y points
generated by pgr_drivingDistance . For x
and y we use the functions St_x and St_y on the points geometry.

Once loaded in QGis, the
result is as follows :   

How to create the
isochrones

The isochrones correspond to the reachable areas
in
a
series
of time steps. We could , in this
example
, want to know which are
the areas we can reach
in
1, 2, 3, 4 and 5 minutes.

Therefore we will proceed in
two
steps
.

The first one, is to create a
table with our nodes resulting
from pgr_drivingDistance for the fastest time step (5 minutes). Logically
, in this table it will, also, be found the nodes
reachable
in
the shortest periods of time.

We create this table ( dd_caserne )
with the following sql command  :

CREATE TABLE dd_caserne AS

SELECT di.seq As id,
di.node , di.edge ,

di.agg_cost As time_access
, v.the_geom As geom

FROM pgr_drivingDistance (SELECT
gid As id, source, target,
cost_s AS cost, reverse_cost_s
AS reverse_cost
FROM public.ways’, 25736, 300, true

) AS di INNER JOIN public.ways_vertices_pgr
AS v ON di.node = v.id;

The resulting table is the following :

Based on this table we will build
a
series
of polygons with pgr_pointsAsPolygon for points at 60, 120 180 240 and 300
seconds of access time by using generate_series
SELECTiAstime_access,
ST_SetSRID(pgr_pointsAsPolygon(
‘SELECT id, ST_X (geom) AS
x, ST_Y (geom) As y
FROMdd_caserne
WHEREaccess_time<= ‘||i :: text), 4326) Asgeom
FROMgenerate_series(60,300,60)
Asi
ORDER BYiDESC

The
result includes
the 5 isochrones polygons , which we can, now,
display
in
QGis:

Cet article Cartographie des revenus des ménages américains est apparu en premier sur Veille cartographique 2.0.

L’une des problématiques cristallisant à la fois des enjeux politiques, économiques et sociales, concerne le revenue perçue par les habitants. Aux États-Unis (à l’image d’autres États dans le monde), les américains font face à une disparité dans la perception des revenus et il a été même constaté une augmentation croissante de cette inégalité depuis plusieurs […]

Cet article Cartographie des revenus des ménages américains est apparu en premier sur Veille cartographique 2.0.

Cet article Zanzibar: a new experience for drones, mapping and risk management est apparu en premier sur Veille cartographique 2.0.

With the help of drones' imagery, the Tanzanian archipelago of Zanzibar is building a new type of land.

Cet article Zanzibar: a new experience for drones, mapping and risk management est apparu en premier sur Veille cartographique 2.0.

Cet article La Blockchain – Une technologie qui peut changer monde SIG est apparu en premier sur Veille cartographique 2.0.

Blockchain – Chaîne de blocs en français La blockchain est un technologie, qui permet tout simplement le stockage et la transmission de différents types d’information. Cela en toute sécurité et sans aucun intermédiaire. Elle se définit par extension, comme un registre dématérialisé, qui contient l’histoire de tous les échanges et les transactions effectuées entre ses […]

Cet article La Blockchain – Une technologie qui peut changer monde SIG est apparu en premier sur Veille cartographique 2.0.

Camarades cartographes, vous qui connaissez sur le bout des doigts la sémiologie graphique de Jacques Bertin, vous le savez pertinemment, la seule variable visuelle permettant de retranscrire visuellement des données quantitatives absolues est la variable visuelle Taille. En d’autres termes, s’il ne fallait retenir qu’une règle et une seule, elle s’énoncerait un peu caricaturalement de la façon suivante : Pas de stocks en aplat. Simple. Basique.

Ce principe est d’ailleurs unanimement admis. Tous les cartographes utilisent cette règle de base de façon stricte, tous les étudiants en géographie l’apprennent et se font taper sur les doigts s’ils y dérogent. En définitive, rares sont les MapFails, les FakeViz, les Cartox, c’est à dire les cartes qui n’appliquent à ce principe simple. Pas de stocks en aplat, c’est le B.A.BA de la cartographie pour les données quantitatives.

Mais la raison de cette règle est-elle vraiment comprise ? Que se passerait-il vraiment si on cartographiait des données quantitatives absolues avec des aplats de couleurs ? La carte serait-elle fausse ? Pour y voir plus clair, voici deux cartes sur la population des communes françaises réalisées rapidement avec le logiciel en ligne Magrit [voir].

Et si on essayait les stocks en aplat ?

Voici une carte de la population (nombre d’habitants = donnée quantitative absolue) à l’échelle des communes françaises représentée sous forme de carte choroplèthe. Ici, la variable visuelle utilisée est la valeur (dégradé de rouge). Question : cette carte est-elle fausse ? Non, cette carte n’est pas fausse. Mais…

Carte 1 : Des stocks en aplat, une bonne idée ?

Mais, elle ne permet pas de retranscrire toutes les relations contenues dans les données quantitatives absolues qui, je le rappelle, sont les suivantes : association, sélection, ordre et proportion.

Sur cette carte, on peut distinguer les communes qui sont dans des classes de population différentes (sélection) et associer 2 communes qui se situent dans la même classe (association). De plus, on peut également repérer ou sont les communes les plus peuplées et les communes les moins peuplées (ordre). Par contre, du fait de la sémiologie graphique utilisée, la carte ne permet pas de rendre compte des quantités (ou proportions). Cela, seule la variable visuelle Taille permet de le faire. Cette carte n’est donc pas fausse, mais elle n’exploite pas la totalité des relations contenues dans les données quantitatives absolues. Elle est donc sous opérante. En résumé, on peut mieux faire…

Passons aux symboles proportionnels

Reproduisons la carte avec avec l’utilisation de figurés proportionnels (variable visuelle Taille).

Carte 2 : Une image pertinente de l’espace géographique

La différence avec la carte précédente est flagrante. Ici, les surfaces des cercles sont toutes différentes. Certains sont très gros, et d’autres très petits, presque imperceptibles. Sur cette carte, la surface de chaque cercle est directement proportionnelle au nombre d’habitant. C’est cela l’expression graphique de la relation de proportion. Et de ce fait, une organisation géographique se dégage nettement. Les grandes villes jaillissent et sautent aux yeux, tout autant que les espaces vides peu densément peuplés. Grace à un bonne usage de la sémiologie graphique adapté aux données représentées, nous avons sous les yeux une image pertinente de l’espace géographique français. Une carte éloquente qui raconte correctement le territoire.

Que retenir ?

En résumé, la sémiologie graphique, ce n’est rien d’autre que du pragmatisme. Faire une bonne carte, c’est se demander comment exploiter au mieux les données, les rendre visibles efficacement pour simplifier le plus possible la vie du lecteur de carte sans l’induire en erreur. Donc si vous pouviez éviter les stocks en aplat, ca rendrait un grand service à tout le monde et ca permettrait à vos cartes de révéler le territoire… A bon entendeur

Nicolas Lambert

More Posts

Follow Me:

The pgrouting extension offers various algorithms to find the best
route: Dijkstra, A *, Ksp, Trsp, …

In this article we will discuss in detail the use of a * (A-star).

We will continue to use the database and tools described in the previous
article (How to develop an application with pgrouting inWindows (1)).

The algorithm A * is a path search algorithm in a graph between an
initial node and an end node. It uses a heuristic evaluation on each node to
estimate the best path passing through it, and then visits the nodes according
to their order in this heuristic evaluation.

Together with the Dijkstra’s algorithm, these are the most used
algorithms for calculating the shortest path between two points of a linear
network.

Request A *

The syntax of the A * algorithm is as follows:

pgr_astar ( sql text, source integer, target
integer, directed boolean, has_rcost boolean);

Where source is the desired departure point of the route, target
the end point of the route and the sql chain is of the following type:

SELECT id, source, target, cost, x1, y1, x2, y2 [, reverse_cost] FROM
network

We will discuss later the two Boolean variables and their use.

The command returns a pgr_costResult element that includes
(seq, id1, id2, cost), where seq is the order of the section in
the route, id1 the starting point of the section, id2
the point of arrival of the section and cost the cost associated
with this stretch.

Preparation of the database

Unlike other pgrouting algorithms, to use A * you must add, if
necessary, the latitude / longitude coordinates of the beginning and end nodes
of each section.

If you followed the creation of the database in
the previous article by importing OpenStreeMap data with osm2pgrouting, you
have nothing to do because this program generates the fields x1, y1, x2, y2 needed
for method A *   

If these fields are not present in your network layer, you will have to
create them.

But, firstly, you have to check the type of
geometry of your network. In pgAdmin III, select the geometry field of your
table:  

Problem: MultiLineString geometry or LineString?

You can find two types of geometry: LineString and MultiLineString. Commands
used to compute node coordinates only work with LineString geometries. If you
have a MultiLineString geometry, not a chance!. You will not get an error
message, but your columns will remain desperately empty.

This is particularly silly since you have 99.99% probability of not
really having a MultiLine String geometry! If you use the PostGis Shapefile
utility and DBF loader, you will have this type of geometry by default, even if
your data is LineString.

SOLUTION:

Test the geometry to verify that it is not necessarily MultiLineString
with the following SQL command SELECT COUNT (
CASE WHEN ST_NumGeometries (the_geom)> 1 THEN 1 END
) AS multi, COUNT (the_geom) AS total
FROM ways;

If the result of Multi is 0 , you do not have multilines and you
can change the geometry type to LineString with the SQL command

ALTER TABLE ways
ALTER COLUMN the_geom geometry TYPE (LineString, 4326)
USING ST_GeometryN (the_geom, 1);

Now you can create the fields x1, y1, x2, y2 with the following sql
commands:

ALTER TABLE ways COLUMN ADD x1 double precision;
ALTER TABLE ways ADD COLUMN y1 double precision;
ALTER TABLE ways ADD COLUMN x2 double precision;
ALTER TABLE ways ADD COLUMN y2 double precision;

UPDATE ways SET x1 = ST_x (ST_PointN (the_geom,
1));
UPDATE ways SET y1 = ST_y (ST_PointN (the_geom, 1)); UPDATE ways SET x2 = ST_x (ST_PointN (the_geom,
ST_NumPoints (the_geom)));
UPDATE ways SET y2 = ST_y (ST_PointN (the_geom, ST_NumPoints (the_geom)));

Problem: choosing the “cost” of a section.

The routing algorithm looks for the path with the lowest cost. Depending
on your goals, you have to decide which cost item you will support.

Let’s take our OpenStreetMap database. You have a field   “cost”
  that gets back the length of the section in degrees. If you use this
field in the A * algorithm as the cost value, the proposed route will be the
shortest path between the two chosen points. Let’s see an example.

The following command calculates the route between points 69072 and
64204 using the “cost”   that corresponds to the length of the section. SELECT seq, id1 AS node, id2 AS edge, di.cost,
the_geom
FROM pgr_astar (
‘SELECT gid as id, source :: integer, target :: integer, cost :: double
precision, x1, y1, x2, y2 FROM public.ways’,
69072, 64204, false, false
) as di
JOIN public.ways ways_vertices_pgr
ON di.id2 = ways_vertices_pgr.gid;

Once
loaded into QGis, the result is as follows:   

On foot, it’s the best route. But by car we would never take it! Small
streets with 30km / h zones instead of a 110km / h fast track…

In the OSM table you find another field, called cost_s. This is the
result of calculating the travel time in seconds, by using the length and speed
allowed for each section.

If you modify the sql query to use this field: SELECT seq, id1 AS node, id2 AS edge, di.cost,
the_geom
FROM pgr_astar (
‘SELECT gid as id, source :: integer, target :: integer, cost_s :: double
precision as cost, x1, y1, x2, y2 FROM public.ways’,
69072, 64204, false, false
) as di
JOIN public.ways ways_vertices_pgr
ON di.id2 = ways_vertices_pgr.gid;

Once
loaded in QGis, the result is the following (red line)

Problem: cost_s has null values

There is a good chance that the last SQL query will return an error
saying that cost_s has null values.

This is because the field that is used by osm2pgrouting to calculate the
cost in seconds is the length of the section in m (length_m), and this field is
not always filled in.

SOLUTION:

After loading the ways layer , select Project-> project
properties-> SCR with QGis.

Check the Projection on the fly box and select a flat
projection, Lambert 95 for example.

Open the attributes table of ways , pass the table in edit
mode.

Select all records with zero cost_s

You
will notice that the selected records have a zero length_m  as well.  

Using
the field calculator check the box Update an existing field ,
select the field lenght_m and in Expression type $
length

This will inform the field the length of the section, calculated
according the current QGis coordinate system (lambert95 for example).

Now you can update the cost_s field with the expression ( ‘length_m« *
3600) / (« maxspeed_forward*
1000)

Problem: The route works in the opposite direction

With the queries used so far, you can get
results such as the following:

The calculated route suggests you to get out of the fast lane and follow
it in the opposite direction!

In the OSM data, a oneway field indicates, if it is equal to 1, that the section has only one direction of travel. Pgrouting algorithms do not use this field directly. They use the reverse_cost field .

So you have a field cost and a reverse_cost
field . If the value of these two fields is the same, the algorithm reads it as
a two-way street. The proposed route can, therefore, go both ways.

If reverse_cost has a negative value, it will never take
this section in the opposite direction but, always, from the source
node to the target node . The section is, immediately, removed
from the resulting graph. If not, you can also assign an extremely large value
(for example 1000000) to the reverse_costs of the one-way sections. In this
case the section will be evaluated (unfavorably) but not rejected immediately.

For the algorithm to take into account these values, you must modify the
two boolean parameters of the SQL query directed and has_reverse
. There are some subtleties that go beyond the scope of this article concerning
the change of only one of the two parameters (true, false   and false,
true). Overall, you set both parameters as true so that the algorithm
works by taking into consideration the forbidden directions.

Here is the request as it should be to avoid the
misinterpretation problem in the expressway:  

Problem: reverse_costs_s has null values

As for the field cost_s , this problem arises due to  the fact that the field being used by osm2pgrouting
to calculate the cost in seconds is the length of the section in m ( length_m
), and, that this field is not always filled.

SOLUTION

Since you have, in theory,  filled
all the values ​​of costs_s , just select in the QGis table all the
records with null reverse_costs_s values , then, using the field
calculator set the value of costs_s to reverse_costs_s
.

But now, we have generated the following problem:

Problem: reverse_costs_s does not take into account
the forbidden direction (same value as the corresponding costs_s)

SOLUTION

Select the records with oneway = 1, then set the -costs_s
value to the reverse_costs_s field

The solutions to the last two problems start up in the base you are
using for the OSM data and render all the records consistent. Of course, if you
have a particular network and have adopted other specifications, you will need
to adapt the queries to meet your definitions.

We have finished the tour of the algorithm A * and its most common
problems. If you find others (I trust you), do not hesitate to leave a comment.

In the next article we will discuss how (do/do not) work the other
routing algorithms with Windows.

Here starts a series of articles to set up a routing web application (route
calculation) completely autonomous, ie using no web service or API for
calculating the route.
We will set up the database including the route network (or fluvial, etc.) with
Postgresql, then we will set up a wms flow with Geoserver, and finally we will
develop a calculation page with OpenLayers 3. All using Windows .

In this first article we will discuss the setting up of the network
database.
You will need to have an operational installation of PostreSQL / Postgis. If
this is not the case, refer to the article Starting with PostgreSQL / Postgis.

Pgrouting installation

For routing calculations, we will use the Postgis pgrouting extension. It
is installed, in theory, with the new Postgis versions. To be on the safe side,
open pgAdmin III and run the following SQL query:

SELECT pgr_version ();

You must have a result like this:   

If pgrouting is not installed:

1. Download the zipped pgRouting file zip file for your system (32 or 64
   bit) from Winnie .
2. Unzip the
   file. You will find three directories: bin, lib and share folders and two text
   files.
3. Copy
   these files and directories into the directory of your Postgres installation
   (in my case C: \
   Programs \ PostgreSQL \ 9.5 )
4. In
   pgAdmin III select your Postgis database and run the following SQL query:

CREATE EXTENSION pgrouting;

Check with the following query that the installation has been completed
successfully

SELECT pgr_version ();

If the version you have is
not the last (2.2.3), download and update your version. The whole series of
these articles is achieved with this version and be aware that the syntax of
many pgrouting commands has been modified. If
you try to run the queries shown here with older versions you risk error
messages like this:  

Setting up the data

We will take the simplest case, but if you already have a network
database, you will need to take inspiration from this example to do the necessary
 adaptation for its use with pgrouting.

In our case, we will download openStreetMap data from Brittany.

We download them from Geofabrik (http://download.geofabrik.de/europe/france/bretagne.html
).

You have several available formats (osm, shp, pbf). Whichever your
choice, there will be work to be done to make the data usable once loaded into
your Postgis database. The format that gives the least work and the best final
results is the osm .In addition, there is a tool (osm2pgrouting) that allows
the loading and creation of the topology in, just, one path.

How to import the OSM data with osm2pgrouting

In the latest Postgis versions, this tool is installed automatically. Check
that the C: \ Program Files \ PostgreSQL \ 9.5 \ bin \ osm2pgrouting.exe file
is present in your installation.

If this is not the case, download the tool version corresponding to your
installation   from winnie. Unzip the file and follow the installation
instructions included in the osm2pgrouting_Readme.txt file.

To simplify your command lines, add the \ Program Files \ PostgreSQL \
9.5 \ bin directory to your PATH environment variable.

To use the tool you will need to open a prompts command window.

To get the complete syntax of the tool you can enter

osm2pgrouting.exe -help

The essential elements to launch the tool:

• the name of the osm file to be loaded
  ( bretagne-latest.osm )
• the name of the postgis database
  ( postgis_22_sample )
• the listening port of your
  Postgresql installation ( 5432 )
• the name of the host ( localhost )
• the name of the config xml file:
  two files are provided with mapconfig.xml (generic) and mapconfif_for_cars.xml (for cars)

Here is an example of a command line

osm2pgrouting.exe -clean = 1 -f bretagne-latest.osm -d postgis_22_sample
-p 5432 -h localhost -c mapconfig_for_cars.xml

The clean parameter= 1 indicates to overwrite
existing tables. This command loads data into multiple tables, but also
generates the corresponding topology. For pgrouting the base table is the ways
table and the topology created the ways_vertices_pgr table .

Once
the command is executed, you will find a series of new tables in your database

The only tables you will use for your routing application are ways
(linear network) and ways_vertices_pg r (network nodes).

How to import the data without osm2pgrouting

If you download the Geofabrik data in shapefile format or if you have
data with this format, it’s a bit lengthier.

You must start by loading your shapefile including the linear network
into your PostgreSQL / Postgis database. If necessary, relaunch your data in
Geographic WGS84 because all pgrouting routing tools work on latitude /
longitude data.

Refer to the article Starting with PostgrSQL / Postgis -Introduction to pgAdmin3
for loading a shape into Postgis.

The created table corresponds to the ways table from the
previous chapter. Therefore, it is necessary to create the nodes table( ways_vertices_pg
r) through the generation of the network topology. In order to make the following
simpler, we will consider that you named your table ways and that
you placed it in the public database .

This is executed by the SQL command pgr_createTopology . But
this command assumes that your table contains two columns named source
and target .

Here are the commands to enter in the pgAdmin
III SQL window.

The value 0.00001 is equivalent to the tolerance in degrees, geom
to the name of the geometry field and gid to the table identifier field.

At the exit of this command you will find the table ways_vertices_pg
r in your PostgreSQL database.

How to validate your data in Postgis

In an ideal world, you could go directly to setting up your data server with
Geoserver. But, there is a good chance that things will not work out properly
…

We will discuss the most common problems, letting you discover by yourself
a lot of additional problems!

Firstly, we will use QGis to test our database and the operation of
different routing algorithms.

Pgrouting tests with QGis

You will will start by connecting  with your Postgis database and loading the ways
layer :   

To
run the pgrouting sql commands on your database, from QGis, open the Database
Manager  

Then,
select your Postgis database from the databases list, and open a SQL window  

It is in this upper window that we will enter the pgrouting sql
commands.

The lower window will list the table records resulting from the sql
command.

By checking the box on the bottom Load as new layer , we will
load the result in the QGis map window.

Example:

The SQL command corresponds to the route search in pgrouting using the
algorithm A *, starting from node 69072 and arriving to node 64204

The Run button sends the command to the Postgres database and
retrieves the number of lines (30 lines in this example) corresponding to the
route and displays in the bottom window these lines in the order for the route.

If we now ask to load the layer in QGis, it is the data of this lower
window that will be displayed in the map window.

Problem: There is no geometry column in the result. We will not be able
to view the route as a layer.

To get around this problem, we will add the geometry in the command
results. It’s a little complicated to explain, so let’s go straight to discuss
how to do it:

We will make a join between the algorithm pgr_astar result (…) (All
that is in parentheses are the algorithm parameters), which does not return in
the result the geometries but only nodes identifiers (edges) , and the node table,
then with the ways table:

SELECT seq, id1 AS node, id2 AS edge,   the_geom
FROM pgr_astar (‘SELECT gid as id, source, target, cost, x1, y1, x2, y2   FROM
public.ways’, 69072, 64204, false, false) as res
JOIN public.ways ways_vertices_pgr
ON res.id2 = ways_vertices_pgr.gid;

In short, we look for the node corresponding to
the edge of the result and we recover the linear section which is joined to it
by the topology. Now we can add in the result fields of  the selected  field the_geom which will allow us to trace
the result in QGis.

To load the layer in QGis, select the Load
as new layer checkbox , select the geometry field, and click the Load
button .

Now that we have discussed how to test our database, we will discuss the
main algorithms proposed by pgrouting, and which changes in the data must be
made in order to work properly … but all this in the next article.

Given a graph and a source vertex in the
graph, Dijkstra’s
algorithm  finds the shortest
paths from source to all vertices in the given graph. It takes as input an oriented graph weighted by real positive
numbers and a top source as root. This is to build gradually a subgraph where
the different vertices are classified in ascending order according their
minimum distance from the root. The distance is the sum of the weights of the
arcs followed.

The syntax of the Dijkstra algorithm is as follows :

pgr_dijkstrar ( sql text , source integer ,
target integer , directed boolean );

Where source is the desired starting point desired, target
is the end point of the route and the chain sql is as follows:

SELECT id, source, target, cost [, reverse_cost ] FROM
network

The “directed” Boolean variable allows taking into account of one-way
route.  By default it is  »   true
  « .

The order returns a set of elements ( seq , path_seq [, start_vid ] [,
end_vid ], node, edge, cost, agg_cost ). Unlike the A * algorithm, which has a
starting point and an end point for the route, the Dijstra algorithm admits several
points of entry and exit.

In the output set, seq is the order number of the segment
in the global set , path_seq is the order number of the segment
in the route , start_vid and end_vid are the point
of departure and arrival of the route and are not informed unless there are
several sources or targets in parameter of the
algorithm , node and edge are the start and end
points of the section considered , cost is the cost of the sectionand
agg_cost is the cost accrued since the departure of the route .

Choice of the « cost  » of a section .

The shortest path algorithm searches the path with the lowest cost. According
to your goals , it is up to you to decide which cost element you going take into
account.

Let’s take back our OpensStreetMap database . You have a « cost »
field that considers the length of the section in degrees . If you use this
field in the Dijkstra algorithm as cost value, the proposed route will be the
shortest path between the two selected points . Let’s see an example .

The following order calculates the route between the points 69072 and
64204 by using the « cost » field which corresponds to the length of
the section .

SELECT seq , path_seq , node,   edge,
di.cost , agg_cost , the_geom
FROM pgr_dijkstra (
‘SELECT gid as id, source, target, cost, reverse_cost FROM public.ways ‘,
69072, 64204, false   ) as di
JOIN public.ways ways_vertices_pgr
ON di.edge = ways_vertices_pgr.gid ;   

Once
loaded in QGis, the result is the same as for algorithm A *   

Problems

When comparing this algorithm with the algorithm A *, you will notice that
there is less need to formatting the layer network . By cons, if you use the cost_s
and reverse_cost_s fields , you will obtain the same error messages as if there
were null values . Refer to a previous article ( Developping an application with pgrouting in Windows (2): the algorithm
A * ) to solve these problems .

For this article we use pgrouting  version 2.2.3. If you use earlier versions you
can encounter a source and target field type problem of your
database:   

Indeed , if the number of nodes in your network is high, the source
and target fields can be bigint type . Earlier pgRouting versions
did not take into account this type of integer .

Check your version with the SQL query

SELECT pgr_version ();

Multiple routes

Here is an example of a path calculation with three starting points and
one arrival point :

SELECT seq , path_seq , start_vid , node,   edge, di.cost ,
agg_cost , the_geom
FROM pgr_dijkstra (
‘SELECT gid as id, source, target, cost_s as cost, reverse_cost_s as
reverse_cost FROM public.ways ‘,
ARRAY [69072,21576,62667] , 64204, true   ) as di
JOIN public.ways ways_vertices_pgr
ON di.edge = ways_vertices_pgr.gid ;

This request calculates the paths between the
starting points   69072, 21576 and 62667 and the point of arrival 64204   

Once
QGis is loaded, the result is the following

Variant pgr_dijkstraCost

You have a Dijkstra algorithm variant with which you state the starting and
arrival point and in return you retrieve the total cost of the path.

Here is an example with the path between points 69072 and 64204

SELECT * FROM pgr_dijkstraCost (
‘SELECT gid as id, source, target, cost_s as cost, reverse_cost_s as
reverse_cost FROM public.ways ‘,
69072, 64204);

Emilie d’Orgeix et Isabelle Warmoes, Atlas militaires manuscrits (XVIIe-XVIIIe siècles). Villes et territoires des ingénieurs du roi, Paris, BnF Editions / Ministère des Armées, décembre 2017, 384 p.

Aux XVIIe et XVIIIe siècles, les ingénieurs militaires façonnent patiemment au plus près du terrain leur conception de l’atlas manuscrit. S’il se conçoit toujours sous la forme d’un recueil relié de cartes et plans, l’atlas militaire adopte des formes infiniment diverses, allant du simple « ramas » de documents utiles à l’exercice de la profession, à la visite de places commandée par l’administration militaire, jusqu’au somptueux ouvrage présenté à un riche protecteur. Dessinés à la plume et le plus souvent rehaussés de lavis, ces recueils, conçus à des fins stratégiques, dressent le portrait inédit et toujours confondant de précision de provinces, païs, villes fortifiées et ouvrages militaires, tour à tour défendus ou convoités par l’Etat monarchique, depuis le règne d’Henri IV jusqu’à la fin du règne de Louis XV.

Cet ouvrage abondamment illustré, qui réunit une étude historique et un catalogue raisonné, complété d’index de lieux et d’auteurs, présente pour la première fois, planche par planche, l’un des gisements cartographiques d’Ancien Régime les plus exceptionnels qui soient conservés dans les fonds d’Île-de-France. Cette promenade cartographique à travers les 10 000 planches contenues dans les 178 atlas inventoriés, constitue un instrument de recherche inestimable pour l’histoire de la cartographie, des villes, de l’architecture et des paysages des « territoires des Bourbons », mais aussi des Etats européens et levantins.

Diffusion BNF : [editions.bnf.fr]

Atlas militaires РextraitsT̩l̩charger

Cet article OneSoil: cartographie des surfaces agricoles américaines et européennes est apparu en premier sur Veille cartographique 2.0.

OneSoil est une carte interactive qui donne un aperçu de la production agricole européenne et américaine. La carte fait apparaître la localisation et le type de cultures pour chaque terre cultivée, révélant les tendances locales et mondiales de la production agricole. Au total, la carte totalise plus de 57 millions de champs dans l’U.E. et […]

Cet article OneSoil: cartographie des surfaces agricoles américaines et européennes est apparu en premier sur Veille cartographique 2.0.

Cet article La photographie de Shanghai à 195 milliards de pixels est apparu en premier sur Veille cartographique 2.0.

Habitués des images satellitaires, ce que vous allez voir est époustouflant – et effrayant. Époustouflant car cela repousse les limites actuelles de l’imagerie numérique (et nous oblige à redéfinir ces dites limites). Effrayant en raison des potentiels dérives que cela permet. Plus de surprise, il s’agit d’une photographie panoramique de la ville de Shanghai. Une […]

Cet article La photographie de Shanghai à 195 milliards de pixels est apparu en premier sur Veille cartographique 2.0.

Cet article Les câbles sous-marin d’internet est apparu en premier sur Veille cartographique 2.0.

Aujourd’hui, tout le monde utilise Internet. De la gamine de 5 ans à la grand-mère en passant par l’adolescent, la mère et le père, tous sont connectés. En effet, grâce à nos smartphones, tablettes et ordinateurs, regarder un film, envoyer des mails ou encore chatter sur les réseaux n’a jamais été aussi facile. Partout dans […]

Cet article Les câbles sous-marin d’internet est apparu en premier sur Veille cartographique 2.0.

Cet article Flourish, un outil infographique, cartographique, statistique puissant est apparu en premier sur Veille cartographique 2.0.

Flourish, un outil infographique, cartographique, statistique puissant   Intensité des relations entre les personnages de la série « Friends » (Occurrence des conversations) Non-directional chords Flouris [https:] À l’image de ce qui peut être fait avec le langage R, mais sans un besoin réel de connaissance en statistiques d’analyse de données ou encore en programmation, Flourish permet […]

Cet article Flourish, un outil infographique, cartographique, statistique puissant est apparu en premier sur Veille cartographique 2.0.

Cet article CartoQuartiers : des Nantais participatifs… est apparu en premier sur Veille cartographique 2.0.

Portée par la ville de Nantes, CartoQuartiers est une cartographie participative réalisée par ArxiT sur les solutions Esri et ArcGis Online. Elle s’inscrit dans la continuité d’une première démarche en 2013/2014 ayant abouti à la création de 11 cartes pour autant de quartiers : « Bien dans mon quartier, bien dans ma ville ». Le réseau nantais […]

Cet article CartoQuartiers : des Nantais participatifs… est apparu en premier sur Veille cartographique 2.0.

Cet article Transiscope, la cartographie collaborative des alternatives de transition en France est apparu en premier sur Veille cartographique 2.0.

  Participer à une association pour donner un coup de pouce à la transition écologique, économique et/ou sociale, cela donne envie. Mais malheureusement, il n’est pas toujours évident de trouver l’association proche de chez soi dans laquelle on veut s’investir. Ainsi, dans le but de palier ce problème, 10 associations ont décidé de créer le […]

Cet article Transiscope, la cartographie collaborative des alternatives de transition en France est apparu en premier sur Veille cartographique 2.0.

Lizmap Web Client 3.2.*

Nous sommes heureux d’annoncer la sortie de lizmap Web Client 3.2 - 1 - 2

Cette version propose de nouvelles fonctionnalités :

• Ajout de capacités de Dataviz - Statistics with Dataviz
• Ajout de capacités d'Atlas - Atlas - sequence of entities of a chosen layer
• Prise en charge de l'impression QGIS Atlas via le plugin qgis-atlasprint https://github.com/3liz/qgis-atlasprint
• Édition : Gestion des coordonnées X, Y des points à l'aide d'un formulaire
• Édition : Utiliser la géolocalisation pour dessiner des géométries
• Cartes incorporables via iframe
• L'outil de recherche peut utiliser une table ou une vue PostgreSQL lizmap_search - Spatial searching - PostgreSQL search
• Récupération du mot de passe

Cette version améliore :

• L'édition
• Les évènements JavaScript
• Les évènements PHP pour les outils de recherche
• La mise à jour des locales

De nouvelles locales sont disponibles :

• Tchèque
• Norvégien
• Brésilien
• Slovène

Nous avons également amélioré la manière de localiser le plugin, le client Web et la documentation via transifex.

Les versions Futures de Lizmap Web Client

Nous avons prévu la sortie de la version 3.3 à la fin du mois de février. Cette version doit supporter pleinement QGIS Server 3.4. * Et supérieur.

Nous prévoyons également de publier une version 4 au cours de l'année 2019. Cette version sera basée sur les versions récentes d'OpenLayers, Bootstrap et JQuery. Nous avons commencé ce travail. Nous développons un module complémentaire à Lizmap pour construire sa carte à partir des couches publiées dans l'instance.

Lizmap Web Client 3.2.*

We are pleased to announce the release of lizmap web client 3.2 - 1 - 2

This version proposes new features:

• Add Dataviz capabilities - Statistics with Dataviz
• Add Atlas capabilities - Atlas - sequence of entities of a chosen layer
• Support QGIS Atlas print through qgis-atlasprint plugin https://github.com/3liz/qgis-atlasprint
• Edition: Manage point X,Y values through form
• Edition: Use geolocation to draw geometries
• Embeddable maps
• Search tool can use a PostgreSQL lizmap_search table/view - Spatial searching - PostgreSQL search
• Retrieving password

This version improves:

• Edition
• Javascript events
• PHP event for searching tool
• Updating locales

And new locales are availables:

• Czech
• Norwegian
• Brazilian
• Slovenian

We also enhance the way to localize the plugin, the web client and the documentation through transifex.

Futur Lizmap Web Client versions

We have planned the release of version 3.3 at the end of February. This version has to fully support QGIS Server 3.4.* and upper.

We also plan to release a version 4 during the year 2019. This version will be based on recent versions of OpenLayers, Bootstrap and JQuery. We have started this work. We develop an add-on to Lizmap to build its map from published layers within the instance.

Cet article Aeromapper et la cartographie par drone est apparu en premier sur Veille cartographique 2.0.

Aeromapper correspond à une entreprise française, dont l'activité principale est la construction de drones. Cette société est apparue en 2012 et "est autorisée à faire voler ses drones de manière automatisée et hors de vue du télépilote."

Cet article Aeromapper et la cartographie par drone est apparu en premier sur Veille cartographique 2.0.

Cet article La planète Mars cartographiée est apparu en premier sur Veille cartographique 2.0.

La sonde lancée par l'Agence Spatiale Européenne en 2003 aura bientôt achevé la cartographie de la planète Mars.

Cet article La planète Mars cartographiée est apparu en premier sur Veille cartographique 2.0.

Le standard 2017 introduit un certain nombre de précisions en matière de prescriptions, notamment à l'aide des sous-codes.

Il remanie certaines prescriptions et en particulier il supprime le code 11 qui avait été l'objet de nombreux débats.

En 2014 Arnauld apportait des précisions à ce sujet dans le fil de discussion dédié. Il y précisait que :

• L’occurrence 11 des prescriptions concerne les limitations particulières d'implantation des constructions comme les alignements ou les marges de recul


• L’occurrence 15 concerne les règles d'implantation des constructions par rapport aux voies, emprises publiques et limites séparatives.

Il était souvent difficile de distinguer clairement les deux codes et de ce fait nous avions alors établi que le code 11 était plus général et qu'il convenait d'y saisir tout ce qui n'allait pas dans le 15 ...

Finalement, maintenant, tout se retrouve dans le code 15 avec une série de sous-codes qui seront peut-être plus faciles à distinguer :

• Implantation des constructions par rapport aux voies et aux emprises publiques


• Implantation des constructions par rapport aux limites séparatives latérales


• Implantation des constructions par rapport aux limites des fonds de parcelles


• Implantation alternative des constructions

Ces sous-codes font référence à 3 articles L151-17 et L151-18 et R151-39 dernier alinéa. Ils sont détaillés page 28 du standard.

Toujours en matière d'implantation des constructions, on trouve aussi les codes : 38 pour l'emprise au sol, 39 pour les règles de hauteur, et 40 pour les règles de volumétrie.

 

Anak Krakatau (Indonesia) erupted on 22 December 2018. During the eruption the collapse of the volcano summit triggered a tsunami in Sunda Strait causing a death toll of 437. The first post-event clear-sky image was finally acquired by Sentinel-2 today on 13 Jan 2019 (after 10 cloudy acquisitions). Here is an image comparison of the Krakatau Island before and after the eruption.

View in full screen

Image-comparison of Anak-Krakatau before and after collapse, showing the major changes to the volcanic Island. First photo captured 5th August and second photo taken by @EarthUncutTV today. 1/3 #AnakKrakatau pic.twitter.com/uXcU3cGydt

— Øystein Lund Andersen (@OysteinLAnderse) January 11, 2019

La révision du processus de rapportage décrit dans un billet récent s'inscrit dans un processus plus large. En effet, depuis le début de l'année 2018, la Commission européenne a entrepris les études préparatoires à la révision de la directive INSPIRE en 2021.

Elle a ainsi repris à son compte un projet franco-danois de séminaire de réflexion sur ce que pourrait être le futur d'INSPIRE. Ce séminaire devrait réunir les représentants des Etats membres et d'autres acteurs à la discrétion de la Commission européenne.

La commission RMO va elle-même organiser un séminaire pour recueillir les idées et propositions des acteurs français (qu’est-ce qui ne va pas ? que faire pour la suite ?). En 2013, nous avions organisé plusieurs séminaires thématiques afin de recueillir les avis et propositions des uns et des autres sur les projets de modèle de données thème par thème. De l'avis général, ils avaient été réussis. Cela nous avait donné une grande force de proposition dans la négociation du règlement.

Même si la révision d'une directive est un objet institutionnel particulier, il s'agit de reproduire l'exercice afin que le représentant français au séminaire de 2019 puisse avoir un mandat reflétant autant que possible des avis partagés par les producteurs et utilisateurs de l'infrastructure française.

Ce séminaire pourrait avoir lieu en mai 2019, sous une forme à bâtir. Le programme de ce séminaire sera à construire lors de la réunion de la commission RMO de mars. J'ai proposé qu'il parte des résultats de l'atelier européen décrit dans le billet précédent. Dans mon esprit, il serait idéal qu'il puisse être préparé au niveau local par les plateformes régionales, mais ce sera à elles d'en juger.

Lors de la conférence INSPIRE 2018, un atelier ‘The future of INSPIRE’ s’est tenu autour de trois questions en lien avec la révision de la directive annoncée pour 2021 :
1. Qu’est-il nécessaire de faire avant et après 2021 ?
2. - Pouvons-nous identifier des fils directeurs (common threads) ?
3. - Sur quoi devrions-nous nous concentrer et de quoi avons-nous besoin ?

Beaucoup pensent qu’INSPIRE est au-dessous de ces objectifs pour de nombreuses raisons : données indisponibles, introuvables, incomplètes ; de meilleures alternatives sont disponibles ; trop de limitations juridiques et pratiques à l’accès et l’utilisation.

L’atelier a défini les enjeux futurs suivants :
1. Se concentrer sur la demande, pas seulement sur l’utilisation : les usages réels doivent induire des adaptations et améliorations de l’infrastructure.
Pour cela : consommer sa propre donnée, créer des couvertures pan-européennes de données de haute qualité et rendre la donnée réellement trouvable.
A noter que la révision du rapportage INSPIRE vise à répondre à ce dernier point.
2. Rendre la technologie et les spécifications techniques d’INSPIRE évolutives, notamment pour mieux répondre à la demande, en évitant des contraintes qui seraient spécifiques à INSPIRE.
3. Publier les données en l’état, au lieu d’attendre des données « parfaites », puis les harmoniser et améliorer leur qualité, quand il y a lieu. L’atelier expose le besoin « d’ouverture réelle des données ».
4. Adapter la gouvernance à un pilotage par la demande : trouver qui sont les utilisateurs, équilibrer la gouvernance d’INSPIRE aujourd’hui pilotée par les fournisseurs, en intégrant des utilisateurs

L’atelier a également reconnu que les concepts fondant INSPIRE restent valides. Il reste à faire évoluer INSPIRE vers une géoplateforme, où l’infrastructure serait un moyen, et non une fin, où la standardisation des données suivrait la demande et où la plateforme serait si attirante que la donnée du public (ex. science citoyenne) et du secteur privée serait également publiée.

La présentation en anglais est ici : Results workshop Future of INSPIRE 2018 1.0

Cet article La base SIRENE évolue en 2019 ! est apparu en premier sur Veille cartographique 2.0.

Une évolution et un changement  prévu au 31 janvier. La question qui se pose, que ce changement implique-il pour les utilisateurs de cette base ? Avant d’entamer ce sujet une petite définition de cette base SIRENE. Il faut savoir que c’est une base de données unique, qui répertorie toutes les entreprises et les établissements à l’échelle de la France ainsi […]

Cet article La base SIRENE évolue en 2019 ! est apparu en premier sur Veille cartographique 2.0.

Cet article Visualisation de la donnée du Google Cloud Storage est apparu en premier sur Veille cartographique 2.0.

La donnée, les données, le trafic de données… Voilà des sujets de conversation inhabituels lorsque nous échangeons avec parents et amis. Bien souvent, on évite le sujet. « La donnée ? C’est quoi ? On ne comprend pas ; bof… ça ne nous regarde pas ». Transformer la donnée en Å“uvre d’art Pour y remédier, Google a mis au […]

Cet article Visualisation de la donnée du Google Cloud Storage est apparu en premier sur Veille cartographique 2.0.

Pour L’Éco, le "nouveau média 100 % éco. créé avec des enseignants, pour les enseignants, leurs élèves et tous ceux qui veulent comprendre l’économie" zoome sur le métier de géomaticien...

Dans sa rubrique "Les jobs de demain" (Pour L’Éco n°4, décembre 2018), Pour L’Éco présente les grandes lignes du métier de géomaticien (les qualités requises, les tâches à réaliser, les caractéristiques du métier...)

Pour accéder à l'article, aller sur le site de l'AFIGEO.

-----------------------------------------

Vous pouvez réagir, contribuer et débattre sur cet article à la suite du message posté sur le forum GeoFormations.

 

 

#BrexitWhereNow 

Brexit is supposed to be a complex matter. 

Jon Worth @jonworth published this diagram on Twitter a couple of days ago. It's an amazing collection of facts.  

 However it is not easy to read.  I follow up all the links and I redraw it without any crossroads thanks to CmapTools.

It is still complex (the matter is) but it is less complicated. All original informations have been kept. Please tell me if it is not the case  

Click to enlarge 

 

 

 

C'est la nouvelle année, et je vous souhaite une excellente année deux-mille-dix-n'oeufs.

Même si la Commission européenne, dans sa grande générosité, dispense cette année les Etats membres de produire l'habituel rapport triennal en 2019, il nous a semblé positif de continuer à recueillir et à publier des récits concrets sur l'apport d'INSPIRE aux différents acteurs.

La dernière fois, en 2016, nous avions ainsi publié sur ce blog la plupart des récits contenus dans le rapport de la France.

Cela a été utile pour comprendre, et faire comprendre, l'intérêt de tout ce travail souterrain de la construction d'une infrastructure de données, normalement invisible - sauf quand cela ne fonctionne pas!

Aussi, merci de me proposer des récits sur l'environnement, sur les territoires, sur des usages par les associations ou les entreprises, aux différents niveaux administratifs. Comme dans toute bonne histoire, il y aura des succès, des problèmes, des acteurs emblématiques, des sujets obscurs ou symboliques, des paraboles si vous le voulez, dans le respect toutefois de la décence propre à un rapport de la France.

C'est à envoyer à mon adresse professionnelle, marc.leobet[(at)]developpement-durable.gouv.fr avec comme objet "rapport INSPIRE 2019" SVP.