Vous pouvez lire le billet sur le blog La Minute pour plus d'informations sur les RSS !
Canaux
3894 éléments (71 non lus) dans 55 canaux
![Dans la presse](/planet/themes/georezo/web/media/folder.gif)
-
Décryptagéo, l'information géographique (1 non lus)
-
Cybergeo (20 non lus)
-
Revue Internationale de Géomatique (RIG)
-
SIGMAG & SIGTV.FR - Un autre regard sur la géomatique (1 non lus)
-
Mappemonde (20 non lus)
![Du côté des éditeurs](/planet/themes/georezo/web/media/folder.gif)
-
Imagerie Géospatiale
-
Toute l’actualité des Geoservices de l'IGN (10 non lus)
-
arcOrama, un blog sur les SIG, ceux d ESRI en particulier (3 non lus)
-
arcOpole - Actualités du Programme
-
Géoclip, le générateur d'observatoires cartographiques
-
Blog GEOCONCEPT FR
![Toile géomatique francophone](/planet/themes/georezo/web/media/folder.gif)
-
Géoblogs (GeoRezo.net)
-
Conseil national de l'information géolocalisée
-
Geotribu
-
Les cafés géographiques (1 non lus)
-
UrbaLine (le blog d'Aline sur l'urba, la géomatique, et l'habitat)
-
Icem7
-
Séries temporelles (CESBIO) (1 non lus)
-
Datafoncier, données pour les territoires (Cerema) (2 non lus)
-
Cartes et figures du monde
-
SIGEA: actualités des SIG pour l'enseignement agricole
-
Data and GIS tips
-
Neogeo Technologies (1 non lus)
-
ReLucBlog
-
L'Atelier de Cartographie
-
My Geomatic
-
archeomatic (le blog d'un archéologue à l’INRAP)
-
Cartographies numériques (7 non lus)
-
Veille cartographie
-
Makina Corpus (1 non lus)
-
Oslandia (3 non lus)
-
Camptocamp
-
Carnet (neo)cartographique
-
Le blog de Geomatys
-
GEOMATIQUE
-
Geomatick
-
CartONG (actualités)
Toile géomatique francophone
-
12:19
Parquet devrait remplacer le format CSV
sur Icem7Parquet est un format ouvert de stockage de jeux de données. Créé en 2013 par Cloudera et Twitter, longtemps réservé aux pros du big data, il a beaucoup gagné en popularité ces derniers mois. Bien plus compact, super-rapide à lire, compris par davantage d’outils, Parquet est devenu une alternative crédible à l’omniprésent CSV.
C’est un standard ouvert, comme le CSV, qui prend les données telles qu’elles sont collectées, en simples tables de lignes et de colonnes. Si CSV empile des lignes, Parquet raisonne d’abord en colonne : il les distingue, les catégorise selon leur type, documente leurs caractéristiques fines. Cela rend les données plus faciles à manipuler, plus rapides à parcourir. Et comme elles sont intelligemment compressées, elles prennent bien moins de place de stockage, jusqu’à 10 fois moins qu’un fichier texte délimité !
Parquet sait aussi organiser l’information en groupes de milliers de lignes, voire en fichiers distincts, partitionnés, ce qui accélère les requêtes en les dirigeant plus vite vers les seules données pertinentes pour le traitement désiré. La richesse de son dictionnaire de métadonnées est d’une efficacité redoutable, au niveau de celles des index d’une base de données.
À rebours du paradigme classique de R ou Python, il n’est plus nécessaire de charger toute une table en mémoire pour l’analyser, les données sont lues uniquement là où elles sont utiles, sans aucune conversion ou recopie (c’est le principe de localité).
Des avantages incontestables par rapport à CSVRésumons les deux points forts de Parquet par rapport au format CSV :
- un fichier Parquet a la taille d’un CSV compressé, il prend jusqu’à dix fois moins de place de stockage.
- Il est parcouru, décodé et traité bien plus rapidement par les moteurs de requêtes analytiques.
Dernier avantage : Parquet sait modéliser des types complexes, une colonne comprenant par exemple une structure hiérarchique, un contenu JSON ou le champ géométrique de nos couches SIG (cf. plus loin le projet GeoParquet).
Encore faut-il savoir créer et lire le format ParquetJusqu’à il y a peu, seuls des outils très spécialisés permettaient de générer ou lire le format Parquet. En quelques mois, la donne a radicalement changé. Le vaste projet Apache Arrow, porté à partir de 2016 par Wes McKinney (le créateur de la librairie Python/Pandas) et des dizaines de développeurs majeurs du monde de la datascience, est sans nul doute à l’origine de cette accélération.
La plupart des outils analytiques de la datascience, jusqu’à JavaScript dans le navigateur, lisent les formats Parquet et son jeune cousin Arrow en s’appuyant sur un noyau commun de routines C++ développées dans le cadre du projet Apache Arrow.
Enfin, le formidable moteur portable DuckDB met à la portée de n’importe quel PC les performances d’un moteur de base de données traditionnel sur serveur. DuckDB est désormais, avec des données Parquet, plus rapide qu’une base PostgreSQL pour les requêtes d’analyse.
R offre un environnement efficace pour travailler avec ParquetVotre tableur favori ne propose pas encore de fonction “Enregistrer sous .parquet”, mais cela ne saurait tarder. Pour aller au plus vite, ce classeur Observable en ligne vous permet de le faire : il vous invite à téléverser un CSV, le type des colonnes tel que deviné vous est présenté, vous pouvez télécharger la version .parquet de votre fichier et déjà admirer la belle réduction de taille.
Pour visualiser le contenu d’un fichier Parquet, à l’opposé, Tad est un utilitaire libre multiplateforme efficace et véloce ; il autorise même les filtrages et les agrégations. À vous de jouer !
Les convertisseurs en ligne CSV => Parquet sont toutefois limités : à l’évidence par la taille des CSV que vous pouvez téléverser (quelques dizaines de Mo), et parfois parce qu’ils “typent” incorrectement certaines colonnes : vos codes département ou commune se retrouveront amputés du 0 initial, ou pire, une erreur surviendra parce qu’une colonne de codes département sera intuitée numérique au vu des premières lignes, mais produira une erreur à l’apparition des 2A ou 2B des départements Corse.
Pour l’heure, R offre un environnement très efficace pour créer des fichiers Parquet (Python aussi, sans doute). La librairie R arrow fait l’essentiel du travail, avec vélocité et robustesse.
Le fichier des migrations résidentielles : un CSV de 2 Go qui devient facile à manipuler converti en ParquetNous allons explorer les avantages du format Parquet à partir d’une table respectable de 20 millions de lignes et 33 colonnes. L’Insee met à disposition la base des migrations résidentielles, issue du recensement de la population, sous deux formats, CSV zippé et .dbf. Le format dbf (DBASE) me rappelle de vieux souvenirs, je ne sais pas qui l’utilise encore… J’espère convaincre mes amis de l’Insee de remplacer un jour ces .dbf par des .parquet !
Chaque résident se trouve comptabilisé dans ce tableau qui résulte d’une ventilation selon une trentaine de caractéristiques de la personne ou de son ménage : commune de résidence et résidence un an avant, CSP, tranche d’âge, type de logement, etc.
Une ligne correspond à un croisement de caractéristiques, elle peut regrouper plusieurs personnes. La colonne IPONDI en donne le nombre : comme il s’agit d’une estimation, IPONDI est en pratique une valeur décimale. C’est la seule colonne numérique, toutes les autres sont des catégories qualitatives d’une nomenclature : code commune, code CSP, etc.
Voici un aperçu de ce CSV, on reconnait le délimiteur français (;), et des valeurs qui peuvent commencer par un 0. Ce CSV n’est pas si simple à afficher, car peu de programmes peuvent ouvrir un fichier texte de 2 Go. J’utilise EmEditor dont la version gratuite fait cela en un clin d’œil.
J’ai rencontré plusieurs personnes s’étant bien pris la tête avec un tel fichier. Dans R ou Python, il faut le charger en entier en mémoire, dont l’occupation peut atteindre en pointe les 10 Go : c’est difficilement supportable, et inenvisageable quand l’environnement de travail R est sur serveur et multi-utilisateurs. On s’en sort habituellement en chargeant les données dans une base comme PostgreSQL, ce qui demande pas mal d’écriture, de temps de chargement et oblige à dupliquer les données.
Dans R, les quelques lignes suivantes assurent la conversion vers Parquet, une fois pour toutes, en moins d’une minute.
library(tidyverse) library(arrow) library(data.table) write_parquet( fread("data/FD_MIGCOM_2019.csv") |> mutate(across(-IPONDI, as.factor)), "data/FD_MIGCOM_2019.parquet" ) # data.table::fread est très efficace pour charger des gros CSV (50 s ici) # IPONDI est la seule col. numérique, les autres seront typées factors plutôt que string # write_parquet génére l'équivalent Parquet du CSV en entrée
La version Parquet ne fait plus que 200 Mo, dix fois moins que le CSV de départ. Et elle est directement utilisable avec peu de mémoire, y compris en contexte multi-utilisateurs, aussi facilement qu’une table dans une base de données. En raison de sa nature de standard ouvert, elle a l’avantage supplémentaire de pouvoir être lue par un grand nombre d’outils analytiques.
Les colonnes caractères de nomenclature doivent être typées avec soinAttardons-nous sur le typage des colonnes qualitatives, car c’est un important facteur d’optimisation des fichiers Parquet. Une colonne de type caractère comprenant les codes souvent répétés d’une nomenclature peut être décrite de façon optimisée à partir du dictionnaire de ses valeurs distinctes, et d’un simple n° d’indice, un entier.
Ces colonnes qualitatives “dictionary-encoded” sont bien plus rapides à lire que les colonnes caractères classiques. Pour l’heure, la plupart des outils automatiques de conversion vers Parquet négligent cette structure optimisée. Dans R, dès lors que les “strings” sont convertis en “factors”, qui reposent sur la même idée de dictionnaire, on pourra générer un Parquet bien optimisé. En pratique, les requêtes deviennent deux fois plus rapides encore, cela vaut donc le coup d’y penser !
Clic droit sur FD_MIGCOM_2019.parquet dans mon explorateur de fichiers et Tad m’affiche en deux secondes le contenu de cette table Parquet. Chaque colonne apparait bien typée, et mes codes géographiques n’ont pas été altérés :
Avec Tad, je peux trier, filtrer sur plusieurs colonnes, et même agréger ! Comprenons comment optimiser une requête en évitant les chargements ou recopies inutiles
Revenons dans R avec une première requête simple, compter les habitants de Toulouse qui ont changé de logement en un an :
read_parquet("data/FD_MIGCOM_2019.parquet") |> filter(COMMUNE == '31555' & IRAN != '1') |> summarise(i = sum(IPONDI)) # 93151 # 7 s
Sept secondes peut sembler un bon résultat pour compter ces 93 151 personnes, mais on peut réduire le temps de calcul à une seconde avec cette variante :
read_parquet("data/FD_MIGCOM_2019.parquet", col_select = c(COMMUNE, IRAN, IPONDI)) |> filter(COMMUNE == '31555' & IRAN != '1') |> summarise(i = sum(IPONDI)) # 93151 # 1 s
Ce qui est encore excessif, car la librairie duckdb peut nous faire descendre à 150 ms :
library(duckdb) con <- dbConnect(duckdb::duckdb()) dbGetQuery(con, "SELECT sum(IPONDI) FROM 'data/FD_MIGCOM_2019.parquet' WHERE COMMUNE = '31555' AND IRAN <> '1'") # 93151 # 150 ms
Comment comprendre que l’on arrive à ces performances assez hallucinantes, et l’impact de ces variantes d’écriture sur la charge d’exécution ?
Soyez vigilants avec les pipelines d'instructions chaînéesDans R et dplyr, le chainage des opérations avec le pipe
|>
(ou%>%
) conduit à séparer les traitements. Ainsi, dans l’écriture suivante;read_parquet()
charge en mémoire toute la table avant de la filtrer drastiquement.read_parquet("data/FD_MIGCOM_2019.parquet") |> filter(COMMUNE == '31555' & IRAN != '1') |> summarise(i = sum(IPONDI)) # 93151 # 7 s
Parquet, on l’a vu, encode séparément chaque colonne, si bien qu’il est très rapide de cibler les seules colonnes utiles pour la suite d’un traitement. La restriction suivante apportée au
read_parquet()
par uncol_select
diminue considérablement la charge mémoire, expliquant la réduction du temps d’exécution d’un facteur 7 :read_parquet("data/FD_MIGCOM_2019.parquet", col_select = c(COMMUNE, IRAN, IPONDI)) |> filter(COMMUNE == '31555' & IRAN != '1') |> summarise(i = sum(IPONDI)) # 93151 # 1 s
Pour autant, on n’évite pas la recopie d’une partie du contenu de FD_MIGCOM_2019.parquet (trois colonnes) vers la mémoire de travail de R.
La variante DuckDB est bien plus optimisée : le fichier FD_MIGCOM_2019.parquet est lu et traité en place sans (presque) aucune recopie des données en mémoire :
library(duckdb) con <- dbConnect(duckdb::duckdb()) dbGetQuery(con, "SELECT sum(IPONDI) FROM 'data/FD_MIGCOM_2019.parquet' WHERE COMMUNE = '31555' AND IRAN <> '1'") # 93151 # 150 ms
Cette notion de “zéro-copie” est fondamentale : elle est au cœur du projet Arrow et avant lui de la conception du format Parquet.
Les requêtes compilées sont plus efficacesUne requête considérée globalement est plus facilement optimisable par un moteur intelligent, qui va chercher le meilleur plan d’exécution. C’est comme cela que les moteurs de bases de données relationnelles fonctionnent, prenant en considération par exemple les clés et les index ajoutés aux tables.
Le chainage proposé par dplyr (ou Pandas dans Python) est toutefois plus agréable à écrire ou à relire qu’une requête SQL. Comment réunir le meilleur des deux mondes ?
C’est possible dans R avec
open_dataset()
qui plutôt que lire directement le contenu du fichier, se contente d’ouvrir une connexion, prélude à l’écriture d’une chaine d’instructions qui ne sera compilée et exécutée que par l’ordre finalcollect()
:open_dataset("data/FD_MIGCOM_2019.parquet") |> filter(COMMUNE == '31555' & IRAN != '1') |> summarise(i = sum(IPONDI)) |> collect() # 93151 # 1 s
Cette écriture conduit le moteur (ici arrow et non plus dplyr) à comprendre qu’il n’a pas besoin de lire toutes les colonnes de la table Parquet. Elle n’est pas tout à fait aussi rapide que le SQL direct dans DuckDB, mais elle s’en approche.
Partitionnez pour simplifier le stockage et les mises à jouropen_dataset()
a un autre mérite, celui de permettre d’ouvrir une connexion vers un ensemble partitionné de fichiers physiques décrivant la même table de données.La base des migrations fait ici 200 Mo, c’est relativement faible. On considère qu’un fichier Parquet peut raisonnablement aller jusqu’à 2 Go. Au-delà, il y a tout intérêt à construire un dataset partitionné.
La base des courses des taxis de New-York représente 40 Go de données couvrant plusieurs années, et elle se décompose en une partition de dizaines de fichiers Parquet, découpés par année et par mois. Ce découpage est logique, il permet par exemple de ne mettre à jour que les nouveaux mois de données fraichement disponibles. La clé de partitionnement correspond également à une clé de filtrage assez naturelle.
R et Arrow arrivent à requêter l’ensemble de ce dataset en moins d’une seconde (DuckDB fait cinq à dix fois mieux).
Voici comment constituer un dataset Parquet partitionné à partir de la base plus modeste des migrations résidentielles, avec ici un seul champ de partitionnement :
write_dataset(fread("data/FD_MIGCOM_2019.csv") |> mutate(across(-IPONDI, as.character)), path = "data/migres", partitioning = c('IRAN'))
Cela crée une petite arborescence de fichiers Parquet :
Nous pouvons désormais comparer les performances de la même requête, sur l’ensemble partitionné en dix fichiers, ou sur le fichier Parquet unique.
La partition accélère naturellement nettement l’exécution (200 ms contre 1 s) car le filtrage suivant sur IRAN correspond à la clé de partitionnement, il n’est donc pas besoin d’ouvrir le second fichier de la partition :
open_dataset("data/migres", partitioning = c('IRAN')) |> filter(COMMUNE == '31555' & IRAN != 1) |> summarise(i = sum(IPONDI)) |> collect() # 93151 # 200 ms open_dataset("data/FD_MIGCOM_2019.parquet") |> filter(COMMUNE == '31555' & IRAN != '1') |> summarise(i = sum(IPONDI)) |> collect() # 93151 # 1 s
Parquet et DuckDB surpassent les bases de données relationnelles classiquesJe me suis intéressé à cette base de migrations pour conseiller un client peinant à la traiter dans R. Travaillant dans une agence d’urbanisme, il voulait simplement extraire les données pertinentes pour sa métropole. Dans le cas de Toulouse, cela reviendrait à extraire de la base les personnes résidant dans l’EPCI de Toulouse-métropole, ou y ayant résidé l’année précédente.
Je m’appuie pour ce faire sur une table annexe listant les communes de Toulouse Métropole. Il s’agit ensuite d’opérer une double jointure avec la base des migrations, utilisant successivement COMMUNE (code de la commune de résidence) et DCRAN (code de la commune de résidence antérieure).
Grâce à DuckDB, cela s’exécute en 2 secondes, je n’ai même pas eu à me préoccuper d’indexer la table principale. Dans PostgreSQL 15, même après avoir indexé COMMUNE et DCRAN, la requête prend plus de 20 secondes. Ite missa est. DuckDB et Parquet écrasent tout !
library(duckdb) con = dbConnect(duckdb::duckdb()) dbSendQuery(con, "CREATE TABLE COM_EPCI_TOULOUSE AS SELECT * FROM read_csv('data/communes_epci_tls.csv', AUTO_DETECT = TRUE, ALL_VARCHAR = TRUE)") dbGetQuery(con, "SELECT M.* FROM 'data/FD_MIGCOM_2019.parquet' as M LEFT JOIN COM_EPCI_TOULOUSE as C1 ON M.COMMUNE = C1.CODGEO LEFT JOIN COM_EPCI_TOULOUSE as C2 ON M.DCRAN = C2.CODGEO WHERE C1.CODGEO IS NOT NULL OR C2.CODGEO IS NOT NULL ") |> summarise(i = sum(IPONDI)) # 282961 # 2,5 s
Parquet et Arrow sont deux technologies complémentairesCloudera est l’une des entreprises conceptrices originelles de Parquet, en 2013, avec Twitter et Google. Quand Wes McKinney la rejoint en 2014, lui qui a créé la célèbre librairie Pandas pour Python (équivalent de R/Tidyverse), il comprend vite qu’il y a là un format d’avenir : un modèle de “dataframe” universel, qui peut encore s’optimiser.
Wes rêve d’un format de données qui soit quasi-identique dans sa représentation physique (stockée ou streamée via les réseaux) à sa représentation en mémoire, qui éviterait toutes ces coûteuses opérations de conversion des différents formats textes ou “propriétaires” vers les bits que manipulent les processeurs. Le pire exemple est naturellement celui du CSV, où les nombres sont d’abord stockés comme des chaines de caractères, qu’il faut décoder (“désérialiser”). Avec ce format idéal auquel le projet Apache Arrow donne forme à partir de 2016, les processeurs pourront déplacer des pointeurs vers des sections de bits de données, sans jamais les recopier.
Si Parquet, format binaire “streamable” (découpable en petits morceaux autonomes) orienté colonnes, s’approche de cet idéal, il impose tout de même une forme de décodage avant d’être porté en mémoire, par exemple parce qu’il compresse les données. A contrario, un fichier physique constitué à partir d’un format Arrow prend beaucoup plus de place car il n’est pas compressé.
Parquet a le mérite d’exister et d’être déjà beaucoup utilisé, il est optimisé pour l’archivage et le partitionnement, Arrow pour les traitements, les accès concurrents et les systèmes très distribués.
Wes McKinney a su motiver de très bons programmeurs au sein du projet Apache Arrow pour bâtir à la fois une spécification de format et des librairies partagées, dont une interface très performante entre Parquet et Arrow. Nous voyons – nous humains – des fichiers Parquets, les moteurs analytiques et les réseaux travaillent à partir de leur conversion en structures Arrow.
Dans le même ordre d’idée, plutôt que chacun dans son coin implémente un module de lecture de fichiers CSV, l’effort est désormais centralisé au sein du projet Arrow. R, Python, Rust, Julia, Java et bien d’autres réutilisent les librairies C++ du projet Arrow. Il en existe même un portage pour JavaScript en Web-Assembly : nos navigateurs savent désormais lire des fichiers Arrow ou Parquet (cf. les librairies Arrow.js, Arquero ou duckdb-wasm).
Ainsi, à rebours de la logique intégrée des systèmes de bases de données, il est aujourd’hui possible de rendre indépendants – sans sacrifier la performance – les sources de données et les moteurs analytiques, les uns et les autres pouvant se déployer dans n’importe quel environnement, portable ou distribué.
GéoParquet pourrait renouveler le stockage des données géographiques tabulairesLe cahier des charges de Parquet prévoyait la possibilité de décrire des colonnes stockant des structures complexes, imbriquées, organisées en listes. Parquet est donc tout à fait capable de modéliser des données spatiales, qui complètent typiquement une table de données classique par un champ géométrique.
À la clé, tous les avantages déjà évoqués : stockage réduit, données volumineuses possiblement partitionables, traitements accélérés, nouveau standard plus facilement acceptable par l’industrie, réduisant l’écart entre l’exotisme des formats SIG et les formats de données statistiques plus traditionnels.
Géoparquet permettra de gérer plusieurs systèmes de référence géographique dans le même dataset, voire plusieurs colonnes de géométrie.
Le projet GeoParquet est déjà bien avancé et le format est d’ores et déjà utilisable. Vous pouvez générer des fichiers GeoParquet avec R ou Python, et les ouvrir, grâce à l’intégration GeoParquet dans GDAL, dans la dernière version de QGIS (3.28).
Voici un exemple à partir d’un fichier historique des cultures en Ariège, obtenu au format geopackage. La conversion en GeoParquet aboutit à un fichier deux fois plus petit, de contenu identique. L’équivalent au format Esri shape produirait un ensemble de fichiers de plus de 500 Mo, de taille quasiment 10 fois supérieure.
Les trois versions s’ouvrent dans R ou dans QGIS avec la même rapidité.
library(sf) library(sfarrow) # [https:] # le gpkg pèse 110 Mo # l'équivalent esri shape 540 Mo gpkg_file = "data/filiation_20_07.gpkg" # liste des couches de ce geopackage : 1 seule couche st_layers(gpkg_file) read_sf(gpkg_file) |> st_write_parquet("data/filiation_20_07_d09.parquet") # le geoParquet généré pèse 60 Mo
Un fond de carte GeoParquet ouvert dans QGIS Pour résumer
Parquet est un standard ouvert particulièrement bien adapté pour stocker des données volumineuses, et traiter des fichiers avec beaucoup de colonnes, ou comprenant des nomenclatures.
Sa structure astucieusement croisée et documentée en colonnes et en groupes de lignes exploite à merveille les capacités des processeurs modernes : parallélisation, vectorisation, mise en cache. Elle est aussi compatible avec une organisation partitionnée ou une distribution “streamée” des données.
Comme Arrow, Parquet épouse le principe de localité : rapprocher les process des données, les lire là où elles se trouvent, plutôt que recopier les données dans des espaces de traitement spécialisés. C’est l’objectif du “zéro-copie” : il permet de travailler avec des données plus volumineuses que la mémoire disponible et de dépasser ce goulet d’étranglement classique, bien connu des praticiens de R ou Python.
GéoParquet est en passe de résoudre le casse-tête de l’hétérogénéité des formats SIG, de leur apporter de nouveaux gains de performance et de substantielles économies de stockage.
Un des formats majeurs de la boite à outils Arrow, Parquet est la face émergée d’un nouvel écosystème décloisonnant les données et les process qui les traitent, complémentaire des bases de données relationnelles traditionnelles.
Si la plupart des outils d’analyse de données lisent désormais les fichiers Parquet, le nouveau moteur portable DuckDB est tout spécialement optimisé pour en tirer le meilleur parti. Il démontre des performances extraordinaires, qui ne cessent de croitre, tirées par la créativité et l’enthousiasme d’une belle communauté de développeurs open-source.
Pour aller plus loinPrésentation du format
- Apache Parquet pour le stockage de données volumineuses
- What is the Parquet File Format?
- What Is Apache Parquet?
- Parquet file format
Différences Arrow / Parquet
- Difference between Apache parquet and arrow
- [https:]]
- The Columnar Roadmap: Apache Parquet and Apache Arrow
Pour jouer avec Parquet
- Tad: A better way to view & analyze data
- Online, Privacy-Focused Parquet File Viewer
- Dbeaver: Universal Database Tool
- How to set up DBeaver SQL IDE for DuckDB
- DuckDB redonne une belle jeunesse au langage SQL
- Package R Parquetize
Le projet Arrow
- Apache Arrow: High-Performance Columnar Data Framework (Wes McKinney)
- Apache Arrow: a cross-language development platform for in-memory analytics
L’article Parquet devrait remplacer le format CSV est apparu en premier sur Icem7.
-
14:58
Geomatys labellisé CNES PME
sur Le blog de GeomatysDepuis juin 2022, Geomatys est titulaire du label CNES PME pour une durée de trois ans, en récompense de son expertise en “standardisation de système d’information géospatiaux interopérables”. Attribué depuis 2020, et comme son nom l’indique, ce label est attribué aux PME innovantes et crédibles agissant dans le domaine du spatial.
The post Geomatys labellisé CNES PME first appeared on Geomatys.
-
11:19
Photos sur une carte dans QGIS
sur GeomatickVous disposez de relevés terrain avec de magnifiques clichés. Vous voulez afficher ces photos sur une carte dans QGIS. Alors, ce tutoriel SIG vous montre trois manières de géolocaliser des photos sur le logiciel. Les photos sont acquises par drone dans le sud du Morbihan entre Lorient et Vannes pour… Continuer à lire →
L’article Photos sur une carte dans QGIS est apparu en premier sur GEOMATICK.
-
14:20
Revue de presse du 16 décembre 2022
sur GeotribuDernière revue de presse de 2022 : PostgreSQL et PostGIS ont la cote, Shapely s'offre une deuxième jeunesse, Overture sort du chapeau,...
-
14:20
Contribution Mapillary et retour d'expérience
sur GeotribuContribution Mapillary et retour d'expérience
-
14:20
Revue de presse du 2 décembre 2022
sur GeotribuGeoRDP du 2 décembre : la revue de presse de la géomatique qui ressemble à un calendrier de l'avent qu'on ouvrirait toutes les 2 semaines tout le long de l'année ! Bonne dégustation !
-
14:20
Revue de presse du 18 novembre 2022
sur GeotribuL’équipe de GeoTribu accompagnée de contributeurs bénévoles achalandent les rayons de la GeoRDP en actualités toutes fraîches : OSRM, IGN, Cartobio, télédétection, PCRS, ...
-
13:30
Création de zooms circulaires et autres astuces amusantes de mise en page dans QGIS
sur GeotribuParamétrer la mise en page de QGIS pour afficher des zooms circulaires. Traduction d'un article de North Road.
-
14:20
Revue de presse du 4 novembre 2022
sur GeotribuGeoRDP du 4 novembre 2022 : QGIS, Topohelper, Clipper 2, JOSM, Lego, LASTIG, des évènements et des rencontres à venir, de la lecture.
-
17:44
across() est plus puissant et flexible qu’il n’y parait
sur Icem7La librairie R dplyr permet de manipuler des tables de données par un élégant chainage d’instructions simples : select, group_by, summarise, mutate… à la manière du langage de requête SQL.
dplyr est le module central de l’univers tidyverse, une collection cohérente de librairies spécialisées et intuitives, ensemble que l’on a souvent présenté comme le symbole du renouveau de R.
Arrivée à maturité il y a deux ans avec sa version 1.0, dplyr accueillait en fanfare l’intriguant élément “across()”, destiné à remplacer plus d’une dizaine de fonctions préexistantes. across() est ainsi devenu l’emblème de la version toute neuve de la librairie emblématique du “R moderne” !
Je l’ai constaté, across() est encore insuffisamment compris et utilisé, tant il implique une façon de penser différente de nos habitudes d’écriture. Cet article vous présente, au travers de 7 façons de le mettre en œuvre, sa logique assez novatrice. Il s’adresse en priorité à des lecteurs ayant déjà une connaissance de R et dplyr.
across() permet de choisir un groupe de colonnes dans une table, et de leur appliquer un traitement systématique, voici sa syntaxe générique :
Je vais présenter l’usage d’across() avec la base Gaspar, qui décrit les risques naturels et industriels auxquels chaque commune française est exposée. J’en ai préparé un extrait décrivant sept risques pour la métropole. Chaque colonne indicatrice de risque vaut 0 ou 1 (présence).
library(tidyverse) tb_risques = read_delim(str_c(" [https:] "20221027-104756/tb-risques2020.csv"), col_types = c('reg' = 'c')) # A tibble: 34,839 x 11 com dep reg lib_reg risq_inond risq_seisme risq_nucleaire risq_barrage risq_industriel risq_feux risq_terrain <chr> <chr> <chr> <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> 1 01001 01 84 Auvergne-Rhône-Alpes 1 0 0 0 0 0 0 2 01002 01 84 Auvergne-Rhône-Alpes 0 1 0 0 0 0 1 3 01004 01 84 Auvergne-Rhône-Alpes 1 1 0 0 0 0 1 4 01005 01 84 Auvergne-Rhône-Alpes 0 0 0 0 0 0 0 5 01006 01 84 Auvergne-Rhône-Alpes 0 1 0 0 0 0 0 6 01007 01 84 Auvergne-Rhône-Alpes 1 1 0 1 0 0 0 7 01008 01 84 Auvergne-Rhône-Alpes 0 1 0 0 0 0 0 8 01009 01 84 Auvergne-Rhône-Alpes 1 1 0 0 0 0 0 9 01010 01 84 Auvergne-Rhône-Alpes 1 1 0 1 1 0 0 10 01011 01 84 Auvergne-Rhône-Alpes 0 1 0 0 0 0 1 # ... with 34,829 more rows
Voici par exemple la traduction cartographique de la colonne risq_barrage (risque de rupture de barrage, en bleu la modalité 1) :
across() cible un ensemble de colonnes avec la même syntaxe que celle utilisée dans un select().
Rappelons les mécanismes de la sélection de colonnes dans dplyr – ils sont nombreux et astucieux – au travers de quelques exemples :
# "tidy selection" : offre plein de possibilités pour spécifier des colonnes # à partir de leur nom, de leur type, de leur indice... tb_risques |> select(codgeo, starts_with('risq_')) tb_risques |> select(where(is.character), risq_nucleaire) # on peut même intégrer une variable externe # ces 3 variables constituent chacune une liste de noms de colonnes de risques c_risques = tb_risques |> select(starts_with('risq_')) |> names() c_risques_naturels = str_c("risq_", c('inond','seisme','terrain')) c_risques_humains = str_c("risq_", c('barrage','industriel','feux','nucleaire')) tb_risques |> select(1:3, all_of(c_risques_humains)) # note : ceci fonctionne, mais plus pour longtemps : avertissement "deprecated" tb_risques |> select(codgeo, c_risques_humains) # il faut donc entourer toute variable (simple ou liste de colonnes) avec all_of()
across() utilise les mêmes mécanismes de sélection concise (tidy selection) à partir d’indices, de portions de noms ou via les types de colonnes : caractère, numérique, etc.
La “tidy selection” ne fonctionne pas partout dans dplyr (ou sa copine tidyr) : seuls quelques verbes en tirent parti comme select(), pivot_longer(), unite(), rename_with(), relocate(), fill(), drop_na() et donc across().
À l’inverse, group_by(), arrange(), mutate(), summarise(), filter() ou count() n’autorisent pas la tidy selection (group_by(1,2) ou arrange(3) ne fonctionnent pas).
Une bonne part de la magie d’across(), on va le voir, consiste à amener la souplesse de la tidy selection au sein de ces verbes qui normalement ne l’implémentent pas (ce “pontage” est aussi dénommé bridge pattern).
1 - rowSums() et across()Voici un premier exemple avec la fonction de sommation de colonnes rowSums(), qui précisément n’est pas compatible avec la tidy selection.
Pour sommer des colonnes, on devait auparavant les écrire toutes (dans un mutate()), ou utiliser une obscure syntaxe associant rowSums() avec un select() et un point.
across() simplifie tout cela :
# on peut sommer des colonnes à la main avec mutate() tb_risques |> mutate(nb_risques = risq_inond + risq_seisme + risq_feux + risq_barrage + risq_industriel + risq_nucleaire + risq_terrain) # ou avec rowSums() tb_risques %>% mutate(nb_risques = rowSums(select(., starts_with('risq_')))) # note : cette syntaxe complexe, où le . rappelle la table en cours, # ne fonctionne qu'avec l'ancien "pipe" %>% # >>> on peut faire plus simple avec across() tb_risques |> mutate(nb_risques = rowSums(across(starts_with('risq_')))) # ou avec une liste de colonnes stockée dans une variable c_risques_humains tb_risques |> mutate(nb_risques = rowSums(across(all_of(c_risques_humains)))) # pour mémoire : cette alternative rowwise() est À EVITER ! # les performances sont catastrophiques (30 s contre 0,5 s ci-dessus) : tb_risques |> rowwise() |> mutate(nb_risques = sum(c_across(all_of(c_risques_humains))))
Cette première utilisation d’across() est basique (et méconnue), elle ne fait intervenir que le premier paramètre d’across() : une sélection de colonnes.
rowSums() (ou sa cousine rowMeans()) conduisent le traitement souhaité (somme ou moyenne) sur ces colonnes.
2 - summarise() et across()Celles et ceux qui ont déjà joué avec across() l’ont probablement employé dans le contexte d’un summarise(), par exemple pour sommer “vite fait” tout un paquet de colonnes numériques.
across() invite à spécifier les colonnes visées, puis le traitement à opérer sur chacune d’entre elles. De façon optionnelle, les colonnes produites par le calcul sont renommées pour mieux traduire l’opération conduite, avec par exemple ajout d’un préfixe ou d’un suffixe aux noms de colonne d’origine.
# série de 5 écritures équivalentes pour compter les communes à risque # avec across et une fonction toute simple tb_risques |> summarise(across(starts_with('risq_'), sum)) # across et une fonction "anonyme", avec une option tb_risques |> summarise(across(where(is.numeric), \(r) sum(r, na.rm = TRUE))) # R 4.1 # across avec l'écriture "en toutes lettres" de la fonction tb_risques |> summarise(across(5:last_col(), function(r) { return( sum(r, na.rm = TRUE) ) })) # across et une fonction anonyme, écriture ultra concise tb_risques |> summarise(across(-(1:4), ~sum(., na.rm = TRUE))) # across avec une variable listant les colonnes tb_risques |> summarise(across(all_of(c_risques), ~sum(., na.rm = TRUE))) # across avec une autre variable et une règle de renommage tb_risques |> summarise(across(all_of(c_risques_humains), \(r) sum(r, na.rm = TRUE), .names = "nb_{col}")) # A tibble: 1 x 4 nb_risq_barrage nb_risq_industriel nb_risq_feux nb_risq_nucleaire <dbl> <dbl> <dbl> <dbl> 3731 1819 6565 480
across() opère un renversement de l’ordre naturel, habituel des opérations, tout en les séparant sous forme de paramètres distincts, de nature très différente : liste (de colonnes) et fonctions (de traitement et de renommage).
Considérez les deux écritures suivantes, la première correspond à nos habitudes de pensée, la seconde, avec across(), introduit une nouvelle façon de modéliser les traitements. Elle n’est pas immédiate à intégrer, elle peut même paraitre abstraite, peu intuitive. Pourtant, l’absorber, franchir ce pas logique, permet de s’ouvrir à de nouvelles dimensions d’analyse et de programmation (dite “fonctionnelle”).
Autre caractéristique fondamentale d’across() : le même traitement est répété indépendamment pour chaque colonne( seule une fonction très particulière comme rowSums() permet de combiner plusieurs colonnes dans une même opération).
Un bouquet de fonctions (par exemple sum et mean) peut être appelé dans un seul across(), en utilisant une liste.
Enfin, comme on l’a déjà souligné, il est très facile avec across() d’injecter des variables dans une chaine de requête, et donc d’écrire ses propres fonctions pour raccourcir et simplifier ses scripts.
3 - mutate() et across()mutate() avec across() suit la même logique qu’un summarise(), tout en préservant le niveau de détail (le nombre de lignes) de la table d’origine. across() permet typiquement de recoder ou “normaliser” (convertir en % par exemple) un ensemble de colonnes.
Les colonnes transformées sont souvent renommées, pour plus de clarté, les colonnes d’origine pouvant être conservées, ou non.
Recodage :
# recoder des colonnes : 1 => 'exposée', 0 => '' tb_risques |> mutate(across(starts_with('risq_'), \(r) ifelse(r == 1, 'exposée', ''))) # recoder selon le risque, 1 => 'barrage', 'inond', 'nucleaire'.... # cur_column() indique le nom de la colonne en cours de lecture tb_risques |> mutate(across(starts_with('risq_'), \(r) ifelse(r == 1, str_sub(cur_column(), 6), ''))) |> select(com, all_of(c_risques_naturels)) # A tibble: 34,839 x 4 com risq_inond risq_seisme risq_terrain <chr> <chr> <chr> <chr> 1 01001 "inond" "" "" 2 01002 "" "seisme" "terrain" 3 01004 "inond" "seisme" "terrain" 4 01005 "" "" "" 5 01006 "" "seisme" "" # ... with 34,834 more rows
Normalisation :
# conversion en % : 100 * nb de communes exposées / nb total de communes tb_risques |> summarise(across(starts_with('risq_'), sum), nb_com = n()) |> mutate(across(starts_with('risq_'), \(r) 100 * r / nb_com)) # A tibble: 1 x 8 risq_inond risq_seisme risq_nucleaire risq_barrage risq_industriel risq_feux risq_terrain nb_com <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <int> 59.2 25.1 1.38 10.7 5.22 18.8 53.8 34839 # conversion en % avec renommage tb_risques |> summarise(across(starts_with('risq_'), sum), nb_com = n()) |> mutate(across(starts_with('risq_'), \(r) 100 * r / nb_com, .names = "part_{str_sub(col, 6)}"), .keep = "unused") # conversion en % avec une variable pour la liste des colonnes à traiter tb_risques |> summarise(across(all_of(c_risques_humains), sum), nb_com = n()) |> mutate(across(all_of(c_risques_humains), \(r) 100 * r / nb_com, .names = "part_{str_sub(col, 6)}"), .keep = "unused") # éliminer les colonnes d'origine # A tibble: 1 x 4 part_barrage part_industriel part_feux part_nucleaire <dbl> <dbl> <dbl> <dbl> 10.7 5.22 18.8 1.38
4 - filter() et 2 variantes d'across() : if_all() et if_any()Que veut dire filtrer une table en considérant tout un ensemble de colonnes ?
Je peux vouloir filtrer cette table des risques de deux façons différentes : dégager les communes cumulant tous les risques, ou celles présentant au moins un risque.
Cette dualité a conduit les concepteurs d’across() à en décliner deux variantes : if_all(), qui reprend la logique d’across() (même condition pour toutes les colonnes), et if_any(), qui ne s’intéresse qu’à la possibilité qu’une colonne au moins remplisse la condition définie par la fonction anonyme.
Par souci de cohérence, across(), étant l’équivalent de if_all(), devient au sein d’un filter() déconseillé (déprécié) au profit de if_all().
# across() est encore utilisable dans filter(), mais plus pour longtemps tb_risques |> filter(across(starts_with('risq_'), \(r) r == 1)) # un avertissement invite à utiliser plutôt if_all() tb_risques |> filter(if_all(starts_with('risq_'), \(r) r == 1)) |> select(com) # A tibble: 4 x 1 com <chr> 1 13039 2 13097 3 42056 4 84019 # 4 communes sont exposées aux 7 risques : Fos-sur-Mer, St-Martin-de-Crau, # Chavanay et Bollène # if_any pour une condition vérifiée sur une colonne au moins # parmi celles décrites dans une variable c_risques_humains tb_risques |> filter(if_any(all_of(c_risques_humains), \(r) r == 1)) |> select(com, all_of(c_risques_humains)) # plus de 10 000 communes exposées à un risque humain # A tibble: 10,679 x 5 com risq_barrage risq_industriel risq_feux risq_nucleaire <chr> <dbl> <dbl> <dbl> <dbl> 1 01007 1 0 0 0 2 01010 1 1 0 0 3 01014 0 1 0 0 4 01024 0 1 0 0 5 01027 1 1 0 0 # ... with 10,674 more rows
5 - mutate() et if_all() ou if_any()if_all() et if_any() ne sont pas réservés au contexte d’un filter(), il est possible de les utiliser avec un mutate(), matérialisant dans une nouvelle colonne le respect d’une condition.
Je pourrai ainsi comparer les communes à risque avec les communes sans aucun risque.
tb_risques |> mutate(risque_humain = if_any(all_of(c_risques_humains), \(r) r == 1)) |> select(com, all_of(c_risques_humains), risque_humain) # A tibble: 34,839 x 6 com risq_barrage risq_industriel risq_feux risq_nucleaire risque_humain <chr> <dbl> <dbl> <dbl> <dbl> <lgl> 1 01001 0 0 0 0 FALSE 2 01002 0 0 0 0 FALSE 3 01004 0 0 0 0 FALSE 4 01005 0 0 0 0 FALSE 5 01006 0 0 0 0 FALSE # ... with 34,834 more rows # variante : un comptage simple tb_risques |> count(if_any(all_of(c_risques_humains), \(r) r == 1)) |> select(`exposition risque humain` = 1, nb_com = n) # A tibble: 2 x 2 `exposition risque humain` nb_com <lgl> <int> 1 FALSE 24160 2 TRUE 10679
6 - group_by() et across()group_by() ne permet pas d’utiliser directement la “tidy selection”, across(), dans sa syntaxe la plus simple (sans fonction), lui apporte cette souplesse d’écriture.
# regroupement selon les colonnes d'indice 2 à 4 tb_risques |> group_by(across(2:4)) |> summarise(across(where(is.numeric), sum)) # regroupement selon les colonnes de type caractère, sauf la 1ère tb_risques |> group_by(across(where(is.character) & -1)) |> summarise(across(where(is.numeric), sum)) tb_risques |> group_by(across(where(is.character) & -1)) |> summarise(across(all_of(c_risques_humains), sum)) # A tibble: 96 x 7 # Groups: dep, reg [96] dep reg lib_reg risq_barrage risq_industriel risq_feux risq_nucleaire <chr> <chr> <chr> <dbl> <dbl> <dbl> <dbl> 1 01 84 Auvergne-Rhône-Alpes 70 56 0 20 2 02 32 Hauts-de-France 0 48 0 0 3 03 84 Auvergne-Rhône-Alpes 73 5 31 0 4 04 93 Provence-Alpes-Côte d'Azur 53 14 173 1 5 05 93 Provence-Alpes-Côte d'Azur 17 37 162 0 # ... with 91 more rows
Il devient également possible, avec across(), d’injecter une variable dans un group_by(), comme on va le voir dans la section suivante.
7 - arrange() et across()Avec across(), le verbe de tri arrange() gagne lui-aussi en souplesse d’écriture.
# cette écriture ne marche pas, arrange n'est pas "tidy select" compatible tb_risques |> arrange(3) # mais avec across, ça marche tb_risques |> arrange(across(3)) # on peut utiliser desc à titre de fonction tb_risques |> arrange(across(3, desc))
Ce bloc plus riche considère, par département, la part de communes exposée au risque rupture de barrage. Le type de risque devient un paramètre, prélude à l’écriture possible d’une fonction.
# deux variables pour cibler un risque risq = 'barrage' col_risq = str_glue("risq_{risq}") # risque barrage par département tb_risques |> group_by(dep) |> summarise(across(all_of(col_risq), sum), nb_com = n()) |> mutate(across(all_of(col_risq), \(r) 100 * r / nb_com, .names = "part_{.col}"), .keep = 'unused') |> # on ne garde pas les variables d'origine arrange(across(str_glue("part_risq_{risq}"), desc)) # avec str_glue(), across() peut même décoder une formule ! # A tibble: 96 x 2 dep part_risq_barrage <chr> <dbl> 1 13 46.2 2 46 38.0 3 38 34.0 4 10 32.7 5 19 30.7 # ... with 91 more rows # Bouches-du-Rhône, Lot, Isère, Aube et Corrèze ont la plus forte # part de communes exposées au risque de rupture de barrage
Cette dernière variante utilise across() à tous les étages : group_by(), summarise(), mutate() et arrange() !
# nouvelle variable pour les colonnes de regroupement # on veut pouvoir regrouper soit par département, soit par région # (avec le libellé associé) nivgeo = c("reg","lib_reg") tb_risques |> group_by(across(all_of(nivgeo))) |> summarise(across(all_of(col_risq), sum), nb_com = n(), .groups = 'drop') |> # raccourci pour ungroup() mutate(across(all_of(col_risq), \(r) 100 * r / nb_com, .names = "part_{.col}"), .keep = 'unused') |> arrange(across(str_glue("part_risq_{risq}"), desc)) # A tibble: 13 x 3 reg lib_reg part_risq_barrage <chr> <chr> <dbl> 1 84 Auvergne-Rhône-Alpes 21.6 2 76 Occitanie 20.0 3 93 Provence-Alpes-Côte d'Azur 19.6 4 75 Nouvelle Aquitaine 13.1 5 44 Grand-Est 10.3 # ... with 8 more rows
Ces 7 exemples démontrent la puissance et la flexibilité d’across(), qui nous permet d’écrire des programmes plus élégants, plus flexibles.
Ayez le réflexe DRY : Don’t Repeat Yourself. Dès que vous détectez une répétition dans vos scripts, la même formule réécrite pour x colonnes, des blocs de code qui ne diffèrent que par quelques variables, il y a de fortes chances qu’across() vous rende service, vous aide à écrire des scripts plus robustes, lisibles et paramétrables.
across() fait intervenir, le plus souvent, l’écriture d’une petite fonction (dite anonyme), matérialisant l’opération à répéter, qui peut ainsi être optimisée.
Il vous invite à écrire vos propres fonctions plus globales, sans en passer par la complexité des {{}}, enquos() et autres :=, toutes syntaxes assez vilaines, impossibles à retenir (et à expliquer).
Pour aller plus loin- Column-wise operations
- Why did it take so long to discover across() ?
- Bridge patterns
- across : appliquer des fonctions à plusieurs colonnes
- Mon top 7 des évolutions récentes de tidyverse
L’article across() est plus puissant et flexible qu’il n’y parait est apparu en premier sur Icem7.
-
17:12
Geomatys se développe et recrute un(e) full stack développeur (se)
sur Le blog de GeomatysNous sommes à la recherche d’un(e) développeur(euse) Full Stack (Bac+5 ou Ecole d’ingé.) dans l’univers Java avec une première expérience (ou stage) réussie en Java/Spring et/ou Javascript/Angular
Ce que nous cherchons chez vous :
- De la curiosité. En veille permanente sur l’évolution des technologies
- Autonomie et pragmatisme dans vos prises de décisions
- Une capacité et un plaisir à travailler en équipe
- De la rigueur. La lisibilité du code/des Api est fondamentale. Les tests font partie intégrante de votre process de dev.
- Une envie de travailler sur des technologiques riches
- Attentif à l’architecture avec réflexion sur les performances de gestion de données volumineuses et de leur traitements
Si vous avez de l’enthousiasme, une appétence pour la cartographie / les problématiques spatiales, et une envie de travailler dans un domaine ultra-innovant, envoyez-nous votre CV (isabelle.pelissier@geomatys.com), pas besoin de lettre de motivation, rien de tel que des projets concrets pour juger de vos compétences (liens Github… ou autre)
Poste à pourvoir sur Montpellier
Salaire selon expérience
Qui sommes-nous ?
GEOMATYS est un éditeur de logiciel qui développe depuis 15 ans des produits et des nouveaux systèmes d’informations permettant de traiter l’information géographique. Notre activité d’édition logicielle nous conduit à développer des bibliothèques dédiées au traitement de gros volume d’information géographique, des Geo-Webservices et des frameworks cartographiques, que nous intégrons ensuite pour les besoins de nos clients.
Nous sommes une société influencée par la forte culture technique de ses dirigeants, développant des projets innovants au service d’industriels et de scientifiques dans des domaines aussi variés que l’Environnement, le Spatial ou la Défense.
Grâce à un travail reconnu en recherche et développement, notre société, GEOMATYS, a gagné une expertise lui permettant de travailler désormais auprès de grands comptes (Naval Group, Airbus, Le CNES ….).
Vous intégrerez une équipe dédiée au développement d’applications à fortes dominantes géographiques, constituée de développeurs fullstack principalement orientés Java et angular, pour des environnements Docker/Kubernetes, combinés à de nombreux produits open-sources tel que la suite Elastic (ELK), ou PostGreSQL/PostGIS.
The post Geomatys se développe et recrute un(e) full stack développeur (se) first appeared on Geomatys.
-
21:34
Divagations à propos du temps
sur Icem7Bonjour, je suis le temps.
Donnée universelle, avec l’implacable régularité du métronome, je passe.
Immuable et inexorable, j’avance de la même manière, partout, toujours.
Je suis la richesse la plus équitablement répartie : 60 secondes par minute, 24 heures par jour, 12 mois par an, c’est pareil pour tout le monde.
Ce qui change, pour vous autres, êtres humains, c’est la perception que vous avez de moi. Dans l’ennui, la peine ou la douleur, je vous semble long. Mais dès que la joie fleurit, vous trouvez que je passe trop vite.
Dans l’époque frénétique et connectée où vous vivez, où les sollicitations pleuvent de toutes parts pour beaucoup d’entre vous, vous êtes nombreux à dépenser beaucoup d’énergie à courir après les aiguilles de la montre. Je suis toujours présent, et pourtant, je vous manque.
Cependant, je reste bien toujours le même. La seule inconnue, pour chacun de vous, c’est de savoir quand cesserez-vous de voir l’horloge tourner. Moi, de toute façon, je continuerai, jusqu’à la fin des temps…
L’horloge ne cesse jamais de tourner
Évidemment, depuis la nuit des temps, on a cherché à me mesurer. De calendriers antiques en cadrans solaires, on a voulu me quantifier avec toujours plus de précision, jusqu’aux plus précises horloges atomiques. Cependant, difficile de savoir exactement quand j’ai commencé. Et, question encore plus vertigineuse, savoir si je finirai un jour.
La statistique, qui se penche sur tous les domaines de la connaissance, n’a pas manqué de s’intéresser à moi. Le moindre indicateur ne fournit aucune information utile s’il n’est pas daté. Dire que la population totale de la ville de Toulouse est de 498 596 habitants ne présente un intérêt qu’en précisant en 2019.
Et cela prend une toute autre dimension si l’on ajoute que cette population était de 466 219 en 2013. Cela permet au statisticien de faire quelque chose dont il raffole : une comparaison
! Et même de calculer une évolution
! Entre 2013 et 2019, la population toulousaine a augmenté de près de 7 %.
Le taux d’évolution est assez simple à calculer : Te = ((Va-Vd) / Vd) * 100 = (Va/Vd – 1) * 100, où Va et Vd sont les valeurs de départ et d’arrivée. Il y a des calculateurs en ligne qui font le calcul tout seuls. Un peu plus compliqué, le taux d’évolution annuel moyen est, comme son nom l’indique, une moyenne par an. Dans cet exemple, il vaut 1,13 %. La formule pour le calculer est assez jolie, même si elle peut intimider les personnes réticentes aux mathématiques : Tem = (((Va/Vd)**(1/n)) – 1) * 100, où n est le nombre de périodes, 6 dans cet exemple.
La boîte à outils du statisticien
Avec dans sa trousse à outils, ces 2 formules, ainsi que les calculs d’une moyenne simple et d’un pourcentage, le statisticien dispose de la base indispensable. Ensuite, une grande partie de son art réside dans savoir représenter les données qu’il a calculées, pour pouvoir les interpréter.
Une donnée, pour avoir du sens, doit être datée. Elle en prend davantage s’il est possible de la comparer. Et moi, le temps, je déploie tout mon potentiel lorsque le statisticien dispose de toute une série de données. L’Insee consacre tout une rubrique de son site aux séries chronologiques. Dans la rubrique consacrée à la population, on trouve des séries remontant jusqu’à 1876.
La série chronologique va de pair avec sa représentation la plus naturelle : la courbe d’évolution. Peu importe l’unité de mesure, on me couche sur l’axe des abscisses. Et on mesure la donnée représentée sur l’axe des ordonnées. Par exemple, l’électrocardiogramme mesure l’activité électrique du cœur.
Plutôt qu’une courbe d’évolution, dans les cas où le nombre de périodes de la série n’est pas trop important, un diagramme en barres verticales peut opportunément être utilisé. Et si les intervalles sont d’inégales amplitudes, le statisticien aura recours à l’histogramme, dans lequel la grandeur représentée est proportionnelle à la surface de chaque barre.
Un autre moyen efficace de représenter des données temporelles est de construire une série de petits graphiques, un pour chaque période (sous réserve que le nombre de périodes ne soit pas trop grand). Les outils numériques rendent aussi possible la construction d’animations temporelles, qui peuvent produire des effets visuels éloquents.
La première courbe d’évolution de l’histoire
Cette forme de représentation semble aujourd’hui une évidence tant on la rencontre un peu partout. Cela n’a pas toujours été le cas. On doit ses premières apparitions, dans les années précédant la Révolution française, au génial et inventif William Playfair. Le même a également eu l’idée des diagrammes en barres et circulaires.
Cela s’applique bien en cartographie statistique : créer une série de cartes thématiques et les afficher successivement rend visible l’évolution du phénomène cartographié dans le temps et dans l’espace. Ceci est par exemple mis en œuvre dans l’application Géodes, de Santé Publique France, pour suivre l’évolution hebdomadaire et quotidienne des taux d’incidence, de positivité et de dépistage du Covid-19 (données de laboratoires Si-Dep).
La distance, la vitesse et moiRevenons pour finir sur cette bonne vieille courbe d’évolution. En voici un exemple très éloquent :
Il provient de la thèse de doctorat intitulée « Les transports face au défi de la transition énergétique. Explorations entre passé et avenir, technologie et sobriété, accélération et ralentissement. », soutenue en novembre 2020, par Aurélien Bigo. Il représente l’évolution de la distance parcourue par jour. Il est plus conçu pour les lecteurs experts d’un rapport de thèse que pour le public large d’un journal, par exemple. On imagine bien qu’Éric Mauvière, expert en datavisualisation, aurait quelques petites remarques sur la présentation de ce graphique, sur les titres, les légendes, la typographie, le choix des couleurs… Il est déjà très intéressant tel qu’il est.
Il montre quelle place absolument prépondérante a pris la voiture individuelle dans les modes de déplacement en à peine un siècle. Les progrès technologiques, permis par l’abondance de sources d’énergie, ont considérablement augmenté les vitesses de déplacement. Des vitesses plus élevées permettent d’aller plus loin ou de mettre moins de temps. Visiblement, la priorité a été donnée à aller plus loin plutôt qu’à gagner du temps. Je ne sais pas vous, mais moi, cela me fais réfléchir sur l’importance que l’on m’accorde, ou pas…
L’article Divagations à propos du temps est apparu en premier sur Icem7.
-
14:20
Revue de presse du 21 octobre 2022
sur GeotribuL'automne est là et bien là et les news tombent aussi régulièrement et nonchallamment que les feuilles des arbres. A vos géorateaux et bon ramassage !
-
18:51
Publier des rasters volumineux avec GeoServer
sur GeomatickEn Système d’Informations Géographiques (SIG), la manipulation de données rasters demande souvent des ressources informatiques importantes. Le poids d’une image raster augmente notamment avec sa résolution spatiale et sa couverture géographique. Mais la complexité de gestion de ce type de donnée géographique ne se limite pas aux propriétés des pixels… Continuer à lire →
L’article Publier des rasters volumineux avec GeoServer est apparu en premier sur GEOMATICK.
-
12:49
Journée d’étude : L’histoire de la cartographie et son écriture à l’épreuve du renouvellement, Campus Condorcet (Aubervilliers), 25/11/2022
sur Cartes et figures du mondeDepuis les années 1980, l’histoire de la cartographie a vu ses concepts, ses objets, ses méthodes d’investigation et ses manières d’écrire se transformer profondément sous l’influence des analyses de John Brian Harley et de ses émules (D. Woodward, C. Jacob, M. Edney, etc.). Une nouvelle manière d’écrire l’histoire de la cartographie s’est progressivement installée, y compris en France, en lien avec une réflexion plus générale sur les représentations de l’espace.
Quarante ans après, la journée d’étude organisée par la Commission « Histoire » du Comité Français de Cartographie se propose de revenir sur ces évolutions et le tournant « déconstructionniste », mais aussi d’interroger de façon élargie la cartographie et son histoire en la confrontant aux apports récents des sciences humaines (histoire, histoire de l’art, littérature, anthropologie, sociologie, etc.) et à la dématérialisation massive tant des modes de production et usages de la cartographie que des méthodes permettant de l’explorer et de l’analyser.
Nicolas Bion, Globe terrestre dressé sur les observations de Mrs de l’Académie royale des sciences et sur les nouveaux mémoires des plus fameux et expérimentée (sic) voyageurs, Paris, avant 1733 Programme
- 9 h : Accueil et introduction
- 9 h 30 -11 h : Table-ronde : Comment écrire aujourd’hui l’histoire de la cartographie ? Débats et perspectives, avec Christian Jacob, Josef Konvitz et Gilles Palsky
Animée par Jean-Marc Besse (CNRS-EHESS)
- 11 h -11 h15 : Pause-café
- 11 h15 -12 h 30 : Première session : l’histoire de la cartographie à la rencontre de la littérature et de l’histoire des savoirs
Sous la présidence d’Emmanuelle Vagnon (CNRS-LAMOP)- Isabelle Ost (Université Saint-Louis, Bruxelles) : Littérature et cartographie : épistémologies croisées
- Zoé Pfister (Université de Bourgogne) : « Lieux, objets et gestes » du savoir cartographique. Approches spatiale, matérielle et pragmatique du projet de Lannoy de Bissy (1873-1889)
- 12 h 30 -14 h : Déjeuner
- 14 h -15 h 30 : Deuxième session : l’histoire de la cartographie et son écriture
Sous la présidence d’Émilie d’Orgeix (EPHE-PSL)- Monika Marczuk (BnF, Dép. des Cartes et plans) : Approche processuelle et approche pragmatique de l’histoire de la cartographie. Convergences et limites
- Carolina Martinez (CONICET, Buenos Aires) : « Ibérisation », « atlantisation », américanisation : l’histoire de la cartographie des « mondes ibériques » au début du XXIe siècle
- Anca Dan (CNRS, Paris) : De l’histoire de la cartographie à l’histoire des représentations spatiales : de l’utilité du postcolonialisme à l’ère numérique
- 15 h 30 -16 h : Pause-café
- 16 h -17 h 30 : Troisième session : les usages de l’histoire de la cartographie dans l’enseignement et dans la construction des savoirs
Sous la présidence d’Isabelle Warmoes (Musée des plans reliefs)- Jordana Dym (Skidmore College, NY, USA) : Leçons de la salle de classe : la pédagogie comme travail de terrain pour l’enseignement de l’histoire de la carte et de la cartographie
- Félix de Montety (Université Grenoble Alpes) : Le langage, des cartographes. Comment écrire l’histoire des méthodes de représentation et approches visuelles en cartographie linguistique
- Fanny Madeline et Alexis Lycas (Université Paris I et EPHE-PSL) : Cartographier l’Europe et la Chine médiévales : productions et usages de la carte chez les médiévistes
- 17 h 30 : Conclusions de la journée.
- 25 novembre 2022
- Campus Condorcet – Centre des colloques – Salle 100 – Aubervilliers (Métro ligne 12, Front Populaire)
- Entrée libre
- Contact : catherine.hofmann@bnf.fr
-
14:20
Revue de presse du 7 octobre 2022
sur GeotribuDans le pipeline de l'actualité : le Géotuileur IGN, de la 3D, un fond OSM VTT, un atlas de l'anthropocène, le 30DayMapChallenge qui approche, le SAGEO qui s'annonce, un Podcast géomatique, un livre PostGIS
-
10:00
Faire une carte façon Ed Fairburn avec QGIS
sur GeotribuUtiliser les modes de fusion pour produire avec QGIS une carte inspirée des dessins d'Ed Fairburn.
-
14:20
Revue de presse du 23 septembre 2022
sur GeotribuGeoRDP du 23 septembre : les GéoDataDays 2022 ont été couronnés de succès, certaines des briques logicielles les plus connues sont mises à jour, des initiatives viennent redonner vie à des illustres cartographes et la géomatique continue de nous donner à voir sa diversité et son intérêt.
-
10:41
Recrutement: IE en Télédétection
sur Le blog de GeomatysLa Tour du Valat est un institut de recherche pour la conservation des zones humides méditerranéennes basé en Camargue, sous le statut d’une fondation privée reconnue d’utilité publique. Fondée en 1954 par le Dr Luc Hoffmann, elle est à la pointe dans les domaines de la recherche multidisciplinaire, l’établissement de ponts entre science, gestion et politiques publiques et l’élaboration de plans de gestion. Elle s’est dotée d’une mission ambitieuse : « Les zones humides méditerranéennes sont préservées, restaurées et valorisées par une communauté d’acteurs mobilisés au service de la biodiversité et des sociétés humaines ».
La Tour du Valat a développé une expertise scientifique reconnue internationalement ; elle apporte des réponses pratiques aux problèmes de conservation et de gestion durable des ressources naturelles. La Tour du Valat emploie environ 80 personnes dont une quinzaine de chercheurs et autant de chefs de projets. Elle accueille également sur son site plusieurs autres structures, ainsi que de nombreux doctorants, post-doctorants, stagiaires et/ou volontaires en saison estivale. Plus de détail sur http://www.tourduvalat.org
La Tour du Valat recrute un/e Ingénieur d’étude en analyse de données pour le suivi des zones humides à l’aide des outils d’Observation de la Terre (OT)
Contexte
Le Bassin Méditerranéen est un des 32 Hotspots mondiaux de biodiversité. Ceci grâce, notamment, à la présence d’une grande diversité de zones humides, considérées comme les écosystèmes les plus riches et les plus productifs de la région. Cependant, malgré leur importance pour l’Homme et la nature, ces milieux sont également les plus menacés par les activités humaines. En effet, selon une étude récente réalisée par l’Observatoire des Zones Humides Méditerranéennes (OZHM), on estime que près de la moitié des habitats humides naturels ont disparus depuis les années 1970 au sein de cette région. Une des principales causes de ce déclin rapide serait leur perte directe, avec leur conversion vers d’autres formes d’usage des sols.
Face à cette situation alarmante, il est donc crucial de rassembler un maximum d’informations pertinentes sur l’état des zones humides méditerranéennes et d’analyser les tendances de leurs habitats naturels ainsi que celles des principales menaces qui pèsent sur eux. C’est dans ce contexte que l’OZHM, coordonné par la Tour du Valat dans le cadre de l’Initiative MedWet, développe depuis une dizaine d’année un ambitieux programme de suivi de ces écosystèmes, basé sur les outils et technologies d’Observation de la Terre (OT). Parallèlement, de nouvelles approches d’analyse des images satellitaires ont prouvé leur capacité à extraire de l’information pertinente. Principalement basées sur des méthodes d’apprentissage profond (Deep Learning) et pour les plus récentes sur le transfert de domaine. Elles permettent, par exemple, d’appliquer des modèles, appris sur une zone donnée, sur d’autres zones pour lesquelles il existe peu ou pas de données d’apprentissage. Ce poste d’Ingénieur d’Étude en Télédétection proposé ici, vient donc répondre à ce besoin d’amélioration des connaissances sur les zones humides à l’aide des outils d’OT. Il s’agit d’une part, de mettre en place une chaine de traitements basée sur des algorithmes développés en collaboration avec divers partenaires scientifiques de la Tour du Valat, tels que le laboratoire ICube de l’Université de Strasbourg ou encore l’UMR Littoral, Environnement, Télédétection, Géomatique (LETG) de l’Université Rennes II et, d’autre part, de valider celles-ci sur des données réelles fournies par l’OZHM. La personne retenue devra donc contribuer à la mise en œuvre de différents projets en cours, notamment le projet AIonWetlands (appuyé par le programme Space Climate Observatory), ainsi qu’un projet de R&D porté par le Ministère de la Transition Ecologique et visant à développer une modélisation nationale des milieux humides en France métropolitaine et de leurs fonctions.
Missions
- Contribuer, avec d’autres partenaires techniques de la Tour du Valat, à la mise en œuvre d’outils d’analyse et de traitement des images satellites (essentiellement optiques), notamment ceux intégrant des algorithmes d’Intelligence Artificielle (Deep Learning et Machine Learning)
- Extraire, à l’aide de ces outils, des informations pertinentes sur l’état et les tendances des zones humides suivies, leurs fonctions, ainsi que les principales pressions qu’elles subissent
- Contribuer au développement et à l’application de protocoles de validation de ces résultats cartographiques
- Automatiser, le plus possible, les chaines de traitement et les intégrer dans les protocoles de suivi de l’OZHM, notamment en lien avec les indicateurs spatialisés
- Contribuer, au développement et à la gestion des bases de données spatialisées de l’OZHM (indicateurs de suivi des zones humides)
- Contribuer à la rédaction des rapports techniques des différents projets dans lesquels il/elle sera impliqué(e), en particulier les deux mentionnés plus haut
- Participer à l’élaboration des différents produits de l’OZHM, notamment les rapports sur l’état et les tendances des zones humides méditerranéennes
Profil et compétences recherchées
Indispensables :
- Bac+5 (M2 ou Ingénieur) en informatique, en télédétection ou en géomatique ou toute autre discipline dans les sciences de l’environnement intégrant une forte composante en traitement d’imagerie satellitaires (géographie, aménagement du territoire/littoral, écologie, etc.)
- Maîtrise des outils SIG et de traitement des données d’Observation de la Terre
- Connaissances en analyse de données et apprentissage. Une bonne pratique des algorithmes d’apprentissage profond, sans être obligatoire, sera un plus indéniable
- Autonomie, esprit d’initiative et bonnes capacités d’analyse, de synthèse et rédactionnelles
- Capacité à travailler en équipe, notamment avec des partenaires externes
- Anglais scientifique et de communication en milieu professionnel fortement souhaité
Constitueraient des atouts :
- Connaissance des indicateurs pour le suivi des écosystèmes (état, tendances et pressions)
- ·Maitrise des outils statistiques pour l’analyse des données
- Connaissance et/ou expérience en méditerranée
Encadrement
L’Ingénieur d’Etude sera intégré(e) au sein de l’équipe du Thème « Dynamiques des Zones Humides et Gestion de l’Eau » et placé(e) sous la supervision du responsable de l’Axe « Dynamique Spatiale des Zones Humides », M. Anis Guelmami guelmami@tourduvalat.org.
Type de contrat : Le poste est à pourvoir en Contrat à Durée Déterminée de 18 mois.
Rémunération : 2300€ à 2600€ brut mensuel, selon expérience professionnelle.
Date de prise de poste : Le poste est à pourvoir dès que possible.
Lieu de travail : Tour du Valat, Le Sambuc, 13200 Arles avec la possibilité de télétravailler 2j/semaine.Comment postuler
Envoi des candidatures à Johanna Perret : perret@tourduvalat.org
(Référence à indiquer : TdV-2022-Suivi Spatialisé ZH) avant le 16 octobre 2022, comportant :- Une lettre de motivation
- Un curriculum vitae
- Deux contacts de référents
Les candidat(es) présélectionné(es) seront convoqué(es) pour un entretien en visio-conférence ou en présentiel en fonction des contraintes géographiques.
Pour toute question sur le processus de soumission de candidatures, merci de vous adresser à Johanna Perret perret@tourduvalat.org.
The post Recrutement: IE en Télédétection first appeared on Geomatys.
-
14:20
Revue de presse du 9 septembre 2022
sur GeotribuDécouvrez notre sélection de la quinzaine : Géoplateforme, LiDAR, le 30DayMapChallenge qui se prépare, le SotM, des évènements autour de la carte,...
-
14:04
Le syndrome de l’empilement
sur Icem7Les graphiques en barres empilées sont notoirement peu lisibles, la presse le sait et les évite. Des alternatives plus efficaces existent. Nous les rencontrons pourtant partout dans la production institutionnelle : pas une étude statistique, pas un rapport d’activité où l’on ne subisse ces guirlandes de bâtons multicolores[1], leurs légendes extensibles et leurs inévitables aides au déchiffrage.
Prenons deux exemples publiés la semaine dernière : à chaque fois la matière est intéressante, mais le traitement graphique la dessert.
Vous avez 5 secondes pour capter une première idée simple qui vous surprenne et vous donne envie d’aller plus loin dans l’exploration (j’aime bien ce test basique, que m’a confié un data-journaliste).
Publication de la Drees : Impact des assurances complémentaires santé et des aides sociofiscales à leur souscription sur les inégalités de niveau de vie (septembre 2022)
Publication de l’Insee : Un habitant sur sept vit dans un territoire exposé à plus de 20 journées anormalement chaudes par été dans les décennies à venir (août 2022)
Un graphique inutile car trop complexe, dans une étude par ailleurs fort intéressante
Vous n’y êtes pas arrivés ? Ou vous avez seulement vu dans le 1er exemple que la CMU concerne surtout les plus précaires, ce qui ne vous a rien appris ? Ne stressez pas, c’est normal. Ces graphiques n’offrent pas de point d’entrée évident, et l’absence de titre informatif ne fait rien pour les sauver. Faute de base horizontale ou verticale commune, la plupart des séries (identifiées par une même couleur) ne sont pas signifiantes « dans l’instant minimal de vision », pour reprendre les mots de Jacques Bertin, le grand sémiologue français.
Considérez par exemple la série rose pâle ci-dessus : présente-t-elle ou non des variations significatives ? Cela ne saute pas aux yeux. Seules les séries jaunes et violettes, aux extrémités, sont rapidement évaluables, disposant d’un solide point d’appui à gauche ou à droite.
Souvent, la juxtaposition de couleurs vives complique l’effort de sélection que l’œil doit conduire pour isoler chaque concept. On le constate dans le premier graphique, par ailleurs constellé de chiffres sans grand intérêt. Enfin, qui souffre de déficience visuelle, même légère, sera peu à la fête, compte tenu du nombre de couleurs à distinguer ou de l’emploi abusif de l’opposition rouge / vert.
Le second graphique (Insee) est un peu plus amical : moins de chiffres, des couleurs plus douces, des axes plus explicites. Mais je n’en retiens rien – si je refuse d’y passer plus de 20 secondes – trop de catégories sans contraste évident surchargent ma mémoire de travail.
Désempilez et simplifiez en catégorisantRevenons aux données publiées par la Drees. Comment leur rendre mieux justice ?
Il s’agit de dépenses de santé et des différentes aides soutenant les ménages selon leur niveau de vie : cela concerne et parle – a priori – à tout le monde. Quels sont les principaux contrastes, les lois et les ordres de grandeur à retenir ?
La science de la sémiologie graphique, formalisée par Jacques Bertin et Edward Tufte, pour ne citer que les plus connus, nous donne les règles à suivre, dont voici une mise en musique.
Les variables visuelles les plus efficaces sont la position dans le plan et la longueur rapportée à une base commune. L’organisation du diagramme suivant, en colonnes, et ses barres horizontales alignées à gauche répondent à ces critères.
La loi de proximité issue de la théorie de la Gestalt[2] privilégie le légendage direct de chaque série. Il est naturellement assuré par la disposition tabulaire : plus besoin d’une légende déportée obligeant à des allers et retours visuels fastidieux.
La théorie de la charge cognitive (que Bertin anticipe) encourage les tris logiques et l’extraction de grandes catégories : on oppose ici de gauche à droite les aides ciblant les niveaux de vie modestes à celles concernant les plus aisés. À côté de ces deux grandes catégories, qui dégagent une première image mentale facile à imprimer, le profil du total des aides relève d’un autre niveau de lecture : la distribution est symétrique, elle favorise les extrémités de l’éventail des niveaux de vie.
L’emploi de la couleur, subtil et souriant, souligne ces différents niveaux de lecture. Il laisse de côté le funeste duo rouge-vert rétif aux daltoniens, et n’hésite pas à utiliser le gris.
Quelques chiffres clés sont portés pour saisir l’ordre de grandeur des barres et souligner les maxima ainsi que les oppositions entre les deux principaux groupes d’aides. L’unité € précise ces chiffres pour une appréhension immédiate de ce dont il s’agit (un montant financier).
Avec ces chiffres repères, nul besoin de dessiner une grille ou des axes gradués, qui surchargeraient inutilement le graphique. Précisons que les données de l’étude sont téléchargeables pour qui voudrait les consulter en détail ou, comme moi, faire ses propres graphiques.
L’aide à la lecture sous le graphique – dont on devrait même pouvoir se passer – vient surtout expliciter les notations « D1-D10 ». Pour soulager le lecteur et lui éviter de scanner le diagramme, elle se rapporte au premier chiffre, au premier symbole visuel rencontré dans le sens de la lecture.
Certains sigles sont explicités : CMU-C, ACS. D’autres libellés sont un peu abrégés pour une meilleure homogénéité et un bandeau d’en-tête réduit à 3 lignes seulement. Tous les textes s’affichent à l’horizontale, le lecteur n’a pas à torturer ses cervicales pour comprendre un axe.
La date des données est plus clairement exposée, de fait elle est un peu ancienne. Depuis, CMU-C et ACS ont été fusionnées dans une nouvelle mesure : la « complémentaire santé solidaire » (2019).
Le titre enfin, l’élément le plus important de cette visualisation, expose le message clé. Sur deux lignes, il présente une coupure « logique » en fin de première ligne (règle de lisibilité trop méconnue elle aussi). La nature de l’indicateur présenté apparait en sous-titre, c’est à la fois nécessaire et suffisant.
Ce n'est pas au lecteur de faire l'effort de déchiffrer, c'est à vous de faire lisible et mémorableOn le voit, cette nouvelle représentation ne prend pas plus de place que l’original. Elle expose autant de données et surtout elle révèle bien davantage, avec plus d’efficacité. Davantage qu’un tableau croisé mis en couleurs, tel quel, dans un « grapheur », elle traduit la démarche analytique du rédacteur-concepteur. Chaque petit ciselage compte et contribue à l’évidence de l’ensemble : confort, équilibre, simplicité, mémorabilité.
Ce n’est pas au lecteur de faire l’effort de déchiffrer vos graphiques, c’est à vous, auteur, statisticien, expert du sujet, pédagogue obstiné, de faire ce qu’il faut pour que le ou les messages principaux « sautent aux yeux ».
Ce travail, la « résolution du problème graphique » comme l’énonçait Bertin, apporte beaucoup de plaisir à celui qui le mène. Des outils intelligents comme DataWrapper – conçus par des sémiologues avertis – le rendent accessible à tout un chacun en offrant de tester en confiance différentes variantes. Ne vous en privez pas, et surtout n’en privez pas vos lecteurs !
« La plus grande qualité d'une image,
John Tukey, Exploratory Data Analysis, 1977
c'est quand elle nous amène à remarquer
ce que l'on ne s'attendait pas à voir. »Voici quelques ressources :
[1] Stacked bars are the worst, Robert Kosara, 2016
[2] Psychologie de la forme, Wikipedia
[3] What to consider when creating stacked column charts, Lisa Charlotte Muth, 2018
PS : Il faudrait conduire un autre genre d’étude pour comprendre l’étrange fascination qu’exerce le diagramme en barres empilées sur le statisticien. J’ai quelques hypothèses en tête. Ce visuel consacre le geste statistique canonique, croiser deux critères. Il permet de “mettre à disposition” dans un petit espace un volume significatif de données. Docile à la mise en couleurs, il ravit le concepteur tout comme le maquettiste. Ne cédant pas à la facilité d’un message trop trivial, il rappelle – discrètement – que l’accès à la connaissance se mérite !
L’article Le syndrome de l’empilement est apparu en premier sur Icem7.
-
14:20
Revue de presse du 26 août 2022
sur GeotribuGeotribu prépare sa rentrée, découvrez notre sélection du mois d'Août : OpenLayers, Boule, PostgreSQL, QGIS, OpenStreetMap, open data, exposition,...
-
14:00
API Python de FME : comment travailler avec des rasters et GDAL
sur GeotribuComment travailler avec des librairies Python dans FME. Illustration avec GDAL.
-
14:20
Revue de presse du 29 juillet 2022
sur GeotribuDécouvrez notre sélection du mois de Juillet : PhilCarto, Bertin.js, de la carte aux terrains de foot, le Tour de France, les Rencontres Géomatiques de La Réunion qui se préparent...
-
10:20
Classification automatisée avec le plugin QGIS dzetsaka
sur GeotribuPrésentation de Dzetsaka, un plugin QGIS pour faire de la classification semi-automatisée.
-
20:00
Réaliser une carte comme la couverture de l'album Unknow Pleasures de Joy Division
sur GeotribuComment faire des cartes à la mode de Joy Division avec les générateurs de géométrie de QGIS
-
18:41
Cartes et géomatique : les articles 2016 sont en ligne
sur Cartes et figures du mondeCartes & Géomatique précédemment Le Monde des cartes est une publication trimestrielle du Comité français de cartographie. Les articles de la revue sont publiés sur le site du CFC un an après leur publication sur support papier. Ne sont recensés ici que les articles en histoire de la cartographie.
n° 228, juin 2016 : “Cartographie et traités de paix (XVe-XXe siècle)” (actes du colloque des 19 et 20 novembre 2015, Archives diplomatiques, La Courneuve)Introduction (Isabelle Warmoes, Catherine Hofmann, Isabelle Nathan)
Entre la liste et le terrain, la carte dans les négociations de paix au XVe siècle (Dauphiné et Savoie, France et Bourgogne) (Léonard Dauphant)
Les cartes au service de la diplomatie (Jean-François Moufflet)
La rectification de la frontière du nord en 1779, sur le terrain, à La Flamengrie (Jean-Louis Renteux)
Une frontière pour les Pyrénées : l’épisode trop méconnu de la commission topographique franco-espagnole Caro-Ornano (1784-1792) (Jean-Yves Puyo, Jacobo García Álvarez)
La frontière franco-italienne sous le Consulat et l’Empire (Michel Lechevalier)
Le géographe Kiepert et les Balkans à Berlin (1878) (Goran Sekulovski)
Cartes topographiques et détermination des frontières en zones montagneuses (Nicolas Jacob)
La délimitation des frontières maritimes – Le rôle du cartographe, principes généraux, cas d’école (Eric van Lauwe, Didier Ortolland, Jean-Pierre Pirat)
Les limites de la carte, objet juridique (Françoise Janin)
L’expertise territoriale des vaincus austro-hongrois (Nicolas Ginsburger)
Le plébiscite de Klagenfurt du 10 octobre 1920 (Roseline Salmon)
Cartes et contre-cartes à la conférence de paix de Paris (1919-1920) : débats cartographiques au sein de la délégation britannique (Daniel Foliard)
De l’Empire ottoman au chaos moyen-oriental (Denis Bauchard)
-
19:28
Appel à communications : « L’histoire de la cartographie et son écriture à l’épreuve du renouvellement » – Date butoir : 6 juin 2022
sur Cartes et figures du mondeJournée d’études
Le vendredi 25 novembre 2022, salle 100, Centre des colloques, Campus Condorcet, Aubervilliers
Organisateur : Comité Français de Cartographie (commission ‘histoire’)
Argumentaire :
Depuis les années 1980, l’histoire de la cartographie a vu ses concepts, ses objets, ses méthodes d’investigation et ses manières d’écrire se transformer profondément. Sous l’influence des analyses de John Brian Harley et de quelques autres (D. Wood, C. Jacob, M. Monmonier, J. Schulz, J. Black, M. Edney, entre autres), l’intérêt s’est porté vers la dimension symbolique des cartes, leurs modes de présence dans les cultures visuelles modernes, leur valeur politique et sociale (en particulier dans le cadre de l’affirmation des États-nations), leurs implications multiples dans les entreprises impériales et coloniales, etc., dans un effort général pour s’éloigner d’une approche strictement positiviste et « naturaliste » de la cartographie et de son histoire. Une nouvelle manière d’écrire l’histoire de la cartographie s’est progressivement installée, attentive aux contextes sociaux et culturels de la fabrication et de l’usage des cartes, aux jeux d’échelles (du général au particulier), et soucieuse d’envisager désormais la cartographie tout autant du côté des processus et des opérations (techniques, scientifiques, politiques, etc.) dont elle est le théâtre permanent, que du côté des objets, des productions et des acteurs plus ou moins prestigieux sur lesquels la recherche se focalisait naguère encore.
La journée d’étude organisée par la Commission « Histoire » du Comité Français de Cartographie propose de revenir sur les formes et les objets de l’écriture de l’histoire de la cartographie considérée dans un temps long. On insistera surtout sur la période contemporaine, en relation au renouvellement actuel des outils, notamment numériques.
Les contributions attendues peuvent répondre à l’une des trois directions suivantes :
– La première porte sur l’héritage des écrits de John Brian Harley, quarante ans après la publication de ses premiers travaux, et plus généralement sur l’ensemble des propositions qui ont marqué les approches « déconstructionnistes » dans l’histoire récente de la cartographie. Quel bilan peut-on en tirer, du point de vue des enseignements et des expériences en matière d’écriture historiographique ? A quelles négociations ces travaux ont-ils donné lieu pour concilier la tension entre la lecture internaliste et l’approche culturelle et sociale des objets cartographiques ? Comment ont-ils renouvelé l’étude de l’histoire de la cartographie et de ses acteurs ? Quelle place doit-on accorder aujourd’hui, à l’« analyse processuelle » (étude des processus cartographiques ) telle qu’elle est proposée par Matthew Edney par exemple ?
– La seconde direction proposée consiste à envisager la cartographie et son histoire en la confrontant de façon élargie aux apports récents des sciences sociales, de l’histoire des arts et de la littérature, de l’anthropologie visuelle et des médias, ainsi qu’aux perspectives ouvertes dans le champ spécifique des disciplines historiques par la micro-histoire, l’histoire globale, l’histoire matérielle, etc. En quoi l’écriture de l’histoire de la cartographie peut-elle être affectée par ces nouvelles manières d’envisager l’histoire des sociétés et de leurs cultures spatiales ? Comment, et jusqu’où, peut-elle répondre à ces sollicitations et se les approprier ? Qu’a-t-elle, symétriquement, à proposer, à apporter, notamment pour ce qui concerne le renouvellement des paradigmes spatiaux en cours au sein des sciences sociales et de l’histoire ?
– Mais l’histoire de la cartographie a une histoire, à la fois passée et très actuelle. Dans une troisième direction de réflexion, on aimerait alors envisager l’histoire de la cartographie, d’une part du point de vue des récits dont elle a été l’objet depuis au moins le XVIIIe siècle, et d’autre part du point de vue de l’impact, a priori considérable, provoqué par l’introduction des outils numériques, sur la reconfiguration de ces récits. Comment l’histoire de la cartographie a-t-elle été racontée, par les cartographes et par d’autres, du XVIIIe au XXe siècle, avec quelles motivations, quelles visées, scientifiques ou politiques ? Comment, aujourd’hui, à l’époque de la dématérialisation des objets cartographiques, et de leurs mises en relation avec les autres formes de l’économie iconographique, est-il possible de parler encore d’histoire de la cartographie stricto sensu ?
Modalités pratiques
• Les propositions de communication (environ 1500 signes), accompagnées d’une courte bio-bibliographie, sont à envoyer avant le 6 juin 2022 à l’adresse suivante : catherine.hofmann@bnf.fr.
• Le comité de sélection communiquera les résultats de l’appel à communications au plus tard le 30 juin 2022.
• Les communications retenues auront vocation à être publiées dans un numéro de la revue du Comité français de cartographie, Cartes & Géomatique, au courant de l’année 2023.
-
18:23
Cartes et géomatique : les articles 2017 sont en ligne
sur Cartes et figures du mondeCartes & Géomatique précédemment Le Monde des Cartes est une publication trimestrielle du Comité Francais de Cartographie. Les articles de la revue sont mis en ligne sur le site du CFC un an après leur publication sur support papier. Ne sont recensés ici que les articles en histoire de la cartographie.
n° 234, décembre 2017 : “A l’échelle du monde – La carte : objet culturel, social et politique, du Moyen Age à nos jours” (actes du colloque d’Albi les 17 et 18 octobre 2016)Bulletin 234 – Introduction (Thibault Courcelle, Emmanuelle Vagnon, Sandrine Victor)
La mappemonde d’Albi – Un pinax chôrographikos (Anca Dan)
La carte comme substitut au voyage (Nathalie Bouloux)
Représenter et décrire l’espace maritime dans le califat fatimide (David Bramoullé)
Quand le cartographe parle de sa carte (Jean-Charles Ducène)
Une cartographie des Lumières (Gilles Palsky)
Penser à l’échelle du monde pour maîtriser le temps en France et en Grande-Bretagne, 1870-1914 (Isabelle Avila)
Un autre monde ? (Clarisse Didelon-Loiseau, Christian Vandermotten, Christian Dessouroux)
Regards croisés sur la création des cartes à l’échelle du monde aujourd’hui (Thibault Courcelle, Emmanuelle Vagnon, Sandrine Victor)
-
8:00
Exposition “Inventer l’Indochine. Cartographier l’ailleurs (1873-1936)”
sur Cartes et figures du mondeExposition à la bibliothèque de l’Institut de Géographie Du 7 mars au 23 juillet 2022De la fin du XIXe siècle au début du XXe siècle, la découverte, la conquête puis l’organisation des terres extrême-orientales colonisées par la France donne lieu à une production de cartes où s’entremêlent science et subjectivité, pouvoir et échanges culturels.
Le fonds qu’en conserve la bibliothèque de l’Institut de Géographie de Paris permet d’appréhender comment les savoir-faire cartographiques ont été progressivement élaborés et adaptés pour rendre compte de terres jusqu’alors largement inconnues des Européens. À travers cette évolution se dessine celle de la géographie et du regard occidental porté sur l’étranger.
Le 10 mars, à partir de 18h00, une visite commentée par Marie de Rugy, spécialiste de l’histoire de la cartographie, marquera le début de cette exposition et sera suivie d’un échange entre historiens, géographes et cartographes.
-
16:23
Cartes et géomatique : les articles 2018 sont en ligne
sur Cartes et figures du mondeCartes & Géomatique précédemment Le Monde des Cartes est une publication trimestrielle du Comité Francais de Cartographie. Les articles de la revue sont mis en ligne un an après leur publication sur support papier.
Ne sont recensés ici que les articles en histoire de la cartographie
n° 235-236, mars 2018L’œil et la toise : l’objectivité cartographique du XVIIIe à nos jours (Henri Desbois)
Ambivalence de la carte entre visible et invisible (Jean-Paul Bord et Nancy Meschinet de Richemond)
Le triple jeu d’un officier-cartographe dans la Régence de Tunis au XIXe siècle (Houda Baïr)
n° 237, septembre 2018L’image de l’espace tunisien dans la cartographie occidentale moderne du XVIe au XVIIIe siècle (Saada Afef)
La fin d’un rêve : dislocation de l’Empire et restitution des cartes réunies pour sa constitution (Monique Pelletier)
Le langage de la cartographie statistique, 1820-2015 : continuité ou ruptures ? (Gilles Palsky)
n° 238, décembre 2018 : “Faire la carte et restituer le paysage” (actes de la journée d’étude du 27 novembre 2017 au Service historique de la Défense, Vincennes)Bulletin 238 – Introduction (Nicolas Jacob et Claude Ponnou)
Courte histoire d’un échec : le mariage de l’armée et du cadastre dans le premier quart du XIXe siècle (Nicolas Verdier)
Pierre-Antoine Clerc et la brigade topographique du dépôt des fortifications : premières réalisations des courbes de niveau (Luisa Rossi)
La carte de Barcelone avec des courbes de niveau (1823-1827) : un tournant vers la cartographie de précision (Francesc Nadal i Piqué et Carme Montaner i Garcia)
La carte topographique en courbes de niveau : une difficile genèse au XIXe siècle (Nicolas Jacob)
Lever-nivelé de la place de Barcelone, 1823-1827 : comment obtenir un modèle 3 (Blanca Baella, Dolors Barrot et Maria Pla)
Apports des SIG pour la restitution de quelques éléments du paysage à Paris (Léa Hermenault)
La ” Carte générale du théâtre de la guerre en Italie et dans les Alpes…” de Bacler d’Albe (1798) et sa numérisation (Nicolas Dion et Nadine Gastaldi)
La ” Carte très particulière du Haynault ” de Naudain (ca 1709 – 1728) (Jean-Louis Renteux)
-
15:55
L’atlas nautique ou portulan du Havre
sur Cartes et figures du monde[Article initialement publié le 22 octobre 2021 sur le site https://nutrisco-patrimoine.lehavre.fr/]
Ces cartes manuscrites sur parchemin sillonnées de lignes noires, rouges et vertes jaillissant de roses des vents, sont immédiatement reconnaissables. Ce sont des cartes portulans, mot dérivé de l’italien portolano qui désigne un livre d’instructions nautiques.
Portugal, Côtes d’Afrique, Atlas portulan du Havre, Jaume Olives ( ?), 1535-1547, Le Havre, Bibliothèque municipale, Ms 243, f. 5
Essentiellement produites entre le XIIIe et le XVIIIe siècle, peu d’entre elles sont parvenues jusqu’à nous. La plupart du temps, elles représentent la Méditerranée. Mais l’atlas nautique du XVIe siècle conservé au Havre consacre au contraire 5 cartes sur 13 au continent américain. Il est à ce titre exceptionnel.
Qu’est-ce qu’un atlas portulan ?Les cartes ou atlas portulan ont à l’origine vocation à être des adjuvants de la navigation. Ils indiquent les ports les plus importants en rouge, les autres en brun, ainsi que les dangers de la navigation, comme les écueils. Le pilote du navire pouvait s’aider des lignes de rhumbs qui indiquent des directions pour tracer son cap. Ce type de carte est principalement utile au cabotage.
Toutefois, les portulans aujourd’hui conservés dans les bibliothèques et les musées sont presque tous des objets d’apparat, destinés à exhiber la puissance de leur propriétaire ou à signifier l’étendue d’un empire, comme s’il existait une équivalence entre dessiner et s’approprier le monde. Souvent somptueux, ils sont souvent tracés sur les peaux les plus blanches et ornementés par des peintres habiles. Soigneusement conservés, ils n’ont jamais connu le roulis et l’humidité tenace d’un navire.
Feuilleter l’atlas portulan du HavreSous quelle forme et dans quel ordre étaient originellement organisés les 13 doubles-pages de l’atlas du Havre ? Il est impossible de le savoir, comme d’être certain qu’il soit complet. Aujourd’hui, il se présente aux regards dans une reliure en maroquin bordeaux, ornée de filets et de fleurons à chaud, autrement dit dorés. Cette reliure soignée date du XIXe siècle et a probablement été réalisée à la demande d’un bibliophile.
Reliure en maroquin bordeaux à la du Seuil, Atlas portulan du Havre, Jaume Olives ( ?), 1535-1547, Le Havre, Bibliothèque municipale, Ms 2
C’est un objet maniable, d’une trentaine de centimètre de hauteur. Toutes les pages ne sont pas inscrites. Chaque double-page de carte est suivie d’une double-page vierge, plus foncée, moins uniforme. Le parchemin étant de médiocre qualité, seul le côté chair de la peau, plus blanc et uni, est inscrit.
Les cartes sont nombreuses pour un atlas portulan et le contenu des cartes, inhabituels. Il s’ouvre sur une représentation du Portugal et de Terre-Neuve et se referme sur l’Amérique du sud, le Brésil jusqu’à l’embouchure de la Plata : loin d’être uniquement méditerranéen, c’est un atlas qui pourrait être qualifié “atlantique” tant il se concentre sur les côtes qui longent à l’est comme à l’ouest cet océan.
S’il est intéressant par son contenu, il ne s’agit pas d’un atlas luxueux, bien au contraire. La qualité du parchemin est médiocre, les inscriptions maladroites et parfois recouverte par le tracé d’un parallèle, les illustrations, comparées à d’autres cartes marines contemporaines, semblent moins habiles et la représentation des animaux est répétitive, comportant uniquement des chameaux, des éléphants et une gazelle. On trouve même une inscription désignant le prêtre Jean des Indes, qui dépasse du cadre qui lui est, montrant que les noms des souverains ainsi que ceux des continents ont été rajouté après les illustrations.
Le prêtre Jean des Indes, détail de la carte de l’Afrique méridionale et de Madagascar, Atlas portulan du Havre, Jaume Olives ( ?), 1535-1547, Le Havre, Bibliothèque municipale, Ms 243, f. 8
L’atlas est dédié en majeure partie à l’Amérique ainsi qu’à l’Afrique, les deux grandes découvertes ibériques des XVe et XVIe siècles. Les toponymes sont espagnols, portugais, italiens et catalans. Toutes les cartes sont à la même échelle, et chacune est délimitée par un encadrement brun, avec des légendes pour chaque port ou cap, tracées à l’encre brune ou rouge pour les plus significatives, disposées le long des tracés des côtes, les noms de pays quant à eux figurent dans des encadrements peints.
32 lignes de rumbs sortent des roses de compas, matérialisant les principales directions par leur tracé en vert, rouge ou brun ; des échelles de latitude sont présentes sur chaque carte. Un utilisateur du portulan a laissé en chiffres arabes quelques notes sur la première carte et une autre main a tracé plusieurs notes en grec sur celle représentant la Mer Egée. Éléments de décor plus pittoresques, on trouve aussi des animaux terrestres et des représentations de souverains régnants, mais aucun bateau ou animal marin.
Bien que moins soigné que d’autres atlas nautiques, rien n’indique qu’il ait été utilisé en mer et il est plus probable qu’il ait servi d’objet relativement ostentatoire manifestant l’expansion ibérique.
Une datation et attribution incertainesQui a produit cet atlas portulan et quand a-t-il été tracé ? Bien que conservé au Havre, cet atlas nautique ne possède aucune caractéristique de la cartographie normande. Au contraire, sa toponymie espagnole, portugaise, italienne et catalane, comme l’ornementation ou les couleurs employées sont typiques de l’Europe du sud. Cependant, une attribution plus précise est délicate. De 1889 à 1910, il a été successivement attribué à un cartographe espagnol, à un pilote catalan ou encore à Salvatore de Pilestrina, cartographe à Majorque. Côté datation, un consensus qui reste admis jusqu’en 1950 : l’atlas portulan du Havre daterait du 2e quart du XVIe siècle et serait d’origine catalane ou majorquine.
En 1951, une note rédigée par Myriem Foncin, conservatrice et directrice du département des cartes et plans de la Bibliothèque nationale de France, indique que l’historien de la cartographie Marcel Destombes date l’atlas plus tardivement, de 1580.
Aujourd’hui, la numérisation de nombreux atlas portulan à travers le monde permet d’établir des comparaisons hier impossibles, offrant la possibilité de porter un nouveau regard sur ces documents. Selon une étude réalisée en 2018, la décoration de cet atlas est dans le style de Jaume Olives, et dans une moindre mesure, dans celui de Bartomeo Olives. Il pourrait avoir été dessiné ou copié sur les œuvres de ces cartographes.
Toujours d’après cet article, son iconographie est de fait héritière d’une longue tradition méditerranéenne typique de la carte de Salvatore de Pilestrina (1511) et même, au-delà, de la carte marine de Mecia de Viladestes de 1413 ou de l’atlas catalan de 1375. Néanmoins, l’iconographie de l’atlas portulan du Havre est plus particulièrement proche de celui des cartes des frères Jaume et Bartolomeu Olives par son vocabulaire esthétique comme dans les coloris employés. On retrouve les formes trapézoïdales aux extrémités des encadrements des noms de princes, les montagnes en forme de bonnet phrygien, le même éléphant, le même chameau, et surtout exactement la même gazelle, plus rare dans les autres cartes.
Iles dites « fantômes » de l’Atlantique nord : Frixland, Mayda, ou Brasil, Atlas portulan du Havre, Jaume Olives ( ?), 1535-1547, f. 1 Le Havre, Bibliothèque municipale, Ms 243, f. 1
Le contenu géographique est d’influence diverses : les cartes de l’Amérique du Sud, l’Amérique centrale et l’Afrique profitent de la cartographie d’État portugaise et espagnole, tandis que les îles de l’Atlantique forgées par hypothèse que sont Frixland, Mayda, ou Brasil, sont typiques de la cartographie d’atelier, dite catalane et majorquine, et ne se retrouve jamais dans la cartographie d’État portugaise et espagnole.
L’atlas portulan ne saurait être antérieur à 1535, car les traces de l’influence de la carte de Gaspar Viegas (1535) dans les cartes d’Amérique sont trop importantes. En revanche, il ne peut pas être postérieur à 1547, car il représente la péninsule du Yucatan au Mexique comme une île. Or, aucune carte datée connue à ce jour ne représente le Yucatan comme insulaire après cette date. L’atlas du Havre aurait donc été produit entre 1535 et 1547 et réalisé ou copié sur un travail de Jaume Olives.
Le Yucatan représenté comme une île dans le golfe du Mexique, Atlas portulan du Havre, Jaume Olives ( ?), 1535-1547, Le Havre, Bibliothèque municipale, Ms 243, f. 11 Un contenu politique singulier
Alors qu’il est plutôt d’allure modeste et que son ornementation au premier abord paraît stéréotypée, le contenu de l’atlas du Havre possède des caractéristiques inhabituelles.
Les cartes portulans se distinguent en général par la stabilité de leur contenu, jusqu’à l’anachronisme. Le prêtre Jean des Indes y figure toujours, alors même que s’il a eu une origine historique, c’est au début du XIVe siècle qu’il aurait régné. Certains souverains d’Europe ne sont pour ainsi dire jamais représentés, comme le roi d’Angleterre, contrairement au roi d’Espagne ou au Grand Turc.
Le duc de Savoie, Atlas portulan du Havre, Jaume Olives ( ?), 1535-1547, Le Havre, Bibliothèque municipale, Ms 243, f. 4
La représentation du duc de Savoie sur la carte dès lors interpelle, d’autant que dans le second quart du XVIe siècle, il n’est pas à la tête d’un royaume puissant. En revanche à cette période, la rivalité entre le royaume de François Ier et l’empire de Charles Quint est à son comble. En s’alliant avec le duc de Savoie, Charles Quint barre la route aux ambitions du roi de France. Ce serait donc en tant qu’important allié qu’il apparaitrait sur la carte. Cette hypothèse encourage à relire le contenu politique de l’atlas, sans a priori sur son éventuel anachronisme. Les drapeaux castillans semés sur le continent américain qui signalent les conquêtes Hernàn Cortez et sans doute la fondation de la Nouvelle Castille (1519-1537) confirment l’importance de la dimension géopolitique de l’atlas : il représente l’emprise ibérique sur le monde.
Cette conclusion invite à réinterroger l’apparent anachronisme de la représentation des princes sur la carte.
Une provenance encore incertaineIl n’était pas évident que cet atlas nautique méditerranéen, à la gloire de l’empire de Charles Quint et des conquêtes ibériques soit conservé en Normandie, à la bibliothèque municipale du Havre. Ses anciens propriétaires comme les modalités de son entrée dans les fonds sont inconnus. On suppose qu’il serait entré dans les collections au XIXe siècle après avoir appartenu à un collectionneur privé. Il n’est signalé au catalogue qu’en 1888, mais son existence est attestée dès 1860 dans le Guide du voyageur de Joseph Morlent, conservateur de la bibliothèque de 1851 à 1861. En revanche, il ne l’évoque pas dans son précédent guide de 1854, ce qui semble indiquer que le document est entré dans les collections entre 1854 et 1860.
Consulter le document en ligne.
Pour en savoir plus :Lucile Haguet, L’Atlas nautique du Havre, une archéologie documentaire, Centre havrais de recherches historiques, n°HS 1, 2018, p. 53-90.
Ernest Grandidier, Histoire physique, naturelle et politique de Madagascar, Paris, 1885, t. I., p. 40, 228.
-
17:05
Cartes et géomatique: les articles 2019 sont en ligne
sur Cartes et figures du mondeCartes & Géomatique précédemment Le Monde des Cartes est une publication trimestrielle du Comité Francais de Cartographie. Les articles sont mis en ligne une année après leur publication sur support papier.
Ne sont recensés ici que les articles relatifs à l’histoire de la cartographie
n° 239-240, mars 2019Archives Nationales (Nadine Gastaldi)
n° 241-242, juin 2019Des emprises cartographiques. Restitution de données géohistoriques à partir de la Carte de France de Cassini, 1750 – 1789 (Bertrand Duménieu, Julien Chadeyron, Pascal Cristofolia, Julien Perreta, Laurence Jolivet, Stéphane Baciocchia)
-
0:00
Utilisation de WebGL pour le rendu de cartes dans OpenLayers, partie 1
sur CamptocampPièce jointe: [télécharger]
Plus que jamais, les cartes interactives doivent être vectorielles. Pour cette raison, nous travaillons inlassablement à améliorer OpenLayers dans un but unique : dessiner des formes géométriques toujours plus rapidement. -
0:00
Utilisation de WebGL pour le rendu de cartes dans OpenLayers, partie 1
sur CamptocampPièce jointe: [télécharger]
Plus que jamais, les cartes interactives doivent être vectorielles. Pour cette raison, nous travaillons inlassablement à améliorer OpenLayers dans un but unique : dessiner des formes géométriques toujours plus rapidement. -
0:00
Implémentation du Chinese Postman Problem au sein du moteur de routage Valhalla
sur CamptocampPièce jointe: [télécharger]
Nous implémentons un algorithme pour résoudre le Chinese Postman Problem au sein du moteur de routage Valhalla. C'est un projet avec Armasuisse pour calculer une route de patrouille. -
0:00
Implémentation du Chinese Postman Problem au sein du moteur de routage Valhalla
sur CamptocampPièce jointe: [télécharger]
Nous implémentons un algorithme pour résoudre le Chinese Postman Problem au sein du moteur de routage Valhalla. C'est un projet avec Armasuisse pour calculer une route de patrouille. -
0:00
Journée romande de la géoinformation 2021
sur CamptocampPièce jointe: [télécharger]
Camptocamp sera présent pour présenter ses projets innovants au cours de la journée romande de la géoinformation le 23 novembre. Venez découvrir nos projets -
0:00
Journée romande de la géoinformation 2021
sur CamptocampPièce jointe: [télécharger]
Camptocamp sera présent pour présenter ses projets innovants au cours de la journée romande de la géoinformation le 23 novembre. Venez découvrir nos projets
-
10:16
Modélisation de la distribution des espèces next-level
sur Le blog de GeomatysPièce jointe: [télécharger]
Les modèles de répartition des espèces (MDS) sont des modèles statistiques et mécanistes utilisés pour définir la répartition géospatiale des espèces en fonction de la combinaison de variables écologiques (telles que l’environnement biotique et abiotique) offrant des conditions et des possibilités favorisant leur présence.
En projetant les MDS sur des environnements futurs, les scientifiques peuvent déterminer où et quand ces conditions seront réunies pour fournir une prédiction de la répartition future des espèces. Ces prédictions sont souvent prévues des mois, des années ou des décennies à l’avance, et sont statiques en ce qui concerne à la fois l’algorithme et les occurrences prédites.
Cependant, les facteurs qui affectent les espèces et leurs déplacements ne sont pas statiques. Imaginez que vous puissiez appliquer ces modèles à un monde en évolution en temps réel ! C’est précisément l’aide que nous apportons aux scientifiques en utilisant la technologie de traitement géospatial et de science des données à la volée EXAMIND de Geomatys.
Lorsque les conditions environnementales changent, ou sont affectées par des perturbations telles qu’un ouragan ou des projets de développement qui perturbent les habitats actuels, des MDS à échelle fine peuvent être appliqués pour prédire comment les animaux se disperseront. En collaboration avec nos partenaires de la recherche et de l’industrie, nous travaillons à l’application de cette technologie en développement pour, par exemple, gérer les populations animales. Cette capacité deviendra essentielle dans presque tous les domaines, y compris la gestion de la biodiversité, car le changement climatique déstabilise les écosystèmes et les habitudes, et ainsi il perturbe les connaissances sur lesquelles nous nous appuyons actuellement pour prendre des décisions.
Un projet dans lequel la technologie de Geomatys facilite ce travail est celui fait pour l’association française pour la gestion et la conservation du cheval de Przewalski, une espèce menacée (TAKH). L’association a présenté son portail Web alimenté par EXAMIND pour visualiser et analyser les populations de chevaux de Przewalski, appelé Shamane, lors du Congrès mondial de la nature de l’UICN de cette année, le 8 septembre 2021 à Marseille.
Explorer le platform Shamane ( [https:]] )
Bien que l’objectif soit de former des algorithmes d’apprentissage automatique qui puissent aider à prédire le comportement des chevaux en réponse à des facteurs environnementaux variant dans le temps, un travail préliminaire que nous ayons effectué pour faciliter ce projet a été de construire la base de données, en rassemblant des sources de données vastes et disparates, en assurant l’interopérabilité et en les rendant accessibles à l’utilisateur dans un seul environnement.
Grâce aux nouvelles fonctionnalités disponible sur son socle EXAMIND en réponse aux besoins des chercheurs TAKH, les utilisateurs peuvent suivre des animaux individuels à travers le temps, basculer leur histoire et leur pedigree, explorer leurs habitats en 4D, interroger des ensembles de données connexes et lancer des analyses, le tout dans l’environnement de l’infrastructure de données spatiales de Shamane. L’outil permet donc non seulement d’analyser les données, mais aussi de fournir des renseignements permettant de prendre des décisions en temps réel en matière de surveillance et de gestion des populations.
Vidéo teaser crée pour le TAKH par Les Fées Spéciales
La vidéo teaser du projet Shamane ci-dessus illustre comment l’utilisateur peut suivre le mouvement de chevaux individuels génétiquement distincts (représentés par des couleurs différentes, souvent regroupés en troupeaux) dans une vue 3D du paysage. À l’aide du curseur situé en bas de la page, il peut suivre les changements de position des animaux ainsi que l’évolution de l’habitat dans le temps. Cela permet aux chercheurs de déterminer, par exemple, quels types de barrières d’habitat peuvent influencer les déplacements.
Dans un prochain temps, ils vont pouvoir également superposer d’autres données, telles que des données météorologiques à cette vue et effectuer des analyses dans la barre latérale de gauche à l’aide d’un notebook de datascience. A priori, ces analyses visent à identifier les facteurs écologiques qui déterminent les comportements de déplacement des animaux afin de soutenir les stratégies de gestion des populations et d’autres efforts de conservation.
Le futur de l’environnement interactif de visualisation de données 4D de Shamane, alimenté par EXAMIND.Bien que l’outil soit disponible via un portail web, l’accès est limité aux utilisateurs autorisés, sécurisé avec la même technologie que celle utilisée par Geomatys dans le domaine de la défense. Ceci est important pour traiter des données sensibles, telles que la localisation précise d’espèces menacées. Cet outil fournit donc une plateforme performante et sécurisée pour gérer la conservation de ces populations fragiles.
The post Modélisation de la distribution des espèces next-level first appeared on Geomatys.
-
12:02
Visualisation des conditions météo à la volée en réalité augmenté
sur Le blog de GeomatysDepuis quelques mois les équipes R&D de Geomatys travaillent sur l’exploitation de données GHOM (Géographiques, Hydrographiques, Océano et météo ) en réalité augmentée.
L’enjeu étant de convertir, côté serveur à l’aide d’Examind-Server, des formats complexes tel que GRIB, NetCDF ou encore S-57, pour les servir en 3D sur un client Unity et de visualiser ces données à la volée avec des HolloLens.
Voici donc un exemple de visualisation de vecteurs de vent issus de fichiers GRIB en réalité augmentée.D’autres cas d’usages arrivent en particulier pour le monde maritime, nous vous les présenterons bientôt.
-
10:39
FOSS4G 2021 - Les présentations que je souhaiterais suivre
sur ReLucBlogLe FOSS4G 2021 a commencé hier, lundi 27 september 2021, avec les premiers workshops. Les présentations commenceront demain, mercredi 29 Septembre 2021.
3Liz a 3 présentations plus 1 faîtes par ONF International :
- Lizmap to create a Web Map Application with QGIS Desktop and Server
- How to use OpenStreetMap data in QGIS Desktop
- PgMetadata - A QGIS plugin to store the metadata of PostgreSQL layers inside the database, and use them inside QGIS
- How Open Source solution help to build an scalable and adaptable environmental decision platform tools
Le programme de cette année est très complet et j'ai du mal à choisir parmi la longue liste de présentations. Voici donc ma liste des présentations que j'aimerais suivre, mais que je ne pourrais pas suivre en entier :
- Printing maps in the browser with InkMap
- OSGeo in the browser: Advances in client-side WebAssembly-based Geospatial Analysis and frontend visualization using jsgeoda and Vis.gl
- Solving Spatial Problems with PostGIS
- 3D geo-applications with CesiumJS - data, possible use-cases and specifications
- Browser-side geoprocessing with Turf.js and Leaflet
- Watching after your PostGIS herd
- Geostyler Mapfile Parser
- A fast web 3D viewer for 11 million buildings
- Graph algorithms on the database with pgRouting
- pygeoapi: what's new in the Python OGC API Reference Implementation
- FOSS4GPU: Faster GIS via GPU and cuSpatial
- OpenStreetMap and the neglected pedestrian
- OGC APIs: background, current state, what's next
- Geospatial analysis using python 101
- OGC API - Deeper Dive into OGC API Features, Records and EDR
- QGIS and OGC APIs - how do they work together?
- Practical Geospatial Data Versioning with Kart
- Processing Massive-Scale Geospatial Data with Apache Sedona
- PMTiles: An open, cloud-optimized archive format for serverless map data
- MapLibre project: community driven Mapbox GL fork
- Modular OGC API Workflows for Processing and Visualization
- Cloud optimized formats for rasters and vectors explained
- Demystifing OGC APIs with GeoServer: introduction and status of implementation
- Deploying and operating GeoServer: a DevOps perspective
- QField Features Frenzy
- Seamless fieldwork thanks to QFieldCloud
- Deployment of open source vector tile technology with UN Vector Tile Toolkit
- The Very Best New Features of QGIS 3.x
- QGIS Plugin Development Is Not Scary: Lessons Learned from Literature Mapper
- QGIS MetaSearch: lowering the barrier to geospatial data discovery in the desktop
- Input, Mergin & QGIS: collect data, sync, and collaborate with ease
- GeoRasterLayer for Leaflet: Truly Server-Free GeoTIFF Visualization
- Versioning in 2021: when and how you should do it
- Using point clouds in QGIS
- GeoHealthCheck - QoS Monitor for Geospatial Web Services
- Wegue - Webmapping with OpenLayers and Vue.js
- GeoMapFish und QGIS Server
- Algorithm Talk: JSON-to-Code Compression
- Vector tile basemaps for your QGIS project
- OpenLayers Feature Frenzy
- Easily publish your QGIS projects on the web with QWC2
- MapStore, a year in review
- Deploying QGIS using command line options.
- Large scale QGIS deployments : feedback and lessons learned
- Fast, Robust Arithmetics for Geometric Algorithms and Applications to GIS
- WAPLUGIN: Water Accounting and Productivity Plugin for QGIS
- FOSS4G software developments for Water Utilities Management in Eastern Africa by using Vector Tiles
- G3W-SUITE: in OS framework for publishing and managing QGIS projects on the Web
- Giswater : open source management tool for water networks
- An implementation of FOSS4G - QGIS, QField and Vector Tiles for rural water supply management in Rwanda
- Geospatial programming with Rust
- QGIS, Football, what else ?
-
10:30
FOSS4G 2021 - Presentations I would like to follow
sur ReLucBlogFOSS4G 2021 began yesterday, Monday September 27 2021, with the first workshops. The presentations will begin tomorrow, Wednesday Septembre 29 2021.
3Liz has 3 presentations plus 1 made by ONF International :
- Lizmap to create a Web Map Application with QGIS Desktop and Server
- How to use OpenStreetMap data in QGIS Desktop
- PgMetadata - A QGIS plugin to store the metadata of PostgreSQL layers inside the database, and use them inside QGIS
- How Open Source solution help to build an scalable and adaptable environmental decision platform tools
This years's schedule is very complete and I find it hard to choose from the long list of presentations. So here is my list of presentations that I would like to attend, but that I will not be able to follow in full:
- Printing maps in the browser with InkMap
- OSGeo in the browser: Advances in client-side WebAssembly-based Geospatial Analysis and frontend visualization using jsgeoda and Vis.gl
- Solving Spatial Problems with PostGIS
- 3D geo-applications with CesiumJS - data, possible use-cases and specifications
- Browser-side geoprocessing with Turf.js and Leaflet
- Watching after your PostGIS herd
- Geostyler Mapfile Parser
- A fast web 3D viewer for 11 million buildings
- Graph algorithms on the database with pgRouting
- pygeoapi: what's new in the Python OGC API Reference Implementation
- FOSS4GPU: Faster GIS via GPU and cuSpatial
- OpenStreetMap and the neglected pedestrian
- OGC APIs: background, current state, what's next
- Geospatial analysis using python 101
- OGC API - Deeper Dive into OGC API Features, Records and EDR
- QGIS and OGC APIs - how do they work together?
- Practical Geospatial Data Versioning with Kart
- Processing Massive-Scale Geospatial Data with Apache Sedona
- PMTiles: An open, cloud-optimized archive format for serverless map data
- MapLibre project: community driven Mapbox GL fork
- Modular OGC API Workflows for Processing and Visualization
- Cloud optimized formats for rasters and vectors explained
- Demystifing OGC APIs with GeoServer: introduction and status of implementation
- Deploying and operating GeoServer: a DevOps perspective
- QField Features Frenzy
- Seamless fieldwork thanks to QFieldCloud
- Deployment of open source vector tile technology with UN Vector Tile Toolkit
- The Very Best New Features of QGIS 3.x
- QGIS Plugin Development Is Not Scary: Lessons Learned from Literature Mapper
- QGIS MetaSearch: lowering the barrier to geospatial data discovery in the desktop
- Input, Mergin & QGIS: collect data, sync, and collaborate with ease
- GeoRasterLayer for Leaflet: Truly Server-Free GeoTIFF Visualization
- Versioning in 2021: when and how you should do it
- Using point clouds in QGIS
- GeoHealthCheck - QoS Monitor for Geospatial Web Services
- Wegue - Webmapping with OpenLayers and Vue.js
- GeoMapFish und QGIS Server
- Algorithm Talk: JSON-to-Code Compression
- Vector tile basemaps for your QGIS project
- OpenLayers Feature Frenzy
- Easily publish your QGIS projects on the web with QWC2
- MapStore, a year in review
- Deploying QGIS using command line options.
- Large scale QGIS deployments : feedback and lessons learned
- Fast, Robust Arithmetics for Geometric Algorithms and Applications to GIS
- WAPLUGIN: Water Accounting and Productivity Plugin for QGIS
- FOSS4G software developments for Water Utilities Management in Eastern Africa by using Vector Tiles
- G3W-SUITE: in OS framework for publishing and managing QGIS projects on the Web
- Giswater : open source management tool for water networks
- An implementation of FOSS4G - QGIS, QField and Vector Tiles for rural water supply management in Rwanda
- Geospatial programming with Rust
- QGIS, Football, what else ?
-
0:00
Conférence DINAcon
sur CamptocampPièce jointe: [télécharger]
Le 29.10.2021, la conférence DINAcon se tiendra pour la première fois dans le parc de la Bâloise à Bâle. -
0:00
Conférence DINAcon
sur CamptocampPièce jointe: [télécharger]
Le 29.10.2021, la conférence DINAcon se tiendra pour la première fois dans le parc de la Bâloise à Bâle. -
0:00
Camptocamp présent au 127ème congrès national des sapeurs pompiers
sur CamptocampPièce jointe: [télécharger]
Annulé l’année dernière du fait de la crise sanitaire, le 127ème congrès national des sapeurs pompiers aura bien lieu cette année du 13 au 16 octobre à Marseille. -
0:00
Camptocamp présent au 127ème congrès national des sapeurs pompiers
sur CamptocampPièce jointe: [télécharger]
Annulé l’année dernière du fait de la crise sanitaire, le 127ème congrès national des sapeurs pompiers aura bien lieu cette année du 13 au 16 octobre à Marseille. -
0:00
Le projet MADD
sur CamptocampPièce jointe: [télécharger]
Ce projet MADD avait comme objectif d’automatiser tant que possible le processus de commande et d ’offrir un accès standardisé aux données issues du RegBL pour les utilisateurs. -
0:00
Le projet MADD
sur CamptocampPièce jointe: [télécharger]
Ce projet MADD avait comme objectif d’automatiser tant que possible le processus de commande et d ’offrir un accès standardisé aux données issues du RegBL pour les utilisateurs. -
0:00
Camptocamp est sponsor de la conférence FOSS4G de Buenos Aires 2021
sur CamptocampPièce jointe: [télécharger]
Du 27 septembre au 2 octobre, la conférence FOSS4G 2021 aura lieu en ligne. Jetez un coup d'œil à nos conférences. -
0:00
Camptocamp est sponsor de la conférence FOSS4G de Buenos Aires 2021
sur CamptocampPièce jointe: [télécharger]
Du 27 septembre au 2 octobre, la conférence FOSS4G 2021 aura lieu en ligne. Jetez un coup d'œil à nos conférences. -
0:00
GeoDatadays : à la rencontre de la communauté geospatial en France
sur CamptocampPièce jointe: [télécharger]
Les GeoDatadays, événement autour de la geodata, auront lieues les 15 et 16 septembre à Grenoble, et sont co-organisées par l'AFIGéo et Décryptagéo. -
0:00
GeoDatadays : à la rencontre de la communauté geospatial en France
sur CamptocampPièce jointe: [télécharger]
Les GeoDatadays, événement autour de la geodata, auront lieues les 15 et 16 septembre à Grenoble, et sont co-organisées par l'AFIGéo et Décryptagéo. -
0:00
MapFish Print - sous le capot
sur CamptocampPièce jointe: [télécharger]
MapFish Print est une solution complète permettant d’imprimer des cartes et des rapports, et pouvant être facilement intégrée dans un SIG. Nous présentons ici l'état actuel de ce projet open-source toujours aussi vivant. -
0:00
MapFish Print - sous le capot
sur CamptocampPièce jointe: [télécharger]
MapFish Print est une solution complète permettant d’imprimer des cartes et des rapports, et pouvant être facilement intégrée dans un SIG. Nous présentons ici l'état actuel de ce projet open-source toujours aussi vivant. -
0:00
La version 2.6 GeoMapFish
sur CamptocampPièce jointe: [télécharger]
GeoMapFish est une application SIG web, extensible et flexible, incluant de nombreuses fonctionnalités. La version 2.6 vient de sortir. -
0:00
La version 2.6 GeoMapFish
sur CamptocampPièce jointe: [télécharger]
GeoMapFish est une application SIG web, extensible et flexible, incluant de nombreuses fonctionnalités. La version 2.6 vient de sortir.
-
14:32
Dataviz : “voir et donner à voir”
sur Le blog de GeomatysDans le cadre de ses activités Geomatys s’est structuré selon trois axes :
1.La mise en place et l’exploitation de Datalakes Geospatiaux (basé sur des infrastructure Cloud et exploitant des volumes massifs de donnée)
2. La (Geo)Datascience
3. La visualisation de données incluant la 3D et la réalité augmentée.
Cet article présente un retour d’expérience sur la mise en place de traitements à la volée sur un DataLake pour les besoins d’une agence spatiale.
Les masses de données brutes et les résultats de leurs analyses disponibles pour la prise de décision humaine sont un challenge pour les outils de visualisation. Ainsi si les masses de données actuelles permettent l’émergence des Jumeaux Numériques, pour la Dataviz elle peuvent parfois ressembler à Janus :
- Agréger les données afin de produire un indicateur pour l’aide à la décision ou un tableau de bord synthétique est une solution pragmatique, mais elle a le défaut de masquer la complexité des données sources.
- Donner accès en visualisation à toutes les données est transparent mais difficilement analysable pour l’opérateur.
Autrement dit et pour paraphraser René Char qui s’interroge quand même un peu sur ce qu’il vient faire là, pour les outils de Dataviz conduisant à une prise de décision, “l’essentiel est toujours menacé par l’insignifiant” .
C’est en cherchant à dépasser cette ambivalence que nous tâchons de concevoir notre environnement d’exploration et de visualisation de la donnée : EXAMIND Playground dont nous faisons ici une petite revue d’inventaire.
S’appuyant sur les capacités de notre socle logiciel à diffuser de large volume de données géospatiaux, le cas échéant en streaming, EXAMIND Playground est conçu comme un ensemble de modules de visualisation cartographique mobilisable et configurable à façon qui s’appuie sur un moteur de visualisation géographique 4D (3D plus la dimension temporelle) sur lequel viennent se greffer des outils d’exploration de la donnée.
Ainsi à partir d’une vue d’ensemble contextuelle à son besoin, l’utilisateur va pouvoir se concentrer et zoomer sur des zones spécifiques et éventuellement en observer la dynamique temporelle (cf infra). L’utilisateur va également pouvoir forer sa donnée et examiner l’évolution de plusieurs variables dernière le long d’une trajectoire ou en un point donné.
L’outil de visualisation interagit avec le serveur de données ainsi, si le cas d’usage le nécessite, l’utilisateur peut ajouter des objets à l’environnement cartographique et simuler leurs impacts. Comme ici, dans le cas de la simulation de l’impact de la circulation des flamands roses après un ajout de linéaire de haies.
Enfin, la donnée géographique pouvant venir enrichir notre perception du monde réel, EXAMIND Playground est utilisable avec des casques de réalité augmentée afin de proposer à l’usager de voir directement son univers enrichi.
EXAMIND Playground propose donc toute une panoplie d’outils de visualisation cartographique mobilisables en fonction du besoin et du cas d’usage traité afin de pouvoir explorer au mieux toute la richesse de ses données. Le seul risque à trop bien voir ses données étant d’ « avoir la surprise de trouver un lion dans un placard là où l’on était sûr [au départ] d’y trouver des chemises. »(Frida Kahlo)
-
0:00
Pièges courants lors de l'impression de cartes sur le web
sur CamptocampPièce jointe: [télécharger]
La production de cartes de qualité professionnelle affichées dans une application Web ne se limite pas à une simple capture d'écran. Nous vous présentons ici quelques-uns des défis et problèmes les plus fréquents à résoudre pour réussir l’impression de cartes en ligne. -
0:00
Pièges courants lors de l'impression de cartes sur le web
sur CamptocampPièce jointe: [télécharger]
La production de cartes de qualité professionnelle affichées dans une application Web ne se limite pas à une simple capture d'écran. Nous vous présentons ici quelques-uns des défis et problèmes les plus fréquents à résoudre pour réussir l’impression de cartes en ligne. -
0:00
Nouvelles de la communauté GeoNetwork - Été 21
sur CamptocampPièce jointe: [télécharger]
Data hub, Opendata, Dataviz : plein de nouveaux concepts évoqués lors du sprint de code GeoNetwork, du 14 au 18 juin 2021 à la Tite Ferme. -
0:00
Nouvelles de la communauté GeoNetwork - Été 21
sur CamptocampPièce jointe: [télécharger]
Data hub, Opendata, Dataviz : plein de nouveaux concepts évoqués lors du sprint de code GeoNetwork, du 14 au 18 juin 2021 à la Tite Ferme. -
0:00
pgRouting comme aide à la décision des Services d'Incendie et de Secours
sur CamptocampPièce jointe: [télécharger]
Les Services d'Incendie et de Secours cherchent à identifier les camions qui mettront le moins de temps à se rendre sur une intervention. PostGIS et pgRouting leur offrent flexibilité et gain de temps. -
0:00
pgRouting comme aide à la décision des Services d'Incendie et de Secours
sur CamptocampPièce jointe: [télécharger]
Les Services d'Incendie et de Secours cherchent à identifier les camions qui mettront le moins de temps à se rendre sur une intervention. PostGIS et pgRouting leur offrent flexibilité et gain de temps. -
0:00
Camptocamp participe au geOcom 2021
sur CamptocampPièce jointe: [télécharger]
Du 8 au 10 juin se tiendra en visioconférence la réunion annuelle des utilisateurs et développeurs de l'Infrastructure de Données Spatiales geOrchestra. -
0:00
Camptocamp participe au geOcom 2021
sur CamptocampPièce jointe: [télécharger]
Du 8 au 10 juin se tiendra en visioconférence la réunion annuelle des utilisateurs et développeurs de l'Infrastructure de Données Spatiales geOrchestra. -
0:00
Simplifier le point d’entrée de votre IDG - Du fun pour les métadonnées !
sur CamptocampPièce jointe: [télécharger]
Comment convaincre les utilisateurs de référencer leurs données dans une infrastructure de données géographiques s'ils doivent passer leur précieux temps à remplir d'obscurs champs de métadonnées ? -
0:00
Simplifier le point d’entrée de votre IDG - Du fun pour les métadonnées !
sur CamptocampPièce jointe: [télécharger]
Comment convaincre les utilisateurs de référencer leurs données dans une infrastructure de données géographiques s'ils doivent passer leur précieux temps à remplir d'obscurs champs de métadonnées ? -
0:00
FOSSGIS 2021: Nos présentations
sur CamptocampPièce jointe: [télécharger]
Rejoignez-nous pour la première édition entièrement numérique de FOSSGIS 2021 et jetez un coup d'œil aux conférences de Camptocamp. -
0:00
FOSSGIS 2021: Nos présentations
sur CamptocampPièce jointe: [télécharger]
Rejoignez-nous pour la première édition entièrement numérique de FOSSGIS 2021 et jetez un coup d'œil aux conférences de Camptocamp. -
0:00
MapFish Print - la solution d'impression cartographique open-source la plus avancée
sur CamptocampPièce jointe: [télécharger]
Dans ce premier article, nous donnons un aperçu de la solution d'impression MapFish Print et nous vous présentons ses divers cas d'utilisation. -
0:00
MapFish Print - la solution d'impression cartographique open-source la plus avancée
sur CamptocampPièce jointe: [télécharger]
Dans ce premier article, nous donnons un aperçu de la solution d'impression MapFish Print et nous vous présentons ses divers cas d'utilisation. -
0:00
La plateforme de documentation FttH du Tyrol
sur CamptocampPièce jointe: [télécharger]
Pour l'agence de services haut débit Breitbandserviceagentur Tirol GmbH, une plateforme de documentation a été développée sous forme de géoportail pour l'infrastructure FttH des municipalités du Tyrol. -
0:00
La plateforme de documentation FttH du Tyrol
sur CamptocampPièce jointe: [télécharger]
Pour l'agence de services haut débit Breitbandserviceagentur Tirol GmbH, une plateforme de documentation a été développée sous forme de géoportail pour l'infrastructure FttH des municipalités du Tyrol. -
0:00
Vers une meilleure intégration de GeoServer dans une infrastructure cloud
sur CamptocampPièce jointe: [télécharger]
Comment améliorer GeoServer pour une meilleure intégration dans une infrastructure “cloud” et dans un contexte de Haute-Disponibilité ? -
0:00
Vers une meilleure intégration de GeoServer dans une infrastructure cloud
sur CamptocampPièce jointe: [télécharger]
Comment améliorer GeoServer pour une meilleure intégration dans une infrastructure “cloud” et dans un contexte de Haute-Disponibilité ? -
0:00
Rebuilding from the ground up with IFREMER
sur CamptocampPièce jointe: [télécharger]
How Camptocamp went through and made a data visualization application more performant and reliable. -
0:00
ArcGIS Pro vers GeoServer
sur CamptocampPièce jointe: [télécharger]
La compatibilité entre la suite d'outils ESRI et les logiciels open source est un défi permanent. Des solutions existent pour ArcMap, mais pas pour son successeur ArcGIS Pro. -
0:00
Rebuilding from the ground up with IFREMER
sur CamptocampPièce jointe: [télécharger]
How Camptocamp went through and made a data visualization application more performant and reliable. -
0:00
ArcGIS Pro vers GeoServer
sur CamptocampPièce jointe: [télécharger]
La compatibilité entre la suite d'outils ESRI et les logiciels open source est un défi permanent. Des solutions existent pour ArcMap, mais pas pour son successeur ArcGIS Pro.
-
10:55
On our way to quality
sur ReLucBlogLizmap is almost 10 years old. 10 years of new features, documentation, and numerous version release. Many software libraries updates, many contributors (31 if github is correct) and contributions later we've released version 3.4 at the end of 2020.
Whilst in the release cycle, we realized that our release process was lacking something. We were unsure of the quality of this release, and we were missing some tools to assess whether the release would contain regressions.
In order to avoid these issues in future releases and updates, we decided to implement a number of processes and changes in both how we release and build lizmap.
First : we have decided to not accept code patches without tests. Be these tests unit tests, integration tests or just some lines of text explaining how to test for the bug or regression being fixed by the patch. We are now maintaining a list of tests in our code repository.
Secondly we changed our release process to be able to test. We now have a dedicated time slot between the time when our code is ready and the time our code is released to the world. This will let us test internally and will let us gather feedback from users testing our release candidates.
Our third point is community centered. It's now quite easy to set up a lizmap stack or two using our Docker images. Using these instructions you'll have a docker running lizmap in no time on your computer. Add a project or two to it, test and see if you see anything that doesn't work like your production environment and let us know by opening a ticket. Our aim here is to have more user test our release candidates (we do these for major releases) so we can quickly fix regressions before we officially release.
Fourth we are setting up internal processes to make our code easier to test (docker is a good example of this) and easier to read. Hence, are growing use of linters. We also added a code analyzer for our backend: PHPstan.
Finally, we spent a good amount of time updating our demos (see demo.lizmap.com), making sure they work. This makes our demos a reference for most of our testing.
We had realized in June 2020 some of theses issues around quality. That's why we had an intern refactor lizmap. That refactor had two goals. One was to make it easier to add tests to its code and the second one was to add more tests. All these changes have made it to the 3.4 branch. They aren't in the 3.3 branch because it would have meant too much work. This means 3.3 is a bit less tested than 3.4 (hint upgrading from 3.3 is very easy).
Now that most of our backend is covered we are focusing our efforts on the front-end. This means we will update some of the libraries we use, we will refactor our code and will add as much test as possible. This is going to be the work of an intern. We have chosen Cypress to build end2end tests.
All of these automated tests (backend, front-end, end2end) are being run from our githubrepo through github actions.
All these changes have been made possible by the growth of 3liz during 2020.
-
10:39
Nos efforts qualité
sur ReLucBlogLizmap a près de 10 ans. 10 ans de code, d'ajout de nouvelles fonctionnalités, de rédaction de documentation, de sortie de nombreuses versions. Des montées de versions de librairies, de nombreux contributeurs (31 si j'en crois GitHub) et contributions plus tard, nous avons sorti la version 3.4 fin 2020.
Lors de ce cycle de release entre les differentes versions RC et la version finale, nous nous sommes rendu compte d'un manque dans notre processus de release. Nous n'étions pas sûrs de la qualité de lizmap au moment de cette sortie et nous n'avions pas assez de moyens pour évaluer le risque d'avoir une version qui contiendrait des régressions.
Afin de rendre le produit plus fiable lors de mise-à-jour et de pouvoir être plus serein lors de nos prochaines sorties de version, nous avons mis en place un certain nombre de points afin d'améliorer la qualité.
Le premier est de ne plus accepter de contributions sans tests. Des tests automatiques, c'est bien, mais des procédures manuelles de tests, c'est bien aussi. Nous avons donc maintenant une règle qui dit "pas de patch sans test". Nous préférons les tests automatiques qui seront joués lors de l'intégration continue. Mais nous avons aussi conscience que tout n'est pas testable de manière automatique. Et donc qu'un certain nombre de tests devront se jouer de manière manuelle. Nous maintenons donc une liste de tests à jouer. Ces projets de tests sont présents dans les branches 3.4 et pour la prochaine version 3.5 (aka master).
Le deuxième est de mettre en place un processus de release qui intègre une phase de test. Nous consacrons maintenant un jour ou deux afin de pouvoir jouer tous les tests et de valider qu'aucune régression n'est présente. Pour les versions majeures, nous avons alloué encore plus de temps afin de pouvoir intégrer le retour de nos utilisateurs.
Troisième point dans lequel nous avons investi, la participation communautaire aux tests. Il est désormais très simple d'avoir un Lizmap avec un ou plusieurs projets. Il suffit d'utiliser notre stack docker, d'ajouter votre projet et de voir si tout fonctionne comme prévu. Si un problème survient, il est alors possible d'ouvrir au plus vite un ticket avec le maximum d'information pour que nous puissions le corriger. Nous souhaiterions que plus de personnes participent aux tests de nos Release Candidates (RC), afin de détecter avant les sorties les régressions sur vos projets.
Quatrièmement, nous mettons en place des processus internes pour que notre code soit plus facile à tester (cf la stack docker), mais aussi plus lisible par l'utilisation de linters. Nous avons également ajouté un analyseur de code pour le backend, PHP Static Analyser afin de nous prévenir de possibles erreurs côté PHP.
Cinquièmement, nous venons de passer du temps à mettre à jour la plate-forme de démo [https:]] ; les projets ont été dépoussiérés et mis à jour. Ces mises à jour facilitent l'adoption de nos démos comme un référentiel de tests avec de vraies données.
Nous avions pris conscience en juin 2020 d'un déficit dans nos processus qualité. Nous avions donc dirigé un stage afin de refactoriser la librairie Lizmap pour qu'elle soit plus facile à tester de manière automatique. De nombreux tests ont été ajoutés lors de cette refactorisation. Ces changements ont été intégrés dans la future branche 3.5 de Lizmap. C'était trop de travail pour l'intégrer dans les branches 3.3 et 3.4 - elles seront donc légèrement moins bien testées de manière automatique par la CI.
La partie backend PHP étant mieux couverte et mieux testable, nos efforts dans les mois à venir vont se focaliser sur la partie front-end (Javascript, inteface Web...), avec des mises à jour de librairies, de la refactorisation de code et l'ajout de nombreux tests. Une stagiaire en fera le sujet de son stage, on ajoutera grâce à l'outil cypress des tests end2end automatiques.
Les tests backend PHP ainsi que frontend end2end Javascript, ainsi que les linters PHP et Javascript sont lancés sur le dépôt GitHub avec Actions.
Tous ces changements n'ont été possibles qu'en allouant plus de ressources au projet Lizmap au sein de 3liz, par l'arrivée de nouvelles personnes dans l'équipe.
-
0:00
Première release pour Inkmap 1.0
sur CamptocampPièce jointe: [télécharger]
Nous sommes fiers d'annoncer la toute première version d'InkMap, une technologie web moderne permettant d'intégrer des services d'impression dans des applications cartographiques web. -
0:00
Première release pour Inkmap 1.0
sur CamptocampPièce jointe: [télécharger]
Nous sommes fiers d'annoncer la toute première version d'InkMap, une technologie web moderne permettant d'intégrer des services d'impression dans des applications cartographiques web. -
0:00
Calcul d’itinéraires avec édition du graphe en ligne
sur CamptocampPièce jointe: [télécharger]
L’application Plan, basée sur GeoMapFish, permet aux visiteurs de l’EPFL d’afficher des itinéraires piétons. Le calcul utilise un réseau édité en ligne. -
0:00
Calcul d’itinéraires avec édition du graphe en ligne
sur CamptocampPièce jointe: [télécharger]
L’application Plan, basée sur GeoMapFish, permet aux visiteurs de l’EPFL d’afficher des itinéraires piétons. Le calcul utilise un réseau édité en ligne. -
0:00
Ouverture du code de GetItFixed!
sur CamptocampPièce jointe: [télécharger]
GetItFixed! est un projet open source et public pour aider à la remontée d’informations par les usagers. -
0:00
Ouverture du code de GetItFixed!
sur CamptocampPièce jointe: [télécharger]
GetItFixed! est un projet open source et public pour aider à la remontée d’informations par les usagers. -
0:00
KADAS Routing – a routing plugin for offline navigation
sur CamptocampPièce jointe: [télécharger]
Learn more about the offline routing plugin that we have developed for KADAS Albirero. -
0:00
KADAS Routing – a routing plugin for offline navigation
sur CamptocampPièce jointe: [télécharger]
Learn more about the offline routing plugin that we have developed for KADAS Albirero.
-
13:45
2021, Lizmap will be 10 years old
sur ReLucBlogThe year 2020 was marked by the growth of the 3Liz team (now we are 8) and the release of version 3.4 of Lizmap Web Client (Liste des nouvelles fonctionnalités)
This new version marks a change in the way Lizmap Web Client works, as some features now depend on the installation of the Lizmap plugin for QGIS Server. The Lizmap plugin extend QGIS Server API.
In 2011, when Michaël imagined Lizmap, he wanted to take advantage of QGIS Server to facilitate the creation of Web maps, by offering a solution that integrates with QGIS so that the geographic data manager doesn't have to change tools when he wants to make a Web publication of his work.
In 10 years, Lizmap has become a true tool for creating and publishing Web mapping applications ranging from simple maps for consulting geographic data to collaborative geographic data management applications (addresses, water networks, naturalist observations, etc.), including the creation of dashboards with graphs or data mining tools.
Consulting data with Lizmap
Points of interest in the Lake Geneva Watershed
Selecting and export data with Lizmap
Faunistic observations in Polynesia
Collaborative Data Editing with Lizmap
Evolution of COVID-19 in France from march to may 2020
Dashboards Lizmap
Data mining with Lizmap
In 2021, we want to continue to improve the quality and stability of Lizmap (code refactoring, adding new tests), release 2 new versions of Lizmap Web Client with a version 3.5 at the end of May 2021, and maybe a new major version at the end of the year.
All the 3Liz team wishes you a very happy new year 2021 with Lizmap.
-
13:30
2021, Lizmap aura 10 ans
sur ReLucBlogL'année 2020 a été marqué par une croissance de l'équipe de 3Liz (nous sommes maintenant 8) et par la publication de la version 3.4 de Lizmap Web Client (Liste des nouvelles fonctionnalités)
Cette nouvelle version marque un changement dans le fonctionnement de Lizmap Web Client, car certaines fonctionnalités dépendent maintenant de l'installation du extension Lizmap pour QGIS Serveur. Le plugin Lizmap étend l'API standard de QGIS Serveur.
En 2011, quand Michaël imagine Lizmap, il souhaite profiter de QGIS Serveur pour faciliter la création de cartes Web, en proposant une solution qui s'intègre à QGIS afin que le gestionnaire de données géographiques n'ait pas à changer d'outil lorsqu'il souhaite faire une publication Web de son travail.
En 10 ans, Lizmap est devenu un vrai outil de création et de publication d'applications Web cartographiques allant de la simple carte de consultation de données géographiques à l'application de gestion de données géographiques collaboratives (adresses, réseaux d'eau, observations naturalistes, etc) en passant par la création de tableaux de bord avec graphiques ou d'outils d'exploration de données.
Risques de crues à Montpellier
Consultation de données avec Lizmap
Points d'intérêts dans le bassin versant du lac Léman
Sélection de données et export avec Lizmap
Observations faunistiques en Polynésie
Édition collaborative de données avec Lizmap
Évolution du COVID-19 en France de mars à mai 2020
Tableaux de bords avec Lizmap
Suivi des déplacements de chats
Exploration de données avec Lizmap
En 2021, nous souhaitons continuer à améliorer la qualité et la stabilité de Lizmap (refactorisation du code, ajout de nouveaux tests), publier 2 nouvelles versions de Lizmap Web Client avec une version 3.5 fin mai 2021, et peut-être une nouvelle version majeure en fin d'année.
Toute l'équipe 3Liz vous souhaite donc une très bonne année 2021 avec Lizmap.
-
16:52
Refactoring and tests about the PHP code in Lizmap
sur ReLucBlogAdrien Lagroy de Croutte from the École 42 joined 3Liz 6 months ago for an internship.
His main goal was to lead a refactoring on the PHP code of Lizmap, to make it easier to write unit tests.
His second goal was writing unittests. Approximately 200 unit tests have been added. These tests are executed by the continuous integration platform on each commit to avoid regressions and bugs.
Thanks to this work, we will avoid regressions for any next versions of Lizmap by having more tests on our continuous integration platform.
Thanks to you Adrien ;)
-
11:03
Refactoring et tests du code PHP de Lizmap
sur ReLucBlogAdrien Lagroy de Croutte de l'École 42 a rejoint 3Liz il y a 6 mois dans le cadre d'un stage.
Sa mission principale a été de faire un refactoring du code PHP de Lizmap, ceci dans le but de pouvoir plus facilement le tester unitairement.
Sa seconde mission a été d'ajouter plus de 200 tests unitaires. Ceci sont exécutés par nos outils d'intégration continue sur chaque modification du code, nous évitant de possible bugs et régressions.
Grâce à ce travail, nous limitons les régressions sur les prochaines versions de Lizmap en rendant le code plus testable par des outils d'intégration continue.
Merci à toi Adrien ;)
-
0:00
FOSSGIS 2021 in Rapperswil: Camptocamp is Platinsponsor!
sur CamptocampPièce jointe: [télécharger]
Camptocamp is happy to be on-site again from June 06 - 09 as a platin sponsor and exhibitor at the FOSSGIS 2021 conference. -
0:00
FOSSGIS 2021 in Rapperswil: Camptocamp is Platinsponsor!
sur CamptocampPièce jointe: [télécharger]
Camptocamp is happy to be on-site again from June 06 - 09 as a platin sponsor and exhibitor at the FOSSGIS 2021 conference. -
0:00
Camptocamp, sponsor des 8èmes Rencontres Utilisateurs de QGIS
sur CamptocampPièce jointe: [télécharger]
Pour la 8ème année consécutive, Camptocamp a été sponsor, au niveau Mécène, de la conférence des Rencontres des Utilisateurs Francophone de QGIS. -
0:00
Camptocamp, sponsor des 8èmes Rencontres Utilisateurs de QGIS
sur CamptocampPièce jointe: [télécharger]
Pour la 8ème année consécutive, Camptocamp a été sponsor, au niveau Mécène, de la conférence des Rencontres des Utilisateurs Francophone de QGIS. -
0:00
InkMap
sur CamptocampPièce jointe: [télécharger]
Pour nous, il est temps de profiter des innovations récentes dans le monde du Web pour embarquer ces outils d’impression directement dans le navigateur. -
0:00
InkMap
sur CamptocampPièce jointe: [télécharger]
Pour nous, il est temps de profiter des innovations récentes dans le monde du Web pour embarquer ces outils d’impression directement dans le navigateur.