#1 Sun 16 June 2024 09:54
Conversion Litto3D en WGS84
Je souhaite convertir des fichiers Litto3D au format .asc Lambert93 en GeoTiff WGS84.
J'utilise gdal ,avec respectivement le EPSG 2154 et 4326, ce fichier est ensuite importé dans Cesium Ion. J'ai systématiquement un problème d'altimétrie, voyez vous mon erreur ?
#!/bin/sh
for i in *.asc
do
j=`basename $i .asc`.tif
gdal_translate -of GTiff -a_srs EPSG:2154 $i $j
k=`basename $j .tif`_wgs84.tif
gdalwarp -s_srs EPSG:2154 -t_srs EPSG:4326 $j $k
done
Merci
Hors ligne
#2 Mon 17 June 2024 08:27
- Patrik Malvenius
- Juste Inscrit !
- Date d'inscription: 5 Jul 2023
- Messages: 6
Re: Conversion Litto3D en WGS84
Bonjour!
Je n'ai pas trop regardé le script, mais si il y a un souci altimétrique, ca vient peut-être du fait que Cesium mesure les altitudes relatives à l'ellipsoide, mais les données tu as là sont, je suppose, relatives à la géoïde? Ca donne un écart (qui n'est pas régulier, mais à la Suède j'ai eu, si je me souviens correctement, env 30 m, dans les Pyrénées ou je travail aujourd'hui même plus parfois)
Bonne journée,
Patrik
Hors ligne
#4 Mon 17 June 2024 13:55
- n314
- Participant assidu
- Date d'inscription: 6 Sep 2005
- Messages: 706
Re: Conversion Litto3D en WGS84
2154 et 4326 sont des SRS 2D ; je ne suis pas certain qu'une simple reprojection plane fasse le job de bien ré-échantillonner un raster d'altitude.
Il peut y avoir des calculs sur la composante Z.
2154 (2d) est d'équivalent 3d 5698 (coordonnées projetées RGF93 / Lambert-93 + NGF-IGN69 height).
-> cherchez ce dont a besoin Cesium comme système de référence verticale.
-> vérifier comment passer reprojeter un raster d'altitude (ce qui impose peut être de repasser en nuage de points)
ou demander au producteur une livraison dans ce format ?
Dernière modification par n314 (Mon 17 June 2024 13:57)
Hors ligne
#5 Mon 17 June 2024 15:39
- Patrik Malvenius
- Juste Inscrit !
- Date d'inscription: 5 Jul 2023
- Messages: 6
Re: Conversion Litto3D en WGS84
Merci Patrik,
En fait je pense que l'altitude n'est pas modifiée avec EPSG:4326
oui, c'est exactement ca - si tu ne modifies pas les Z tu auras une décalage avec les données "globale" de Cesium ION (le terrain mondiale, les bâtis de Google ou OSM etc) qui sont rélatif à l'ellipsoide. Mais ca dépend aussi de quoi tu mets sur l'import de tes données dans Cesium ION. A l'époque (il y a env 4 ans, quand je l'utiliserai beaucoup en Suède, Cesium ION) on avait l'option de mettre les z des données source relatif à l'ellipsoide ou "sea level". Le bon choix là serait "sea level" si tu fais pas de translation Z entre la géoide et l'ellipsoide. ION le fera pendant l'import
Encore, à l'époque, Cesium Ion utiliserait une rélation entre la géoide et l'ellipsoide qui n'était pas très précis, donc j'avais décidé de faire le translation Z moi-même avant l'import, en utilisant des données depuis le "IGN" suédois
Mais cela dit, si tu as un décalage avec tes propres données "francaises" avec un z déjà rélatif à la géoide, et les données sont tous importés dans ION dans la même façon, le souci c'est qqc autre. Mais bon, je ne crois pas qu'on a vraiment besoin de reprojeter 2154->4326 avant de faire l'import dans tous les cas? Si je ne me trompe pas ION le fera aussi
En plus, si le souci altimétrique et vraiment grand, possible que ION crois que les z sont des dégrés, pas des mètres
Mais là je commence de kill-gissa (expression suédois - un mec qui sait rien mais propose des solutions quand même)
Désolé si je viens tout confondre
Bonne journée!!
Patrik
Hors ligne
#6 Mon 17 June 2024 16:17
- fbecir
- Participant assidu
- Lieu: Saint-Mandé
- Date d'inscription: 16 Sep 2008
- Messages: 518
Re: Conversion Litto3D en WGS84
Bonjour
Pour bien faire le passage entre altitude et hauteur ellipsoïdale, il faut utiliser une grille :
https://geodesie.ign.fr/index.php?page=grilles
Donc convertir son fichier Lambert 93 / IGN69 en Lambert 93 / Hauteur ellipsoïdale puis convertir le tout en WGS84 ...
Peut-être un peu compliqué ... reste la solution de mettre une différence constante (environ 47 m en France).
Si on veut être plus précis, avec Circé on peut passer de l'altitude à la hauteur ellipsoïdale en tout point. Donc connaissant les coordonnées de votre zone d'intérêt, vous pouvez affiner les 47 m ...
Cordialement
Hors ligne
#7 Mon 17 June 2024 16:40
- Yves Egels
- Participant assidu
- Lieu: Paris
- Date d'inscription: 29 Sep 2011
- Messages: 268
- Site web
Re: Conversion Litto3D en WGS84
Si on peut mettre une valeur constante, pourquoi utiliser des scans laser de qualité. la BD Alti sera meilleure.
[
Même en ne regardant que les zones côtières, il y a pas loin de 7 mètres d'écart entre le Pas de Calais et le Finistère. Et ne parlons pas des Alpes Maritimes, où les variations à courte distance sont loin d'être négligeables. Il y a tout ce qu'il faut sur le site de la géodésie IGN, ça s'appelle RAF20 ...https://geodesie.ign.fr/index.php?page=grilles
Dernière modification par Yves Egels (Mon 17 June 2024 16:40)
Ingénieur géographe honoraire
École nationale des sciences géographiques
Société française de photogrammétrie et télédétection
En ligne
#8 Mon 17 June 2024 23:58
- Julien81
- Participant assidu
- Lieu: Giroussens
- Date d'inscription: 14 Jan 2019
- Messages: 181
Re: Conversion Litto3D en WGS84
Pour utiliser au quotidien ces grilles de correction d'altimétrie ellipsoide-géoide c'est bien la RAF20 de l'IGN qu'il vous faut prendre, car comme dit dans les différents post et notamment le précédent il peut y avoir des écarts importants sur deux emprises distinctes. Après je ne sais pas ce qu'attend votre logiciel d'un point de vue réf alti, mais en me fiant a ce qui a été dit sur Cesium (hauteur ellipsoidale?) je ferais la correction alti (inversée du coup) avec la grille avant reprojection éventuelle à l'import.
Hors ligne
#9 Fri 12 July 2024 16:01
Re: Conversion Litto3D en WGS84
Bonjour à tous,
Je reviens vers vous pour vous remercier de vos conseils, j'ai, je pense réglé mon problème. J'avais l'habitude de mapper avec WMS par exemple de la 3D, d'où l'utilisation de l'EPSG:4326. Mais ici le problème est entièrement en 3D car il s'agit de fusionner des MNT.
J'ai tout d'abord injecter le CRS EPSG:5698 dans les fichiers .asc, qui n'en avait pas, et ensuite reprojeté les données Lambert en WGS84 avec l'EPSG:4979.
Reste le problème des trous dans le MNT et celui des abords, Litto3D étant livré en dalles rectangulaires, alors que les données suivent les contours de la côte. Ce n'est pas vraiment rédhibitoire pour mon projet.
J'ai testé aussi l'utilisation de la RAF20 de l'IGN, mais sans gain apparent, gdal fait le travail.
Voici mon script actuel :
#######################
#!/bin/bash
# Fonction pour parcourir l'arborescence des fichiers
traverse_directory() {
local directory="$1"
# Boucle à travers chaque fichier/répertoire dans le répertoire courant
for entry in "$directory"/*; do
if [ -d "$entry" ]; then
# echo "Directory: $entry"
traverse_directory "$entry" # Appel récursif pour parcourir les sous-répertoires
elif [ -f "$entry" ] ; then
if [[ "$entry" = *"MNT_"* ]]; then
#echo "File: $entry"
cp $entry ./tmp/
fi
fi
done
}
#EPSG:2154 LAMBERT
#EPSG:4326 WGS84 2D
#EPSG:5720 IGN69
#EPSG:5698 RGF93 v1 / Lambert-93 + NGF-IGN69 height
#EPSG:4979 WGS84 3D
lambert2WGS84Tif(){
for i in *.asc
do
j=`basename $i .asc`.tif
echo ''
echo '$i : ' $i
echo '$j : ' $j
gdal_translate -of GTiff -a_srs EPSG:5698 $i $j
k=`basename $j .tif`.asc
echo ''
echo '$j : ' $j
echo '$k : ' $k
gdal_translate -of AAIGrid -a_srs EPSG:5698 $j $k
l=`basename $k .asc`_wgs84.tif
echo ''
echo '$k : ' $k
echo '$l : ' $l
gdalwarp -s_srs EPSG:5698 -t_srs EPSG:4979 -r bilinear -dstnodata -9999 $k $l
done
}
# Point d'entrée du script
if [ -z "$1" ]; then
echo "Usage: $0 <directory>"
exit 1
fi
# Appel de la fonction traverse_directory avec le répertoire spécifié
mkdir tmp
traverse_directory "$1";
cd tmp
mkdir wgs84Tif
# Reprojection en WGS84 depuis Lambert 93
lambert2WGS84Tif
mv *_wgs84.tif wgs84Tif
# Fusion des images .tif
cd wgs84Tif
gdal_merge.py -o "$1".tif ./*.tif
mv "$1".tif ../../
cd ../../
# Decommenter la ligne suivante pour suppression répertoires dans tmp
#rm -R tmp
########################
Hors ligne