Try   HackMD

École thématique Sciences de l’information géographique reproductibles

Lien vers le hackmd: https://hackmd.io/@sigr2021/ryEIk-whu

Vos remarques et suggestions

Nous aimerions recueillir vos remarques et suggestions sur cette école thématique. Qu'elles portent sur l'organisation (hébergement, repas…), la forme (par ex. "ateliers le matin cours le soir, il faudrait faire l'inverse…") ou le fond ("c'est dommage de n'avoir pas évoqué les questions de stockage des données") vous pouvez les écrire ici :

  • Peut-être aurait-il fallu laisser une demi journée libre pour profiter un peu du site pendant la journée. :-1:

  • Beau panorama des méthodes, outils et chouettes discussions et échanges, très belles interventions + un max. de ressources très pédagogiques mises à disposition. Emploi du temps OK. Temps de mise en pratique parfois un peu juste.

  • Pour une prochaine édition (celle-ci est déjà géniale !), peut-être que mettre les participant·e·s sur un travail commun un peu conséquent pourrait permettre de renforcer la pratique d'une façon plus profitable que des séries d'exercices (géniaux aussi ;-) déconnectés entre eux ? Voire, est-ce qu'un tel projet collectif ne pourrait pas permettre de résoudre de vraies problématiques qui se posent dans les labos (mise en place d'un portail de données, par ex ?) ?

  • (Sylvestre) Cours et ateliers très rapides (mais toujours en écoles thématiques), mais le volume de contenu était bien et adapté à la semaine ! :+1:

  • (Sylvestre) Idée qu'il serait pas mal d'avoir des projets de groupe avec présentations collectives à la fin de la semaine : par ex mettre à dispo sur github et pour tout le monde un traitement de données spatiales (vecteur ou raster) sur r, par ex sur Oléron.

  • (Sylvestre) super intéressant d'avoir les présentations de tout le monde en fin de journée.

  • (Sylvestre) idée que ce genre de semaine est indispensable à beaucoup de gens environ tous les deux-trois ans… pour continuer à suivre des outils/enviro/techniques et des méthodes qui évoluent vite. :+1:

  • Tous les ateliers sont parfaits. Le temps donné est idéal. Le seul bémol est le cours de l'analyse spatial qu'il faudrait peut-être plus lier au TD du lendemain.

  • c'était super ! Un grand bravo aux organisateurs et intervenants. Je repars avec plein d'idées et d'outils que j'espère mettre en pratique bientôt. L'équilibre ateliers/conférences était parfait pour moi. En plus il y avait un off avec sessions du soir, merci aux intervenants pour leur disponibilité.

  • Semaine très enrichissante. Programme adapté pour tous les niveaux. Visio en anglais à éviter car TP + visio + langue anglaise = TP trop compliqué à ingérer et digérer.

  • Un super moment, réellement adaptée à toutes les pratiques de R, mêmes en partant de 0. Bienveillance et entraide tout du long. Super idée que de mixer les niveaux autour des tables pour une meilleure autogestion.

  • Cette école thématique a répondu à mes attentes : intervenants pédagogues, présentations claires, adaptées à tous, exemples pertinents. J'espère que les liens aux présentations resteront actifs longtemps. Merci beaucoup pour cette trés enrichissante semaine.

  • Intervenants très intéressants et beau panel méthodologique une semaine avec un planning dense ; j’ai apprécié l’alternance théorie / atelier, avec un bémol pour le manque de temps pour manipuler pendant les ateliers… très bonne idée de créer des petits sous-groupes, cela a facilité l’interrelation et à permis aux débutants d’avoir des bouées de sauvetage à proximité ;o). Très bien les petites présentations de fin de journées pour connaitre les participants et prendre connaissance de ce qui se fait dans d’autres labos ; beaucoup de richesse ! Quelques grands écarts entre la théorie et la pratique (lorsque les intervenants étaient différents). Difficulté avec la visio en anglais… par la force des choses l’intervenant était trop en recul par rapport à ce qui se passait dans la salle. L’accès aux supports (en espérant une certaine pérennité) est un +. Côté logistique : merci pour les navettes ; hébergement correct mais restauration moyenne (problème de gestion de stock entre la commande et le service à table…). Un grand merci aux organisateurs et intervenants de cette ET

  • Suggestions d'intervenants pour #SIGR2022

    • #rspatial
      • Edzer Pebesma
      • Roger Bivand
    • création de package R : Sébastien Rochette
    • Production documents Rmarkdown
      • Yihui Xie
      • Christophe Dervieux

tout simplement :smile: :arrow_heading_up: (@rgeomatic)

  • Le bar ferme trop tôt + trop de moustiques

  • :cupid: rgeomatic :world_map:

  • superbe semaine, merci aux organisateurs et intervenants pour l'énorme travail de conception et de réalisation. J'ai apprécié l'alternance de théorie et de mise en pratique. Rien a suggérer, vous avez mis la barre très haut ! Peut-être prévoir des temps de pratique commune suplémentaires ? sur la base du volontariat ? lors des temps off ? A condition que le bar ferme plus tard !! :smile:

Un grand merci Timothée, plus généralement aux colègues de Riate.

  • (Arnaud) :pray: Un grand merci à tous et à toutes pour cette super semaine que j'ai passée avec vous. J'ai appris plein de choses, des discussions super intéressantes sur des problèmes complexes aux enjeux majeurs. Je saurai où aller en cas de reconversion thématique! :smiley: Et grand bravo aux organisateurs de RIATE!

Site web de l'école: https://sigr2021.github.io/site/ Lien vers le hackmd: https://tinyurl.com/sigr2021 https://hackmd.io/@sigr2021/ryEIk-whu

Notes au format packagedown

Aide pour les installations

Rtools installe pour windows les compilateurs et tout ce qu'il faut pour pouvoir developper et installer du code (pas forcément en R). devtools et remotes fournissent ce qu'il faut pour développer des package R "proprement" (notamment installer des packages qui ne sont pas sur le CRAN).

Lundi 28 Juin

Présentation générale

Constitution des groupes en fonction des compétences

Séminaire Recherche Reproductible

Quelques ressources (slides, MOOC, git avec des petits dessins, etc.)

Autres ressources qui n'ont rien à voir avec la recherche reproductible mais dont j'avais discuté avec certain(e)s à table:

Reproducibility Crisis and Open Science (Arnaud Legrand)

Ioannidis : statisticien, inflation de résultats faux, 2005

Crise de reproductibility : différent en fonction des disciplines

  • falsification / fraude (cas Dong-Pyou Han, Diederik Stapel, Brian Wansink, Reinhart and Rogoff)
    • "si lui c'est faux que doit-on penser des autres"
    • "coding errors, selective exclusion" (2013 Herdon, Ash and Pollin)
    • Publication en appuie aux politiques d'austerité

La mauvaise science est déletere. Facilite un discours "anti-science".

-> crise de la crédibilité

Pourquoi est-ce que ces problèmes sont mis sur le devant la scéne ?

Fraude scientifique pas nouvelle.

Les pratiques évoluent. Pas simple de faire le tri entre ceux qui trichent, ceux qui "ameliorent/mise en forme".

Crise de la reproductibilité : multi facteurs : fraudes, conflits d'interêt, incitations à reproduire et craintes pour se faire pirater (data et codes). En + de ces facteurs organisationnels, il y a aussi les facteurs + techniques : performance, data manquantes ou incompletes.

Cas en informatique de conf. centrée sur la reproductibilité des autres. Besoin d'un débat cordial dans la communauté scientifique.

Voire la reproductibilité comme une valeur coeur de la science et accessible à tous. contrôle de l'universalité et robustesse, permet un controle qualité.

Les pratiques scientifiques ont évolué avec l'informatiques.

-> besoin d'ameliorer les pratiques logiciels

Il peut y avoir des problèmes au niveau des outils non adaptés, techniques non comprises, environnement logiciel.

Différentes réponses en fonction des disciplines:
Il y a des techniques de "pre-registration" : on publi methode et hypothèse et quoi qu'il arrive au niveau des résultats l'etude sera publiée.

Pas inutile de raconter les impasses. Article iceberg de la recherche. Reproductibilité : Donner accès à un maximum d'infos pour reproduire les calculs, les analyses et les résultats publiés dans un article.

  • reproductibilité expérimentale = même data, mêmes analyses, refaire le calcul de bout en bout
  • reproductibilité statistique : data différentes, mêmes analyses
  • reproductibilité computationnelle :

Plusieurs outils:

  • Notebooks and workflows R studio, Jupyter
  • Software environments (Docker)
  • plateforme de partage (gitlab/ github)

Bonne pratique #1 : prendre des notes

Tool 1 : Journals and Litterate Programming

Programmation lettrée: code lisible pour un humain (Jupyter fonctionne comme du html; RStudio). Dans Jupyter, la trace des résultats est stockée (différemment de RStudio).

Contient : raisonnement, code et résultat de ce dernier

Avoir un cahier de laboratoire électronique equivalent : Emacs = 1 seul fichier, un éditeur de texte pensé comme un journal et qui sera diffusé ensuite.

Savoir si le doc va être partagé ou pas y compris ulterieurement.

Utilisation d'org mode.

Deux fonctionnalités : Git et ecrire en même temps.

Journal: structure par date + mots clefs

Pas une panacée pour dev du code. Peu finir illisible.

Il y a utilisation de workflow pour décrire la liste des processus : structurer, décrire chaque brique et leur articulation. Exemples : Galaxy, Pegasus, snakemake (make en Python)… Avec R le package targets est une solution récente (successeur de drake, même auteur).

Tool 2: Software Environment Control

En + de la version du code, la gestion des environnements logiciels et des dépendances des OS sont essentiels + impacts des compilers + des écosystèmes complexes (dépendance entre les packages).

Ecosysteme complexe:

Résultat différent entre la version de matplotlib donnée par la fonction et celle donnée par le gestionnaire de packets.

Il y a pas de standart sur les gestionnaires de packets (?).

Dans le notebook, utiliser sessionInfo() et expliquer précisement les précautions d'usage Qq outils pour nous aider :

  • repro.zip , fichier créé automatiquement, pas limité
  • docker, singularity : conteneur, plus léger qu'une machine virtuelle, il embarque une image comprenant le programme et ses dépendances. Il faut builder: docker build -f <mon dockerfile> Lancer : docker run <img> <cmd> mais Docker a aussi ses limites, plutôt adapté pour de la diffusion (ex : derniere version d'un developpement), mais pas pour de la reproductibilité
  • gestionnaire de paquets fonctionnels : écrire sous forme de fonctions. exemple : GUIX/NiX

Tool 3: FAIR principles, Git, archives, …

Findable Accessible Interoperable Reusable

Principes generaux n'aidant pas toujours dans la vie de tout les jours.

Git = version control

En local avec une facilité de retour en arrière

Distribué tout le monde a une copie de l'histoire.

Gérer son versionnement de son code avec GIT

Forges logiciels : GitHub, GitLab

"verité des prix poussé à l'extrème"

  • Réseau social de dev.
  • Interface web
  • Gestion des utilisateurs
  • Autres outils: Issues, CI/CD
  • Github pour le côté collaboratif, soit : avec
    • Github : racheté par Microsoft
    • Gitlab : code source ouvert
    • Gitlab institutionnels

des possibilités de migrer d'une forge à l'autre. Attention, ces forges ne sont pas des archives! La forge Inria Gforge est en cours de fermeture.

Archives

Git n'est pas une archive.

Article archives arXiv.org / HAL : travail de curation

Data archives: figshare / zenodo : pas de curation

Software Archive: Software Heritage

Archives

  • de données : Zenodo (CERN) pour les données libres de droit, Figshare
  • de codes : Software Heritage : rassemble toutes les versions de codes des différentes forges. Il collecte, mais aussi référence tous les développements avec des url pérennes. sions de codes des différentes forges. Il collecte, mais aussi référence tous les développements avec des url pérennes.

"Aspect Humains"

Il existe des manifestes.

Software carpentry

En tant que communauté il est possible d'agir.

Le faire progressivement.

Ouvrir la science :https://www.ouvrirlascience.fr/ ?

R Markdown

Présentation

Produire des documents reproductibles avec R markdown : Partager code et documentation

Tricoter son document que l'on peut partager avec ses collègues.

chunk : un morceau de code dans un document de literate programming.

literate de programmation: "Expliquer à des êtres humains ce que nous voulons que l'ordinateur fasse" Knuth 1970

Permet de suive le cheminent de la pensée.

Un gain géneral de la reproductibilité + partage

balisage léger+ langage de programmation (R, Python, SQL..)

Usage de la communauté

2012, Yihui Xie -> knitr 2014 -> rmarkdown

Il y a beaucoup de packages qui dependent de rmarkdown.

Repose sur:

  • Markdown
  • R Markdown : encapsule du code dans des chunks qui va l'executer
  • Knitr
  • Pandoc convertit md en plus structuré

Un doc R Markdow contient 3 éléments:

  • des metadonnées avec le YAML
  • texte : decrit le cheminement
  • Bloc de code Plusieurs formats possibles en sortie : html, sorties de site web

kniter / tricoter le document = produit le document

Avec la même syntaxe Rmarkdown on peut faire plein de choses différentes, il suffit d'utiliser le bon "backend":

Faire son Rmarkdown

Etape 1: se préparer

  • Travailler en projet via Rstudio (gestion des liens en relatif)
  • Organiser son espace de travail. Possibilité de s'inspirer de https://github.com/benmarwick/rrtools qui fournit des scripts R qui automatisent la création du répertoire, de la licence, du README, etc.

R studio est un IDE: environnement de développement

Il propose des modèles paramétrables.

Questions: autour de l'accés aux données, liens vers des entrepots de données, controles sur l'evolution de ces sources ? -> dépasse la question du Rmarkdown

Syntaxe markdown

Passe du md en html

Pour les tables : Tables Generator

Parfois besoin de compléter avec du html.

Bonnes pratiques de codes

Decomposer le code

  • Respecter indentation, hiérarchie
  • Organiser ses commentaires. Distinction entre le texte et le commentaire
  • Des noms d'objets prononcables et révélateur
  • Virer la dépendance si peu de ligne de code
  • Cibler la langue en fonction du public

Fonctionnement du R Markdown

chunks = trocons délimité par des backticks

On peut avoir un setup chunk avec les paramètres que l'on souhaite par defaut.

mettre en fin du markdown : 'sessioninfo::session_info()' Ca permet d'avoir des infos sur sa session : quel langage, etc.

Mardi 29 juin

Présenter vos travaux en Markdown

Plus d'abdo avec R et Rmarkdown qu'avec ppt

Pro:

  • Tout se fait dans un meme environnement
  • adapter pour du code
  • partage/versionning via git

cons:

  • pris en main plus compliqué
  • besoin de connaissance CSS/html

Il y a des packages pour améliorer les présentations.

Avec Xaxingan: - Ninja - Ninja avec theme

en tête

On a un YAML.

il y a différentes options.

seal desactiver la première slide de la présentation (dans les output)

On peut activer des librairies JS.

contenu

–- fait une nouvelle diapo

On peut cloner l'ecran.

Présenter facilement du code avec coloration synthaxique et l'option highlight pour souligner les lignes de codes.

Marche pour R et d'autres langages.

<ins>souligngé</ins>

On peut définir des classes spécifiques pour des contenus dans une slide.ex : deux contenus en vis-à-vis (pull-left)

Il y a des classes CSS par defaut et on peut personnaliser au besoin.

On peut définir des élements pour toutes les slides avec layout (créer ses modeles de slide)

On peut y intégrer tous les éléments d'une page web : carte Leaflet, du code JavaScript…

Pour personnaliser sa présentation, soit créer son propre fichier .css , soit avec le package xaringanthemer, qui permet de modifier directement le style css dans l'environnement R Studio. Associer également des styles pour ggplot

xaringanthemer va ecrire le fichier .css dans la racine de la présentation.

xaringanExtra: Possibilité de rendre du texte editable mais pas sauvegardé (penser à faire une capture d'ecran).

Possibilité d'ajout d'un countdown / minuteur

library(countdown)

il existe une option pour encapsuler tout les fichiers annexes dans un seul fichier selfcontained = true (probablement pas la bonne commande)

intro à Git

Pour Windows, dans R Studio, aller dans terminal choisir GitBash, puis recréer un terminal dans Tools Terminal New terminal.

obj: configurer Git et Github et partager une présentation

possibilité de GitLab avec Huma-Num

imspiration : https://happygitwithr.com/

  1. créer un compte sur GitHub

dans R Studio ouvrir le terminal



which git
git --version

  1. configuer sur la machine en local

  2. faire le lien entre la machine en local

    • HTTPS
    • SSH (couple de clefs : une publique avec .pub et une privée) C'est la clef publique que l'on doit communiquer à la forge.

  3. Verifier et activer le gestionnaire de clefs ici ssh-agent

  4. Ajouter la clef

Workflow

Création du dépot Github
Cloner le repo dans sa machine
Créer un projet
Faire une nouvelle présentation
Faire un commit sur la présentation

Avant de déposer, pousser sur Github, ne pas oublier de faire un pull, pour récupérer les fichiers en local, au cas où une autre personne aurait modifié en même temps.

Réaliser un fork : avoir une copie du dépot en local

Ressources

Pour les utilisateurs de windows, quelques informations sur comment installer pas à pas https://gitlab.inria.fr/learninglab/mooc-rr/mooc-rr-ressources/-/blob/master/module2/ressources/gitlab_fr.org

Trivia:

Mes commits en starwars:

Modele: http://starlogs.net/<#user>/<repo>

http://starlogs.net/#defuneste/arbresosm

SIG et Cartography

https://nowosad.github.io/SIGR2021/

R pour les statitiques, evolution pour les données spacialisées.

Obj: donner une vue d'ensemble de l'ecosysteme avec R

ecrire des scripts -> ecrire des packages -> partage sa recherche de manière partagée

"je peux coder une nouvelle idée et regarder comment elle se materialise"

Pour partager du code:

https://rustpad.io/#uFuBVH

Après le cours:

  • SO pour des questions generales / reponses rapides
  • Rstudio community
  • GIS SE
  • R-SIG-GEO

créer une reprex : exemple reproductif

package reprex

rstudioapi::openProject("<path>")

reprex::reprex() Besoin d'avoir le code surligné

GIS ecosystem of R

Différentes disciplines

Différentes utilisations (EDA, I/O, data processing, data viz, web map, software dev.)

Pourquoi R ou un autre outils ?

Partager ses idées avec R:

  • Rmarkdown
  • rpubs

Commencer small et construire dessus.

Partager son workflow

excalidraw.com

Construire ses propres packages et codes

R Packages

Faire un package: une idée et un problème

un exemple : travailler un jeux de données, le nettoyer et partager se travail

R package

On peut appeller certains GIS via R

Il y a des packages generiques et des plus specialisés

citer un package:

citation("tmap") - un pour un paquet

Permet de montrer le travail.

R spatial infrastructure

Différents niveaux

  • Package de R
  • Bibliothèques exterieur à R: utiliser par d'autres software

Etre sur les epaules des geants / layer of complexity

pont vers d'autres logiciels

qgisprocess connect vers QGIS

On peut aussi appeller un script de R dans QGIS

Package pour vector data et accés à des BD: sf

Pourquoi a-t-on besoin de spatial class : dans un programme il peut y avoir des tas de facon de une chose. Il y a différentes facon d'encoder un type de donnnée.

Dans un sf: une donnée spatiale est representé comme un tableau

Pour les données raster: raster et on bouge sur terra ou stars

raster comme geotiff pour terra

pour stars raster comme un data cube <- in progress

terra une classe, resolutions, bbox, +, source (peut être en memoire ou path)

Les objets de terra sont des vecteurs de valeurs

Mapping ecosytem

Différentes facons de faire de la cartographie / visualisation

tmap permet de lire bcp de format de classes spatiales dans R et permet de génerer des cartes statiques et dynamiques.

il y a des fonctions pour les couches (?) de formes et des fonctions pour les couches(?) d'attributs et +.

mapview vue rapide des données

mapdeck permet d'extruder des polygones par ex.

gganimate permet de réaliser des animations pour montrer des variations spatiales et temporelles

CRS

coordonnées projetées et coordonnées géographiques

Dessiner des cartes et aussi changer d'une à l'autre

https://ihatecoordinatesystems.com/

Geocomputation

Openshaw, 2000

Building and creating geotools but also sharing it.

Mercredi 30

C'est parti

slack si question: https://join.slack.com/t/geocomprworkspace/shared_invite/zt-sc7tqriq-9Q2rkveZwqCAQoBS3yqZNQ

Accès au support : https://nowosad.github.io/SIGR2021/workshop1/workshop1_rl.html#1

Meeting zoom: Sujet : SIGR 2021 - Wenesday Heure : 30 juin 2021 09:00 AM Paris

Participer à la réunion Zoom https://univ-eiffel.zoom.us/j/85952107647

ID de réunion : 859 5210 7647 Mot de passe : Vxv6h5LT

Comment importer des données

  • data dans un pakages
  • data fournit via un package
  • data via OSM
  • data via website










pkgs = c(
        "spData",
        "osmdata",
        "osmextract",
        "nzelect"
        )

remotes::install_cran(pkgs) # ne reinstalle pas les packages 

# si ils sont deja présents





library(spData)
library(osmdata)
library(osmextract)
library(nzelect)










?datasets # pour trouver la commande suivante

library(help = "datasets")  # liste des jeux de données dans R

world_phones_new <- datasets::WorldPhones # on charge le package

class(world_phones_new) # on regarde ce qu'il y a dedans (macherait aussi avec la commande str)

class(spData::nz)  # fonction class précise le type s'il s'agit de dataframe, matrix, vector...

class() retourne la classe de l'objet R

str() retourne la structure du jeux de données

Une bonne approche est d'utiliser un petit jeu de donnée plutot que sur tout le jeux de donnée afin de prototyper. Question : how small an example should be ?

Robin : assez grand pour demontrer la méthode et assez petit pour le charger, et on peut en faire plusieurs

Exercice : on télécharge une base de donnée (un objet) du package datasets. Celles-ci sont listées grâce à library(help=datasets).

mapview::mapview(abstr::montlake_buildings)

Je ne comprends pas à quoi correspond la ligne précédente : d'où vient Montlake_buildings ? <- c'est un jeu de donnée qui vient du package abstr

syntaxe : nom_package::fonction_du_package

exemple : sf::read_sf <- package sf avec la fonction read_sf




plot(nz$geom) # ajuste la geometry

plot(nz["Island"])

Un concept important est de garder la donnée originale safe.

On va donc reassigner à un objet d'exemple nz2 <- nz et nz2 = nz est pareil










library(nzelect) # on charge le paket avec des infos sur Nz en plus
nz_longlat <-  sf::st_transform(nz, 4326) # reproject nz
names(voting_places)

voting_places_sf <- sf::st_as_sf(voting_places, coords = c("longitude", "latitude"))

plot(sf::st_geometry(nz_longlat))
plot(voting_places_sf, add = TRUE)

Pour utiliser les fonctions d'un package que l'on a déjà installé, on peut soit charger le package entier avec library() :



library(sf)
st_crs(nz)

ou bien utiliser pkg:: pour chaque fonctions :

sf::st_crs(nz)

L'avantage de la deuxième solution est de de rendre explicite l'origine des fonctions que l'on utilise et de ne pas surcharger l'espace des fonctions, cela évite les conflits (entre 2 packages qui auraient des fonctions portant le même nom).

vsub <- voting_places_sf[nz,] # va retourner un msg avec un pb de crs

sf::st_crs(nz) # retourne le wkt du crs de ns

Quand on a des données sans CRS on peut le donner

voting_places_sf # NA en CRS

sf::st_crs(voting_places_sf) <- sf::st_crs(nz_longlat) # ici on va le crs de nz

Ici devrait marcher (pe optimum dans le workflow)





voting_places_sflonglat <- sf::st_transform(voting_places_sf, 4326)

vsub <- voting_places_sflonglat[nz_longlat,]

(installer packages {pryr} {repr} {skimr} {mapview} car ne fonctionne pas nécessairement avec le ::)

si on a ecrit une fonction sur github on peut la charger dans notre environnement avec source

source("https://github.com/Nowosad/SIGR2021/raw/master/workshop1/osm_combine.R")

attention à bien faire cela pour obtenir le link en raw :

Si on utilise osmextract le code de dessous montre comment on peut choisir une zone de delimitation des objets que l'on veut récupérer.




gzones <- osmextract::geofabrik_zones
gzones_france <- gzones %>% filter(parent == "france")
gzones_france$name

getting started with tmap package

On veut utiliser des données raster (terra) et vector (sf).







library(sf)
library(terra)
library(tmap)

remotes::install_github("Nowosad/spDataLarge")
nz_elev <- rast(system.file("raster/nz_elev.tif", package = "spDataLarge"))

le point de départ est la donnée spatiale

tm_shape(mon_objet_spatial) + et on ajouter des layers pour la visualiser (ATTENTION si on met juste la commande sans autres options avec des "+" ça ne marche pas)

il faut aussi rajouter d'autres objets à la legende si non compris dans le premier objet spatial






tm_shape(nz_elev) +
  tm_raster(title = "Elevation (m asl)", 
            style = "pretty",
            palette = "-Spectral")

pour explorer les couleurs

tmaptools::palette_explorer()

Les positions des attribute layers ne se superposent pas si elles sont indiuqés aux meme endroits c("right", "bottom")

il est important de garder un ordre dans l'affichage des layers : ex si on veut les graticules en fond il faut les mettres en premier

layout : concerne toute la cartes.

ex tm_layout(bg.color = "lightblue") va nettre un fond bleu

legend.outside option qui permet dans tm_layout de mettre la légende en dehors de la carte

On peut ajouter des marges ordre: bottom , left , top, right

Dans tmap il y a deux modes :

  • plot: static view
  • view: interactive mode

on peut sauver ses cartes dans un objets

fonction tm_ <- construire la carte, changer les paramètres sur les différentes couches et objets

fonction tmap_ <- aspect global portant sur le document save map, export, change modes

tmap_save prend une extension dans son filename qui détermine le type de fichier sauvé

Sciences reproductibles et analyse spatiale - M. Guérois

Synthèse sur plusieurs publications récentes sur la reproductibilité en analyse spataile, mais aussi des contreverses et erreurs -> cf. Brundson.
Obstacles techniques : régressions pondérées divergentes selon les outils utilisés et obstacles méthodologiques : échelle d'observation et variation des contextes.

Pionniers : Openshaw

Enquete sur les pratiques (Konkol et al): la moitié des enquetés ne mettent pas forcement à dispo le code et les données, mais seulement la méthodologie.

Particularités de la reproductibilité en analyse spatiale

  • existence de particularités liés aux SHS cf. Cura et al. (type de données, collecte, intérêt pour le raisonnement plus que sur la mesure)
  • incertitudes liées à la nature de l'info. géographique (difficulté intrinsèque : pas d'échelle fixe d'observation ou bien le périmètre d'étude)
  • ce n'est pas la reproductibilité des résultats qui est recherchée à tous prix, comme in sciences dures, à cause du principe fondamental de l'analyse géo à savoir l'hétérogénéité géographique. D'ou limites aux objections de généralisation, recherche de motifs, de lois, qui s'opposent au principe de reproductibilité à l'identique.
  • Statut ambigu de la recherche de reproductibilité en analyse spatiale. Cf . dév autour de la Regression géographique pondérée

-> Une synthèse possible est prorposée par Kedron & al. qui fait le lien entre recherche de repro. et démarches méthodo. de l'analyse spatiale. Hyp : à chacune de ces étapes (liées à la déf. de l'incertitude), on peut trouver des obstables à cette recherche de reproductibilité

Enjeux de la reproductibilité en analyse spatiale

Ces enjeux sont liés à des incertitudes conceptuelles et méthologiques

  • Incertitudes conceptuelles : ex. de l'artificialisation, qui est un concept équivoque (perte de biodiversité et consommation d'espaces agricoles).

Cf. discussion de A. Ruas dans Cybergéo sur les raisons de ces diversités de mesure.
Anne Ruas : Que penser du sens donné à l’artificialisation et à la désartificialisation des sols ?

2 hypothèses sont avancées : (1) diversité liées aux sources des données et des dispositifs de mesures et (2) incertitude sur le concept d'artificialisation (espace artificiel) dont le sens a pu évoluer. L'origine du concept de l'artificialisation date des années 80 (nomenclature TERUTI), puis progressivement un glissement sémantique : cf. vers un intérêt croissant pour la préservation de la biodiversité (/enjeux production agricole).

Comment relier cette évolution conceptuelle avec la chaîne de traitement informatique ?

Kedron & al. (2021) insistent sur la nécessité de clarifier les concepts, de développer l'ontologie et pour renforcer le formalisme dans les chaînes méthologiques.

  • Incertitudes liées aux données : cf. Projet en cours à l'UMS Riate sur les AirDNA

Exemple d'enjeux liés aux données en géomatique :

– accès aux sources

– diffusion de données dites "non conventionnelles" (réseaux sociaux, gps, plateformes de services, etc.)

– pauvreté des métadonnées

– problème d'échantillonage des observations (surtout pour traces)

– données manquantes dans les bases renseignées par utilisateurs

– appariement avec des données instutionnelles ou d'enquêtes pour :

–- les enrichir : cf. S. Duroudier dans Mobikids, pour enrichir sémantique des traces gps Diagnostic qualité et apurement des données de mobilité quotidienne issues de l’enquête mixte et longitudinale Mobi’Kids

–- vérifier leur qualité: cf. à Riate, travail sur OSM vs BPE

Ex. des prétraitements réalisés sur la base AirDNA

(..)

Travailler sur les distinctions de marchés, sur les types de locations, sur les propriétaires.

La base Airdna renseigne sur les locs AirBnb (ce n'est pas la seule) Elle renseigne aussi sur les performance des annonces. On voit le lien avec l'identification de différents marchés. Difficile d'avoir des infos sur les durées de séjour ou sur les nuitées correspondant à de longues durées de location. On a des données sensible avec un cout important.

Ici reproduvtion des traitements importantes, – pour éclairer la signification de cette base. – pour fournir des données sur des réservation effective parait compliquer. Airdna c'est 2 fichiers bruts :

  1. les annonces
  2. les performances mensuelles. Le travail du Riate résumer en Markdown, créer un document pour reproduire l'analyse sur les 3 communes et de diffuser ce doc pour partager l'expertise de la BD. Il est reproduit des éléments des pré-traitements des données. (base sur performance des logements est à part.)
  3. les annonces enrichies. est effectué une analyses sur les qualités et un nettoyage des données. (des problèmes d'incohérences, en taille, en prix et des prix fixe alors qu'on sait qu'ils varient, enfin imprécision spatiale car floutée à + ou - 100 m)

question sur l'accés aux données : ça s'achète, et c'est cher, pas de conventions possibles. On est ici sur des données privées d'entreprise. Autres enjeux, sur le markdown diffusable, question sur les données aggrégées ou randomisées ? wait & see

remarque : d'où l'importance de la donnée ouverte. MG : sur Airbnb de plus en plus de données scrapées. InsideAirbnb (mais que dans les centres-villes). remarque: les données de santé ne seront jamais ouverte (au chercheur péniblement mais c'est tout) remarque : les impots sur leur BD ont crée un pont pour retrouver les déclarations airbnb

Dernier point : méthodes de traitements et seuils et comment les choisir dans cette idée ?

Projet TRADEVE. ESPON puis Guérois, Bretagnolle. => BD internationale de morpho urbaine de plus de 10 000 Habitants, pour suivre leur trajectoire. D'ou l'intéret de créer une base pour les mesurer.

Un exemple qui renvoi à l'ensemble des exemples du cercles d'incertitudes.

Un enjeu de définition (concept de ville : aire fonctionnelles >50 000 , agglomération morphologique UMZ) des bases 'bottom up' souvent limitées car de chacuns des pays dépend. Définition agglo qui est suffisante.

Un enjeu d'harmonisation dans le temps du MAUP

MAUP : problème des unités spatiales modifiables (instabilité des résultats statistiques)

Quelle continuités dans le temps ? quelles limites fixe ? => 4 modèles théoriques.

Dans Tradev : limites évolutives : on part des limites actuelles et à partir d'un certain nombre de règles on rétropole

Référence travail de définition et d'harmonisation sur la délimitation de périmètres urbains, réalisé par Marion Maisonobe, laurent Jégou, Denis Eckert dans Revue M@ppemonde Les villes et la science: apports de la spatialisation des données bibliométriques mondiales

Délimitation automatisée des zones urbaines réalisée à l'époque avec PostGIS et récupération des résultats dans R.

Divers traitements pour harmoniser les périmètres urbains. L'ensemble de cette harmonisation de la BD, a fait l'objet d'un datapaper (périmètres et popoulation associée), mais le code n'a pas été diffusé. La BD a été déposée sur le dépôt Nakala.

Enjeux d'harmonisation des bases de données dans l'espace à l'échelle européenne

Questionnements sur :

  • les paramètres identiques choisis
  • le choix des seuils fixes, comment les faire évoluer? alternatives : s'orienter vers des seuils évolutifs, relatifs : procedure de détection de noyau de densité (mais, pas totalement automatisable)
  • le choix des simplifications : changement de la délimitation des aires urbaines en zone d'attrction, pour s'aligner sur les données de référence européenne, mais qui se fait au détriment d'un suivi dans le temps (exemple illustré par l'aire urbaine de Lyon).

Questions et ressources générales sur l'utilisation de R

Demander de l'aide ou du support

Stackoverflow

gis.stackexchange

Community Rstudio

stat.ethz

Journal

Documenter son travail en continu dans un Journal, exemple de orgmode utilisé par Arnaud L. compatible tous langages y compris R.

Utiliser des programmes et pkgs R anciens

shameless plug (@rgeomatic) : spectre reproductibilite

– sessionInfo(): permet de déclarer le système utilisé à la fin du prg ou du .rmd

– miniCRAN : permet de faire un snapshot du CRAN et de lancer des programmes et pkgs anciens (et non de se connecter sur le CRAN courant, actualisé).

– renv : package pour gérer les dépendances (et leurs versions) des packages dans les projets RStudio (pas les versions de R).

– Docker : installer un Docker qui va conteuriser (outils, traitements, construction d'images) et éviter de travailler en local. D'ou permet de contourner les pb de dépendance des logiciels, de faire des mises à jour en permanence.

Il faut configurer les images docker de manière très fine, très explicite, sinon on travaille par défaut sur les dernières versions des logiciels. Docker est initialement conçu pour le DevOps pas pour la recherche reproductible.

-> Bonne pratique : éviter au maximum les extensions de R (packages) alors que les fonctions de base de R permettent de faire beaucoup de choses et qu'un soin particulier est porté à la stabilité du code par la R Core Team.

On parle de reproductibilité (facile lorsque le traitementt peut être modélisé par une équation) et jusqu'à la réversibilité : on passe d'un état A à un état B et inversement. Plusieurs exemples de discussions et travaux sur le sujet général des Transformations cartographiques.

Question de la pérenité des outils et de la multiplicité des outils (lequel choisir ?). La question des outils perturbe la reprodutibilité globale (ce qui n'est pas le cas du corpus méthodologique).

Question aussi de l'archivage des programmes anciens (cf. travaux de Openshaw, de Tobler etc.), mais qui nécessite le maintien de compétences.

Question aussi de la reproductibilité opérationnelle : des ressources humaines et de la permanence des gens sur des postes qui permet de conserver la mémoire sur le fonctionnement des outils.

xkcd

Binder permet de faire… "Turn a Git repo into a collection of interactive notebooks"
Binder permet aussi de plonger depuis un Docker dans un environnement R/Rstudio distant pour aller rejouer du code, kniter un .rmd associé à un article. Possible pour des projets avec des datasets pas trop lourds. À ce sujet, regarder l'article exécutable de Carl Boetinger évoqué très rapidement par Robin et Jakub en page 16 de leur premier exposé. Ça utilise binder et à permet de reproduire complètement son article avec son Rstudio mais directement dans son navigateur! :smiley: Click the Binder button above to explore in an interactive RStudio session.

API: interface de programmation d'application. Permet d'interagir avec un systeme info, par exemple obtenir une donnée. Dans le monde d'OSM: overpass API

Le pipe R : %>%

Le %>% est un sucre syntaxique fournit par {magrittr} pour rendre le code plus joli (éviter des codes trop longs), ne change pas le fond du programme.

Proposé aujourd'hui par R base, le %>% est remplacé par celui-ci : |>

Dans Rstudio pour faire %>% Ctrl+Maj+m en raccourci clavier

Retrouver le dépôt Github associé à un html

Lien vers le Rmd en html : https://sigr2021.github.io/gwr/

Lien équivalent vers le dépôt Github : https://github.com/sigr2021/GWR

Projet Rzine

Hughes présente le projet développé au sein de FR CIST. Partage de docs sur R dans les SHS et promouvoir la programmation lettrée et l'utilisation des logiciels de versionnement décentralisé

2 axes :

  • dépôt de ressources (actuellement déjà plus de 300 !)
  • dépôt de Fiches Rzine (.rmd avec comité de lecture)

Ressources

– développement d'un plateforme collaborative Projet Rzine qui référence près de 300 ressources

– Actualités de la communauté de R en SHS

– Projets en lien avec la pratique de R en SHS

– Référence aussi les auteurs qui produisent des doc, des prgs

Tous ces contenus sont ouverts et tout le monde peut proposer l'ajout de contenus sur le site.

Rzine est produit avec R {Blockdown} utilisant le site statique Hugo (donc sans BDD derriere). Chaque ressource se formalise par un .rmd qui contient les métadonnées de l'information à rajouter. code et fichiers sont stockés sur le Gitlab de Humanum. On peut proposer une pull-request pour actualiser 3 maintainers (Timothée G., Hugues P. et Sébastien R.)

Rzine.fr appartient au CNRS. Le site est distribué par une université publique, construction collective souhaitée.

Publications - Fiche Rzine

Soumises à comité de lecture, avec DOI. Un seul format = une Fiche = un rmd. en sortie .html didactique présentant un certain type de données, et un exemple complètement reproductible. Plutôt en français (anglais accepté). En cours de mise en place. Seuls trois exemples (non formalisés) sont actuellement disponibles

Relectures / revieuw sont prévues sur git, avec une totale transparence sur la review entre auteurs et relecteurs.

Et il y a même des stickers !

Jeudi 1 juillet

Thierry Feuillet : Atelier analyse spatiale (GWR)

Geographical weight regression (GWR)/Régression géographique pondérée

Dépendance spatiale : corrélation spatiale, cad le fait que les choses qui sont proches interagissent davantage entre elles qu'avec celles qui sont éloignées.

Indépendance spatiale : les choses et leurs relations entre elles varient dans l'espace (moyennes, variances, cov)

La non stationnarité spatiale (ou hétérogénéïté spatiale de la relation statstique) est cette variation de ces paramètres dans l'espace

Cette non stationnarité est vérifiable dans différents domaines : dans le domaine de lasanté, en connue (lien entre prix de vente de l'immobilier et la surface des logements).

Ne pas considérer cette hétérogénéïté spatiale conduit à des erreurs d'interprétations importantes. Une des méthodes proposée par l'analyse spatiale pour étudier cette hétérogénéïté est la Geographical weight regression (GWR).

EXOS : 4 étapes Voir https://sigr2021.github.io/gwr/

Etape 1. Modélisation

Privilégier un modèle log-log (plutôt que log-lin ou lin-log) car les paramètres sont plus faciles à interpréter : on regarde l'effet de l'aug du % en X sur l'effet de l'aug du % en Y

Modèle de regression linéaire log-log : est un modèle global (MCO), avec moyenne, sur tout l'espace -> MCO, fonction lm (data quanti continu) sinon fonction glm (quali)

Détails

  • faire un summary(mco) des estimation pour résumer

  • (toujours) vérifier l'indépendance des variables explicatives avec un vif, mais ici, passant par {car}

library(car)
vif(mco)

Interprétation des résultats bruts du modèle

Beta : coeff de regression qui caractérise la relation entre Y à expliquer et les variables explicatives. Si negatif, la relation - interprétée en % - est négative.

95% : intervalle de confiance de l'estimation. Si pas de zéro, alors les relations sont significatives et ici, elles le sont à un niveau élevé

intercept : valeur "moyenne" de Y lorsque toutes les variables sont égales à zéro. Si on standardise (ce qui est mieux), alors on interprète les val. moyennes de Y AINSI QUE les moyennes des différentes X Cf. Y=aX+b

Etape 2. analyse des résidus

Observer la distribution des résidus pour savoir si le modèle est bon ou non : on entre à ce stade dans "l'analyse spatiale" pour savoir si le modèle #surestime ou sous-estime les prix.

Etape 3. Modèle GWR

Permet de passer au niveau local en estimant un coefficient par maison, sur la base des maisons voisines et non un coeff. global, sur l'ensemble de la zone d'étude.

{GWmodel} qu'on utilise ici n'est pas compatible avec sf, donc on sort de {sf} pour retourner sur {sp} - supprime donc la geom associée.

Construire une matrice de distances Distance continue en mètres cf. exemple donné. Matrices de proximité binaire (1,0) ou ordinale (1,2,3,…k) cf. nombre de limites de zone sà franchir pour aller d'un point A à B fonctionnent aussi.

Comparaison de deux fonctions de pondérations spatiales : exponentielle et racine carrée

2 paramètres fondamentaux à calibrer

  • bw : définit la fenêtre de voisinage
  • adaptive : définit le paradigme continu (ex. distance kilométrique) ou discret (ex. voisinage, plus proche voisin). Donc si adaptive=TRUE, on est dans le voisinage et il faut définir le bw en termes de nombre de voisins (ex=10)

on teste deux pondérations ici car on cherche à minimiser l'AICC, cad à optimiser le voisinage, en fonction du type de fonction

  • nNeigh.exp : pour estimer le nombre maximal de voisins

(1) Exponential

  nNeigh.exp <- bw.gwr(data = dataSp, approach = "AICc",
                       kernel = "exponential", #fonction exponentielle
                       adaptive = TRUE, #voisinage
                       dMat = matDist, #a pu être calculée ailleurs (ex. CKij)
                       formula = log_valeur_fonciere ~ log_dist_litt + log_surface_reelle_bati + log_surface_terrain)

(2) Bisquare

nNeigh.bisq <- bw.gwr(data = dataSp, approach = "AICc", 
                      kernel = "bisquare", 
                      adaptive = TRUE, 
                      dMat = matDist, 
                      formula = log_valeur_fonciere ~ log_dist_litt + log_surface_reelle_bati + log_surface_terrain)

Etape 3 - Etape de cartographie

Thierry F. a créé une fonction de cartographie pour geoviz les résultats

Fonction mapGWR

mapGWR <- function(spdf,var,var_TV,legend.title = "betas GWR",main.title, dot.size = 0.3) {
    tv <- spdf[abs(var_TV)>1.96,]
  tm_shape(spdf) +
    tm_dots(var, title = legend.title, size = dot.size) +
    tm_shape(oleron) + tm_lines() +
    tm_shape(tv) + tm_dots(col="grey40") +
    tm_layout(title = main.title, legend.title.size =0.9, inner.margins = .15) 
}

avec:

  • t value :coeff. de regression divisé par l'écart-type

Objectif : on veut cartographier à la fois les coeff et les tv associées, pour un seuil alpha donné, typique 5% (cf. t. de Student)

On réalise enfin une planche contenant les X cartes associées aux 3 variables explicatives.

Les valeurs de la légende sont en log, donc difficilement lisibles / interprétables : ne pas oublier de les transformer (exp) pour que la carte puisse être lisible et facilement commentée.

On applique la même fonction aux 3 planches et on plot le tout avec tmap (mode plot)

tmap_mode("plot")
a <- mapGWR(GWR.exp$SDF, var = "log_dist_litt",var_TV = GWR.exp$SDF$log_dist_litt_TV,
            main.title = "Distance au littoral")
b <- mapGWR(GWR.exp$SDF, var = "log_surface_reelle_bati",var_TV = GWR.exp$SDF$log_surface_reelle_bati_TV,
            main.title = "Surface bâtie")
c <- mapGWR(GWR.exp$SDF, var = "log_surface_terrain",var_TV = GWR.exp$SDF$log_surface_terrain_TV,
            main.title = "Surface terrain")

tmap_arrange(a,b,c)

Interprétation des cartes

On regarde les points situés au centre, pour chacune des X : pour surface bâtie, c'est positif partout, donc c'est signif' partout, alors que pour la surface terrain, il existe des zones homogènes, mais aussi des zones non signif, au nord ; pour distance au littoral : peu signif' à certains endroits etc.

Etape 4. Régionalisation

Régionalisation : recherche de zones homogènes (cf. Marianne G.) avec une contrainte spatiale de proximité. Conduit à une partition du territoire.

On utilise les valeurs des GWR pour réaliser cette typologie, en faisant l'hypo. qu'il existe des sous-marchés immobiliers (cf. Renaud l. G.)

On applique la méthode SKATER (cf. doc de l'INSEE).. jusqu'aux résidus.

*Pour la visualisation et l'interprétation *:

– cartographier les clusters de points, en trois planches (idem précédent)

– ET représenter les écarts aux profils moyens pour les trois paramètres.

retirer la fonction add_vif et le pipe qui le précéde dans le chunck Modèle log-log global (MCO)

La Gwr c'est faire une régression linéaire par individu

On retransforme notre objet sf en sp puis on crée notre matrice de distance. Une fois qu'on a la matrice il faut calibrer l'espace du voisinage.

Estimation de la gwr : on calibre: bw on définitit la distance et adaptive (true = nb voisin, false = distance) on utilise nb voisin car les maisons réparties de manière hétérogènes, le risque il peut ne pas y avoir assez d'individus dans le voisinage local, ici on s'assure qu'il y a assez de voisins plutot que distance ou risque de pas en avoir ou très éloignée

on va essayer 2 types de de comparaison = minimiser l'AIC avec 2 types de comparaison une fonction gaussienne ou expo et une fonction bicarrée ou boxcar.

question : peut on prendre un maillage et construire une matrice ordinale, par exemple, en dénombrant le nombre de limites de zones à franchir ? -> Oui (matrices binaires et ordinales fonctionnent aussi) => il faut préparer ces matrices de distance jointure avant.

T Value est l'inverse proportionnel à la P value Si t Value très basse permet de voir ou il faut faire attention aux coefficients. le seuil est de 1,96

Malika Madelin : Analyse d'images Raster et télédetection

presentation de diverses sources d'images SENTINEL, SRTM, NDVI, MNE,LANDSAT, Corine Land Cover etc.

JRC Pop2018 : maille pour la population VIIRS Image de luminosité nocturne ?

Données satellitaires : on définit des résolutions spatiales, spectrales et temporelles un meme satellite peut avoir plusieurs capteurs, comme Landsat.

Lors d'un export d'images, il est important de connaitre le datatype pour gérer le poids des images.

Une image sentinelle = 1GB

Production massive et quotidienne de données

Les produits sont forunies à différents niveaux de traitements (brutes, corrections atmosphèriques, reliefs).

Données souvent accessible via des plateformes (Earth Explorer, Sentinel Hub, GEE). Certaines permettent de faire du calcul sur leurs plateformes.

Copernicus Research and User Support (RUS) : https://rus-copernicus.eu/portal/

On peut aussi choisir la compression en plus du type de données pour economiser du volume.

Formats d'image qui permettent d'avoir des images moins lourds (rapport de 1 à 3 entre ASCII et geopkg)

Sous R 3 packages "phares"

  • {raster} : le plus ancien. Possible de faire de la parallélisation.
  • {stars] : dimension multiscalaire ET multi-dimentionnelle (datacubes) pour gérer des données types NetCDF. Fonctionne aussi pour données vecteur. Permet de gérer des rasters lourds
  • {terra] : plus perfomant que {raster}

Lire les fichiers raster dans R :

  • Avec le package raster :
    • type image : Rasterlayer : l'image n'est pas chargée en mémoire dans R, ne pas hésiter à enregistrer le fichier temporaire (par exemple, en Tiff) et le recharger ensuite.
  • Avec le package terra : il donne plus d'infos sur l'image et chargemnt bcp moins lourd
  • Avec le package star :
    • stars object

type de données dans terra: https://rspatial.github.io/terra/reference/writeRaster.html

Centre canadien de Teledétection pour s'initier à la teledection.

Opérations réalisables

Methodes de reprojection : bien choisir entre la méthode : plus proche voisin ou bilinéaire qui entraîne une modification des valeurs (par exemple, par un moyennage avec les pixels voisins), et donc à utiliser en adéquation avec le type de données (donc pas pour des catégorielles).

st_transform

Découpages : crop & mask

Le crop découpe l'image

Le mask conserve l'étendue de l'image initiale

Agrégation / désagrégation

Possibles selon fonctions moyennes, max. etc.

Les gens utilisent cette proc d'agrégation en changeant la résolution pour voir ce que cela donne visuellement de comparer un produit sur 30m et sur 300 mètres. Pas très convaincue par cette méthode.

Fusion / merge et mosaïque

merge créé un raster, alors que mosaïque créée un objet virtuel

Opérations :

3 types d'opérations sont possibles : locales, focales et zonales, correspondent à un schéma de pensée.

Opérations locales : on regarde pixel à pixel

Reclassifications

Création de masques raster (1/0) : de la lecture des valeurs spectrales à une typologie binaire (avec une classe à zéro où on pourra enlever les valeurs)

Gestion des NA -_9999

Calcul matriciel / calculatrice raster

On peut aussi calculer des NDVI

:warning: mise en garde valeur en fonction du min et max et pas en fonction du signal donc le NDVI ne sera pas normalisé mais dépendant de sa couche d'entrée. Lire alors attentivemnt la métadonnée associée.

avec Terra terra::calc de la doc pour définir le calculateur matriciel le plus rapide.

on peut aussi comparer 2 raster, voir des corrélations usw…

opérations focales

on regarde plus uniquement le pixel mais ce qui se passe autour

filtres

opérations zonales ou globales

Au niveau du raster entier ou d'une sous-zone, par ex. surface occupée par chacune des classes.

avec class(r_zoom)

Calcul de statistiques locales

possibilités de caler les données gps.

Traitement des images satellites

Objectifs :

  • amélioration pour aider à l'interprétation (jouer sur seuillages, compo. colorée etc.)

  • traitements physiques (températures de surface à caluler en fonction des contextes)

  • réalisation de zonages: élément central, réalisation de classifications, typologies du territoire.

(1) Approche dite par pixel: on regarde les pixels en tant que tel (valeurs radiométriques ex. ACP sur les valeurs de surfaces réalisées sur un ensemble de canaux des valeurs sentinel) + classifications types CAH (on coupe le dendro etc.), segmentations.

On utilise de plus en plus les k-means mais on va définir d'office le nombre de classes en amont

(2) Approche focale : on regarde le pixel par rapport à ses voisins : détection de contours, etc.

(3) Approches O-O : on définit des zones qui correspondent à des classifications supervisées (on connait le terrain car on a déjà une photo interpréation de son image… et on veut rechercher les secteurs aux valeurs qui sont proches de ce que l'on connaît : cf. permet de définir des "local climate zone" dans des villes) Mais cela pose d'autres questions, car a été développé pour des villes europénnes donc effets de contexte. Quelques tetatives dans quelques villes du sud.

Classif. non supervisées (réalisées avant d'aller sur terrains)

(4) Cartographie et visualisation Pas génial dans R au niveau des couleurs

{raster} avec plot()

{stars} gère bien les rasters lourds car il y a un tuilage en amont

{sp} avec spplot()

{rasterVis} avec levelplot() intéressant car fournit l'hist. par défaut. Gère bien les vignettes, pratique pour données temporelles

{leaflet} en mode vectoriel est adoré, mais très moyen en raster car gère mal les projections

{tmap} avec tm_raster()

{rayshader}

{mapview}

Netatmo : surveillance de nounou et temperature

Timothée G. : mapsf

Cerise sur le gateau, Timothée fait une présentation en 15 minutes chrono (enfin 17') de {mapsf} permettant de faire de la cartographie thématique ou cartostats… et comparaison avec {cartography}

Contexte de développement

existe un historique des dév. depuis son 1er package {rCarto} retiré depuis du CRAN.

2013 : {rCarto}

2015 :{cartography} dev. avec Nicolas L. pour pouvoir faire des cartes avec R.

Avaient fait une série de choix sur le choix des fct, les différentes arguments, l'ordre des arguments, la manière d'écrire les funcions. s'appuyait sur {sp}, {rgdal} et {rgeos}. Mais le passage à {sf} a bcp compliqué les choses.

2017 : maj de {cartography} avec {sf}

2020 : ré-écriture complète pendant le 1er confinement, plus simple, plus léger et puls ergonomique. Résultat = {mapsf}

mf_map() : fonction principale composée de 3 arguments

– x : prend un objet {sf} en entrée

– var : variable à représenter

– type : type de carte à réaliser (choro, cercles prop. etc)

Voir le README de mapsf , ou sa vignette pour les types de caractères points, lignes, polygones.

Nouvelles fonctionnalités** par rapport à {cartography}

(sélection)

Habillage : gestion améliorée des élements de cosmétisation mf_title() mf_arrow() etc.

Export (en .png ou en svg): on exporte la carte avec un ratio hauteur/largeur qui correspond par défaut à la Bbox de départ.

Inset (cartouches)

mf_inset_on() permet de faire l'inset et de définir le ratio (la taille en % inset / carte principale).

On peut également mettre une carte dans un inset

Aussi un hist. dans un inset

Situation/localisation monde

mf_worldmap() place automatiquement un point à l'endroit de la zone d'étude sur une petite carte du monde.

Thème

Le thème est davantage paramétrable

– couple de couleurs (fond de la planche, fond du titre)

– position du titre, dedans / hors de la carte

– marges de la figure : gestion facilitée

on peut utliser un thème défini, modifier un thème existant ou en créér un à partir de rien.

Associés au package** :

  • un site web réalisé avec {packagedown} riatelab - mapsf
  • Documentation - CRAN compacte et succinte avec peu d'arguments par choix arguments dans mf_map() tous les arguments pas utiles pour chaque type de cartes.

Schéma des types de cartes proposées:

  • Voir aussi le Carnet Hypothèses rgeomatic de Timothée (in english)
  • Plus généralement : Riatelab

Lizmap permet d'heberger des projets QGIS et publier. Ex chez EVS : https://websig.univ-st-etienne.fr/renaud/

Vendredi 2 juillet

Dans le dev de package R il est plus sage de sauver les exemples dans des fichiers plutot que des objets R. Les fichier sont plus stables, les packages évoluent.

plot() va diminuer la resolution des images raster pour l'afficher. il y a une limite dans le nombre max de cell (cf doc de plot).

Defaut dans le tmap max 10 M de cells.

Pour la reclassification il faut fournir une matrice de reclassification.

terra::lapp -> apply that on layer, proche de lapply for raster

terra est en c++: dans zonal si on veut utiliser la fonction c++ dans zonal on utilise "mean" si on veut une fonction de R on met la fonction sans "" ex: mean.

Deux sites de la communautée :

Les deux ont leurs dépots Github.

Pour réechantillonner un raster on va créer un template (vide). Il faut aussi speifier la methode en fonction du type de donnée (continue, categorique). Par defaut resample prend "bilinear". On peut changer l'argument dans la fonction (ex: method = "near".)

Pour créer ses propres projections : https://projectionwizard.org/

On peut spécifier ce que l'on veut garder "Equal-area", "Equidistant" ou "compromise" entre les deux autres.

crop resert la bbox autour du vecteur.

mask remplace les valeurs au dela du vecteur par NA.

Un workflow peut être:

crop
mask

première étape permet de limiter la taille puis de mettre les valeurs en dehors en "NA".

terra::extract permet de sortir les valeurs en fonction d'un vecteur. La différence avec des stats zonales est que l'on retrouve toutes les valeurs et pas un agrégat.

https://geocompr.github.io/

conversion entre format : https://geocompr.github.io/post/2021/spatial-classes-conversion/

points clouds :https://jean-romain.github.io/lidRbook/index.html

Last changed by 
 
sigr2021
SIGR 2021
0
1
1450
Published on HackMD