If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Merci de poster ou de m'indiquer ou je peux trouver un tuto complet sur les overlay.
et un grand merci a Oscar pour sa réactivité et le temps qu'il dédie a un logiciel gratuit pour la communaute X-Plane. Ceci n'a pas de prix et ce logiciel m a incite
a passer de P3D a X plane.
Je ne suis qu'un utilisateur de xPlane dans un contexte de réseau et la différence de niveau vient de OrthoX4P c'est tout ce que j'ai identifié.
....
La différence vient du mesh mais Ortho4XP n'est qu'un exemple. Ce sera la même chose entre le Global Scenery d'origine, le Mesh HD v2, v3, le Mesh UHD pour les Alpes. C'est pourquoi une solution universelle ne pourra venir que du simulateur, donc de Laminar.
Daniel
Intel I5 6500 3,2 Ghz, RAM 16 Go, GeForce GTX 960 2 Go, Linux Ubuntu 18.04
Portable Asus Intel i5 2,8 Ghz, RAM 8 Go, GeForce 840M, Windows 8.1 64bits
#AMD II X2 245 2,9 Ghz, RAM 8 Go, GeForce GTX 650 1 Go, Linux Ubuntu 14.04
#AMD 64x2 5200 2,6 Ghz, RAM 4 Go, GeForce 9600 GT 512 Mo, Linux Ubuntu 10.04
#MacBook Pro 15" 2,4 Ghz, RAM 4 Go, GeForce GT 330 M 256 Mo, Mac OS 10.6
J'essaie de générer la tuile +45/+6 (celle d'Annecy que tu connais bien, je crois, et moi aussi : j'y ai fait mon année d'armée) avec ton nouveau code v1.18 (au passage un grand merci pour cette nouvelle mouture qui va nous permettre de gagner du temps dans la génération des tuiles et de gérer les tuiles avec une vue géographique, c'est vraiment super). A l'étape 1, j'obtiens des erreurs OSM. Je me suis donc plongé dans OSM et JOSM que je ne connaissais pas du tout jusqu'à il y a quelques jours pour essayer de comprendre et le cas échéant de corriger. Seulement voilà et avec le peu de connaissances que j'ai, je ne comprends toujours pas ces erreurs.
Il y a deux types d'erreurs :
* Erreur type 1 : Relation id=3963059 contains a member with role different from inner or outer, it was not treated
Les relations qui ont cette erreur ont toutes comme attribut type=waterway qui ne peut pas avoir inner ou outer comme role. Ces rôles sont réservés aux relations de type=multipolygon. Donc pour moi ce ne serait pas des erreurs.
* Erreur type 2 : Relation id=3963078 contains member relation which was not treated because it is not a way.
En effet ces relations appellent dans leurs membres des chemins mais aussi (et c'est là que les erreurs sont générées) d'autres relations. Je pense que l'on a le droit d'inclure des relations dans des relations (mais je n'en suis pas sûr car bien que l'ayant vu dans pas mal d'endroits je ne l'ai pas vu écrit). Si on n'a pas le droit de faire ça alors il y aurait beaucoup trop de modifications à prévoir.
N'ayant pas généré la tuile (je me suis arrêter à l'étape 1) je ne sais pas quel est l'impact d'ignorer ces erreurs. Bien entendu cela n'a rien à voir avec la v1.18 puisque j'ai la même chose avec la 1.16.
Voilà j'espère avoir été clair et vu ma candeur sur Ortho4XP et OSM/JOSM je te prie de m'excuser si j'ai fait fausse route.
Step 1 : Building OSM and patch data for tile +49+005 :
--------
-> Downloading airport and water/ground boundary data from Openstreetmap :
Obtaining OSM data for way["aeroway"="aerodrome"]
Done.
A total of 248 node(s) and 7 way(s).
* LFGW Verdun-Le Rozelier
* LFAW Aérodrome de Villerupt
* LFQE Base aérienne d'Etain-Rouvres
* EBAR Aérodrome d'Arlon-Sterpenich
* EBBX Base aérienne de Bertrix
* ELNT Aerodrome de Wiltz-Noertrange
* Airfield Useldange
Obtaining OSM data for rel["aeroway"="aerodrome"]
Done.
A total of 72 node(s) and 1 relation(s).
Ortho4XP ne fait plus rien et en parallèle, j'ai sur la console:
Exception in thread Thread-60568:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "./Ortho4XP_v117.py", line 369, in build_poly_file
print(" * "+idcosmr_icao[relid])
NameError: name 'idcosmr_icao' is not defined
Est-ce du à l'Airfield Useldange qui ne contient pas de variable ICAO sur OpenStreetMap ?
EDIT: J'ai ajouté l'ICAO manquant dans OSM mais j'ai toujours 'NameError: name 'idcosmr_icao' is not defined' pourtant il récupère bien le ICAO (ELUS Airfield Useldange)
Pourrais-tu ajouter une fonctionalité dans Ortho4XP pour ignorer l'aérodrome dans ce cas de figure en affichant un warning plutôt que de laisser crash le script ?
Merci beaucoup
Dernière modification par nicowork, 12 septembre 2016, 19h18.
Salut, oui j'avais corrigé dès que j'ai vu ton message et mis en ligne le correctif,
ce sont mes noms de variables à la mord moi le knot (dicosmr_icao comme "dico" (dictionnaire),
osm pour openstreetmap, r pour relation et icao pour... icao) qui m'ont joué un tour.
Ca n'apparaissant que dans les tuiles dont un des aéroports est codé en "rel", c'est pour cela
que tu as pu faire plusieurs autres tuiles s'en t'en apercevoir.
Attend un poil pour télécharger, je suis en train d'ajouter ce que tu m'as demandé
concernant les aéroports à plus fort zl automatique, et je dois aussi m'occuper de nvcompress
pour les mac (j'ai déniché un imac 2010 core 2 duo, cela va me permettre de ne plus travailler
à l'aveugle).
Dernière modification par Oscar Pilote, 12 septembre 2016, 20h41.
Linux Debian sid - Intel i7 4Ghz - 16Gb RAM - Nvidia GTX 970
Ortho4XP v130 : Dépôt github (mises à jour au fil de l'eau (avant la période de sécheresse)), ou Version clés en main sous Windows.
Oui j'ai hésité à mettre toutes les erreurs trouvées en ligne, c'est comme les notices de médicaments si tu lis tout
tu jettes tout de suite à la poubelle. Mais les 95% sont sans conséquences néfastes (là je parle de OSM).
La règle que je te propose : tu oublies tous les messages où j'indique avoir détecté une erreur, et tu n'y reviens que si l'étape 2 ne passe pas où si
en volant tu t'aperçois qu'une surface en eau à été oubliée ou tronquée. Pour la France tu peux être assez serein. Par ailleurs tu as raison concernant
les relations contenant des relations, mais dis toi que même si le message 'erreur' mal choisi dans ce cas, le traitement que j'en fais est (j'espère) correct.
Linux Debian sid - Intel i7 4Ghz - 16Gb RAM - Nvidia GTX 970
Ortho4XP v130 : Dépôt github (mises à jour au fil de l'eau (avant la période de sécheresse)), ou Version clés en main sous Windows.
Oui j'ai hésité à mettre toutes les erreurs trouvées en ligne, c'est comme les notices de médicaments si tu lis tout
tu jettes tout de suite à la poubelle. Mais les 95% sont sans conséquences néfastes (là je parle de OSM).
La règle que je te propose : tu oublies tous les messages où j'indique avoir détecté une erreur, et tu n'y reviens que si l'étape 2 ne passe pas où si
en volant tu t'aperçois qu'une surface en eau à été oubliée ou tronquée. Pour la France tu peux être assez serein. Par ailleurs tu as raison concernant
les relations contenant des relations, mais dis toi que même si le message 'erreur' mal choisi dans ce cas, le traitement que j'en fais est (j'espère) correct.
Cela me parait raisonnable. Je fais faire comme tu dis. Merci beaucoup.
Attend un poil pour télécharger, je suis en train d'ajouter ce que tu m'as demandé
concernant les aéroports à plus fort zl automatique.
Un très grand merci à toi. Peut-tu me confirmer que tu te base sur les données OSM ?
Je vérifirais si tous les AD français (hors ULM) existent dans OSM et à l'occasion dans X-Plane.
Est-ce que tu écris un changelog à chaque changement de version de Ortho4XP ?
Pourrais-tu permettrais à Ortho4XP d'être executé en ligne de commande sous un format similaire à celui-ci ?
Exemple ./Ortho4XP --no-cli --tile-coordinates= +47-002;+45+002 --base-source=BI --base-zoomlevel=17 --output=output.txt
--no-cli => don't start CLI interface
--tile-coordinates => title to build separated by ';', accept +47-002 or +47-2
--base-source => provider as specified in address book
--base-zoomlevel => zoom level
--output => write output to file
@Utilisateurs OSX
Pourriez-vous essayer la dernière version en mettant à jour
- le fichier Ortho4XP_v119.py
- le fichier Utils/nvcompress-osx (vous pouvez virer les anciens nvcompress-cuda et -no-cuda)
- (le fichier Ortho4XP.cfg, en adaptant ses quelques premières lignes à vos noms de répertoire)
Merci ! (si vous reportez merci d'indiquer qu'elle version d'osx vous utilisez).
Pour les windowsiens qui ne veulent que la version exécutable, pour ne pas tout recharger la dropbox
j'ai mis un autre lien dans ma signature, il n'y a que les 3 fichiers à mettre à jour.
Linux Debian sid - Intel i7 4Ghz - 16Gb RAM - Nvidia GTX 970
Ortho4XP v130 : Dépôt github (mises à jour au fil de l'eau (avant la période de sécheresse)), ou Version clés en main sous Windows.
@Utilisateurs OSX
Pourriez-vous essayer la dernière version en mettant à jour
- le fichier Ortho4XP_v119.py
- le fichier Utils/nvcompress-osx (vous pouvez virer les anciens nvcompress-cuda et -no-cuda)
- (le fichier Ortho4XP.cfg, en adaptant ses quelques premières lignes à vos noms de répertoire)
Merci ! (si vous reportez merci d'indiquer qu'elle version d'osx vous utilisez).
Pour les windowsiens qui ne veulent que la version exécutable, pour ne pas tout recharger la dropbox
j'ai mis un autre lien dans ma signature, il n'y a que les 3 fichiers à mettre à jour.
Je l'ai édité avec windows hier soir, le fichier est au format dos (les retours chariot sont différents)
et ton terminal doit avoir du mal avec, je viens de te le remettre au format unix.
La prochaine fois si ça arrive tu peux faire :
vim Ortho4XP_v119.py (ça te l'ouvre dans mon éditeur de texte favori)
:set fileformat=unix (dans l'éditeur, ça change le format de fichier de dos à unix)
:wq ( w = sauver, q = quitter)
Linux Debian sid - Intel i7 4Ghz - 16Gb RAM - Nvidia GTX 970
Ortho4XP v130 : Dépôt github (mises à jour au fil de l'eau (avant la période de sécheresse)), ou Version clés en main sous Windows.
Bonjour Oscar,
la v119 change quelque chose versus v118 pour les linuxiens?
Pas grand chose, quelques petits bugs qui auraient pu survenir et aussi le truc qu'avait demandé
nicowork avec les aéroports. Il y a plein de fonctions que les gens me demandent mais que je
n'utiliserai personnellement jamais (cette dernière par exemple, comme les use_masks_for_inland
de simheaven). J'ai pris le parti de changer de nom de fichier à chaque changement, sinon ça
devient ingérable pour moi quand les gens me posent des questions et que je ne sais pas de
quelle version du script ils parlent).
Autre chose que j'ai oublier de dire ici. Depuis avant hier il y a une ligne de code
(la 2994 dans le fichier actuel) qui fait augmenter un compteur web de une unité
(comme sur le bas de certaines pages web) à chaque fois qu'une tuile est lancée (au step 3).
La ligne c'est
r=s.get("http://simplehitcounter.com/hit.php?uid=2163525&f=16777215&b=0"
et vous pouvez la commenter (mettre # devant) si ça vous dérange (moi comme
quiconque n'ai accès qu'au compteur - d'ailleurs on le fausse d'une unité à chaque fois
que l'on regarde..).
Il y a deux raisons. La première c'est la curiosité. La seconde et c'est plus important c'est
de savoir à quel point on pèse sur les serveurs overpass d'openstreetmap
(http://wiki.openstreetmap.org/wiki/Overpass_API), ce sont des serveurs gérés par
des bénévoles et ils ont une puissance limitée. D'ailleurs, je pense que je vais devoir
les contacter.
(j'utilise juste un nouveau nom à chaque changement de fichier pour éviter
Linux Debian sid - Intel i7 4Ghz - 16Gb RAM - Nvidia GTX 970
Ortho4XP v130 : Dépôt github (mises à jour au fil de l'eau (avant la période de sécheresse)), ou Version clés en main sous Windows.
Commentaire