CDEM's de toute la France à résolution horizontale de 5 mètres (RGEALTI IGN)

Commentaires

56 commentaires

  • Avatar
    Bernard Perrot

    Bonjour,
    Je tâcherai de te répondre demain, en ce moment, je n'ai que mon téléphone.
    A suivre,
    Cordialement

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Juste une remarque préalable au cas où : il faut bien avoir à l'esprit que les fichiers manipulés sont à surface égale, 25x plus gros avec la résolution de 1m.
    Il ne faut donc pas avoir pour ambition de créer des MNT couvrant un grand territoire.

    Savoir aussi, que en attendant les données LiDAR, le RGE à 1m n'apporte pas très souvent de précision effective meilleure que celui à 5m (ce sont souvent des interpolations du RGE 5m, et la précisions des mesures souvent bien supérieures à 1m).

    Cdlt,

    0
    Actions pour les commentaires Permalien
  • Avatar
    Samuel Wieczorek

    Pas de souci pour la taille des fichiers. L'objectif est de faire des MNT par "petit massif" montagneux pour affiner le calcul des dénivelés pour mes traces GPX.

    Faire ce boulot sur les données RGE à 1m me permettra déjà de me faire la main sur la procédure que je pourrai reproduire ensuite sur les données LIDAR.

    Merci pour votre aide

    0
    Actions pour les commentaires Permalien
  • Avatar
    Thierry CHARLÈS

    Bonjour,

    L'argument qui de mon point de vue ne plaide pas en faveur du cdem a 1 m est le suivant :

    La précision actuelle du GPS lorsque les conditions de réception sont les plus favorables c'est de l'ordre de 4 m 95 fix sur 100. Des que la qualité de réception se dégrade, la précision de dégrade aussi. Concrètement en situation favorable 95 fix sur 100 sont entre 0 et 4 m. Concrètement sur un CDEM ayant une résolution de 1m la probabilité que la position de la trace soit dans le bonne maille est très faible.

    L'effet positif attendu ne sera pas au rendez vous.

    Cdlt

    0
    Actions pour les commentaires Permalien
  • Avatar
    Samuel Wieczorek

    Je vais préciser mon utilisation et mon besoin. Je n'utilise les MNT que sur Land pour préparer mes itinéraires VTT. J'ai déjà remarqué de bonnes différences entre un MNT ajouté et le calcul des altitudes avec les cartes fournies par défaut de Land et je ne voudrais pas me faire avoir 2 fois :)

    Donc, utilisation uniquement sur Land. Ensuite, sur le GPS, j'utilise la carte par défaut, ça me va bien.

    PS : et il y a peut-être un peu de déformation professionnelle :D Je suis informaticien et j'aime bien comprendre comment ça fonctionne

    0
    Actions pour les commentaires Permalien
  • Avatar
    Thierry CHARLÈS

    Bonjour,

    Sur le principe Land ou le GPS ça ne change rien, pourquoi ?

    Il faudrait qu'avec Land ou l'outil qui est utilisé pour tracer l'itinéraire que la précision de location des points soit meilleure que 1m (je reste sur le principe, après si ont développe mathématiquement le problème....) Or vu la précision des cartes IGN ou OSM Je doute qu'il soit concevable de poser les points avec une telle précision.

    Cdlt

    0
    Actions pour les commentaires Permalien
  • Avatar
    Samuel Wieczorek

    Bonjour,

    pour préparer un itinéraire, j'utilise 2 cartes :

    • une carte "routable" (OSM par exemple car les cartes topographiques de l'IGN ne le sont pas) pour tracer mon parcours. La précision du tracé des cartes proposées est largement suffisante, ce n'est pas là que j'essaie d'améliorer les choses.
    • un Modèle Numérique de Terrain que j'ouvre en même temps que la carte précédente, dans Land. Cette carte est utilisée, en lieu et place du modèle d'altitude fourni par défaut dans Land, pour calculer le dénivelé de mon parcours avec une option de Land qui permet de recalculer les altitudes des points du tracé.

    Avec cette méthode, j'ai une idée plus fine du dénivelé sur ordinateur et qui se rapproche effectivement assez bien de ce que j'enregistre sur le terrain.

    Ce que je recherche du coup, c'est un MNT assez précis. D'où l'idée d'essayer celui à 1M diffusé par l'IGN

    0
    Actions pour les commentaires Permalien
  • Avatar
    Thierry CHARLÈS

    J'ai bien compris, mais si tu imagines que les chemins, singles, routes et autres sont placés dans OSM au mètre près la tu te trompes. Ils sont a l'heure actuelle soit issu de la BD européenne appelles Corinne (donc pour la France c'était L'IGN d'avant 2010) ou c'est corrige par des contributeurs a partir de photos aériennes ou issues de traces GPS. Depuis peu l'image aériennes c'est l'ortho IGN 2021, le trait d'une route par exemple est rarement sur la ligne blanche qui sépare les voies. En gros une route c'est 10 m de large, ce qui permet de se faire une idée de la précision. Si la trace qui a servi à placer un DFCI ou un single est issue d'un GPS la précision du GPS a son importance. Toutes ces constatations, font que bien que ça soit précis ont n'est pas dans la gamme du mètre. (Je suis contributeur et je passe du temps a corrigé quand c'est possible, mais placé une trace (un single) en sous bois ou dans le relief tant que la trace au sol de ce single n'est pas visible sur la photo aérienne est utopique. ... Dans une décennie peut être..
    Imagine une route de 10 m de large c'est 10 dalles de relief de 1m en largeur, sur les points ou ce trait de route est a côté de la route sur la photo aérienne l'altitude sera fausse (en faisant l'hypothèse que les dalles ont une résolution métrique dans les relèves, ce qui n'aura lieu qu'après 2025. Ton idée est bonne dans l'hypothèse où les relevés du relief sont métriques. (après 2025) et si les "highway" OSM sont précis a mètre près, et ça ça implique qu'un contributeur se retrousse les manches...
    Cdlt

    0
    Actions pour les commentaires Permalien
  • Avatar
    Samuel Wieczorek

    ok, ok, je saisis le problème, en effet... :D

     

    Merci pour ces informations

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Bonjour,

    Bon, on va dire que Samuel fait ce qu'il veut, voici quelques détails sur le flux de travail que j'ai utilisé :

    Pour répondre à votre question, et comme vous êtes informaticien (moi aussi...), je vais tâcher de parler la même langue :

    1) récupérer les MNT de l'IGN, pour mon cas, le RGEALTI à 5m. Cela donne une collection de fichiers .ASC (format texte, pas le plus compact possible...).  Les fichiers sont géoréférencés en Lambert-93 (RGF93/EPSG:2154) pour la France métropolitaine (on va les laisser comme cela dans un premier temps).
    A savoir que le nommage représente les coordonnées du coin nord-ouest de la dalle, abscisse/ordonnée en kilomètres : cela va faciliter l'assemblage puisque le nom permet de savoir quelles sont les dalles jointives.
    Chaque fichier représente une dalle de 5km X 5km.

    2) Land permet d'ouvrir et d'assembler les fichiers .ASC, mais le processus est pénible avec de (trop) nombreux fichiers source, et il y a très souvent des problèmes à la jointure des dalles (caractérisé par une ligne d'un pixel de large à altitude zéro, soit un trait bleu si on visualise le DEM sous Land). Il est donc pratique de commencer par assembler les dalles initiales pour en contruire des plus grandes, qui elles mêmes permettront ensuite de faire des cartes par régions par assemblage de ces dalles intermédiaires (100km X 100 km dans mon cas, soit au plus 400 dalles .ASC initiales).
    J'ai également besoin de fichiers indépendant du format CDEM de TwoNav pour d'autres applications.
    Pour tout cela, j'utilise le logiciel QGIS.

    3) toute la France à 5m, cela représente environ 22300 fichiers ! Sélectionner à la main successivement des zones de 400 dalles... ça prendrait des jours, donc, pour faciliter le travail, j'ai regroupé les zones de 100km2 en collections dans des sous-répertoires à l'aide de petits scripts en bash : un premier pour regrouper par latitudes, puis un second pour classer par dalles.

    Le premier, dans ce genre (avec une génération semi-automatique de ce script) :

    #!/bin/bash
    #
    # moove.sh (regroupement des .ASC par latitudes)
    #

    d="04"

    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_61*.asc ASC-lat61/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_62*.asc ASC-lat62/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_63*.asc ASC-lat63/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_64*.asc ASC-lat64/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_65*.asc ASC-lat65/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_66*.asc ASC-lat66/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_67*.asc ASC-lat67/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_68*.asc ASC-lat68/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_69*.asc ASC-lat69/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_70*.asc ASC-lat70/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_71*.asc ASC-lat71/

    d="05"

    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_61*.asc ASC-lat61/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_62*.asc ASC-lat62/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_63*.asc ASC-lat63/
    mv -f ASC-France/RGEALTI_2-0_5M_ASC_LAMB93-IGN69_D${d}*/RGEALTI/1_DON*/RGEALTI*/*_64*.asc ASC-lat64/
    etc...

    Le second :

    #!/bin/bash
    #
    # sort.sh (regroupement par dalles de 100km2)
    #

    for lon1 in "01" "02" "03" "04" "05" "06" "07" "08" "09" "10"
    do
      for lat1 in "61" "62" "63" "64" "65" "66" "67" "68" "69" "70" "71"
      do
        echo "FR_${lon1}00_${lat1}00"
        mkdir "FR_${lon1}00_${lat1}00"
        for lon2 in "00" "05" "10" "15" "20" "25" "30" "35" "40" "45" "50" "55" "60" "65" "70" "75" "80" "85" "90" "95"
        do
          for lat2 in "00" "05" "10" "15" "20" "25" "30" "35" "40" "45" "50" "55" "60" "65" "70" "75" "80" "85" "90" "95"
          do
            if [ -f "ASC-lat${lat1}/RGEALTI_FXX_${lon1}${lon2}_${lat1}${lat2}_MNT_LAMB93_IGN69.asc" ]
            then
              echo ASC-lat${lat1}/RGEALTI_FXX_${lon1}${lon2}_${lat1}${lat2}_MNT_LAMB93_IGN69.asc
              mv ASC-lat${lat1}/RGEALTI_FXX_${lon1}${lon2}_${lat1}${lat2}_MNT_LAMB93_IGN69.asc FR_${lon1}00_${lat1}00/
            fi
          done 
        done
      done
    done
    echo "Fini..."
    exit

    4) Ensuite, il faut faire la compilation des dalles au format GeoTIFF, effectuée aussi avec un script de ce genre :

    #!/bin/bash
    #
    # mktiff.sh (construction des dalles 100km2)
    #

    for lon1 in "01" "02" "03" "04" "05" "06" "07" "08" "09" "10"
    # for lon1 in "10"
    do
      for lat1 in "61" "62" "63" "64" "65" "66" "67" "68" "69" "70" "71"
    #  for lat1 in "69"  
      do
        frdir="FR_${lon1}00_${lat1}00"
        echo $frdir
        if [ -d "${frdir}" ] 
        then
          ls -d "${PWD}/${frdir}"/* > Temp/asclist.txt
          /Applications/QGIS.app/Contents/MacOS/bin/gdal_merge.py -v -a_nodata -10 -ot Float32 -of GTiff -o ./TIFFs/${frdir}.tif --optfile ./Temp/asclist.txt
        fi
      done
    done
    echo "Fini..."
    exit

     

    Ce script utilise la commande ligne "gdal_merge.py" qui est un des (nombreux) outils en mode ligne inclu dans la distribution de QGIS. Attention que le path "/Applications/QGIS.app/Contents/MacOS" est dépendant du système, à adapter selon que ce soit un Windows, un macOS ou un Linux (macOS ici).

    Selon la puissance de l'ordinateur, cette phase automatisée peut être très (très) longue, laisser faire le temps qu'il faut...

    Après cela, on obtient nos fichiers MNT de 100km2, qu'on peut assembler sous QGIS : Layer -> Add Layer -> Add Raster Layer autant que nécessaire, puis Raster -> Miscellaneous -> Merge. Puis, une fois fusionnés (attention à bien configurer la projection (CRS) à EPSG:2154), exporter en BILL/HDR (Clic droit sur la couche, Export -> Save As, avec Format ERSI HDR Labelled).

    Une fois là, Land sait ouvrir le .HDR (qui est accompagné d'un .PRJ et .BIL), qu'il ne reste plus qu'à convertir en CDEM avec Land.

    Est-ce que cela répond à votre question ?

    Cordialement,

     

    PS : comme je l'ai déjà dit plus haut, pour les GeoTIFF à 5m de 100km2, je peux les fournir, mais je n'ai pas l'espace de stockage en ligne suffisant pour toute la France, me demander.   

    0
    Actions pour les commentaires Permalien
  • Avatar
    Samuel Wieczorek

    Un grand merci Bernard pour ce mode opératoire. Je vais quand même l'essayer pour voir ce que ça donne !

    C'est parfait comme explications. Ca me permettra de voir les différences de dénivelé calculé sur du 1M et 5M versus la réalité terrain.

    Que ça soit concluant ou non, ça aura au moins le mérite de me faire progresser dans ce domaine avec ce type de données.

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    PS2 : Ah oui, j'ai oublié un truc important...

    Les MNT de l'IGN ont des trous, cela veut dire que dans le REGALTI à 5m, il manque certaines dalles de base.

    Pour boucher, prendre un MNT de résolution inférieure (j'ai pris la BDALTI à 25m), et utiliser l'outil intégré à QGIS qui est dans l'arborescence "SAGA", outil "Patching". Le principe de celui-ci est de remplir les zones vides de la couche supérieure avec les données de la couche inférieure avec interpolation si les résolutions sont différentes.

    Il est important dans QGIS à faire en sorte de bien programmer ces trous en "nodata" (on affecte une valeur à ce qui est "nodata", souvent -9999, ou -99999 selon le type des données.

    Cdlt,

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    "Je vais quand même l'essayer pour voir ce que ça donne !"

    N'hésite pas à me demander s'il manque quelque chose pour comprendre et refaire, j'ai forcément oublié quelque chose ... !

    Cdlt,

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    PS3 : un autre détail...

    Dans le script ci-dessus, j'ai mis les "nodata" à -10.
    Dans la pratique, cela correspond aux zones marines sur l'estran des côtes.
    J'ai fait comme cela, parce que Land ne semble pas gérer correctement les nodata habituels, et on se retrouve alors avec des "falaises" monstrueuses.
    -10m permet de rester à une profondeur raisonnable sur la côte, tout en conservant la cohérence avec les altitude négatives (quelques mètres) du MNT IGN.

    NB: ces altitudes négatives du MNT sur l'estran sont des altitudes terrestres, pas marines (qui sont différentes) !

    0
    Actions pour les commentaires Permalien
  • Avatar
    Samuel Wieczorek

    Bonjour Bernard,

     

    je suis en train de mettre en place des scripts pour automatiser le processus, comme tu l'avais fait. Quelques adaptations ont été nécessaires car la nomenclature des fichiers *.asc a changé.

    Je reprends ta méthode en faisant des groupes de 400 dalles mais prises dans l'ordre où elles apparaissent dans le répertoire d(origine.

     

    Je me posais une question : la partie assemblage des Tiffs ne peut-elle pas être automatisée avec une commande de QGIS ? 

    " Après cela, on obtient nos fichiers MNT de 100km2, qu'on peut assembler sous QGIS : Layer -> Add Layer -> Add Raster Layer autant que nécessaire, puis Raster -> Miscellaneous -> Merge. Puis, une fois fusionnés (attention à bien configurer la projection (CRS) à EPSG:2154), exporter en BILL/HDR (Clic droit sur la couche, Export -> Save As, avec Format ERSI HDR Labelled)."

     

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Bonsoir,

    "Je me posais une question : la partie assemblage des Tiffs ne peut-elle pas être automatisée avec une commande de QGIS ? "

    Comme tu es informaticien, je commencerai par répondre : oui bien sûr, tout est faisable avec un ordinateur !

    Plus en détail : oui, c'est faisable. Mais je ne l'ai pas fait pour diverses raisons.

    D'abord, comme je le dis ci-dessus, il faut de toute façon commencer par vérifier les TIFF générés visuellement pour voir s'il n'y a pas des trous.

    Ensuite, à partir de ces "meta-dalles" de 100km2, j'ai fabriqué des MNT pour des "régions d'intérêt", mais elles même n'étant pas à des frontières d'assemblage de ces méta-dalle. Donc, après avoir fusionné plusieurs méta-dalles, j'ai aussi croppé le résultat pour délimiter la région que je voulais exactement générer.

    Et comme c'est visible sur les messages du début de ce fil, tu vois que mes régions ne sont pas parfaitement jointives, mais comportent des zones de recouvrement. Ça, c'est plus intuitif pour le mettre où il faut que facile à automatiser.

    Et puis, cette partie du travail ne représente que peu de MNT, pas un gros intérêt à l'automatiser, et puis aussi, il est bien de voir à l'écran le résultat avant export.

    Cordialement,

    0
    Actions pour les commentaires Permalien
  • Avatar
    Samuel Wieczorek

    J'ai encore une autre question, concernant le remplissage des dalles manquantes.

     je n'ai pas bien compris à quel niveau tu rajoutes les dalles de résolution inférieure : au niveau des fichiers *.asc ou des *.tif ? Dans les deux cas, l'utilisation de l'outil de gdal et l'interpolation rend-elle le résultat meilleur que si on intègre simplement les dalles de résolution inférieure et qu'on crée ainsi un MNT avec des résolutions différentes ?

    Merci

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Bonjour,

     "je n'ai pas bien compris à quel niveau tu rajoutes les dalles de résolution inférieure : au niveau des fichiers *.asc ou des *.tif ?"

    Au niveau des TIFs. 
    Une fois ma région fusionnée, je relève les endroits où il y a des trous, et je découpe des patches de la surface manquante (un peu supérieure pour bien assurer) dans un TIF de résolution inférieure (en l'occurence mon assemblage à partir du BDALTI à 25m). C'est important de ne découper que le nécessaire pour minimier le temps de calcul.
    Je charge ce (ou ces) patches dans une (des) couche(s) que je fusionne, et j'obtiens une couche à résolution 5m, et une autre à résolution 25m placée "en dessous".
    Là, Processing -> Toolbox -> Saga -> Raster Tools -> Patching.

    Il est important dans les étapes précédentes de veiller à ce que les zones manquantes restent bien en "nodada". 

    Dans les deux cas, l'utilisation de l'outil de gdal et l'interpolation rend-elle le résultat meilleur que si on intègre simplement les dalles de résolution inférieure et qu'on crée ainsi un MNT avec des résolutions différentes ?

    Je ne sais pas ce que tu veux dire par "simplement". Si c'est charger des couches de résolution différentes, qui ont des recouvrement, et faire une fusion, alors, ben non, cela ne donne pas le résultat escompté (ne boucher que les trous).

    Cordialement,

    0
    Actions pour les commentaires Permalien
  • Avatar
    Samuel Wieczorek

    Oui, je vois. Du coup, je serai intéressé par tes fichiers GeoTiff à une résolution de 5M. Je pourrais m'en servir pour les patches justement.

     

    Cordialement

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    "je serai intéressé par tes fichiers GeoTiff à une résolution de 5M"

    Il va falloir me dire quelle portion plus précisément, parce que l'ensemble pour la France, c'est pas loin de 120Go si je ne me trompe... Je n'ai aucun espace de stockage sur Internet où mettre ça en entier (1,6Go chaque).

    0
    Actions pour les commentaires Permalien
  • Avatar
    Samuel Wieczorek

    Bonjour,

    Je peux t'ouvrir un port ftp sur mon réseau domestique pour que tu y mettes les fichiers, j'ai suffisamment de stockage pour ces fichiers. Il faudrait juste qu'on puisse s'échanger les infos de connexion ailleurs que sur ce forum

     

    PS : Je bloque sur l'ouverture des fichiers dans Land. Il me dit qu'il n'arrive pas à gérer le type de projection. Je te donnerai des infos plus précises dès que possible, si tu peux me débloquer...

     

    Cordialement

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Bonjour,

    "Il faudrait juste qu'on puisse s'échanger les infos de connexion ailleurs que sur ce forum"

    Me joindre via le mail de contact indiqué sur mon site (en bas de page).

    "Il me dit qu'il n'arrive pas à gérer le type de projection."

    Probablement tu n'as pas correctement indiqué la projection (CRS)  comme j'ai dit ci-dessus (il ne s'agit pas de reprojeter car Land et les GPS TwoNav acceptent très bien le RGF93, mais juste indiquer quelle est la projection de la couche).

    Cordialement,

    0
    Actions pour les commentaires Permalien
  • Avatar
    frederic duch

    Bonjour et tout d'abord un grand merci pour le travail effectué et les CDEM mis à disposition, je viens de les découvrir et c'est vraiment très utile.


    Habitant à la jonction de 3 dalles Brie+Normandie+Nord j'essaie de me faire un CDEM personnelle autour de chez moi, les résultats avec Land sont décevant (ligne bleu) j'ai donc suivie la technique pour en générer un à partir des ASC de l'IGN 5m.
    J'arrive bien à générer le GTIFF mais toutes mes tentatives d'export en HDR ce solde par un message d'erreur "cannot read this proyection params." dans Land.
    J'ai portant bien définie le CRS sur "EPSG:2154 - EGF93 v1 / Lambert-93" sur le Layer, le projet et lors de l'export.


    Lors de l'Export je choisi :

    • Output mode : Rendered image
    • Format : ESRI .hdr Labelled
    • File name : Test.bil
    • CRS : EPSG:2154 - EGF93 v1 / Lambert-93
    • les autres paramètre reste par default


    Voici mon fichier « test.prj » résultant que Land ne semble pas comprendre


    PROJCS["RGF_1993_Lambert_93",GEOGCS["GCS_RGF_1993",DATUM["D_RGF_1993",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",700000.0],PARAMETER["False_Northing",6600000.0],PARAMETER["Central_Meridian",3.0],PARAMETER["Standard_Parallel_1",49.0],PARAMETER["Standard_Parallel_2",44.0],PARAMETER["Latitude_Of_Origin",46.5],UNIT["Meter",1.0]]


    Quelqu’un pourrait-il me dépanner ?


    J’utilise QGIS 3.28 et pour le test je ne fusionne que 6 dalles RGEAlti 5M, histoire de gagner du temps dans le debug


    Merci
    Frederic

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Bonjour,

    Ah oui... c'est une étape que je n'ai pas du documenter, j'ai du oublier...

    L'export génère trois fichiers de même nom et avec les extensions suivantes : .bil, .hdr et .prj

    Malheureusement, le fichier .prj généré par QGIS n'est pas compatible avec Land.
    Il faut donc lui substituer, en conservant bien le nom, un fichier dont le contenu est :

    Projection    27,Lambert 93,
    Datum         WGS 84
    Zunits        METERS
    Units         METERS

    Bon, c'est vrai, ça ne s'invente pas... c'est du Land pur et dur compatible avec seulement lui-même.
    Avec cela, ça devrait fonctionner.

    Tiens nous au courant si cela fonctionne maintenant, ça pourrait servir à d'autres.

    Cordialement,

    PS : ce fichier n'est valable que pour la France métropolitaine, pas pour les DOM et TOM qui ne sont pas en Lambert93

    0
    Actions pour les commentaires Permalien
  • Avatar
    frederic duch

    Merci beaucoup Bernard effectivement avec un fichier .prj lisible de TwoNav cela fonctionne bien mieux :)

    J'en profite pour une autre question

    Comment fait tu pour générer des zone CDEM si grande ?

    j'ai du faire 3 TIFF avec recouvrement, 3 HDR puis 3 CDEM pour la zone qui m'intéresse de 729 dalles IGN 5m (zone carre de 27x27) avant de pouvoir assembler les 3 CDEM en 1 dans Land.
    j'ai des erreurs Out of Memory dans Land des que les HDR a importer sont trop gros, il en charge 2 mais pas 3.

    Ca ma pris des heures mais au final j'ai le résultat souhaité, encore merci

     

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Bonjour,

    Oui, quand les HDR sont trop gros, ça plante...

    Pour y remédier, je fais effectivement plusieurs HDR, de moins de 2Go en général (si je consulte mes archives, il faisaient en général de l'ordre de 1,6Go ou moins), ça semble être environ la limite fatale, je les charge dans Land, et je les fusionne comme tu le dis. Avec la précaution également d'une (petite) zone de recouvrement pour éviter les lignes bleus (c'est à dire une rangée à altitude zéro). Il faut faire attention que ce recouvrement soit rectiligne aussi, sinon, ça crée des trous.

    Pour les CDEM que j'ai publié, en moyenne, j'avais de 6 à 8 TIFF (donc bil/hdr) à assembler par CDEM.

    Et oui, ça prend des heures comme je le disais plus haut, surtout si on ne dispose pas d'un disque de travail SSD.

    Cordialement,

    0
    Actions pour les commentaires Permalien

Vous devez vous connecter pour laisser un commentaire.