Librairie des fichiers de configuration Ortho4XP

[nicowork]

Bonjour à tous,

Je lance l'idée un peu comme cela, mais que pensez-vous de créer une librairie des fichiers de configuration Ortho4XP ?

Cela permettrais à tout le monde de créer des tuiles de qualitées tout en générant la tuille au ZL souhaité. Cette librairie permettrais de centraliser les efforts de chacun et ceux qui "realflight" pourrais aussi nous dire quel est le niveau de réalisme par rapport à la réalité du terrain.

On pourrais imaginer un système similaire à Zonephoto sauf que l'on ne télécharge pas de tuile complète mais juste une fichier archive avec le fichier de configuration, les fichiers de corrections d'AD et de données additionnelles.

Qu'en pensez-vous ?

Nicolas

[milan]

Hum...
Tu pourrais préciser ?
Si je comprends bien, selon la tuile et suivant l'expérience de chacun, cette bibli donnerait des info sur le meilleur zoom, le type de source (BI, Go2 etc.) les paramètres à modifier selon que l'AD est proche de sources d'eau, en montagne (tolérance de courbes) et toutes ces sortes de choses ?

Si c'est ce dont il s'agit je suis tout-à-fait d'accord.

[temium62]

Ah pour sûr ! Pour 1 bonne idée C est 1 idée qui est bonne !!!!

[jojo64]

Dans ce cas, la difficulté sera quand même de rendre toutes les tuiles compatible les une avec les autres... Et là c'est pas gagné d'avance...
Sinon l'idée est super bonne! Déjà, on pourrait commencer par les patchs, pour ce qui en ont déjà créés pour des aéroport, ou autre...

[nicowork]

Bonjour à tous,

Milan: Oui c'est tout à fait cela.

Voici par exemple une fiche de tuile que l'on pourrait envisager:

Modèle de génération: (une lettre qui défini le règles utilisées pour la génération de la tuile afin de connaitre la compatibilité, toutes les tuiles du modèle A sont parfaitement compatible entre elle, mais une tuile de modèle A ne le sera pas compatible avec une tuile de modèle B)
Nom de la tuile: (la ville comme sur ZoomPhoto)
Coordonées de la tuile:
AD OACI disponible sur la tuile:
Zoom validé (ZL16, ZL17, ZL18)
Source utilisé: (BI ou Goo2 ou IGN)
Date de la prise de photo de la source: (attention BI semble proposer des prises de vue très anciennes comparé à Google)
Anomalie connus sur les sources: (exemple: Photos très sombre sur BI, nuages visible sur Goo2,...)
Configuration AD particulière:
Configuration eau particulière:
Configuration topographie particulière:
Commentaire réalisme:
Auteur(s):
Testeur(s):
Note sur 10 qualité de la tuile:
Note sur 10 réalisme:
Date à laquel la tuile a été généré depuis la source avec succès:

Pour faciliter l'utilisation de Ortho4XP, il y aura possibilité de télécharger le fichier archive contenant tout les fichiers à injecter dans Ortho4XP pour obtenir le *même* résultat que celui de l'auteur hors imagerie (BI, Goo2, IGN,... peuvent changer les photos entre temps).

[milan]

Je trouve cela excellent
Quelques questions et considérations :

Qu'entendez-vous (toi et jojo64) par compatibilité (dans le rendu d'une tuile par rapport à l'autre ?)
AD disponibles est un peu superflu (on les sait dès qu'on a les coordonnées lat/lon de la tuile) mais pourquoi pas.
Zoom validé : j'ai l'habitude de faire des tuiles en z16 avec des portions en z17. Comment valider et quel zoom (la portion de tuile dans un zoom différent ne va pas être facile à décrire)
Date de prise de vue de la photo : où voit-on cela (j'avoue ne jamais m'être penché sur ce genre d'info mais ça me semble une bonne info pour contrôler des màj)

-------------------
Voilà.
Cela dit il va falloir créer un club de tuileux, non ?

[jojo64]

Je trouve cela excellent
Quelques questions et considérations :
Qu'entendez-vous (toi et jojo64) par compatibilité (dans le rendu d'une tuile par rapport à l'autre ?)

Par exemple, il est nécessaire d'avoir un relief qui correspond entre chaque tuiles. Au pérou par exemple, j'avais remarquer que lorsque que l'on utilisait un paramètre de mesh différent entre 2 tuiles, il arrivait des fois qu'il se forme de drôles de bosses à la jonctions des 2 tuiles. En France, plusieurs aéroport sont à la jonction de 2 tuiles, t'imagine facilement le problème si il y des bosses sur la piste, au niveau de la jonction.

Autre exemple, si d'un coté tu as une tuile "Bing" et de l'autre une tuile "Google", tu risque d'avoir une grosse démarcation à la jonction de 2 tuiles, ça ne pose pas de problèmes en soit, mais c'est très moche. Pareil pour le dégradé au niveau des bord de cotes. Pareil pour les "sea equivalent", il faut qu'il soit des deux cotés pareil... Et je te parle aussi des correction de couleurs et contraste, des zones Z17 ou Z18 délimitées à la main, qui pareil si elles sont à la jonction de 2 tuiles, doivent bien être coordonnées...

Bref, l'idée c'est que si chacun fait sa tuiles dans son coin, s'en prendre en compte la tuiles d'à coté, il risque d'y avoir de drôles de résultat.

Sinon encore une fois, l'idée est bonne, faudrait juste faire attention à ce genre de chose.

[milan]

Merci pour ces éclaircissements

En somme comme l'utilisation d'une source (BI, GO etc) pour une tuile implique la même source pour les tuiles adjacentes, il faut donc déterminer la meilleure source pour un pays voire un continent (ou partie de continent) pour éviter les jonctions discordantes
Reste alors à tester les tolérance de courbe entre une tuile de bord de mer et une tuile montagneuse (et il y a des pays où la tuile de bord de mer et aussi une tuile montagnueuse, spécialement sur la côte ouest de l'amérique latine)

Après il y a certes les couleurs et le contraste. Mais ma discrhomatie (un truc à la cône) ne me permet pas d'influer sur le rendu colorimétrique.

[jojo64]

Déjà, si comme le propose NicoWork, on mettait à disposition ne serai-ce que les informations "écrites" des paramètres idéals que l'on utilise chacun pour la tuiles à coté de chez soit, ce serai un bon début qui permettrait d'y voir plus claire.

A partir de là, il serai effectivement possible de coordonner l'ensemble. En théorie, car pour une tuiles créée, il y a 8 tuiles autours, chacune ayant aussi 8 tuiles autour... Tu vois là la complexité de la chose...

Par contre, je ne sait pas si certains d'entre vous utilise la fonction "Patch.osm" (encore un coup génie d'Oscar!!) qui permet d'avoir les pistes arrondies (et non plates comme un lac de sel) comme dans la réalité. Partager ces fichiers serai aussi une bonne idée! Mais je ne crois pas que beaucoup d'entre vous utilise cette fonction...

[nicowork]

Un exemple pour illustrer mes propos sur la prise de vue avec l'AD de Besançon La Veze (LFQM).
Sur cette AD, la route D246 a été déplacée en 2012 car elle était trop proche du seuil de piste.

http://maps.google.com/maps?ll=47.205896,6.080632&spn=0.03,0.03&t=k&q=47.205896,6.080632&hl=fr

Prise de vue 2016 (l'année correspond au copyright de CNES/Spot Image/DigitalGlobe).
L'emplacement de la D246 est correct, c'est à dire éloigné du seuil de piste.

http://www.bing.com/maps/default.aspx?v=2&cp=47.205896~6.080632&style=a&lvl=15&sp=Point.47.205896_6.080632_airport___

Prise de vue dont l'année est inconnu mais qui est très ancienne vue qu'elle a été faite avant le déplacement de la D246 (qui pour rappel a eu lieu en 2012).
J'en déduit que la prise de vue de Bing date de 2011 car cela correspond aux travaux sur la piste de LFQM.

Si la tuile est multi-ZL, alors il faudra avoir une image de prévisualisation avec des couleurs differents en fonction du ZL sur la tuile afin de pouvoir localiser les différents ZL.

Personnellement j'ai toujours trouvé les images Google et IGN plus a jour que celle de Bing.

Si les photos ne sont pas extractibles des tuiles une fois générée, peut-être que l'IGN serait d'accord pour une diffusion des tuilles réalisées sous une license spécifique (ex: les tuiles ne doivent pas pouvoir être désassemblé et utilisé uniquement pour les scènes de X-Plane à titre gratuit,....)