Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considèrerons que vous acceptez l'utilisation des cookies. J'ai compris ! ou En savoir plus !.
banniere

Le portail francophone de la géomatique


Toujours pas inscrit ? Mot de passe oublié ?
Nom d'utilisateur    Mot de passe              Toujours pas inscrit ?   Mot de passe oublié ?

Annonce

Rencontres QGIS 2025

L'appel à participation est ouvert jusqu'au 19 janvier 2025!

#1 Wed 10 August 2011 14:30

Jule
Participant occasionnel
Date d'inscription: 21 Jul 2009
Messages: 48

[GeoServer] Chargement de données SRTM

Bonjour,

Je suis à la recherche d'une méthode pour importer du SRTM (format .hgt) dans GeoServer.
Existe-t-il un plugin pour charger ce type de format ou la seule possibilité est actuellement de transformer les données .hgt vers un autre format ?


J'ai bien vu quelques messages traitant du cas et qui préconisaient de passer du format .hgt au format .bil mais la transformation de semble pas très évidente.

J'ai essayé de convertir mes .hgt en .dt1 avec GlobalMapper mais le plugin DTED GeoServer n'arrive pas à charger mes dalles. Visiblement il faudrait créer un index ou quelque chose du genre pour qu'il puisse retrouver les dalles dans mon dossier mais je n'ai aucune idée de la méthode à employer pour ce faire.

Je suis un peu déçu que le plugin ImageMosaic n'arrive pas à charger ni le format .dt1 ni le format .hgt (Unable to acquire a reader for this coverage with format: ImageMosaic) alors que gdal semble posséder des readers pour ces deux formats.


Que puis-je donc faire pour charger mes dalles SRTM ?

Merci d'avance,
Jule.

Dernière modification par Jule (Wed 10 August 2011 14:31)

Hors ligne

 

#2 Wed 10 August 2011 17:00

Jule
Participant occasionnel
Date d'inscription: 21 Jul 2009
Messages: 48

Re: [GeoServer] Chargement de données SRTM

Bon j'ai trouvé le moyen de faire ce que je veux en transformant mon format SRTM (.hgt) en format GeoTiff de type Elevation (16 bit integer samples) via GlobalMapper et en chargeant le tout avec ImageMosaic plugin dans GeoServer. En appliquant le style dem on voit bien les données.

Cependant s'il y a une méthode plus directe qui évite la transformation des fichiers hgt en GeoTiff je suis preneur !
Car la procédure est tout de même assez longue et surtout pour ne pas faire grand chose au final. J'imagine que le fichier doit être le même mais avec en plus un header geotiff à moins qu'il y ai en plus une inversion lignes/colonnes. Enfin bref là n'est pas la question...

Hors ligne

 

#3 Fri 02 September 2011 18:30

Jule
Participant occasionnel
Date d'inscription: 21 Jul 2009
Messages: 48

Re: [GeoServer] Chargement de données SRTM

Bonjour,

Je relance un peu le sujet car j'ai quelques soucis encore avec GeoServer pour pouvoir publier des données/tuiles d'élévation.

Après mes conversions de données HGT en GeoTiff, j'ai créé dans GeoServer un entrepôt avec ImageMosaic sans problèmes particuliers et j'ai publié un layer elevation. Jusque là tout semble se passer correctement.

Malheureusement, lorsque j'essaye d'accéder à mon layer à travers GeoWebCache ou encore en direct sur GeoServer, je me retrouve avec des tuiles d'élévation parfois disjointes alors que chargées dans GlobalMapper elles sont parfaitement jointes. Par "disjointes" il faut comprendre que les dalles générées sont bien de 256x256 et elles se touchent correctement mais il y a dans les dalles des trous de données ! Ça c'est le premier problème...

Le second problème est que lorsque je demande des tuiles en PNG ou en GeoTiff (qui est le format des données dans mon entrepôt) j'ai exactement le même résultat, ce qui est plutôt rassurant, mais ce n'est pas celui attendu. En effet mes tuiles sont converties automatiquement en niveaux de gris et je perds de fait toute information d'élévation. Visiblement GeoServer opère la conversion implicite : 1 canal 16bits/sample -> 1 canal 8bits/sample en transposant la plage de valeurs présentes dans la tuile vers l'intervalle de niveaux de gris [0,255].

Bien évidemment l'idéal pour moi serait que GeoServer me renvoi des tuiles aux format GeoTiff d'origine avec 1 canal 16bits/sample sans aucune transformation des données si ce n'est l'interpolation des valeurs... Mais je ne suis pas sûr que ce soit possible et si ça l'est je ne sais pas comment faire.

Une autre solution est peut-être de configurer un style SLD mais je n'ai pas l'impression que cela me permette de retrouver la valeur d'origine.

J'ai vu qu'il était possible de récupérer la bonne valeur via un GetFeatureInfo, en ciblant un pixel particulier dans une dalle particulière, mais étant donnée que je souhaite me servir de ma couche comme heightmap il n'est pas souhaitable de faire 100 requêtes serveur pour juste dessiner un maillage de 10x10...

Quelqu'un a-t-il déjà fait ce que j'essaye de réaliser ou bien quelqu'un aurait une idée pour me dépanner ? Je suis à court d'idées...

Merci d'avance pour vos éventuelles pistes, voire solutions ! smile

Hors ligne

 

#4 Tue 13 March 2012 16:27

Jule
Participant occasionnel
Date d'inscription: 21 Jul 2009
Messages: 48

Re: [GeoServer] Chargement de données SRTM

Pour ceux que ça intéresse, je m'en suis sorti en créant un style SLD qui map des plages de dégradés de 256 valeurs (0x00 => 0xFF).

Ainsi j'obtiens une suite de ColorMapEntry :

Code:

-32768    => 0x000000
0         => 0x000000
255       => 0x0000FF
256       => 0x000100
511       => 0x0001FF
512       => 0x000200
...

Ensuite dans mon application je lis la valeur des pixels et je reconverti directement en int :

Code:

int altitude = (int)pixelColorRGB & 0xFFFF

Sachant que pour du SRTM le mask 0xFFFF suffit, 65535m d'altitude c'est difficile à trouver sur Terre ! Toutefois attentions aux erreurs dans certaines tuiles SRTM non retravaillées !!
On peut éventuellement élargir le map dans les négatifs sachant que certaines zones sont négatives.


Bon courage aux challengers !
Jule

Dernière modification par Jule (Tue 13 March 2012 16:27)

Hors ligne

 

Pied de page des forums

Powered by FluxBB