Discussion :

[MatRem]

Bonjour,
Je chercher à récupérer des données altimétriques pour reproduire en 3D des environnement réels des Pyrénées, c'est tout naturellement que je me suis penché sur celles de l'IGN.

Après quelques recherches il m'a semblé que ce qui me conviendrait le mieux serait les données RGE alti via WMS pour récupérer une zone définies en une image geotiff :
https://geoservices.ign.fr/services-...rts-altimetrie

Ces 2 couches me semblent les plus intéressantes :
- Modèle numérique de terrain RGE Alti : ELEVATION.ELEVATIONGRIDCOVERAGE.HIGHRES
- Modèle numérique de terrain RGE Alti Fr Métro : RGEALTI-MNT_PYR-ZIP_FXX_LAMB93_WMS

Ma requête ressemble donc à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

https://wxs.ign.fr/altimetrie/geoportail/r/wms?LAYERS=RGEALTI-MNT_PYR-ZIP_FXX_LAMB93_WMS&FORMAT=image/geotiff&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&STYLES=&CRS=EPSG:4326&BBOX=42.726159847821,0.493319711489,42.735377807206,0.505823362736&WIDTH=1024&HEIGHT=1024

Une fois reconstruit, pour le layer HIGHRES j’obtiens de gros artefacts (type crénelage) quel que soit la résolution demandée (1m ou 5m), pour le layer ZIP_FXX_LAMB93_WMS j'obtiens d'autres types d'artefacts (type grille) :



C'est un peu moins flagrant avec la couleur pour le cas grille, mais bon ça se voit bien quand même :


Suis-je sur la bonne piste, et ces données doivent forcément être lissées (ce qui va me faire perdre en précision...), ou bien dois-je faire autrement?

Merci

[elias couppe]

Bonjour,

je ne suis pas expert sur ces données, mais quelques pistes :
- quel outil utilisez-vous pour visualiser les données ? est-il possible avec cet outil d'exploiter le flux MNT en WMTS (ELEVATION.ELEVATIONGRIDCOVERAGE.HIGHRES ou ELEVATION.ELEVATIONGRIDCOVERAGE) ? J'ai un lointain souvenir d'un effet "escalier" avec le flux WMS...
- je me demande si ces artefacts ne sont pas la résultante de la reprojection en WGS84

En espérant d'autres avis sûrement plus pertinents que le mien sur le sujet.

[MatRem]

Merci pour l'info, je pensais bien à cette piste, mais si j'ai bien compris WMTS travaille en tuile, et je trouvais ça moins pratique que la récupération d'un seul fichier.

A la base je voulais charger ces données sous Unreal Engine 5, j'ai donc fais la conversion du geotiff avec GDAL en raw uint16, pour pouvoir le charger facilement.
Comme j'ai vu ces artefacts apparaitre, et que je maitrise mieux Unity, j'ai écrit un petit script pour effectuer une reconstruction de Maillage directement dans Unity pour vérifier et c'est ça que j'ai capturé ici.

Concernant le layer RGEALTI-MNT_PYR-ZIP_FXX_LAMB93_WMS j'imagine que les données acquises sont projetés sur le cone lambert 93, et donc j'ai du mal à comprendre que ce qu'on récupère en WMS fasse effectivement apparaitre une sorte de tuilage avec une non uniformité d'orientation.

Pour le layer ELEVATION.ELEVATIONGRIDCOVERAGE.HIGHRES vu qu'ici je récupére une zone de 1024x1024m dans une image de 1024x1024, je me suis dis que sans doute la source n'était pas à 1 m de précision (ceci dit je m'attendais à ce que la requête lisse pour moi), j'ai donc essayé de récupérer une zone 5x plus grandes (toujours dans une image 1024x1024), mais ce n'est pas franchement mieux.

[MatRem]

J'ai commencé à investiguer la piste wmts et j'ai deux problèmes :

> la requête pour l'altitude highres ne fonctionne pas (erreur "No data found") :
https://wxs.ign.fr/altimetrie/geopor...&TILECOL=20273
Alors que pour l'ortho j'y arrive bien :
https://wxs.ign.fr/ortho/geoportail/...TILECOL=131435

D'après la documentation (https://geoservices.ign.fr/documenta...-wmts-ogc#1616) et en regardant les capacités pour le layer qui m'intéresse (https://wxs.ign.fr/altimetrie/geopor...etCapabilities)
J'en ai déduit que je devais rester dans un système de coordonnées WGS84 (TILEMATRIXSET=WGS84G) et faire mes calculs en lat/lon (contrairement à l'ortho ou il faut travailler en projection web mercator : TILEMATRIXSET=PM)
ce qui me donne TILEROW=8146&TILECOL=20273, mais j'ai quelques doutes malgré le fait q'ils semblent être dans le bon range.

> Et je ne trouve pas vraiment de documentation pour le format "image/x-bil;bits=32" qui à l'air d'être le seul disponible pour l'altitude en wmts.

[SgtLame]

Ton terrain, c'est un mesh ou un terrain Unity?

[ngauthe]

Bonjour,

Et je ne trouve pas vraiment de documentation pour le format "image/x-bil;bits=32" qui à l'air d'être le seul disponible pour l'altitude en wmts.

Le format BIL est un format binaire générique qui nécessite un fichier de header (déductible des paramètres de la requête) pour être pleinement exploité:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
MAPUNITS               METERS
ULXMAP  592000.0000
ULYMAP  6239000.0000
XDIM    1.0000
YDIM    1.0000
NROWS   1000
NCOLS   1000
NBANDS  1
NBITS  32
BYTEORDER   I
LAYOUT  BIL
PIXELTYPE         FLOAT

Les deux premières valeurs sont le géoréférencement de l'image, le produit RGEAlti est référence en coin nord-ouest (https://geoservices.ign.fr/sites/def...GEALTI_2-0.pdf)
Les deux suivantes (DIM) indiquent la taille des pixels en x et y (une valeur négative inverse l'axe)
Les deux suivantes (NROWS/NCOLS) indiquent le nombre de lignes et de colonnes dans l'image
Le reste décrit comment lire la donnée, notamment le datatype des pixels (important car de mémoire gdal considère que par défaut c'est de l'integer)

En pratique il suffit de créer un fichier .hdr contenant ces valeurs à côté du .bil (avec le même nom), gdal sait l'interpréter automatiquement.
Pour plus d'informations sur le format: https://desktop.arcgis.com/en/arcmap...ster-files.htm

S'il s'agit d'une récupération de données "one-shot" je pense que le WMS est tout à fait adapté au besoin, le crénelage observé dans le premier message peut être dû à une interpolation (en ppv) des données lors de la génération de l'image sur le serveur, qui peut venir:
-> d'une reprojection (projection native en IGNF:LAMB93 ou les équivalents sur les DOM)
-> d'un décalage entre la grille de l'image demandée et la grille du produit.
Pour approfondir ce 2e point: le RGEALTI est un produit référencé en centre-pixel, alors que la plupart des images sont en coin-pixel. Ce qui veut dire qu'en demandant au serveur une image avec un coin en coordonnées entières (par exemple 592000.0, 6239000.0 comme dans le header indiqué plus haut) on se retrouve avec le centre du premier pixel sur des coordonnées demi-entières (592000.5, 6238999.5) qui ne correspondent pas à la grille initiale du produit et vont donc devoir être interpolées. Pour contourner ce problème il faut décaler la BBOX d'un demi pixel afin de s'aligner sur la grille initiale (donc toujours avec l'exemple précédent: BBOX=591999.5,6238000.5 , 592999.5,6239000.5)

[MatRem]

Ton terrain, c'est un mesh ou un terrain Unity?

C'est un mesh que je créé moi même avec une structure de triangles très simple du genre (4x4 vertices):
--- --- ---
| / | / | / |
--- --- ---
| / | / | / |
--- --- ---
| / | / | / |
--- --- ---

Le but étant de débuguer la donnée d'entrée. Ensuite je vais essayer de la travailler sous UE5.

[MatRem]

...

Merci pour toutes ces pistes je vais continuer à investiguer
Le format GDAL correspondant est celui ci j'imagine : https://gdal.org/drivers/raster/envi.html ?[/url]

[MatRem]

Effectivement en faisant des requêtes WMS sur le layer RGEALTI-MNT_PYR-ZIP_FXX_LAMB93_WMS dans le repère EPSG:2154 (LAMBERT93) avec les demi coordonnées c'est parfait, merci !

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
https://wxs.ign.fr/altimetrie/geoportail/r/wms
?LAYERS=RGEALTI-MNT_PYR-ZIP_FXX_LAMB93_WMS
&FORMAT=image/geotiff
&SERVICE=WMS
&VERSION=1.3.0
&REQUEST=GetMap
&STYLES=
&CRS=EPSG:2154
&BBOX=495122.5,6180974.5,496122.5,6181974.5
&WIDTH=1000
&HEIGHT=1000

[MatRem]

Un petit aperçu, des données IGN importées dans UE5 :