Annonce

**robster** · 16 septembre 2026, 22h07

Bonsoir,
Merci pour votre travail .

**jasum** · 17 septembre 2026, 13h08

Salut

ORTHO4XP V3.5 — Première version stable etant publié, j'ai voulu tester l'installateur "automatique" sous Linux sur une version ubuntu-LTS "out the box" mise à jour,

La version courante actuelle est la 26.04, cependant il n'y a pas de paquetage python3.12 disponible, il faut installer python3.12 depuis le source, mais ORTHO4XP_V3 fonctionne bien sous un "venv python3.14".

J'ai donc testé l'installateur sur la 24.04.4 LTS qui est La version de référence actuelle pour X-Plane-12 sous linux.

Il y a eu quelques problèmes:?
erreur de texte dans LANCEUR_INSTALL_LINUX.sh à la ligne 5:
>>>>
(ou chmod +x LANCER_ORTHO4XP.sh && ./LANCER_ORTHO4XP.sh)

elle devrait être:

(ou chmod +x LANCEUR_INSTALL_LINUX.sh && ./LANCEUR_INSTALL_LINUX.sh)
>>>>

La présence de python3.12 installé par défaut dans Ubuntu, n'est pas suffisante, il a fallu installer:

sudo apt install python3-tk python3-pip python3.12-venv

J'ai donc consulté le fichier INSTALL_PREREQUIS.py:

Il y a incohérence à la ligne 526 et suivantes:

la présence de python3.12 échappe les commandes suivantes pourtant indispensables:

sudo apt-get install python3.12-venv python3-pip python3-tk

**Ypsos** · 17 septembre 2026, 22h21

Envoyé par jasum Voir le message

Salut

ORTHO4XP V3.5 — Première version stable etant publié, j'ai voulu tester l'installateur "automatique" sous Linux sur une version ubuntu-LTS "out the box" mise à jour,

La version courante actuelle est la 26.04, cependant il n'y a pas de paquetage python3.12 disponible, il faut installer python3.12 depuis le source, mais ORTHO4XP_V3 fonctionne bien sous un "venv python3.14".

J'ai donc testé l'installateur sur la 24.04.4 LTS qui est La version de référence actuelle pour X-Plane-12 sous linux.

Il y a eu quelques problèmes:?
erreur de texte dans LANCEUR_INSTALL_LINUX.sh à la ligne 5:
>>>>
(ou chmod +x LANCER_ORTHO4XP.sh && ./LANCER_ORTHO4XP.sh)

elle devrait être:

(ou chmod +x LANCEUR_INSTALL_LINUX.sh && ./LANCEUR_INSTALL_LINUX.sh)
>>>>

La présence de python3.12 installé par défaut dans Ubuntu, n'est pas suffisante, il a fallu installer:

sudo apt install python3-tk python3-pip python3.12-venv

J'ai donc consulté le fichier INSTALL_PREREQUIS.py:

Il y a incohérence à la ligne 526 et suivantes:

la présence de python3.12 échappe les commandes suivantes pourtant indispensables:

sudo apt-get install python3.12-venv python3-pip python3-tk

Ortho4XP V3 — mise à jour interface & installateur Linux

Merci Jasum pour les retours détaillés. Les points remontés sont corrigés dans la prochaine mise à jour :

Affichage sur écrans haute résolution / mise à l'échelle Windows : les fenêtres (principale, configuration, niveaux de zoom personnalisés, bibliothèque de tuiles) s'adaptent désormais automatiquement à la taille de l'écran. Plus besoin de maximiser au lancement, et les boutons du bas restent toujours visibles.
Aide des raccourcis (fenêtre Custom ZL) : rendue plus lisible et complétée.
Installateur Linux : corrigé pour Ubuntu 24.04 LTS (installation des paquets système nécessaires même lorsque Python 3.12 est déjà présent), plus une coquille dans le lanceur.

Ces corrections sont universelles (tout écran, tout système). N'hésitez pas à signaler tout point qui resterait imparfait sur votre configuration — vos retours sont précieux.

Merci encore ! ?
?

**Ypsos** · 17 septembre 2026, 22h51

Petit ajout de confort:

Bibliothèque de tuiles

Gestion des tuiles Ortho4XP déjà installées dans X-Plane : liste + filtre, activation/désactivation instantanée, suppression sécurisée (lien symbolique ou dossier), vidage de cache (OSM_data / Masks / Patches). Aucune écriture sans sauvegarde .bak, chemin de scenery_packs.ini mémorisé automatiquement

?

**Ypsos** · 18 septembre 2026, 08h07

?? Ortho4XP V3 — Nouveautés ergonomie (V3.6)

Cette mise à jour rend Ortho4XP plus simple à prendre en main, sans rien retirer aux experts :

? Simulateur visuel des réglages — chaque réglage est illustré par une petite image qui montre son effet, avec une explication en clair (FR/EN). Plus besoin d'être technicien pour comprendre les curseurs.
Profils en 1 clic — ? Rapide / ? Équilibré / ? Qualité max — règlent d'un coup le compromis vitesse / qualité / espace disque. Tous les réglages détaillés restent accessibles.
? Suivi de build en direct — pendant la construction, la console affiche le temps restant estimé et la vitesse.
? Estimation avant build — l'espace disque et le temps nécessaires sont estimés avant de lancer, avec un garde-fou si la place manque.
? Bibliothèque de tuiles — activer / retirer de X-Plane, supprimer, vider le cache d'une tuile, en toute sécurité (confirmation, jamais en bloc).
? Confort d'affichage — les fenêtres s'adaptent aux petits écrans (ascenseurs, tailles plafonnées).

Le tout bilingue FR/EN et compatible Windows / macOS (Intel + Apple Silicon) / Linux. Vos retours sont les bienvenus ??

?

?

**domisilasol** · 18 septembre 2026, 12h15

Salut Ypsos,

j'ai testé cette fois-ci "Altimétrie DEM" / "Préparer les données"

Fichiers sources pris sur RGE ALTI :
A) Corse D02A, LAMB93 (donc à priori EPSG2154)
B) Réunion D974, UTM40S (donc à priori EPSG32740)
C) Guadeloupe Saint Barthe, UTM20N (donc à priori EPSG32620)

Voir ci-joint les rapports détaillés.

En conclusion :

- si la source est un fichier .tif avec le CRS défini dans les EXIFs, Ortho4XP_V3 fait bien la conversion.

- si la source est un fichier .asc (dont le CRS n'est pas défini), le CRS de repli utilisé dans O4_Altimétrie_Utils.py ne fonctionne pas.
-> il semble que la conversion coordonnées mètre/degré n'est pas correctement gérée tout au long du processus de conversion.
-> il en résulte un fichier .tif noir (décalage de la terre par rapport à la fenêtre de l'image).

Proposition d'amélioration si ce problème peut être résolu :

-> il faudrait lors de la conversion de fichiers .ASC demander à l'utilisateur de définir le code EPSG à utiliser.
-> si l'utilisateur ne sait pas ou ne définit rien, on reste sur la valeur de repli par défaut EPSG:2154

A+
domisilasol

Fichiers attachés

**Ypsos** · 18 septembre 2026, 16h58

Envoyé par domisilasol Voir le message

Salut Ypsos,

j'ai testé cette fois-ci "Altimétrie DEM" / "Préparer les données"

Fichiers sources pris sur RGE ALTI :
A) Corse D02A, LAMB93 (donc à priori EPSG2154)
B) Réunion D974, UTM40S (donc à priori EPSG32740)
C) Guadeloupe Saint Barthe, UTM20N (donc à priori EPSG32620)

Voir ci-joint les rapports détaillés.

En conclusion :

- si la source est un fichier .tif avec le CRS défini dans les EXIFs, Ortho4XP_V3 fait bien la conversion.

- si la source est un fichier .asc (dont le CRS n'est pas défini), le CRS de repli utilisé dans O4_Altimétrie_Utils.py ne fonctionne pas.
-> il semble que la conversion coordonnées mètre/degré n'est pas correctement gérée tout au long du processus de conversion.
-> il en résulte un fichier .tif noir (décalage de la terre par rapport à la fenêtre de l'image).

Proposition d'amélioration si ce problème peut être résolu :

-> il faudrait lors de la conversion de fichiers .ASC demander à l'utilisateur de définir le code EPSG à utiliser.
-> si l'utilisateur ne sait pas ou ne définit rien, on reste sur la valeur de repli par défaut EPSG:2154

A+
domisilasol

Bonjour domisilasol,

Merci pour ce test très clair sur RGE ALTI (Corse, Réunion, Guadeloupe/St-Barth). Le diagnostic était juste : un fichier .asc ne contient aucune information de projection, et jusqu'ici l'outil supposait toujours du Lambert-93 (métropole). Pour la Réunion et la Guadeloupe (projections différentes), la terre se retrouvait décalée ? le .tif noir.

Ce qui change. Quand « Préparer les données » rencontre des .asc sans projection, une petite fenêtre te demande maintenant le code EPSG de tes données source. La fenêtre indique aussi où le trouver : sur la page de téléchargement de tes données (RGE ALTI, etc.), ou en cherchant le nom de ta zone sur epsg.io.

Quelques exemples : 2154 (métropole), 32740 (Réunion), 32620 (Guadeloupe/St-Barth), 32621 (Martinique), 2972 (Guyane). Mais tu peux entrer n'importe quel code — ça marche partout dans le monde. Si tu laisses vide ? Lambert-93 (2154) par défaut, comme avant. Les fichiers .tif qui portent déjà leur projection ne sont pas concernés.

À vérifier :

Réunion ? entre 32740 ; Guadeloupe/St-Barth ? 32620 : le résultat doit être bien placé (plus de noir).
Corse ? entre 2154 (sa vraie projection).

Une question sur la Corse. Si la Corse te donne encore un résultat noir même avec 2154, ce serait un souci différent du code EPSG. Dans ce cas seulement, peux-tu m'envoyer les premières lignes d'un de tes .asc Corse — c'est-à-dire ncols, nrows, xllcorner, yllcorner, cellsize, NODATA_value ? Ça me permettra de vérifier la conversion. Mais si la Corse passe avec 2154, il n'y a rien de plus à faire.

Encore merci — ce test sur plusieurs territoires fait vraiment avancer l'outil. ?
?

**domisilasol** · 18 septembre 2026, 19h52

Salut,

je viens de tester la dernière version.

1°) Impeccable pour les dimensions de fenêtre sur ma config -> problème réglé

2°) Pour la préparation des données Altimétrie :

- la proposition de définir le code EPSG à utiliser dans une fenêtre avant la conversion -> c'est très bien

- par contre la conversion produit toujours des fichiers noirs -> il doit y avoir un soucis dans le code qui utilise la valeur de repli !

Ci-dessous les en-têtes du premier fichier .ASC :

(Fichiers sources pris sur RGE ALTI )

A) Corse D02A, LAMB93 (donc à priori EPSG2154) :

- RGEALTI_MNT_1M_ASC_LAMB93_IGN78C_D02A_20240326
ncols 1000
nrows 1000
xllcorner 1155999.500000000000
yllcorner 6156000.500000000000
cellsize 1.000000000000
NODATA_value -99999.00

- RGEALTI_MNT_5M_ASC_LAMB93_IGN78C_D02A
ncols 1000
nrows 1000
xllcorner 1154997.500000000000
yllcorner 6130002.500000000000
cellsize 5.000000000000
NODATA_value -99999.00

B) Réunion D974, UTM40S (donc à priori EPSG32740) :

- RGEALTI_MNT_1M_ASC_RGR92UTM40S_REUN89_D974_2023091 4
ncols 1000
nrows 1000
xllcorner 313999.500000000000
yllcorner 7671000.500000000000
cellsize 1.000000000000
NODATA_value -99999.00

- RGEALTI_MNT_5M_ASC_RGR92UTM40S_REUN89_D974
ncols 1000
nrows 1000
xllcorner 309997.500000000000
yllcorner 7670002.500000000000
cellsize 5.000000000000
NODATA_value -99999.00

C) Guadeloupe Saint Barthe, UTM20N (donc à priori EPSG32620) :

- RGEALTI_MNT_1M_ASC_RGAF09UTM20_GUAD88SB_D977_20210 119
ncols 1000
nrows 1000
xllcorner 504999.500000000000
yllcorner 1984000.500000000000
cellsize 1.000000000000
NODATA_value -99999.00

- RGEALTI_MNT_5M_ASC_WGS84UTM20_GUAD88SB_D977
ncols 1000
nrows 1000
xllcorner 504997.500000000000
yllcorner 1980002.500000000000
cellsize 5.000000000000
NODATA_value -99999.00

A+
?

**Ypsos** · 18 septembre 2026, 20h10

Envoyé par domisilasol Voir le message

Salut,

je viens de tester la dernière version.

1°) Impeccable pour les dimensions de fenêtre sur ma config -> problème réglé

2°) Pour la préparation des données Altimétrie :

- la proposition de définir le code EPSG à utiliser dans une fenêtre avant la conversion -> c'est très bien

- par contre la conversion produit toujours des fichiers noirs -> il doit y avoir un soucis dans le code qui utilise la valeur de repli !

Ci-dessous les en-têtes du premier fichier .ASC :

(Fichiers sources pris sur RGE ALTI )

A) Corse D02A, LAMB93 (donc à priori EPSG2154) :

- RGEALTI_MNT_1M_ASC_LAMB93_IGN78C_D02A_20240326
ncols 1000
nrows 1000
xllcorner 1155999.500000000000
yllcorner 6156000.500000000000
cellsize 1.000000000000
NODATA_value -99999.00

- RGEALTI_MNT_5M_ASC_LAMB93_IGN78C_D02A
ncols 1000
nrows 1000
xllcorner 1154997.500000000000
yllcorner 6130002.500000000000
cellsize 5.000000000000
NODATA_value -99999.00

B) Réunion D974, UTM40S (donc à priori EPSG32740) :

- RGEALTI_MNT_1M_ASC_RGR92UTM40S_REUN89_D974_2023091 4
ncols 1000
nrows 1000
xllcorner 313999.500000000000
yllcorner 7671000.500000000000
cellsize 1.000000000000
NODATA_value -99999.00

- RGEALTI_MNT_5M_ASC_RGR92UTM40S_REUN89_D974
ncols 1000
nrows 1000
xllcorner 309997.500000000000
yllcorner 7670002.500000000000
cellsize 5.000000000000
NODATA_value -99999.00

C) Guadeloupe Saint Barthe, UTM20N (donc à priori EPSG32620) :

- RGEALTI_MNT_1M_ASC_RGAF09UTM20_GUAD88SB_D977_20210 119
ncols 1000
nrows 1000
xllcorner 504999.500000000000
yllcorner 1984000.500000000000
cellsize 1.000000000000
NODATA_value -99999.00

- RGEALTI_MNT_5M_ASC_WGS84UTM20_GUAD88SB_D977
ncols 1000
nrows 1000
xllcorner 504997.500000000000
yllcorner 1980002.500000000000
cellsize 5.000000000000
NODATA_value -99999.00

A+
?

Attention en 1 m cela na jamais fonctionné c'est pourquoi dans notre groupe le plus fidèle en détail de niveau acceptée est en 4m. Neanmoins je vais soumettre à claude ton résultat .

Attention avec tout ce que je lui ai fais fare , je crainds que mon quota de la semaine est usé et je vais être bloqué jusqu'à mardi prochain 21h00.
Si cela m'arrive il faudra être patient.

(ps il travaille encore sur des travaux que je lui ai demandé et j'espère qu'il arrive à me livrer les fichiers modifié et codés avant mon blocage)

**Ypsos** · 18 septembre 2026, 20h34

Bonjour à tous,

Une nouvelle mise à jour d'**ORTHO4XP V3** est disponible : la **version 3.6**. Elle est entièrement tournée vers le confort d'utilisation et la sécurité des builds. Comme toujours, **tout est 100 % additif** : le moteur (mer, mesh, masques, DSF) n'est pas touché, et si vous n'utilisez pas une option, le comportement reste identique à avant.

## ? Nouveautés

- **? Garde-fou « place disque » avant chaque build.** Ortho4XP estime l'espace nécessaire avant de démarrer et refuse de lancer un build qui manquerait de place, avec un message clair « il manque X Go ». Il ne bloque jamais un build sain.
- **? Contrôle des chemins avant build (disque externe / serveur).** Avant chaque build, Ortho4XP vérifie que les chemins que vous avez déjà choisis (altimétrie `custom_dem`, bathymétrie, dossier de sortie) sont bien accessibles. Si un disque externe ou un serveur n'est pas branché, le build est refusé avec un message clair qui nomme le chemin manquant ? **fini les tuiles plates à altitude zéro** à cause d'un SSD oublié.
- **?? Suivi de build détaillé.** Pendant la construction, une ligne s'affiche régulièrement en console avec le **temps restant estimé et la vitesse**.
- **?? Réglages en langage clair + 3 profils en 1 clic.** Les textes d'aide ont été réécrits sans jargon (FR + EN), les onglets défilent sur les petits écrans, et trois profils ? **Rapide** / ? **Équilibré** / ? **Qualité max** remplissent les réglages d'un seul clic. C'est non destructif : rien n'est enregistré tant que vous ne cliquez pas « Écrire cfg », et tous les réglages experts restent accessibles.
- **?? Carte ? coordonnées.** Un double-clic sur une tuile de la carte du monde (?) remplit automatiquement Latitude / Longitude ; la saisie manuelle reste bien sûr possible.
- **?? Bibliothèque de tuiles.** Deux listes côte à côte — **Activées** et **Désactivées** — pour voir d'un coup d'œil l'état de vos sceneries `zOrtho4XP_` et savoir lesquelles réactiver. Boutons **Activer** / **Désactiver**, plus **Supprimer** (sans danger pour les liens symboliques) et **Vider le cache**, le tout depuis l'interface, sans jamais éditer `scenery_packs.ini` à la main. Chaque écriture est précédée d'une sauvegarde `.bak`.

## ?? Corrections (retours forum)

- **?? Affichage sur écrans Windows « scaled » (haute densité).** Les fenêtres sont plafonnées à la taille réelle de l'écran et les zones longues deviennent défilantes. Aucune régression sur grand écran. *(Merci domisilasol.)*
- **? Installateur Linux (Ubuntu 24.04).** Détection réelle des modules manquants (`ensurepip`, `tkinter`) avant installation, au lieu de les sauter quand Python est déjà présent.
- **?? Altimétrie — sources `.asc` sans projection.** À « Préparer les données », si un fichier n'a pas de système de coordonnées, Ortho4XP vous demande le **code EPSG** (universel, valable pour tous les pays) au lieu de forcer le Lambert-93. Cela corrige les `.tif` noirs hors métropole (Réunion, Guadeloupe, etc.).

## ? Téléchargement

Toujours sur le dépôt officiel : **https://github.com/Ypsos/ORTHO4XP_V3**
(et page X-Plane.org habituelle)?

?

**Ypsos** · 18 septembre 2026, 21h10

Domisilasol en privé je t'ai adressé un fichier Py de test et ce que demande Claude.

Je n 'arrive pas à reprosuire ton erreur ser la corse

**jasum** · 18 septembre 2026, 22h41

Envoyé par domisilasol Voir le message

Salut,

je viens de tester la dernière version.

1°) Impeccable pour les dimensions de fenêtre sur ma config -> problème réglé

2°) Pour la préparation des données Altimétrie :

- la proposition de définir le code EPSG à utiliser dans une fenêtre avant la conversion -> c'est très bien

- par contre la conversion produit toujours des fichiers noirs -> il doit y avoir un soucis dans le code qui utilise la valeur de repli !

Salut

Il est imperatif d'utiliser le système de référence de coordonnées des fichiers .asc il ne peut y avoir de valeur de repli.

Les fichiers de l'IGN (comme les GIS en général) ont toujours une information relativee à la projection dans leur nom: et il est alors facile de trouver la correspendance EPSG par exemple:

RGEALTI_MNT_1M_ASC_RGR92UTM40S_REUN89_D974_2023091 4
===================RGR92UTM40S==================== ==

RGR92 / UTM zone 40S >>> EPSG:2975

RGEALTI_MNT_1M_ASC_RGAF09UTM20_GUAD88SB_D977_20210 119
===================RGAF09UTM20==================== ====

RGAF09 / UTM zone 20N >>>EPSG:5490

RGEALTI_MNT_5M_ASC_WGS84UTM20_GUAD88SB_D977
===================WGS84UTM20===================== =====

WGS 84 / UTM zone 20N>>> EPSG:32620?

**Ypsos** · 19 septembre 2026, 06h35

Envoyé par jasum Voir le message

Salut

Il est imperatif d'utiliser le système de référence de coordonnées des fichiers .asc il ne peut y avoir de valeur de repli.

Les fichiers de l'IGN (comme les GIS en général) ont toujours une information relativee à la projection dans leur nom: et il est alors facile de trouver la correspendance EPSG par exemple:

RGEALTI_MNT_1M_ASC_RGR92UTM40S_REUN89_D974_2023091 4
===================RGR92UTM40S==================== ==

RGR92 / UTM zone 40S >>> EPSG:2975

RGEALTI_MNT_1M_ASC_RGAF09UTM20_GUAD88SB_D977_20210 119
===================RGAF09UTM20==================== ====

RGAF09 / UTM zone 20N >>>EPSG:5490

RGEALTI_MNT_5M_ASC_WGS84UTM20_GUAD88SB_D977
===================WGS84UTM20===================== =====

WGS 84 / UTM zone 20N>>> EPSG:32620?

Merci Jasum j'ai mis une portection en plus par Claude :

Ce que ça fait. Quand une source ne déclare aucun CRS ( le module déduit maintenant le bon EPSG à partir du nom du fichier — exactement la logique de jasum — au lieu d'appliquer un repli aveugle. La table est fondée sur les codes officiels IGN/EPSG :

RGR92UTM40S (Réunion) ? 2975
RGAF09UTM20 (Antilles) ? 5490
RGFG95UTM22 (Guyane) ? 2972
RGM04UTM38S (Mayotte) ? 4471
RGSPM06U21 (St-Pierre-et-Miquelon) ? 4467
LAMB93 (métropole) ? 2154
WGS84UTM<zone><N/S> ? règle EPSG universelle (326xx Nord / 327xx Sud), donc n'importe quelle zone, n'importe quel pays, sans liste codée en dur.

Si le nom ne permet aucune déduction fiable, aucun code n'est inventé : on garde le code que tu as tapé dans la fenêtre. Le choix retenu est écrit dans le log à chaque fichier, tu vois toujours quelle projection a été prise.

Portée / non-régression. Modification appliquée aux deux chemins concernés (« Préparer les données » et l'assembleur), plus le décodeur commun. Un fichier qui déclare déjà son CRS n'est pas touché (la déduction n'est même pas appelée). Le nom est lu sur le fichier d'origine, pas sur la copie temporaire assainie qui perd le jeton.
?

**Ypsos** · 19 septembre 2026, 07h49

? Altimétrie — le bug des .tif noirs est résolu (+ 2 correctifs)

Merci à domisilasol (rapport + diagnostic) et à jasum (piste EPSG) : on a corrigé trois choses dans O4_Altimetrie_Utils.py.

1. Les .tif noirs à la préparation (cause enfin trouvée).
Un .asc IGN ne déclare aucun CRS. Le module passait la source à la reprojection « en flux » (rasterio.band) — et dans ce cas, rasterio ignore le CRS qu'on lui donne ? toute la donnée valide était perdue ? .tif 100 % noir. Sous Windows ça passait quand même (limite système plus haute) mais sortait noir ; sous macOS ça plantait avant. Correctif : la source est maintenant lue en tableau (src.read), le CRS est respecté. Vérifié en réel (Corse : relief correct, ?0,5 à 72 m).

2. EPSG déduit automatiquement du nom du fichier (idée de jasum).
Plus de repli aveugle : LAMB93 ? 2154, RGR92UTM40S (Réunion) ? 2975, RGAF09UTM20 (Antilles) ? 5490, RGFG95UTM22(Guyane) ? 2972, WGS84UTMxx ? 326/327xx… Si le nom ne dit rien, le code que vous saisissez reste le repli.

3. Départements entiers : plus de « Too many open files ».
La fusion se fait désormais par paquets — un département de plusieurs milliers de dalles passe sans erreur.
?
?

Annonce

ORTHO4XP V3.5 — Première version stable

ORTHO4XP V3.5 — Première version stable

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire