[Ortho4XP] Message d'erreur elevation data

[ghandii]

Hello,

en voulant construire la tuile +51+005, et souhaitant utiliser les données http://gdex.cr.usgs.gov/gdex/, j'ai téléchargé le fichier SRTMv3_1_N51E005.tif que j'ai placé dans le dossier Elevation_data.
Pourtant, lors de la création du mesh (Step2), j'ai le message suivant:

-> Loading of elevation data.
!!!I could not fin the elevation data file, or it was broken.
!!!I go on with all zero elevation (perhaps a tile full of sea ?)


Je ne comprends pas... J'ai beau lire la doc jointe à Ortho4XP, je cale. J'ai essayé de renommer l’extension "tif" en "tiff", mais même message.

Une idée qui pourrait éclairer ma compréhension?

Merci

[Oscar Pilote]

Hello,

en voulant construire la tuile +51+005, et souhaitant utiliser les données http://gdex.cr.usgs.gov/gdex/, j'ai téléchargé le fichier SRTMv3_1_N51E005.tif que j'ai placé dans le dossier Elevation_data.
Pourtant, lors de la création du mesh (Step2), j'ai le message suivant:

-> Loading of elevation data.
!!!I could not fin the elevation data file, or it was broken.
!!!I go on with all zero elevation (perhaps a tile full of sea ?)


Je ne comprends pas... J'ai beau lire la doc jointe à Ortho4XP, je cale. J'ai essayé de renommer l’extension "tif" en "tiff", mais même message.

Une idée qui pourrait éclairer ma compréhension?

Merci

Il te faut gdal si tu veux utiliser des .tif pour les altitudes. Mais as-tu une bonne raison de vouloir utiliser ces fichiers plutôt
que ceux proposés par défaut (les 3" de viewfinderpanorama, malgré une résolution théorique plus faible, sont de mon point
de vue bien supérieurs aux 1" de la nasa), et qui ne nécessitent aucune dépendance.

[Glah_Salamanthe]

en voulant construire la tuile +51+005, et souhaitant utiliser les données http://gdex.cr.usgs.gov/gdex/, j'ai téléchargé le fichier SRTMv3_1_N51E005.tif Je ne comprends pas... J'ai beau lire la doc jointe à Ortho4XP, je cale. J'ai essayé de renommer l’extension "tif" en "tiff", mais même message.
Une idée qui pourrait éclairer ma compréhension?

Pour ma part, les fichiers d'élévation que j'utilise portent l'extension ".hgt" et non pas ".tif" !

[papet30]

Hello,

en voulant construire la tuile +51+005, et souhaitant utiliser les données http://gdex.cr.usgs.gov/gdex/, j'ai téléchargé le fichier SRTMv3_1_N51E005.tif que j'ai placé dans le dossier Elevation_data.

Bonjour,
j'utilise également les fichiers SRTM de USGS pour eviter les '" no data zone" de Viewfinder qui provoquent quelques fois des sortes de "pyramides" dans le mesh.
Pour moi cela fonctionne très bien avec les fichiers 1° comme 3°.

[Oscar Pilote]

Bonjour,
j'utilise également les fichiers SRTM de USGS pour eviter les '" no data zone" de Viewfinder qui provoquent quelques fois des sortes de "pyramides" dans le mesh.
Pour moi cela fonctionne très bien avec les fichiers 1° comme 3°.

Ah bon tu as encore des pyramide avec la nouvelle version (1.19 de mémoire ) ?
J'ai passé un peu de temps à trouver un mode de remplissage des vides qui soit le plus efficace possible, et j'espérais que cela était maintenant invisible.

Les gdex sont de mon point de vue nettement moins bons que les viewfinderpanarama, et ceci malgré une résolution nominale plus faible (sans parler des alpes, scandinavie etc où ils sont en 1" aussi). Si tu veux faire l'essai vas voir comment rendent les Drus à Chamonix ou Ayers Rock en Australie, il n'y a pas photo.

[papet30]

Ah bon tu as encore des pyramide avec la nouvelle version (1.19 de mémoire ) ?

Bonjour Oscar,
j'utilise la version devel qui fonctionne impeccable. Pour ce qui est des DEM je suis passé aux SRTM (void filled) de USGS lorsque je t'avais parlé des "pyramides" , tu m'avais répondu à l'époque que cela venait des no data zone.
Mais je vais réessayer avec les hgt's.
Je profite pour une question que tu as évoqué il y a bien longtemps mais je ne retrouve pas ta réponse à savoir : entre utiliser un dem 1° avec une curt_tol de 3 et un dem de 3° avec une curv_tol de 0.3, à ton avis quelle est la meilleure solution
d'un point de vue visuel?
Merci

[Oscar Pilote]

Bonjour Oscar,
Je profite pour une question que tu as évoqué il y a bien longtemps mais je ne retrouve pas ta réponse à savoir : entre utiliser un dem 1° avec une curt_tol de 3 et un dem de 3° avec une curv_tol de 0.3, à ton avis quelle est la meilleure solution
d'un point de vue visuel?

Comparer deux DEM c'est un peu comme comparer deux photos d'un même paysage, ce n'est pas parce forcément la photo qui a la plus forte résolution qui est celle de meilleure qualité. Les DEM de srtm sont basés sur des acquisitions
spectrales depuis navettes, ceux de viewfinderpanorama sont basés sur les srtm mais en y intégrant des données de courbes de niveaux de carte topographiques, d'où leur plus grande exactitude.
Par ailleures, la plupart des 1" en srtm sont juste du sur-échantilonnage de ces mêmes fichiers en 3"...

Pour curv_tol oui plus tu abaisses plus le mesh va être exigeant pour coller au DEM, mais là aussi il vaut mieux moins coller à un bon DEM qui bien coller à un mauvais DEM.

In fine pour répondre à ta question je dirais que ce que je pense être le "mieux" le l'ai mis comme paramètre par défaut dans le programme, mais ne te casse pas trop la tête avec
cela, si tu as des regrets sur un mesh il sera toujours temps de le modifier.

[papet30]

OK merci Oscar.

[ghandii]

Hello,

merci pour ces précisions
L'idée est double
- me faire ma propre opinion et expérimenter
- comme tu le disais Papet, les données de chez De Ferranti contiennent des no data zones qui à mon sens donnaient des artefacts de terrain (sur les v116 ou v117 je crois, raison pour laquelle j'ai utilisé les .tiff avec ces versions de Ortho4XP)

C'est vrai que depuis lors je suis passé en v119 avec l'exécutable windows (le top, by the way).

D'après ce que je comprends ici
- la v119 lisse davantage les no data zone pour éviter les artefacts (ok dans ce cas, va pour De Ferranti)
- l'utilisation des .tiff n'est pas possible avec l'exécutable (il faut "installer" Ortho4XP à l'ancienne avec python, les libraries - notamment gdal).

Correct?

[papet30]

Hello,
merci pour ces précisions

Bonjour,
exact depuis la V1.18 Oscar à modifié le traitement des no data zones, l'utilisation des hgt ne crée plus d'artefacts.
Je vais suivre son conseil et tout refaire avec les dem .hgt's.
Bye

[Oscar Pilote]

Ce n'est pas du lissage, on prend l'altitude du point le plus proche qui ne soit pas en no_data zone, mais sinon en gros
oui c'est cela. Pour gdal aussi, le mettre dans l'exécutable aurait rendu ce dernier inutilement gros.