ORTHO4XP V3.5 — Première version stable

[domisilasol]

Merci Ypsos, merci jasum, merci Claude

je viens de faire un teste avec la dernière version, en prenant les codes EPSG donnés par jasum

-> tout semble fonctionner correctement, plus besoin de passer par QGIS

il faut simplement corriger la fenêtre qui s'affiche pour définir le code EPSG
- les codes affichés dans la liste ne sont pas les bons (liste pas à jour)
- le code affiché dans la fenêtre de saisie devrait être celui du fichier source déduit du nom du fichier source


Un pas de plus vers un outil fonctionnel

[domisilasol]

Salut Ypsos,

je viens de noter un petit bug sur un autre sujet.

Quand je lance le build de plusieurs tuiles en mode Batch, pas possible d'interrompre le calcul en cours de route !

Le bouton Stop (Red Flag) n'a aucun effet.
-> la seule solution pour stopper est de fermer toutes les fenêtre d'Ortho4XP

A+

[Ypsos]

Salut Ypsos,

je viens de noter un petit bug sur un autre sujet.

Quand je lance le build de plusieurs tuiles en mode Batch, pas possible d'interrompre le calcul en cours de route !

Le bouton Stop (Red Flag) n'a aucun effet.
-> la seule solution pour stopper est de fermer toutes les fenêtre d'Ortho4XP

A+

sur mac cela fonctionne tu as un log ou quelque chose ?

[Ypsos]

il faut simplement corriger la fenêtre qui s'affiche pour définir le code EPSG
- les codes affichés dans la liste ne sont pas les bons (liste pas à jour)
- le code affiché dans la fenêtre de saisie devrait être celui du fichier source déduit du nom du fichier source?

ok inscrit sur liste "à corriger" faudra patienter -> Limite d'utilisation atteinte · Réinitialisation 22 sept. à 21:00 ·?

[domisilasol]

Salut Ypsos,

je reviens sur le fonctionnement de la fenêtre du choix du code EPSG.

Pour la corse le nom des fichiers contient "LAMB93_IGN78C" -> ce qui correspond à EPSG=10498 (suivant site epsg.io)

Dans le champ de saisie je rentre donc 10498.
-> cette saisie n'est pas prise en compte
-> le calcul se fait ensuite avec EPSG=2154

Le fonctionnement du champ de saisie devrait être le suivant :

- si le code EPSG peut être déduit du nom des fichiers .ASC
-> alors afficher ce code dans le champ de saisie

- si le code EPSG ne peut pas être déduit du nom des fichiers .ASC
-> alors ne rien afficher dans la case de saisie

L'utilisateur peut ensuite modifier ou écrire un code dans le champ de saisie, si il le souhaite.

Lors de la fermeture de la fenêtre :

- si un code EPSG est défini dans le champ de saisie
-> alors ce code doit être pris en compte en priorité

- si aucun code n'est défini dans le champ de saisie
-> le programme détermine le code le plus approprié pour le calcul

Cordialement
domisilasol

[Ypsos]

Salut Ypsos,

je reviens sur le fonctionnement de la fenêtre du choix du code EPSG.

Pour la corse le nom des fichiers contient "LAMB93_IGN78C" -> ce qui correspond à EPSG=10498 (suivant site epsg.io)

Dans le champ de saisie je rentre donc 10498.
-> cette saisie n'est pas prise en compte
-> le calcul se fait ensuite avec EPSG=2154

Le fonctionnement du champ de saisie devrait être le suivant :

- si le code EPSG peut être déduit du nom des fichiers .ASC
-> alors afficher ce code dans le champ de saisie

- si le code EPSG ne peut pas être déduit du nom des fichiers .ASC
-> alors ne rien afficher dans la case de saisie

L'utilisateur peut ensuite modifier ou écrire un code dans le champ de saisie, si il le souhaite.

Lors de la fermeture de la fenêtre :

- si un code EPSG est défini dans le champ de saisie
-> alors ce code doit être pris en compte en priorité

- si aucun code n'est défini dans le champ de saisie
-> le programme détermine le code le plus approprié pour le calcul

Cordialement
domisilasol

je n'avais pas encore transférer cette version vérifie :

ce qui a été fait

1. Table de normalisation Compound ? 2D horizontal (codes officiels EPSG uniquement) :

10498	9793	RGF93 v2 / Lambert-93 (partie horizontale)
10497	9793	idem + IGN69
10499 / 10500	9794	RGF93 v2b / Lambert-93

1. Comportement :
   • L’utilisateur peut saisir 10498 (ou tout autre code composé).
   • Avant tout appel à rasterio/PROJ, le code est automatiquement remplacé par son équivalent 2D horizontal.
   • Les DEM restent des grilles 2D ? seule la planimétrie compte pour la reprojection vers 4326.
   • Aucun plantage possible en aval (calculate_default_transform / reproject).
   • Tout le reste du monde n’est pas touché (les codes 2D purs passent inchangés).

Résultat final pour la Corse

• Saisie 10498 ? acceptée et normalisée en 9793 (Lambert-93 horizontal propre).
• Priorité utilisateur respectée.
• Pipeline de calcul en sécurité.
• Approche toujours mondiale (pas de logique « si Corse »).comem claiude est coupé je voulais vérifeir ce poinyt

Comme Claude est coupé jusqu'à mardi je voulais clarifier et sécuriser ce point relevé par Claude si je donnais suite à ta demande sans controle

1. EPSG:10498 est un CRS composé (Compound) :
2. partie horizontale = Lambert-93 (RGF93 v2)
3. partie verticale = NGF-IGN78 (hauteur)
4. Les fichiers .asc IGN sont des grilles 2D (X, Y + valeur d’altitude dans le pixel).
   Ils n’ont pas de composante Z dans le système de coordonnées lui-même.
   
   Quand on fait CRS.from_epsg(10498) puis une reprojection purement planimétrique vers EPSG:4326 :
5. GDAL/PROJ moderne extrait généralement la partie horizontale automatiquement,
6. mais ce n’est pas garanti sur toutes les versions de PROJ/rasterio,
7. et certains appels (calculate_default_transform, reproject) peuvent échouer ou se comporter de façon imprévisible avec un Compound CRS.
8. C’est exactement le genre de situation qui peut faire planter le traitement plus loin, même si l’interface a bien accepté 10498. Recommandation (universelle, sans casser)
   
   
   Ne pas interdire 10498, mais normaliser les codes composés vers leur équivalent 2D horizontal avant de les passer à rasterio.?

essaye la version en ligne si cela focntionne je n'ai pas pu faire vérifier par Claude qui avait commencé le travail en ton sens avec la sécurté.

[domisilasol]

J'ai fait le test avec la version github téléchargée à midi.

On va attendre le retour de Claude

[Ypsos]

J'ai fait le test avec la version github téléchargée à midi.

On va attendre le retour de Claude

j'ai mis en ligne après ton témoignage vers 15h45 la version non entièrement vérifiée par Claude .

CAD je lui demande une correction après l'autre sinon il plante et si ORTO Bug on ne sait pas quel nouveau codage est en cause qui a cassé.

Aussi après chaque nouveau bloc ajouté ou modifié il doit vérifier le pipeline, la compatibilité multi-système, langue en Anglais et Francais, test de sécurité et vérifer s'il n'a rien cassé par rapport au fichier livré.

La vesion en ligne est finalisée. Mais vendredi soir il était en train de réaliser la dernière partie de vérification des langues avant de couper.

Tu peux tester la version de 15h45 ; en vérification visuelle dans Visual studio code il y a 1 ou 2 mots en français non traduit ce n'est pas un problème .

[domisilasol]

Sur github, les dernieres modifications datent d'hier !

[Ypsos]

Sur github, les dernieres modifications datent d'hier !

Re essaye j'ai fait vérifier et relancé Github Dektop il était sur l'ancien dossier d'hier désolé

Maintenant — c’est bon. Les deux correctifs sont bien sur GitHub.

Commit MAJ (16afabc) :

src/O4_Altimetrie_Utils.py	_COMPOUND_VERS_2D · Priorité STRICTE · _suggestion_epsg · 10498?9793	OK (+101 / ?40)
src/O4_DEM_Utils.py	non-square DEM · nydem, self.nxdem · hautes latitudes	OK

Local et GitHub sont alignés.
?

[androl2015]

Salut Roland
peux tu mettre un lien pour cette dernière version , je m'y perd complètement dans GitHub, au fait nul besoin d'ouvrir un compte GitHub je suppose ?
merci
RoRo

[Ypsos]

?lien vers la page

Cliquer sur le bouton "Code"
Sélectionner la ligne Download ZIP





?

[domisilasol]

Bonjour Ypsos,

je viens de télécharger la dernière version, et tout semble marcher.

Je tape10498 pour la corse. Le programme sélectionne de lui-même ce qu'il faut , c'est à dire 9793, pour faire le calcul.


Pour androl,

le lien de téléchargement d'Ortho4XP_V3 sur github :

https://github.com/Ypsos/ORTHO4XP_V3

Bonne journée
domisilasol

[Ypsos]

Bonjour Ypsos,

je viens de télécharger la dernière version, et tout semble marcher.

Je tape10498 pour la corse. Le programme sélectionne de lui-même ce qu'il faut , c'est à dire 9793, pour faire le calcul.


Pour androl,

le lien de téléchargement d'Ortho4XP_V3 sur github :

https://github.com/Ypsos/ORTHO4XP_V3

Bonne journée
domisilasol

Merci

reste plus que la fenêtre qui reste en FR qui 'n'est pas traduite en anglais

[domisilasol]

J'ai oublié de mentionner une chose.
Quand la fenêtre de choix du code EPSG s'affiche, le champ de saisie est déjà prérempli avec 2154.


Le fonctionnement du champ de saisie devrait être le suivant :

- si le code EPSG peut être déduit du nom des fichiers .ASC
-> alors afficher ce code dans le champ de saisie

- si le code EPSG ne peut pas être déduit du nom des fichiers .ASC
-> alors ne rien afficher dans la case de saisie

L'utilisateur peut ensuite modifier ou écrire un code dans le champ de saisie, ou laisser le champ vide si il le souhaite.

Lors de la fermeture de la fenêtre : (cela semble déjà pris en compte d'après le test que je viens de faire)

- si un code EPSG est défini dans le champ de saisie
-> alors ce code doit être pris en compte en priorité

- si aucun code n'est défini dans le champ de saisie
-> le programme détermine le code le plus approprié pour le calcul?

Dans la plupart des cas, ce champ de saisie n'a pas besoin d'être modifié par l'utilisateur, Ortho4XP se débrouille tout seul.

DONC :
ce qui reste à faire est ce qui est en vert ci-dessus.

A+