Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considèrerons que vous acceptez l'utilisation des cookies. J'ai compris ! ou En savoir plus !.
Un Planet est un site Web dynamique qui agrège le plus souvent sur une seule page, le contenu de notes, d'articles ou de billets publiés sur des blogs ou sites Web afin d'accentuer leur visibilité et de faire ressortir des contenus pertinents aux multiples formats (texte, audio, vidéo, Podcast). C'est un agrégateur de flux RSS. Il s'apparente à un portail web.
Vous pouvez lire le billet sur le blog La Minute pour plus d'informations sur les RSS !
  • Canaux
  • Categories
  • Tags

    • Canaux

    4384 éléments (139 non lus) dans 55 canaux

    Dans la presse Dans la presse

    Toile géomatique francophone

    Sauter à la page: 1 ... 8 9 10 11
     
    • 02 January 2023

    • sur Je viens de ou bien je vais à Yaoundé ?

      Publié: 2 January 2023, 12:32pm CET par Françoise Bahoken

      [UPDATE] 3 juin 2023.
      L’ouvrage Villes enchantées coordonné par Raphaël PIERONI et Jean-François STASZAK a reçu le Prix du livre de géographie (étudiants, lycéens) 2023 !!! Un grand bravo !
      Suis fière d’y avoir un peu participé avec la chanson dont il était question dans ce billet.

       

      Dans ce court billet, comme dans le texte auquel il fait référence, s’il n’y a point de cartographies, ni de cartes et ni même d’images, il est tout de même questions de migrations. Ces migrations diffèrent cependant de celles que j’ai maintenant l’habitude d’examiner, car elles sont locales et concernent le cœur de l’Afrique noire. Elles sont aussi décrites par le recours à une chanson.

      Pour rédiger le texte Je vais à Yaoundé commentant la chanson éponyme, je suis donc sortie de ma zone de confort, pour mon plus grand plaisir tant l’exercice fut amusant et rafraichissant.

      Nous vous invitons donc à contribuer à Villes enchantées. L’idée est simple : il s’agit de choisir une chanson qui évoque plus ou moins directement une ville, un lieu ou un espace urbain, et d’écrire un court texte qui en fait le commentaire, d’un point de vue géographique ou urbanistique, mais qui peut être très subjectif. Il peut s’agit d’un lieu réel ou fictif, spécifique ou générique.

      En répondant favorablement et à chaud à ce message tambouriné de Raphaël Pieroni et Jean-François Staszak (Univ. de Genève) sur la liste des géographes francophones, je me suis retrouvée face au petit défi personnel d’écrire un texte sur une ville (ah bon ? ben oui) à partir d’une chanson (ah?!). Je fus immédiatement saisie d’une sorte de stress lié à un excessif engouement pour cette idée, qui m’avait pourtant plue d’emblée. Mais n’y avais-je pas répondu favorablement trop rapidement ?

      Quelle ville allais-je donc choisir d’évoquer ? Et ensuite quelle chanson ? C’est pas comme si j’écoutais de la musique tous les jours…

      Vu l’un des chefs d’orchestre que je ne connaissais que de nom, j’ai immédiatement pensé qu’il fallait que je choisisse une ville africaine. Dakar fut la première qui me vint à l’esprit, évoquée par l’artiste Youssou N’dour, dans From Village to Town – un album que j’aime beaucoup -. Si ce texte pouvait convenir dans un contexte d’écriture professionnel, je ne trouvais pas l’idée satisfaisante pour deux raisons principales. La première est que les travaux sur l’Afrique subsaharienne/noire portent quasi exclusivement sur la belle et majestueuse Afrique de l’ouest : le Sénégal, le Mali, le Niger (mais moins le Nigéria), la Mauritanie et ainsi de suite. L’Afrique centrale m’apparaît (depuis quelques temps déjà) comme le parent pauvre de ces travaux sans que je sache vraiment pourquoi (enfin, je peux le deviner, mais je n’en suis pas spécialiste). La seconde raison est que je me suis étrangement sentie comme obligée d’écrire quelque chose sur Yaoundé, alors que j’avais initialement pensé à Dakar, et que, maintenant, je pensais aussi à Lagos. Ce choix de Yaoundé m’a questionné. pourquoi Celui-là ? C’est bizarre comme je m’assigne ici, moi-même, toute seule, une obligation de choisir cette ville, dont je savais qu’elle me renverrait immédiatement à une identité d’appartenance quasi exclusive à cette sous-région d’Afrique noire, alors que ce n’est pas le cas. Est-ce que les autres auteurs et autrices de cet ouvrage allaient choisir leur ville à chanter/enchantée en fonction d’un sentiment d’appartenance ?  Pourquoi je fais cela ? Tout de suite, à l’heure ou j’écris ces lignes, je ne me sens même pas, ou même plus de Yaoundé d’où je suis partie il y à plus de trente ans, après y avoir vécut quelques treize années de ma vie. Bref.

      Ayant par ailleurs la conviction qu’il n’allait pas y avoir beaucoup de textes sur des villes africaines, j’ai donc réfléchi à une chanson sur Yaoundé. Laquelle choisir ? Comme cette chanson devait être “populaire” et qu’il fallait que je puisse écrire dessus, mon esprit s’est rapidement arrêté sur Je vais à Yaoundé de André-Marie Talla. Mais était-elle assez populaire pour le public européen occidental auquel l’ouvrage m’apparaissait se destiner ? Pour moi, en tous cas, elle l’était et c’est gaiment que je soumettais peu après l’appel, ma proposition de ville enchantée.

      La réponse ne se fit pas attendre.

      Les coordinateurs de l’ouvrage ayant accueilli favorablement mon idée, je me lançais dans la soirée qui suivi à l’écriture de ce court texte d’environ 700 mots, portant sur les mobilités des espaces ruraux vers les centres espaces urbains, dans le Cameroun des années 1975/1980.

      Extraits

      Lire la suite dans… Villes enchantées. Chansons et imaginaires urbains, pages 108-109.

      ou le manuscrit auteur déposé dans HAL

      Référence : Françoise Bahoken (2022), Je vais à Yaoundé, André-Marie Tala (1975), in : Raphaël Pieroni et Jean-François Staszak (coord.), Villes enchantées. Chansons et imaginaires urbains, Georg Editor, Seine-Bourg (Suisse), pp. 108-109. 

      Françoise Bahoken

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

      More Posts

    • 29 December 2022

    • sur Parquet devrait remplacer le format CSV

      Publié: 29 December 2022, 12:19pm CET par Éric Mauvière

      Parquet 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é !

      parquet1

      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 à CSV

      Ré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 Parquet

      Jusqu’à 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 Parquet

      Votre 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 Parquet

      Nous 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 soin

      Attardons-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ées

      Dans 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 un col_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 efficaces

      Une 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 final collect() :

      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 à jour

      open_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 classiques

      Je 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émentaires

      Cloudera 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 tabulaires

      Le 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 loin

      Présentation du format

      Différences Arrow / Parquet

      Pour jouer avec Parquet

      Le projet Arrow

      L’article Parquet devrait remplacer le format CSV est apparu en premier sur Icem7.

    • 20 December 2022

    • sur Geomatys labellisé CNES PME

      Publié: 20 December 2022, 2:58pm CET par user
      Geomatys certified by the CNES SME Label

      Depuis 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.

    • 03 November 2022

    • sur across() est plus puissant et flexible qu’il n’y parait

      Publié: 3 November 2022, 5:44pm CET par Éric Mauvière

      La 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

      L’article across() est plus puissant et flexible qu’il n’y parait est apparu en premier sur Icem7.

    • 28 October 2022

    • sur Geomatys se développe et recrute un(e) full stack développeur (se)

      Publié: 28 October 2022, 5:12pm CEST par user

      Nous 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 October 2022

    • sur Divagations à propos du temps

      Publié: 21 October 2022, 9:34pm CEST par Isabelle Coulomb

      Bonjour, 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 &#x1f929; ! Et même de calculer une évolution &#x1f60d; ! 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 moi

      Revenons 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.

    • 12 October 2022

    • sur Journée d’étude : L’histoire de la cartographie et son écriture à l’épreuve du renouvellement, Campus Condorcet (Aubervilliers), 25/11/2022

      Publié: 12 October 2022, 12:49pm CEST par Catherine Hofmann

      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 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.
      Informations pratiques
      • 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
      Journée d’étude soutenue par la Comité français de Cartographie, le CNRS, la BnF et Histara Affiche-Journee-detude-CFC-25-novembre-2022Télécharger
    • 15 September 2022

    • sur Recrutement: IE en Télédétection

      Publié: 15 September 2022, 10:41am CEST par user

      La 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.

    • 04 September 2022

    • sur Le syndrome de l’empilement

      Publié: 4 September 2022, 2:04pm CEST par Éric Mauvière

      Les 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égorisant

      Revenons 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émorable

      On 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,
      c'est quand elle nous amène à remarquer
      ce que l'on ne s'attendait pas à voir. »

      John Tukey, Exploratory Data Analysis, 1977
      Pour aller plus loin

      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.

    • 31 May 2022

    • sur Cartes et géomatique : les articles 2016 sont en ligne

      Publié: 31 May 2022, 6:41pm CEST par Lucile Haguet

      Cartes & 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)

    • 25 April 2022

    • sur Appel à communications : « L’histoire de la cartographie et son écriture à l’épreuve du renouvellement » – Date butoir : 6 juin 2022

      Publié: 25 April 2022, 7:28pm CEST par Catherine Hofmann

      Journé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.

    • 31 March 2022

    • sur Cartes et géomatique : les articles 2017 sont en ligne

      Publié: 31 March 2022, 6:23pm CEST par Lucile Haguet

      Cartes & 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)

    • 07 March 2022

    • sur Exposition “Inventer l’Indochine. Cartographier l’ailleurs (1873-1936)”

      Publié: 7 March 2022, 8:00am CET par Catherine Hofmann
      Exposition à la bibliothèque de l’Institut de Géographie Du 7 mars au 23 juillet 2022

      De 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.

    • 28 February 2022

    • sur Cartes et géomatique : les articles 2018 sont en ligne

      Publié: 28 February 2022, 4:23pm CET par Lucile Haguet

      Cartes & 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 2018

      L’œ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 2018

      L’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)

    • 22 February 2022

    • sur L’atlas nautique ou portulan du Havre

      Publié: 22 February 2022, 3:55pm CET par Lucile Haguet

      [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 Havre

      Sous 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 incertaines

      Qui 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 incertaine

      Il 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.

    • 31 January 2022

    • sur Cartes et géomatique: les articles 2019 sont en ligne

      Publié: 31 January 2022, 5:05pm CET par Lucile Haguet

      Cartes & 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 2019

      Archives Nationales (Nadine Gastaldi)

      n° 241-242, juin 2019

      Des 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)

    • 04 October 2021

    • sur Modélisation de la distribution des espèces next-level

      Publié: 4 October 2021, 10:16am CEST par user
      Piè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.

    • 01 October 2021

    • sur Visualisation des conditions météo à la volée en réalité augmenté

      Publié: 1 October 2021, 12:02pm CEST par user

      Depuis 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.

    • 02 July 2021

    • sur Dataviz : “voir et donner à voir”

      Publié: 2 July 2021, 2:32pm CEST par user

      Dans 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)

    • 18 March 2021

    • sur On our way to quality

      Publié: 18 March 2021, 10:55am CET par René-Luc D'Hont

      Lizmap 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.

    • sur Nos efforts qualité

      Publié: 18 March 2021, 10:39am CET par René-Luc D'Hont

      Lizmap 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.

    Sauter à la page: 1 ... 8 9 10 11
     
    ← Du côté des éditeurs Géomatique anglophone →