Ortho4XP V3 — mise à jour

[Ypsos]

Changement de priorités temporaire pour économiser mon quota (le bouton taille plus grand est reporté). Merci pour votre patience !

Un grand merci à vous : c'est grâce à vos contributions et à nos échanges réguliers sur les forums que la V3 gagne en visibilité et attire de nouveaux regards sur GitHub. C'est ainsi qu'un utilisateur situé à Tokyo a repéré et proposé des correctifs pour des bugs historiques (présents depuis la V1 et la 1.40), validés parGrok et Chatgpt.

Dès que Claude sera disponible et dès ce soir à 21h00 je vais de suite lui demander d'intégrer ces correctifs:

• Bug #1 (#11) — Override custom_dem ignoré par Triangle4XP : Le code écrivait uniquement le raster de base (self.alt_dem) dans le fichier transmis à Triangle4XP, ignorant totalement les subdems chargés via les custom_demséparés par des points-virgules. Résultat : le raffinement du maillage (mesh) et les données d'altitude ne prenaient pas en compte les overrides, ce qui provoquait des incohérences géographiques majeures, plaçant à la fois le terrain, le relief et les bâtiments sur de fausses collines.
• Bug #2 (#10) — Échec silencieux de conversion DDS et blocage d'X-Plane : Ce problème combine plusieurs défaillances. D'une part, la commande subprocess.call transmettait une chaîne de redirection shell (>/dev/null 2>&1) comme un simple argument textuel au lieu d'une vraie redirection. D'autre part, et c'est le plus critique, le fichier temporaire du décors (xxx.dsf.tmp) était renommé en xxx.dsf avant que le contrôle d'erreur (UI.red_flag) ne soit vérifié. Un build ayant échoué à convertir ses textures DDS laissait donc passer un DSF corrompu actif, provoquant le blocage complet d'X-Plane au chargement de la tuile.

?( ps pourquoi Grok et ChatGPT? Je sus bloqué chez eux plus rapidement que chez Claude que je paye. Mais cela suffit pour leur demander les pré-études et annalyses. Si nécessaire je fais aller/retour Grok ChatGPT s 'ils ne sont pas d'accord. Une fois Ok entre eux, je transfère le codage à Claude ce qui lui permet de démarrer de site le codage et économiser les thoken de recherche et d'analyse)

[Ypsos]

Bugs Historiques corrigées

Bouton Mode plus grand


selon mode actif les teintes des boutons changent pour matérialiser visuellement la rubrique de travail.

version en ligne sur GitHub

[domisilasol]

Salut Ypsos,

un grand merci pour ton travail

Je viens de télécharger la dernière version.

Je note un oubli dans la fenêtre de configuration :

Dans la configuration globale, on a aussi les réglages par défaut pour les tuiles (quand il n'y a pas de config tuile).
=> donc "Donnees vectorielles", "Maillage", "Masques", "DSF/Imagerie" doivent aussi être actifs, et enregistrés dans la config Globale

Dans la configuration Globale :
-> j'ai vérifié, tout est bien sauvegardé.
-> c'est donc juste cosmétique, il ne faut pas griser/ désactiver tous les paramètres du haut. (ils sont toujours actifs quelque soit le mode)?


A+

[Ypsos]

corrections faites sera sur site avec prochaine mise à jour

[Ypsos]

? Finalisation module : Simulateur visuel Ortho4XP V3

Configurer Ortho4XP, c’est souvent un parcours d’obstacles. Les noms de paramètres sont techniques, les plages de valeurs peu parlantes, et il faut parfois plusieurs builds (et beaucoup de temps) pour comprendre ce que fait vraiment un curseur. La présentation « historique » des options — listes de variables, fichiers .cfg, hints courts — reste précieuse pour les experts, mais elle n’aide pas toujours un utilisateur qui veut simplement obtenir un bon résultat sans devenir ingénieur mesh.

C’est pour ça que le module Simulateur a été conçu.

Il ne remplace pas la fenêtre Config : il illustre les réglages. Ce que vous y trouvez

1. Graphismes animés
   Chaque onglet (Mer & Côte, Terrain, Mesh 3D, Imagerie & Aéroports) montre l’effet des curseurs en direct : fondu photo / eau XP, densité du maillage, aplatissement des routes, zone HiRes autour des aéroports, etc. L’idée : voir plutôt que deviner.
2. Sens des curseurs clarifié
   En général : gauche = effet « brut » / moins favorable, droite = correction / plus de détail (sauf cas documentés). Plus besoin de se demander si une valeur haute est « mieux » ou « pire ».
3. Recommandations intégrées
   Sous les curseurs, les plages utiles sont indiquées (ex. ratio_water ? 0.10, masks_width ? 100 m, default_zl 16–17, etc.), tirées de l’usage réel et de la doc Ortho4XP.
4. Messages d’aide FR / EN
   Une ligne d’explication sous chaque curseur, dans la langue choisie au lancement (pas les deux en même temps). Objectif : comprendre en une phrase ce que le paramètre contrôle.
5. Lien avec Outils ? Config
   Les noms de variables sont les mêmes que dans la config tuile / globale. Vous réglez dans le simulateur, vous écrivez le .cfg, et la fenêtre Outils peut se rafraîchir en conséquence.

Ce module n’a de sens que s’il est lisible pour un utilisateur non expert.
Merci de le tester et de dire franchement :

• les graphismes sont-ils compréhensibles sans lire la doc ?
• y a-t-il un curseur dont l’animation induit en erreur ?
• un texte d’aide trop vague, trop long, ou inversé gauche/droite ?

Vos retours (captures, « je n’ai pas compris X ») nous aideront à corriger avant d’élargir l’usage.

Merci d’avance — et bon build.
?

[domisilasol]

Salut Ypsos,

j'ai quelques remarques (constructives) concernant le module "Simulateur Visuel".

Il faudrait pour que ce soit fonctionnel :
- afficher quelle configuration est active (Tuile ou Globale)
- bouton "Recharger depuis configuration Tuile"
- bouton "Recharger depuis la config Globale"
- quand on sélectionne "Ecrire cfg App" ou "Ecrire cfg Tuile", il ne faut pas perdre dans les fichiers de configuration les clés ajoutées V3
language=
dem_sonny_dir=
dem_asc_dir=
dem_epsg_dir=
dem_tile_out_dir=
dem_prepare_src_dir=

Bon courage
A+
?

[Ypsos]

Salut Ypsos,

j'ai quelques remarques (constructives) concernant le module "Simulateur Visuel".

Il faudrait pour que ce soit fonctionnel :
- afficher quelle configuration est active (Tuile ou Globale)
- bouton "Recharger depuis configuration Tuile"
- bouton "Recharger depuis la config Globale"
- quand on sélectionne "Ecrire cfg App" ou "Ecrire cfg Tuile", il ne faut pas perdre dans les fichiers de configuration les clés ajoutées V3
language=
dem_sonny_dir=
dem_asc_dir=
dem_epsg_dir=
dem_tile_out_dir=
dem_prepare_src_dir=

Bon courage
A+
?

J'ai demandé à IA de coder ta demande voici ce qu'il a fait .

Afficher config active Tuile / Globale	non	? bandeau en haut
Bouton bascule mode (comme Outils)	non	? ? Mode Tuile / Globale
Recharger depuis config Tuile	un seul « cfg »	codé
Recharger depuis config Globale	nion	codé
Écrire cfg sans perdre les clés V3	? (réécrit tout list_tile_vars)	? fusion

Clés V3 conservées à l’écriture


language=, dem_sonny_dir=, dem_asc_dir=, dem_epsg_dir=, dem_tile_out_dir=, dem_prepare_src_dir=
(+ toute autre clé absente du simulateur)

Principe : lecture du fichier existant ? mise à jour uniquement des paramètres du simulateur ? réécriture en gardant le reste. UI

1. Haut : bascule mode + libellé Configuration active : TUILE / GLOBALE
2. Bas : Recharger Tuile | Recharger Globale | Écrire Tuile | Écrire App | Fermer

je lui ai demandé de placer le bouton mode ?en haut au dessus du Canvas en premier pour garder la cohérence



?

et les boutons sont ajoutés aux autres en bas
?bien entendu comme d'habitude en bilingue selon langue sélectionnée.

Version en ligne

[Ypsos]

Le pas a pas pour le module Visualiseur de configuration en Français et en Anglais est en ligne.

?

[domisilasol]

Salut Ypsos

Un petit soucis qui dure depuis un certain temps…

Le custom_dem de la configuration tuile active n'est pas pris en compte certaines fois !
Pour remédier à cela, je me suis contraint à une routine avant chaque création de tuile :
- afficher la Configuration Tuile
- cliquer sur "Appliquer" puis "Fermer"
- parfois je fais aussi "Charger Config Tuile", "Appliquer" puis "Fermer"
=> ensuite le build step 1 se passe bien


Je me suis résolu à faire des tests pour voir d'où venait le problème.

1°)
- sélectionner une tuile X Y
- créer un custom_dem pour cette tuile -> le custom_dem est enregistré dans le fichier Config Tuile (Config Tuile à 1 ligne)
- lancer Step1 "Assembler vecteurs" -> le custom_dem n'est pas pris en compte
(-> je remarque que le fichier Config Tuile n'est pas mis à jour (complété) lors du Step1)

2°)
- sélectionner une tuile X Y
- créer un custom_dem pour cette tuile -> le custom_dem est enregistré dans le fichier Config Tuile (Config Tuile à 1 ligne)
- Afficher la configuration tuile "Mode Config Tuile"
- quitter la fenêtre de Config
- lancer Step1 "Assembler vecteurs" -> le custom_dem n'est pas pris en compte
(-> je remarque que le fichier Config Tuile n'est pas mis à jour (complété) lors du Step1)

3°)
- sélectionner une tuile X Y
- créer un custom_dem pour cette tuile -> le custom_dem est enregistré dans le fichier Config Tuile (Config Tuile à 1 ligne)
- Afficher la configuration tuile "Mode Config Tuile"
- cliquer sur "Appliquer"
- quitter la fenêtre de Config
- lancer Step1 "Assembler vecteurs" -> le custom_dem est pris en compte
(-> je remarque que le fichier Config Tuile n'est pas mis à jour (complété) lors du Step1)

4°)
- sélectionner une tuile X Y
- créer un custom_dem pour cette tuile -> le custom_dem est enregistré dans le fichier Config Tuile (Config Tuile à 1 ligne)
- Afficher la configuration tuile "Mode Config Tuile"
- cliquer sur "Appliquer"
- Basculer en "Mode Config Globale
- cliquer sur "Appliquer"
- quitter la fenêtre de Config
- lancer Step1 "Assembler vecteurs" -> le custom_dem de la tuile n'est pas pris en compte
(-> je remarque que le fichier Config Tuile n'est pas mis à jour (complété) lors du Step1)

5°)
- sélectionner une tuile X Y
- créer un custom_dem pour cette tuile -> le custom_dem est enregistré dans le fichier Config Tuile (Config Tuile à 1 ligne)
- Afficher la configuration tuile "Mode Config Tuile"
- cliquer sur "Appliquer"
- cliquer "Ecrire Config Tuile" => (Config Tuile complet)
- Basculer en "Mode Config Globale
- cliquer sur "Appliquer"
- quitter la fenêtre de Config
- lancer Step1 "Assembler vecteurs" -> le custom_dem de la tuile n'est pas pris en compte
- Afficher la configuration tuile "Mode Config Tuile"
- "Charger cfg Tuile"
- cliquer sur "Appliquer"
- lancer Step1 "Assembler vecteurs" -> le custom_dem de la tuile est pris en compte


6°) CONCLUSIONS :

a) Au début du Step1, si le fichier de Config Tuile n'existe pas ou n'est pas complet, il faut le compléter, l'enregistrer et le prendre en compte.
-> c'est ce fichier qui sert de référence pour tout le processus de création tuile.
-> l'utilisateur doit veiller à ne pas modifier ce fichier durant les différentes étapes de la création tuile.

b) il ressort que dans la fenêtre Config, la bascule du Mode Config Tuile / Config Mode Globale entraîne des conflits dans les données.
-> il semble que les données de config sont gérées par une même variable (structure), et que le fait de cliquer sur "Appliquer Config Tuile" dans la fenêtre Config met à jour cette variable avec les bonnes valeurs.
-> on a 3 entités à gérer, le fichier Config Globale, le fichier Config Tuile et l'affichage dans la fenêtre Config.
-> ces entités doivent être gérées avec des variables différentes pour éviter les conflits.
-> la construction tuile doit se faire avec les


A+
domisilasol




?

[Ypsos]

Salut Ypsos

...
-> on a 3 entités à gérer, le fichier Config Globale, le fichier Config Tuile et l'affichage dans la fenêtre Config.
-> ces entités doivent être gérées avec des variables différentes pour éviter les conflits.
-> la construction tuile doit se faire avec les


A+
domisilasol




?

Merci pour ces tests et pour avoir signalé précisément ce comportement dans la fenêtre Config.?

J'ai donné tes tests à IA en lui demandant de cherher si ce comportement est un BUG introduit par la modernsation de la V3 ou s'il est plus ancien.

La cotrrection ne sfreoaty pas la même

Les 2 IA sélectionnées donnent cette synthèse


Grok et ChatGpt ont vérifié le point dans le code historique d’Ortho4XP V1/V1.40 : le comportement que tu décris concernant la bascule entre Configuration Tuile et Configuration Globale, et le risque de mélange des valeurs lors de l’application de la configuration, est déjà présent dans l’architecture historique. Il ne s’agit donc pas d’un comportement introduit par la modernisation d’ORTHO4XP V3.

Cette analyse est néanmoins très intéressante, car elle met en évidence une faiblesse réelle de cette gestion des configurations.

À terme, la correction V3 devra conserver la compatibilité avec le fonctionnement historique tout en séparant clairement :

• la configuration globale ;
• la configuration propre à la tuile ;
• les valeurs affichées/modifiées dans la fenêtre Config.

La construction de la tuile devra ensuite travailler avec les paramètres propres à la tuile, sans que ceux-ci puissent être involontairement écrasés par l'état de la configuration globale ou de l'interface.

Nous allons donc conserver ce point dans l'audit V3 comme problème historique à corriger proprement dans V3, et non comme une régression introduite par la modernisation.

Merci encore pour le test et le signalement : il permet justement d'identifier un point important de robustesse de la gestion des configurations.
?
Ok je fais coder les corrections ce soir lorsque Claude sera disponible à nouveau .

(ps : > un copier coller a coupé la fin de ta dernière ligne)

[domisilasol]

Oui, le copier_coller a été tronqué

-> la construction tuile doit se faire avec les données du fichier Config Tuile seulement.

[Ypsos]

Salut domisilasol,

Encore une fois merci pour tes tests, ils étaient impeccables et ils ont permis d'isoler précisément le problème — ta conclusion 6a était la bonne.

La cause : au lancement d'un build, Ortho4XP préparait la tuile à partir de la « mémoire » (les valeurs en cours) et ne relisait pas le fichier de config de la tuile. Il n'en récupérait qu'un seul morceau (les zones d'imagerie). Ton custom_dem, lui, était bien écrit dans le fichier, mais jamais rechargé — d'où ton obligation de passer par « Appliquer » pour le pousser en mémoire.

Le correctif : la tuile se charge maintenant directement depuis son fichier .cfg avant chaque étape. Le fichier de config tuile fait donc foi, exactement comme tu le décrivais. Le provider et le zoomlevel restent, eux, pilotés par la fenêtre principale (choix de session).

Concrètement pour toi : plus de routine « Appliquer / Fermer / Charger / Appliquer ». Tu crées ton custom_dem, tu l'écris dans la config tuile, et il est pris en compte au build même sans rouvrir la fenêtre Config.

À noter : comme le fichier tuile fait foi, il vaut mieux y écrire tes réglages (via l'outil ou « Écrire cfg tuile ») plutôt que de te fier au seul « Appliquer », qui règle les valeurs par défaut globales.

Testé sur +46-003 : le relief perso est bien pris en compte au Step 1 sans manipulation, et le mesh est propre.
?

[domisilasol]

Salut Ypsos,

merci pour ta mise à jour.

Le custom_dem est bien pris en compte lors du Step1.

Je note toutefois que le fichier Config Tuile n'est pas mis à jour et enregistré avec tous les réglages.
-> donc les données utilisées sont en mémoire pour les phases suivantes de la création tuile
-> y a-t-il un risque que la configuration mémoire évolue au cours des phases de la création tuile ?

En partant de zéro :
- créer un custom_dem pour cette tuile -> le custom_dem est enregistré dans le fichier Config Tuile (Config Tuile à 1 ligne)
- je lance le Step1 -> tout se passe bien
- le fichier Config Tuile est resté inchangé (1 ligne)
-> le fichier Config Tuile devrait avoir été complété avec les réglages par défaut et enregistré dans le dossier tuile.
-> ce fichier de config tuile reste la référence pour tout le process de construction de la tuile.
-> on est ainsi plus sécurisé. La seule façon que ce fichier soit modifié est que l'utilisateur enregistre une nouvelle Configuration Tuile (volontairement, en toute conscience)

A+

[Ypsos]

Salut Ypsos,

merci pour ta mise à jour.

Le custom_dem est bien pris en compte lors du Step1.

Je note toutefois que le fichier Config Tuile n'est pas mis à jour et enregistré avec tous les réglages.
-> donc les données utilisées sont en mémoire pour les phases suivantes de la création tuile
-> y a-t-il un risque que la configuration mémoire évolue au cours des phases de la création tuile ?

En partant de zéro :
- créer un custom_dem pour cette tuile -> le custom_dem est enregistré dans le fichier Config Tuile (Config Tuile à 1 ligne)
- je lance le Step1 -> tout se passe bien
- le fichier Config Tuile est resté inchangé (1 ligne)
-> le fichier Config Tuile devrait avoir été complété avec les réglages par défaut et enregistré dans le dossier tuile.
-> ce fichier de config tuile reste la référence pour tout le process de construction de la tuile.
-> on est ainsi plus sécurisé. La seule façon que ce fichier soit modifié est que l'utilisateur enregistre une nouvelle Configuration Tuile (volontairement, en toute conscience)

A+

Salut domisilasol,

Tes remarques étaient justes, tout est intégré.

1. custom_dem au Step 1 : la tuile se charge maintenant directement depuis son fichier .cfg avant chaque étape — plus besoin de la routine « Appliquer ».

2. Fichier config tuile figé : au début du Step 1, si le .cfg tuile est absent ou incomplet, il est écrit complet avec tous les réglages effectifs et sert de référence à toute la construction. Un .cfg déjà complet n'est jamais touché automatiquement — la seule façon de le modifier reste une action volontaire de ta part (« Écrire cfg tuile »). Une sauvegarde .bak est faite quand un fichier existant est remplacé.

Résultat : le fichier config tuile est bien le référentiel unique et sécurisé du process, comme tu le proposais. Plus de config « en mémoire » qui pourrait dériver entre les phases.

Testé de bout en bout sur +46-003 : relief perso pris en compte sans manipulation, .cfg complet généré, mesh propre.
?

La mise a jour sera publiées en fin de AM sur Github

[Ypsos]

Domisilasol tu as vue mon message en privé?