Ortho4XP: relief sur le Méridien de Greenwich à Tarbes LFBT

[jojo64]

Les indications qui auraient pu mettre sur la voie :

création de la +43-001 : Step 1 dit LFBT 1 runway
création de la +43+000 : Step 1 dit LFBT boundary
-> bien que la piste déborde sur les deux tuiles, elle n'est prise en compte que pour la 1ère.

Explications :
La personne qui a encodé dans OSM a mis à la fois le bord de la piste et le centre de la piste (rien d'anormal et très courant).
Seulement son bord de piste déborde pas mal sur les taxiways avec des espèces de bras de part et d'autre.
Du coup Ortho4XP repère que la piste n'est pas suffisamment rectangulaire et utilise un rectangle générique
basé sur la ligne du centre de piste (rien d'anormal non plus).
Problème : la ligne de centre de piste est entièrement contenue dans la +43-001, elle n'est donc pas vue dans la +43+000 (et donc comme il n'a ni un polygone de bord de piste suffisamment rectangulaire, ni une ligne centrale, il ne fait pas d'auto-patch sur la +43+000, seulement un lissage sur toute la surface de l'aéroport.

Ok ok, ceci explique cela!
J'avais bien remarqué qu'il n'y avait pas le même traitement en exportant le relief en obj wave. Je comprend le pourquoi maintenant.
Il y a de grande chance que ce soit moi qui ai encodé ça dans OSM (EDIT: en fait après vérification dans OSM, non ce n'est pas moi qui ai fait ça comme ça!!), à la base, l'encodage de l'aéroport était une vrai pataterie, sans compté que les éléments étaient décalés. Décidément, on en apprend tous les jours!
Je vais suivre tes recommandations et voir ce que j'obtiens!
Merci beaucoup Oscar!

Autre chose à laquelle faire attention : pour un aéroport qui déborde de part et d'autre de la tuile, pour que le lissage ne donne pas des résultats différents de part et d'autre il faut que les données d'élévation "débordent" de la tuile (d'au moins autant que apt_smoothing_pix). C'est fait automatiquement avec les données viewfinderpanorama par défaut (elles sont recollées entre elles avant traitement), mais si tu utilises des données custom qui ne débordent pas (par exemple Sony) tu risques de faire face à des problèmes.

Je vois aussi.
Du coup, j'aime bien les données de Sony qui sont beaucoup plus précises et offrent un superbe relief.
Pour contourner le problème que tu cites, serai t'il possible d'utiliser la fonction "iterate"?
Par exemple, je fait la tuile 43-001, pour que les données de cette dernière débordent (sur la 43+000), j'utilise "iterate" avec les données alti de la 43+000. Tu crois que ça fonctionnerai?

[jojo64]

Et bien et bien, je dit hip hip hip houra pour Oscar qui a trouvé la solution!
Ta première méthode fonctionne, tous les taxi sont maintenant praticables sans la moindre secousse.
Reste un petit défaut dans la jonction des images de la piste (par défaut) et celle du .pol du tarmac, mais pas de quoi casser trois pattes à un canard, pour moi ça fait parfaitement l'affaire, du moment où au roulage il n'y a pas de bosse!


Encore merci à tous!

Il me reste encore à comprendre pourquoi je n'arrive pas à faire des patch (que ce soit les .obj de Jasum ou mes patch à moi) ici, mais je verrai ça bien plus tard, j'ai encore du boulot sur la planche!

[Oscar Pilote]

Reste un petit défaut dans la jonction des images de la piste (par défaut) et celle du .pol du tarmac

Ceci est indépendant de Ortho4XP (sinon ce serait raccord ), c'est exactement pareil avec le Global Scenery. C'est X-Plane qui trace les pistes et Cie, et son unité de précision dans le placement des draped polygons est de l'ordre d'une vingtaine de centimètres.

Pour ta question sur les fichiers d'élévation. Le mieux est de t'en fabriquer des qui débordent à partir de ceux de Sony (avec par exemple gdalwarp, je suis sûr que Jasum va pouvoir t'aider!).