Ortho4XP

[Mclnight]

avec un travail collaboratif

Je suis partant pour donner un coup de main dans la limite de mes compétences

[Odevillée]

En même temps il nous a sortis ça tout de Go...

Bon pour tous les comiques (et les autres), différence de taille Tuile +50+004 (Bruxelles) zoom 17, mesh HDV3, Bing, G2xpl 9.4Go, Ortho4xp 12.8 Go.

[atanorr]

Hello, oscar ,
J'ai un petit souci ,
voici le message d'erreur que j'optiens après un certains temps :

Converting jpeg to build /home/yves/Ortho4XP/My_new_tile/textures/43050_67284_BI17.dds
sh: /usr/bin/convert: Bad address
4 [waitproc] python3 6772 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6

Je viens de voir le message de: DSFTOOLS peut-être est ce le fautif ? mais ou et comment voir quelle version est bonne ou mauvaise..... dois je prendre celle ci?
==> http://developer.x-plane.com/2012/02...ool-available/
j'utilise la version de ton paquetage , .. dois je le changer?
Windows 8.1 , 64 bits 24g ram
Merci ;)
Une idée?

Dois-je ré-uploader ton paquetage ?

[Oscar Pilote]

@Atanorr : je sais que lebelge a connu le même genre de souci sous windows, j'ai cherché un moment ce qui pourrait en être
la cause du côté de mon programme pour finir par me rendre compte que le fautif est en fait l'émulateur cygwin :

https://cygwin.com/faq/faq.html#faq.using.bloda

J'essaierai de réfléchir à comment contourner le problème à l'occasion, mais je ne suis certainement pas le plus compétent
ici pour résoudre les problèmes spécifiques à windows (si d'autres ont des idées ?).

Désolé pour ces ennuis.

[atanorr]

merci pour ton aide, je vais essayer le mode compatibilité , j'ai mis les droits en mode administrateur ,

dois-je aussi réaliser ce que tu indique dans ton readme ou est-ce que dans ton package c'est réalisé ? :
To have nice water transitions we need more 9 plane coordinates for vertices than is available in the online version
of DSFTool.
The consequence is that the complied version available at developer.x-plane.com cannot be used, and you (or someone for you) needs to build it from the sources.
This is a 2 minute job if done appropriately, but it is probably going to be a pain for most users.
If you wish to try, go to http://developer.x-plane.com/code/ and follow instructions.
After you get the source code, please make the following change :

replace the 8 by a 10 at line 51 (as of June 4th 2015) of DSFPointPool.h regarding MAX_TUPLE_LEN
(you can preview the file at http://dev.x-plane.com/cgit/cgit.cgi...DSFPointPool.h)


The two 'make' commands listed on B. Supnik's tutorial will do too much work for our purposes (and will last long),
you can just build zlib for the libs, and DSFTool for the second make (we don't need WED
and so on here!). Compilation time is a few seconds.



Je fais mon possible pour ne pas t'ennuyer
Grand merci déjà pour tes travaux , , j'essaie de tester également pour Amsterdam . bcp de sources d'eaux +52+004

Et si j'essaie d'installer la version 32bits de cygic est-possible sur un win 64bits? peut être la version 32bits plus stable?
Peut-être LeBelge a trouvé la solution?

- Peut-on utiliser plus de 2 endroits sur une même tuile en zoom supérieur ?

[Oscar Pilote]

- Peut-on utiliser plus de 2 endroits sur une même tuile en zoom supérieur ?

Oui, l'algorithme fait simplement la chose suivante :

Pour chaque triangle du maillage qui constitue le sol, il commence par regarder la première
ligne de [Ortho_zone_list] dans le fichier de configuration.
1) si le triangle se trouve dans la zone en question, il lui applique la texture correspondante
(avec le zoomlevel et le fournisseur indiqué dans la ligne) et passe au triangle suivant.
2) sinon, il passe à la deuxième ligne dans [Ortho_zone_list] : si le triangle se trouve dans
la zone en question, il lui applique la texture correspondante sinon il passe à la troisième
ligne, et ainsi de suite.
3) si après avoir atteint la fin de [Ortho_zone_list] il n'a trouvé aucune zone contenant
le triangle, il le laisse avec la texture qu'il avait initialement (par e.x. celle de base d'X-Plane si
le programme est utilisé sur un dsf de base d'X-Plane).

Détails concernant le point 1) : lorsque le programme a déterminé la texture à appliquer, il
va vouloir faire deux choses : a) télécharger la texture jpeg (c'est en jpeg que les orthos sont
"disponibles" sur les sites des fournisseurs) puis b) la transformer en dds après avoir appliqué
éventuellement les réglages demandés de contraste, luminosité, etc.
Pour a) le programme vérifie d'abord si le fichier jpeg n'est pas déjà présent dans le sous-répertoire
adéquat de Orthophotos. S'il l'est il ne le retélécharge pas.
Pour b) le programme vérifie d'abord si le fichier dds n'est pas déjà présent dans le sous-répertoire
adéquat de "build_dir" (My_new_tile par défaut). S'il l'est il ne convertit pas le jpeg mais conserve
le dds existant.

Pour ces dernières raisons, en cas d'échec de construction de tuile (plantage cygwin, connexion
internet coupée, etc), il n'est pas nécessaire de supprimer le travail qui a déjà était fait. En relançant
Ortho4XP de la même manière il vous indiquera des "Skipping" lorsqu'il rencontrera des triangles
dont il a déja téléchargé et/ou converti la texture.

Vous pouvez ainsi décider à posteriori d'ajouter une zone plus détaillée sur une partie d'une tuile
déjà faite, il ne fera que le travail nécessaire et ne reprendra pas tout à zéro.

[atanorr]

Grand Merci oscar pour tes réponses j'ai lancé 3 ou 4fois effectivement ortho4xp afin qu'il arrive à la fin de la tuile en conversion dds sans crash..
Mais la fin est moins fructueuse .. :-(
Après 3h d'essais ....

DSFTool now converts back the newly created dsf to binary format :
Converting +52+004.txt.new from text to DSF as +52+004.dsf.new
Scanning for dimension properties...
Got dimension properties, establishing file writer...
Got entire file, processing and creating DSF.
Vertices: total = 7229043, strip = 12, fan = 0.
Primitives: total = 29181, strip = 3, fan = 0.
4.940614,52.497813,-32768.000000,-0.000015,-0.000015,0.551412,0.686810 4013c330432d95ff,404a3fb857b76e63,c0e0000000000000 ,bef0000e7eda0be1,bef0000e7eda0be1,3fe1a52a15162b7 f,3fe5fa585e1000a9
ERROR: !"ERROR: could not sink vertex:\n"
(src/DSF/DSFLibWrite.cpp, 619.)
cp: impossible d'évaluer «*+52+004.dsf.new*»: No such file or directory

, dsftools me plante :-( J'essaie de trouver sur google le pourquoi.. , cygwin , ou dsftools .. , peut être tanter sous virtualbox ?

dois-je aussi réaliser ceci?

" To have nice water transitions we need more 9 plane coordinates for vertices than is available in the online version
of DSFTool.
The consequence is that the complied version available at developer.x-plane.com cannot be used, and you (or someone for you) needs to build it from the sources.
This is a 2 minute job if done appropriately, but it is probably going to be a pain for most users.
If you wish to try, go to http://developer.x-plane.com/code/ and follow instructions.
After you get the source code, please make the following change :

replace the 8 by a 10 at line 51 (as of June 4th 2015) of DSFPointPool.h regarding MAX_TUPLE_LEN
(you can preview the file at http://dev.x-plane.com/cgit/cgit.cgi...DSFPointPool.h) "

[Oscar Pilote]

Bon pour tous les comiques (et les autres), différence de taille Tuile +50+004 (Bruxelles) zoom 17, mesh HDV3, Bing, G2xpl 9.4Go, Ortho4xp 12.8 Go.

Pourquoi ? Imaginons que la terre soit une feuille quadrillée de petits carreaux : Ortho4XP trace en gras une grille dont les gros carrés
font 14 petits carreaux de large par 14 petits carreaux de haut. Ensuite, les images qu'il télécharge sont plus grosses que les gros
carrés de la grille, elles font 16 petits carreaux de large par 16 petits carreaux de haut (à dessein, il utilise ensuite les
chevauchements de 2 petits carreaux).

Pour une zone en réel de 14*14 petits carreaux, il stocke donc 16*16 petits carreaux d'images. Cela correspond donc à un rapport de
(16*16)/(14*14) par rapport à la zone réelle, soit 30% de surcoût. 9.4Go + 30% cela fait 12.2Go. Les 600 mégas supplémentaires sont
dus à des triangles qui ont du se voir attribuer un zoomlevel plus bas que celui demandé, ceux-là disparaîtront dès que le mailleur
dédié ortho sera pret. Les 30% eux ne disparaîtront pas (ils pourraient se transformer en 15% en ne chevauchant qu'un d'un carreau,
mais il faudrait ensuite mailler plus fin).

En parallèle à ce surcoût au niveau des textures, il y a un "moinscoût" au niveau du nombre de triangles, mais il est moins visible
directement pour l'utilisateur...

Selon PhM, le maillage (= le découpage du sol en triangles) ne doit dépendre que de la courbure du terrain (tout plat ou montagneux),
et pas des textures qui vont être posées dessus. C'est un avis que je partage et c'est l'optique que j'ai suivie. G2XPL suit la logique
opposée, qui consiste à adapter le maillage aux textures (il découpe les triangles qui intersectent le bord des orthos).
Heureusement chacun fait comme il veut.

Par ailleurs, dans mon idée la chose importante (ce qui se stocke "précieusement") ce sont les jpeg, pas les dds. En effet les
seconds se retrouvent à partir des premiers à raison d'un toutes les 2 secondes à l'aide d'un utilitaire type convert. Et si un dds
en 4096x4096 fait environ 10Mb pour les orthos, le jpeg correspondant ne fait que 4Mb environ. In fine, si on ne conservait (ou mettait
à disposition sur un site non commercial bien connu, assorti d'un extracteur convertisseur... ;-) que les jpeg, on aurait un surcoût de
(16*16)/(14*14)*(4/10), soit en fait un moinscoût de 50%.

Pour les utilisateurs dont la place de stockage est "limitée", je pense qu'il est plus intéressant (et aussi sans doute mieux visuellement)
d'avoir la tuile de base en ZL16 et de la compléter au gré des envies par des petites zones de ZL18 voire ZL19 (je radote moi), plutôt que
d'avoir les 10000km2 de la tuile en ZL17. Là aussi chacun fait comme il veut, j'ai reçu quelques retours d'utilisateurs qui tuilent à tour de
bras en ZL18

[atanorr]

dernier essais ;) avant koh lanta.. ,

Creating directory /home/yves/Ortho4XP/My_new_tile/Earth nav data/+50+000 if it does not yet exists
DSFTool now converts back the newly created dsf to binary format :
cp: impossible d'évaluer «*+52+004.dsf.new*»: No such file or directory

j’arrête là aujourd'hui .. snif
j'ai essayer les 2 dernières versions de dsftools..

[Odevillée]

Pourquoi ? Imaginons que la terre soit une feuille quadrillée de petits carreaux : Ortho4XP trace en gras une grille dont les gros carrés
font 14 petits carreaux de large par 14 petits carreaux de haut. Ensuite, les images qu'il télécharge sont plus grosses que les gros
carrés de la grille, elles font 16 petits carreaux de large par 16 petits carreaux de haut (à dessein, il utilise ensuite les
chevauchements de 2 petits carreaux).

Pour une zone en réel de 14*14 petits carreaux, il stocke donc 16*16 petits carreaux d'images. Cela correspond donc à un rapport de
(16*16)/(14*14) par rapport à la zone réelle, soit 30% de surcoût. 9.4Go + 30% cela fait 12.2Go. Les 600 mégas supplémentaires sont
dus à des triangles qui ont du se voir attribuer un zoomlevel plus bas que celui demandé, ceux-là disparaîtront dès que le mailleur
dédié ortho sera pret. Les 30% eux ne disparaîtront pas (ils pourraient se transformer en 15% en ne chevauchant qu'un d'un carreau,
mais il faudrait ensuite mailler plus fin).

En parallèle à ce surcoût au niveau des textures, il y a un "moinscoût" au niveau du nombre de triangles, mais il est moins visible
directement pour l'utilisateur...

Selon PhM, le maillage (= le découpage du sol en triangles) ne doit dépendre que de la courbure du terrain (tout plat ou montagneux),
et pas des textures qui vont être posées dessus. C'est un avis que je partage et c'est l'optique que j'ai suivie. G2XPL suit la logique
opposée, qui consiste à adapter le maillage aux textures (il découpe les triangles qui intersectent le bord des orthos).
Heureusement chacun fait comme il veut.

Par ailleurs, dans mon idée la chose importante (ce qui se stocke "précieusement") ce sont les jpeg, pas les dds. En effet les
seconds se retrouvent à partir des premiers à raison d'un toutes les 2 secondes à l'aide d'un utilitaire type convert. Et si un dds
en 4096x4096 fait environ 10Mb pour les orthos, le jpeg correspondant ne fait que 4Mb environ. In fine, si on ne conservait (ou mettait
à disposition sur un site non commercial bien connu, assorti d'un extracteur convertisseur... ;-) que les jpeg, on aurait un surcoût de
(16*16)/(14*14)*(4/10), soit en fait un moinscoût de 50%.

Pour les utilisateurs dont la place de stockage est "limitée", je pense qu'il est plus intéressant (et aussi sans doute mieux visuellement)
d'avoir la tuile de base en ZL16 et de la compléter au gré des envies par des petites zones de ZL18 voire ZL19 (je radote moi), plutôt que
d'avoir les 10000km2 de la tuile en ZL17. Là aussi chacun fait comme il veut, j'ai reçu quelques retours d'utilisateurs qui tuilent à tour de
bras en ZL18

Merci, c'est clair comme réponse et comme tu dis un zoom de 16 c'est déjà très bien, agrémenté le cas échéant par certaines zones plus détaillées.
Le plus de ce prg c'est aussi de pouvoir aussi régler le contraste, la luminosité et la saturation comme on veut. Enfin des scènes uniformes de couleurs.

[Oscar Pilote]

@atanorr
La réponse était dans un post plus haut mais j'avais omis de mentionner que je n'avais fait le boulot que pour Linux.
DSFTool version 64 bit est bugué, j'ai remplacé hier ou avant hier la version Linux, je viens de le faire pour la version
Windows (DSFTool.exe). J'ai aussi changé le README.FIRST suite à tes remarques.
J'ai testé la tuile +52+004 en ZL15 sous windows 7 (nu, sans antivirus ni quoi que ce soit d'autre, j'utilise windows
uniquement pour les tests), je n'ai eu aucune erreur. Par contre c'est une tuile bord de mer, donc il y a des petites
tuiles blanches de bing au large des côtes, je n'ai pas encore traité ce point.

@Odevillée. Merci pour tes retours ! Pour être honnête, les points positifs que tu mentionnes sont surtout à mettre
au crédit du petit couteau suisse qu'est "imagemagick", et dont Ortho4XP ne fait qu'utiliser le tranchant (Pensez que
ce programme fait qqch comme 100k je crois et qu'il fait l'essentiel de tout ce que beaucoup d'entre vous avez jamais
utilisé de Photoshop (je prends mes précautions car il y a des artistes de la retouche numérique parmi nous ;-)
Serais-tu intéressé à ce que les ajustements contraste/saturation etc puissent être définis zone par zone dans
Ortho_zone_list ? (j'ai remarqué que parfois les orthos changent brusquement de tonalité suivant les zones
rectangulaires des prises de vue).
[Et maintenant que tu es un utilisateur averti, surtout ne te gène pas pour répondre à ma place aux questions qui
surviennent sur le fil (d'avance merci!)]

[atanorr]

voilà , je viens de refaire un download pour tester
toujours la tuile Amsterdam +52+004 dsf v3

Mais... Malheureusement ....

TU ES UN CHEF :DDDD

:D après 4h d'essais de mon côté ... ça MARCHE :D merci OSCAR :D

[Oscar Pilote]

:D après 4h d'essais de mon côté ... ça MARCHE :D

C'est sûrement l'effet koh lanta.
Bons essais !

[atanorr]

après reste , je suppose quelques réglages pour bordure de mer , j'ai fais erreur quelque part?
voici une capture


dans le cfg:
[Ortho_zone_list]
52 53 4 5 17 BI


[Terrain_keep_list]
terrain_Water


[Polygon_remove_list]
beaches
autogen

[papifs57]

... j'ai reçu quelques retours d'utilisateurs qui tuilent à tour de
bras en ZL18

Pff..."Y ont pas froid aux yeux"

J'avais commencé en 17 pour finalement opter pour le 16...certes à grande échelle, en effet je crois qu'ils ont intérêt de prévoir ce genre de Disque pour les Archives

https://www.digitec.ch/fr/s1/product/seagate-archive-hdd-8000go-35-serveurs-disques-durs-3496868?tagIds=76

Ce genre de DD pourrait très bien faire l'affaire pour les utilisateurs de tuiles "à large spectre" même en vol. Ils ne sont pas conçu pour du "NAS", mais, en lecture sous xp pas de soucis.


Bon WE.
François
PS j'essayerais tes applications en W7 & tous le tintoin qu'il faut pour "émuler" Python son Windows.

Pas le temps (ma femme rentre passer ce WE en famille... ;) )