Page 3 sur 4 PremièrePremière 1234 DernièreDernière
Affichage des résultats 21 à 30 sur 34

Discussion: Ortho4XP : lac ignoré !

      
   
  1. #21
    Utilisateur enregistré Avatar de Glah_Salamanthe
    Date d'inscription
    décembre 2005
    Localisation
    LSGL environs
    Messages
    10 249
    Total Downloaded
    0
    Citation Envoyé par jef32 Voir le message
    Ton nouveau fichier water_osm.bz2 il est où ? C'est la miniature jointe ? C'est un .jpg, non un .bz2, donc désolé je n'ai pas trouvé. J'ai juste fait comme tu le préconisais en effaçant le water_osm.bz2 après le step 1 et comme je le disais, ça semble avoir bien marché, mais sans ton fichier water_osm.bz2 dont tu parles, remplaçant celui qu'on vient d'effacer avant de passer au step 2 d'ortho4x, j'ai peur d'avoir créé un bintz ailleurs sur la tuile. Car après vérif, il ne s'en est pas recréé un nouveau dans /chemin/Ortho4XP/OSM_data/+40+000/+43+001.
    Déjà indiqué plus haut (fin du post N° 13) :
    Enfin, pour la re-génération de ta tuile, dans le dossier Ortho4XP, en suivant les conseils de papet30 il faut :
    • Dans le dossier "OSM_data" détruire toutes les données OSM stockées afin d'obliger Ortho4XP à les régénérer . Pour ta tuile, c'est dans le dossier +40 +000 que tu vas trouver "+43+001"
    • Dans le dossier de ta tuile "zOrtho4XP_+43+001", détruire tous les "Data" de façon à obliger Ortho4XP à les reconstruire . Tu peux conserver les .dds du dossier textures (mais vider les png qui s'y trouvent) , tu gagneras en temps !
    Pour les obliger à se régénérer, dans le dossier Ortho4XP, il y a deux sortes de données à détruire :
    • Celles du dossier "OSM_data" (pour ma part, je les ai toutes détruites ):
    Cliquez sur l'image pour la voir en taille réelle

Nom : OSM Datas.jpg
Affichages : 48
Taille : 147,3 Ko
ID : 25447

    • Celles qui figurent dans le dossier de ta tuile :
    Cliquez sur l'image pour la voir en taille réelle

Nom : Dans le dossier de la Tuile.jpg
Affichages : 49
Taille : 40,5 Ko
ID : 25444


    Si tu conserves l'un ou l'autre, Ortho4XP ne va pas se casser les nénettes : il va utiliser l'une ou l'autre des données existantes .
    Conserve par contre le dossier "textures", dans lequel tu vas détruire les .png, pour les obliger à se régénérer. Les .dds étant là, Ortho4XP ne va pas s'amuser à les recharger, ça ira donc très vite
    Mac Pro 3Ghz 8 Core Intel Xeon E5 / 64Go DDR3 1866Mhz / 2x AMD FireProD700 6144Mo / SSD 1To + En Externe : SSD 2To + HD 5To Lacie Thunderbolt
    Samsung 49" 3840 x 1080 /
    Joystick Saitek X52 & Rudders
    MAC OS Mojave 10.14.6 / XPlane 11.53r1 (… XP à partir de XP 6 !)

    " Soyez vous même … les autres sont déjà pris ! "
    "… la fausseté des idées ne se règle pas par les interdictions mais s'asphyxie dans la liberté ! " Marc Bonnant

  2. #22
    Utilisateur enregistré
    Date d'inscription
    février 2003
    Localisation
    gers
    Messages
    277
    Total Downloaded
    0
    J'avais mal compris, je croyais que papet30 avait mis un lien pour télécharger son fichier.
    Suite à ce que j'ai fait, sans enlever tous les fichiers mais juste le fichier préconisé par papet30, avant que tu ne me répondes, ça semble fonctionner. J'ai fait une nav AR entre LFBR et St-Gaudens Montréjeau (nav prévue en vrai mardi prochain si météo favorable) et je n'ai pas remarqué de souci sur les plans d'eau. Le lac de Rieumes est enfin là, et les autres aussi. Si je constate un souci, je referai en effaçant TOUS les fichiers tel que tu le préconise.
    Un truc me parait cependant étrange: quand Ortho4x construit sa tuile, il charge des .jpg et non des .png ( ce qui peut poser un souci de transparence) avant de les convertir en .dds dans le répertoire textures de la tuile. Ce sont des jpg que je trouve dans orthophotos.
    CPU: I7-6700K 4Ghz, GC: nVidia GeForce Titan X Gigabytes 12Go VRAM, 32 Go DDR4, Motherboard: Gigabytes Z170X-Gaming 3. OS: W10-Famille, 3 HD Samsung SSD 850 Pro 1TB + 1 Samsung SSD EVO 500 Gb. Oculus Rift CV1

  3. #23
    Utilisateur enregistré Avatar de papet30
    Date d'inscription
    février 2016
    Localisation
    LFLP
    Âge
    77
    Messages
    634
    Total Downloaded
    0
    Citation Envoyé par jef32 Voir le message
    J'avais mal compris, je croyais que papet30 avait mis un lien pour télécharger son fichier.
    Suite à ce que j'ai fait, sans enlever tous les fichiers mais juste le fichier préconisé par papet30, avant que tu ne me répondes, ça semble fonctionner. J'ai fait une nav AR entre LFBR et St-Gaudens Montréjeau (nav prévue en vrai mardi prochain si météo favorable) et je n'ai pas remarqué de souci sur les plans d'eau. Le lac de Rieumes est enfin là, et les autres aussi. Si je constate un souci, je referai en effaçant TOUS les fichiers tel que tu le préconise.
    Un truc me parait cependant étrange: quand Ortho4x construit sa tuile, il charge des .jpg et non des .png ( ce qui peut poser un souci de transparence) avant de les convertir en .dds dans le répertoire textures de la tuile. Ce sont des jpg que je trouve dans orthophotos.
    bonsoir jef
    l'explication de Glah est très claire, il faut savoir que si on régénère une tuile déjà existante pour quelque raison que ce soit, Ortho4XP par programmation et optimisation cherche toujours à réutiliser les données existantes (jpeg's, dds, Osm_data...) donc si on modifie comme dans le cas qui nous préoccupe un paramètre dans openstreetmap, il faut avant de relancer Ortho4XP supprimer la ou les données existantes ( ici les fichiers osm.bz2 ) alors Ortho4XP ne trouvant ces fichiers il les reconstruira à partir des nouvelles données openstreetmap modifiées.
    J'espère que cela va d'aider.
    Bons vols
    Asus Z390-E , I7-9700K 32Gb (3200 Mz)- SSD 950Pro 256 Gb - SSHD 1Tb - 2 x HDD 3Tb - 6Tb HDD USB_3.1 - 4Tb HDD USB3.0 - Asus Strix 1070 (Driver 450.102.04)- ThrustMaster T.16000M + Rudder pedals
    Ubuntu 18.04.2 LTS 64bits
    X-Plane 11.36r2. 11.41r1 11.50r3 11.51r1 11.52
    Avions : A350_1.6.13, Cessna172 Airfoillabs, B737-800X, A319 TolissV1p5p1, A321 TolissV1.2neo, DA62, Pipistrel-Panthera, Legacy RG, Epic Victory, B17G, P-51, Phenom 300

  4. #24
    Utilisateur enregistré Avatar de Glah_Salamanthe
    Date d'inscription
    décembre 2005
    Localisation
    LSGL environs
    Messages
    10 249
    Total Downloaded
    0
    Citation Envoyé par jef32 Voir le message
    Un truc me parait cependant étrange: quand Ortho4x construit sa tuile, il charge des .jpg et non des .png ( ce qui peut poser un souci de transparence) avant de les convertir en .dds dans le répertoire textures de la tuile. Ce sont des jpg que je trouve dans orthophotos.
    Oui, et c'est normal.
    Le format .dds est un format particulier .
    Pour son travail, X-Plane va télécharger des fichiers .jpeg, fichiers qu'il va stocker dans le dossier "Orthophotos" . Ce dossier est un dossier de travail pour Ortho4XP, pour toi il ne te sert à rien .
    Ta tuile définitive et utilisable se trouve dans le dossier "Tiles"
    Le problème de transparence ne se pose pas : les .dds sont opaques et n'ont pas besoin de transparence . C'est le masque d'eau déposé dessus qui a lui besoin de transparence .
    Quand c'est nécessaire, sur la base de son masque .png Ortho4XP va poser de l'eau par dessus l'image qu'il a téléchargé et c'est là que la transparence intervient : dans la partie noire du masque, la structure "eau" est opaque : tu ne vois pas le fond du bassin . Plus tu t'approches de la rive, plus le masque devient gris . Cette progression de gris vers le blanc va permettre à la structure "eau" de devenir progressivement transparente afin de dévoiler le .dds caché dessous . Plus tu t'approcheras du bord, plus tu verras le .dds caché dessous et tu auras ainsi l'impression d'une transparence en eau peu profonde, apercevant les fonds sableux.


    A propos des .jpeg et des .dds …

    Si tu dois re-générer une tuile, tu peux optimiser ton travail et temps d'attente .

    Il est impératif dans un premier temps de détruire toutes les données qui vont permettre à Ortho4XP de calculer son travail . Si ces données sont là Ortho4XP va les réutiliser et donc reproduire son erreur .
    Tu peux par contre conserver les jpeg ou les .dds ou les deux !
    Si tu conserves les .dds , c'est là que tu vas gagner le plus de temps . Ce ne sont que des images, pas de risque qu'elles contienne des erreur . Ortho4XP va donc pouvoir les réutiliser telles qu'elles , mais il va recalculer tout ce qui va autour.
    Si tu conserves les jpeg : Ortho4XP n'aura plus à aller les télécharger, tu vas gagner sur ce temps , selon ta vitesse de connexion . Mais le temps de conversion en .dds sera lui nécessaire .
    Mac Pro 3Ghz 8 Core Intel Xeon E5 / 64Go DDR3 1866Mhz / 2x AMD FireProD700 6144Mo / SSD 1To + En Externe : SSD 2To + HD 5To Lacie Thunderbolt
    Samsung 49" 3840 x 1080 /
    Joystick Saitek X52 & Rudders
    MAC OS Mojave 10.14.6 / XPlane 11.53r1 (… XP à partir de XP 6 !)

    " Soyez vous même … les autres sont déjà pris ! "
    "… la fausseté des idées ne se règle pas par les interdictions mais s'asphyxie dans la liberté ! " Marc Bonnant

  5. #25
    Utilisateur enregistré
    Date d'inscription
    février 2003
    Localisation
    gers
    Messages
    277
    Total Downloaded
    0
    Ok merci de tous ces renseignements. Le but me semble atteint, le lac est un lac désormais, et tout semble Ok chez moi. Mais je garde ce topic sous le coude car entre toi et papet30, ce thread est une mine de renseignements.

    Merci à vous 2.

    Ce matin, je ré-édite ce message pour dire que j'ai fait l'essai comme vous le préconisez tous les 2: J'ai effacé TOUS les fichiers dans "chemin\ortho4x 1.30\OSM_data\+40+000\+43+001"
    Mais quand j'ai voulu effacer ceux de la tuile après le step 1, j'ai eu droit à:

    ERROR: Could not find G:/X-Plane 11/X-Plane 11/Custom Scenery\zOrtho4XP_+43+001\Data+43+001.node

    J'ai juste remis ceux de la tuile et j'ai continué.
    Je vais tester.

    Reprise du message:

    Alors testé et Ok. La seule différence, par rapport à avant (quand j'avais juste supprimé du +43+001_water.osm.bz2 avant le step 2), je ne l'ai pas visuellement vue dans X-Plane mais les dossiers ont changé de taille. La tuile faisait 2,14 Go avant et 2.25 Go maintenant. Ceci dit, j'ignore comment et où se traduit cette différence dans X-Plane.
    Dernière modification par jef32 ; 06/03/2021 à 07h55.
    CPU: I7-6700K 4Ghz, GC: nVidia GeForce Titan X Gigabytes 12Go VRAM, 32 Go DDR4, Motherboard: Gigabytes Z170X-Gaming 3. OS: W10-Famille, 3 HD Samsung SSD 850 Pro 1TB + 1 Samsung SSD EVO 500 Gb. Oculus Rift CV1

  6. #26
    Utilisateur enregistré Avatar de Glah_Salamanthe
    Date d'inscription
    décembre 2005
    Localisation
    LSGL environs
    Messages
    10 249
    Total Downloaded
    0
    Citation Envoyé par jef32 Voir le message
    Ce matin, je ré-édite ce message pour dire que j'ai fait l'essai comme vous le préconisez tous les 2: J'ai effacé TOUS les fichiers dans "chemin\ortho4x 1.30\OSM_data\+40+000\+43+001"
    Mais quand j'ai voulu effacer ceux de la tuile après le step 1, j'ai eu droit à:

    ERROR: Could not find G:/X-Plane 11/X-Plane 11/Custom Scenery\zOrtho4XP_+43+001\Data+43+001.node
    Pourquoi vouloir effacer après le step 1 et en plein processus ???
    Ortho4XP a besoin de ces données pour construire ta tuile !

    Tu peux donc effacer :
    • AVANT de relancer tout le processus, pour obliger Ortho4XP à reconstruire avec les nouvelles données qu'il va trouver !
    • APRES le processus, notamment dans le dossier final de ta tuile , pour gagner un peu de place , en ne laissant QUE : Earth nav dat / terrain / textures
    Mais jamais pendant, entre les étapes de réalisation !
    Mac Pro 3Ghz 8 Core Intel Xeon E5 / 64Go DDR3 1866Mhz / 2x AMD FireProD700 6144Mo / SSD 1To + En Externe : SSD 2To + HD 5To Lacie Thunderbolt
    Samsung 49" 3840 x 1080 /
    Joystick Saitek X52 & Rudders
    MAC OS Mojave 10.14.6 / XPlane 11.53r1 (… XP à partir de XP 6 !)

    " Soyez vous même … les autres sont déjà pris ! "
    "… la fausseté des idées ne se règle pas par les interdictions mais s'asphyxie dans la liberté ! " Marc Bonnant

  7. #27
    Utilisateur enregistré Avatar de papet30
    Date d'inscription
    février 2016
    Localisation
    LFLP
    Âge
    77
    Messages
    634
    Total Downloaded
    0
    Citation Envoyé par jef32 Voir le message
    Mais quand j'ai voulu effacer ceux de la tuile après le step 1, j'ai eu droit à:

    ERROR: Could not find G:/X-Plane 11/X-Plane 11/Custom Scenery\zOrtho4XP_+43+001\Data+43+001.node
    Bonjour jef
    je me suis mal fait comprendre si j'en crois ton message.
    Je vais essayer d'être plus clair. Reprenons : la tuile zOrtho4XP_+43+001 existe et est parfaitement fonctionnelle avec tous ses fichiers, mais un problème est détecté : un lac n'est pas vu comme un plan d'eau lorsque on effectue un vol.
    Comme Ortho4XP va chercher dans openstreetmap toutes les infos qui lui sont nécessaires concernant le terrain (les routes, les rivières, les lacs, les côtes maritimes.....) immédiatement on pense à une erreur de donnée dans openstreetmap. Après vérification effectivement ce lac n'est pas déclaré avec les bons attributs ( natural water ). Correction faite il faut refaire la tuile pour intégrer la modif.
    Pour ce faire Ortho4XP utilisant par principe les données de zOrtho4XP_+43+001 déjà existantes, avant tout la première chose à faire est de supprimer les fichiers .osm.bz2, ainsi quand je vais relancer Ortho4XP pour reconstruire la tuile +43+001 les fichiers, osm.bz2 n'étant pas présents, Ortho4XP va refaire un accès à openstreetmap et récupèrer au step 1 les nouvelles données modifiées pour régénérer tous les fichiers osm.bz2. Ensuite les autres steps vont s'exécuter normalement pour obtenir une nouvelle tuile.

    A ta disposition.
    Bons vols.

    Edit : Oops Glah a dégainé plus vite.
    Asus Z390-E , I7-9700K 32Gb (3200 Mz)- SSD 950Pro 256 Gb - SSHD 1Tb - 2 x HDD 3Tb - 6Tb HDD USB_3.1 - 4Tb HDD USB3.0 - Asus Strix 1070 (Driver 450.102.04)- ThrustMaster T.16000M + Rudder pedals
    Ubuntu 18.04.2 LTS 64bits
    X-Plane 11.36r2. 11.41r1 11.50r3 11.51r1 11.52
    Avions : A350_1.6.13, Cessna172 Airfoillabs, B737-800X, A319 TolissV1p5p1, A321 TolissV1.2neo, DA62, Pipistrel-Panthera, Legacy RG, Epic Victory, B17G, P-51, Phenom 300

  8. #28
    Utilisateur enregistré
    Date d'inscription
    février 2003
    Localisation
    gers
    Messages
    277
    Total Downloaded
    0
    Effectivement j'avais pas tout pigé. Il faut dire que j'ai réglé mon Ortho4xp de manière à ce qu'il construise directement sa tuile dans le custon scenery de X-Plane, et c'est peut-être ça qui m'induit en erreur par rapport à vos explications, même s'il ne s'agit pas d'une faute technique. Pour moi inconsciemment, la tuile est déjà dans X-Plane alors que si je l'avais laissé dans "tiles", partie intégrante du répertoire Ortho4X, ça aurait facilité ma compréhension, quant à vos explications.

    Donc:
    -Remettre le setting Ortho4Xp par défaut, à savoir génération de la tuile dans son sous-répertoire "Tiles" pour pouvoir la re-travailler ensuite sans avoir l'impression qu'elle est déjà dans X-Plane. Mais ma question est alors de savoir comment Ortho4x va accepter de re-travailler une tuile existante alors qu'elle sera déjà présente sur sa carte ?
    -Lancer Ortho4XP, et lui faire générer la tuile complètement ( cochage des quatre premières options à gauche de la carte, cliquer Batch Built et laisser faire).
    -Effacement des fichiers .osm.bz2.
    -Relancer Ortho4x et lui faire régénérer la même, qu'il va déjà détecter non-présente mais comme il y a quand même les autres fichiers que les osm.bz2, il va juste réécrire les bonnes données OSM par dessus, et correctes cette fois.

    C'est ça ?

    Reprise du post:

    Fait et ça a marché.
    La tuile a été construite dans Tiles
    J'ai relancé Ortho4X après avoir effacé les fichiers osm.bz2
    J'ai relancé au step 2, puis ensuite le 3 et enfin le 4 qui est allé très vite puisque les .dds étaient déjà là.
    J'ai transféré ma tuile dans le custom scenery.

    testé et lac Rieumes OK
    Dernière modification par jef32 ; 06/03/2021 à 10h49.
    CPU: I7-6700K 4Ghz, GC: nVidia GeForce Titan X Gigabytes 12Go VRAM, 32 Go DDR4, Motherboard: Gigabytes Z170X-Gaming 3. OS: W10-Famille, 3 HD Samsung SSD 850 Pro 1TB + 1 Samsung SSD EVO 500 Gb. Oculus Rift CV1

  9. #29
    Utilisateur enregistré Avatar de Glah_Salamanthe
    Date d'inscription
    décembre 2005
    Localisation
    LSGL environs
    Messages
    10 249
    Total Downloaded
    0
    Citation Envoyé par jef32 Voir le message
    Donc:
    -Remettre le setting Ortho4Xp par défaut, à savoir génération de la tuile dans son sous-répertoire "Tiles" pour pouvoir la re-travailler ensuite sans avoir l'impression qu'elle est déjà dans X-Plane. Mais ma question est alors de savoir comment Ortho4x va accepter de re-travailler une tuile existante alors qu'elle sera déjà présente sur sa carte ?
    -Lancer Ortho4XP, et lui faire générer la tuile complètement ( cochage des quatre premières options à gauche de la carte, cliquer Batch Built et laisser faire).
    -Effacement des fichiers .osm.bz2.
    -Relancer Ortho4x et lui faire régénérer la même, qu'il va déjà détecter non-présente mais comme il y a quand même les autres fichiers que les osm.bz2, il va juste réécrire les bonnes données OSM par dessus, et correctes cette fois.
    Oui, ça doit marcher , mais j'ai l'impression que tu en fait trop !
    (pour ma part, je ne demande pas à Ortho4XP de mettre la tuile de lui-même dans mon Custom Scenery : je préfère gérer cela moi-même, d'autant plus que je renomme ma tuile pour que le système de nomination corresponde avec ce que j'avais déjà avec mes anciennes (589 en tout) tuiles qui couvrent l'Europe (mon HD fait 5 To alors …))
    Mais je crois savoir que Ortho4XP ne déplace pas de lui-même les tuiles créées, mais il ne fait que placer un lien symbolique dans Custom Scenery pour la tuile nouvellement créée.
    Donc , après avoir détruit les fichiers indiqués dans les posts précédents (les vrais fichiers, pas ceux se trouvant dans des liens symboliques ) , je lance la construction de ma tuile , directement sur le premier écran, avec "All in one" .
    Il n'est pas nécessaire de ;
    • Lancer la construction de ta tuile
    • effacer les fichiers " .osm.bz2."
    • relancer la construction une deuxième fois !

    (le premier point est inutile…)
    Cliquez sur l'image pour la voir en taille réelle

Nom : Ortho4XP.jpg
Affichages : 35
Taille : 79,9 Ko
ID : 25449
    Mac Pro 3Ghz 8 Core Intel Xeon E5 / 64Go DDR3 1866Mhz / 2x AMD FireProD700 6144Mo / SSD 1To + En Externe : SSD 2To + HD 5To Lacie Thunderbolt
    Samsung 49" 3840 x 1080 /
    Joystick Saitek X52 & Rudders
    MAC OS Mojave 10.14.6 / XPlane 11.53r1 (… XP à partir de XP 6 !)

    " Soyez vous même … les autres sont déjà pris ! "
    "… la fausseté des idées ne se règle pas par les interdictions mais s'asphyxie dans la liberté ! " Marc Bonnant

  10. #30
    Utilisateur enregistré
    Date d'inscription
    février 2003
    Localisation
    gers
    Messages
    277
    Total Downloaded
    0
    Oui, testé et fonctionne. Je vais laisser comme ça. D'autant plus, qu'à ma connaissance, il ne doit pas y avoir pléthore d'endroits en Europe où les données OSM sont erronées, donc cette manip de remettre un lac existant là où open street map n'en voit pas, ne doit surement pas être renouvelée très souvent.
    Merci à vous 2 de votre aide et de votre patience envers mon ignorance.
    CPU: I7-6700K 4Ghz, GC: nVidia GeForce Titan X Gigabytes 12Go VRAM, 32 Go DDR4, Motherboard: Gigabytes Z170X-Gaming 3. OS: W10-Famille, 3 HD Samsung SSD 850 Pro 1TB + 1 Samsung SSD EVO 500 Gb. Oculus Rift CV1

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •