[FSX]Comment améliorer un autogen de base

JpP · [↑]

En convertissant les données au format KML, on peut lire sous GE: Z_ORDER=0
Donc cette donnée alti doit bien exister quelque part dans le .shp

JpP

JpP · [↑]

Puisque ScenProc sait lire les .kml, j'ai essayé avec les données converties à ce format; ça fonctionne, plus de référence à PolygonZ.
C'est une solution de secours, mais ça va un peu être lourd à gérer.

JpP

Vogel69 · [↑]

Pour ma part j'ai eu ce même bug en début de semaine mais dans l'autre sens le fichier shp utilisé etait issu d'un fichier Area.kml contenant les cours et plans d'eau de la Loire... Même résultat: PolygonZ not supported ou un truc comme ça. Je viens de jeter un coup d'œil rapide et apparement pas de données d'altitude sur les polygones non plus ?! Bizard ?! J'ai essayer l'import direct du kml dans scenproc mais pour l'instant ça bug... Je vais tenté d'isolé le ou les polygones responsable de mon fichier kml à taton pour voir si une explication se profile...

Vogel69 · [↑]

Je ne peux pas verifier pour l'instant mais j'ai peut être une piste, PolygonZ pourrait vouloir dire: polygon a plusieurs dimension c'est à dire un polygone formé par plusieurs polygones... peut être faut il forcer Qgis a séparer chaque polygone de manière unique(comme dans la méthode pour les routes et les polyvegtation) ?

Vogel69 · [↑]

Je confirme !!!

je viens de refaire le test:

1/ sur mon fichier kml brut de traitement => "Shapetype PolygonZ is not implemented"

2/ passage dans Qgis et application de l'option:

Vecteur -> Outils de Geometrie -> Morceaux multiple vers morceau unique

3/ apres traitement du fichier shp => ca roule ! "Written 411 Autogen"

à toi de jouer

Dernière modification par Vogel69 (31-01-2013 17:29:11)

JpP · [↑]

Vogel69 a écrit :

Je ne peux pas verifier pour l'instant mais j'ai peut être une piste, PolygonZ pourrait vouloir dire: polygon a plusieurs dimension c'est à dire un polygone formé par plusieurs polygones... peut être faut il forcer Qgis a séparer chaque polygone de manière unique(comme dans la méthode pour les routes et les polyvegtation) ?

C'était çà; l'[large]I[/large]dée !!!! =W=W

Les polygones, une fois réunifiés, sont traités normalement par ScenProc; et ça fonctionne également pour les SHP!!!
C'est tout bon, merci merci.

Je suis soulagé que ça passe en SHP car les colonnes d'attributs de ces récentes (pour moi au moins) données sont beaucoup plus riches que celles issues de Geofabrik; idem pour les tags dans chaque colonne d'attributs; on peut envisager des filtres Scenproc beaucoup plus ciblés.

C'était une bonne journée!

JpP

Dernière modification par JpP (31-01-2013 17:57:03)

Gropied · [↑]

@JpP et Vogel69

Content que vous ayez réussi à résoudre ce problème. Merci JpP pour ton obstination et merci à Vogel69 pour l'idée de cette manip. C'est à retenir.

Gropied

JpP · [↑]

Bonjour

A propos de toutes ces données que nous préparons pour ScenProc, QGis commence maintenant à ramer sur les gros volumes; j'ai essayé autre chose, avec une certaine satisfaction...

http://www.pilote-virtuel.com/viewtopic.php?pid=517786#p517786

JpP

JpP · [↑]

Vogel, ce que tu demandes à Arno est fondamental, mais il va effectivement avoir du boulot! Ces trous ou îlots dans les polygones mettent la pagaille! Je suppose que c'est à cause d'eux que, malgré l'unification des polygones multiples, je reçois encore la sanction PolygonZ etc.

JpP

JpP · [↑]

Ouaaaiiiiis!!

Arno:

"I have made some changes to scenProc. From the next development release it can also read shapefile types PolygonM, PolygonZ and PolyLineM.

Be aware that scenProc does not use the M or Z values stored with the features at the moment. "

JpP

Edit (les gars): qui aurait un topo sur les classes M/Z des Polygon/Line?

Dernière modification par JpP (02-02-2013 12:21:14)

Vogel69 · [↑]

Shape type in XY Space
Polygon
A Polygon consists of one or more rings. A ring is a connected sequence of four or more points that form a closed, non-self-intersecting loop. A polygon may contain multiple outer rings. The order of vertices or orientation for a ring indicates which side of the ring is the interior of the polygon. The neighborhood to the right of an observer walking along the ring in vertex order is the neighborhood inside the polygon. Vertices of rings defining holes in polygons are in a counterclockwise direction. Vertices for a single, ringed polygon are, therefore, always in clockwise order. The rings of a polygon are referred to as its parts.

Because this specification does not forbid consecutive points with identical coordinates, shapefile readers must handle such cases. On the other hand, the degenerate zero length or zero area parts that might result are not allowed.
...

Measured Shape type in XY Space
PolygonM
A PolygonM consists of a number of rings. A ring is a closed, non-self-intersecting loop. Note that intersections are calculated in XY space, not in XYM space. A PolygonM may contain multiple outer rings. The rings of a PolygonM are referred to as its parts.
...

Shape type in XYZ Space
PolygonZ
A PolygonZ consists of a number of rings. A ring is a closed, non-self-intersecting loop. A PolygonZ may contain multiple outer rings. The rings of a PolygonZ are referred to as its parts.
...

http://publib.boulder.ibm.com/infocente … spat36.htm

Dernière modification par Vogel69 (02-02-2013 19:12:07)

JpP · [↑]

Merci à toi pour ces éclaircissements.

je ne comprends néanmoins toujours pas pourquoi ScenProc reproche la présence de PoylgonZ alors que c'est issu de shapefiles 2D; PolygonM, j'aurais compris car les formes à anneaux multiples ne manquent pas; je réalise d'ailleurs qu'il n'y a pas de qualification spécifique pour les polygones à anneaux intérieurs.

Bon, le principal est que Maître Arno nous a dit que c'était réglé et dispo dans la prochaine mouture de ScP.

Encore une bonne journée.

JpP

Vogel69 · [↑]

En fait, je dois bien t'avouer que je n'ai pas tout compris non plus et surtout à mes explications

pour résumé, apparemment dans les fichiers .shp(ESRI) il existe plusieurs types de polygones: Polygon, PolygonM, PolygonZ, PolygonsZM. les deux premiers ne contiennent que des données relatives à un espace en 2D (x,y), la différence avec le second est que celui ci contient en plus des informations de "mesures". Enfin, Les deux derniers eux, contiennent des données relatives à un espace 3D(x,y,z). Dans tes données j'imagine que ce z doit correspondre à des données d'altitude (comme tu l'avais pré-sentit au départ ). A noter que tous ces types de polygone peuvent être composés d'un plusieurs polygones (ring) qui ont la seule contrainte de ne pas se croiser les uns avec les autres !

Et donc contrairement à ce que je disais plusieurs posts plus haut le problème ne venait pas de ça même si la manœuvre décrite sur mon fichier .kml a suffit car elle à peut être permis en même temps la conversion d'un type de polygone non supporté par un autre supporté par scenproc... Au final, j'imagine tout simplement que Arno n'avait pas encore trouvé l'utilité d'implémenter le traitement des tous les types de polygones du format ESRI et que cela semble chose faite maintenant

JpP · [↑]

Bonjour

Matière première augmentée (du moins pour moi) pour nourrir ScenProc.

http://www.pilote-virtuel.com/viewtopic.php?id=51325

JpP

JpP · [↑]

Bonjour

Vogel, tu avais raison, les maj de ScenProc sont parfois silencieuses.
Arno a bien intégré dans la dernière version la gestion promise des PolygonZ; voici un extrait de mon .spc, remerciements au passage à Gropied et à Domsimu.

#=================================================================================================
#Grouping Gropied Defaut Flat Roofs 1_3_5_7_12
CREATEAGNGENBUILD|FTYPE=POLYGON; FAREA>1000;FROMFILE=LANGROUS_bldg.shp|{e206cd08-5008-4dea-ad4a-db42bfa5298b}|MAXRATIO=5
#=================================================================================================
#Grouping Domsimu of all flat roofs
CREATEAGNGENBUILD|FTYPE=POLYGONZ;FAREA>1000;FAREA<10000;FROMFILE=LANGROUS_bldg.shp|{B597DDC9-4AA1-4391-8383-231620161427}|MAXRATIO=6
#=================================================================================================

OK, c'est une combinaison redondante qui a peu de sens, mais le but était de tester les instructions sur un .shp XYZ; j'ai donc déclaré conjointement POLYGON et POLYGONZ visant le même .shp, et dans un cas comme dans l'autre, ScenProc n'a pas renâclé. Je vais pouvoir cesser de me préoccuper de cette composante Z, bonne chose de faite Maître Arno!

JpP

Edit
Finalement, le résultat du mélange de ces groupings Gropied/Domsimu est plutôt agréable; le panachage des toits industriels me plait bien.

Ce message est originaire d'un autre fil http://www.pilote-virtuel.com/viewtopic.php?pid=520682#p520682 relatif à la gestion des couches XYZ par ScenProc

JpP · [↑]

Bonjour à tous

je livre ici le résultat d'un court échange avec Arno sur l'usage de multiples SETAGNBUILDINGHEIGHT dans le même .spc

Imaginons que vous vouliez créer une zone d'habitations basses entourant un zone de bâtiments plus élevés, typiquement un centre-ville et une banlieue.
L'empilement de la commande SETAGNBUILDINGHEIGHT le permet, à condition de commencer par déclarer la zone la plus étendue, selon cet exemple

SETAGNBUILDINGHEIGHT|délimitation banlieue|1;0.00;0.00;0.0
SETAGNBUILDINGHEIGHT|délimitation centre-ville|0.75;0.25;0.00;0.0

Rien n'empêche de continuer avec d'autres zones dans le style d'un gâteau à étages, ou d'inclure dans la première plusieurs zones distinctes (genre "tête de Toto") ou même se recoupant, en gardant à l'esprit que la dernière empreinte de SETAGNBUILDINGHEIGHT déclarée est prioritaire sur celle(s) sous-jacente(s).

JpP

Dernière modification par JpP (12-02-2013 13:30:50)

Vogel69 · [↑]

Merci JpP pour ces éclaircissement sur cette nouvelle option et pour test explications très intéressantes.

Vogel69 · [↑]

pour les utilisateurs d'ogr2ogr (boite à outil Gdal).

Voici la commande pour filtrer uniquement les données de végétation "utiles" à Scenproc à partir du fichier importé directement depuis Corine2006. Les données "utiles" ont étés déterminés à partir du fichier Scenproc de Gropied pour la végétation et de quelques ajouts perso pour le jardinier d'AGN Merge Tools.

Faire un copier-coller de l'instruction ci dessous (en ayant pris soins de retirer les retours à la ligne si besoin) dans la fenêtre MS-DOS pointant le dossier où se trouve ogr2ogr.exe et le fichier .shp et ses satellites issus de Corine2006 (CLC06_WGS.shp dans cette exemple).

ogr2ogr -where "(CODE_06 > '110' AND CODE_06 <'113') OR (CODE_06 > '140' AND CODE_06 <'143') OR (CODE_06 > '220' AND CODE_06 <'224') OR (CODE_06 = '244') OR (CODE_06 > '310' AND CODE_06 <'314') OR (CODE_06 > '321' AND CODE_06 <'325') " -f "ESRI Shapefile" CLC06_WGS_apres_filtrage.shp CLC06_WGS.shp

Dernière modification par Vogel69 (15-02-2013 12:34:47)

JpP · [↑]

Vogel69 a écrit :

pour les utilisateurs d'ogr2ogr (boite à outil Gdal).
Voici la commande pour filtrer uniquement les données de végétation "utiles" à Scenproc à partir du fichier importé directement depuis Corine2006. Les données "utiles" ont étés déterminés à partir du fichier Scenproc de Gropied pour la végétation et de quelques ajouts perso pour le jardinier d'AGN Merge Tools.
Faire un copier-coller de l'instruction ci dessous (en ayant pris soins de retirer les retours à la ligne si besoin) dans la fenêtre MS-DOS pointant le dossier où se trouve ogr2ogr.exe et le fichier .shp et ses satellites issus de Corine2006 (CLC06_WGS.shp dans cette exemple).
ogr2ogr -where "(CODE_06 > '110' AND CODE_06 <'113') OR (CODE_06 > '140' AND CODE_06 <'143') OR (CODE_06 > '220' AND CODE_06 <'224') OR (CODE_06 = '244') OR (CODE_06 > '310' AND CODE_06 <'314') OR (CODE_06 > '321' AND CODE_06 <'325') " -f "ESRI Shapefile" CLC06_WGS_apres_filtrage.shp CLC06_WGS.shp

Merci pour cette ligne de commande!

Comme j'ai l'intention de planter mes oliviers en PACA, je rajouterai (je tenterai au moins) un petit coup de 223; j'ai fait des essais avec la "vigne", mais les mesquites de taille basse, disséminés un peu partout ne sont absolument pas convaincants; en outre, même si on obtenait une bonne densité, il resterait le problème de la plantation en rangs et de l'orientation desdits rangs.

JpP

Vogel69 · [↑]

JpP a écrit :

... j'ai fait des essais avec la "vigne", mais les mesquites de taille basse, disséminés un peu partout ne sont absolument pas convaincants; en outre, même si on obtenait une bonne densité, il resterait le problème de la plantation en rangs et de l'orientation desdits rangs.
JpP

Tout a fait d'accord vaec toi, cependant pour l'instant je garde cette ligne dans mon fichier scenproc si d'aventure il me prenait d'ajouter dans AGN Merge Tool la possibilité de supprimer un élément en fonction de son GUID... ce qui permettrait au moins de faire un peu de ménage sur les plantations de vignes.

Gropied · [↑]

Mersi JpP d'avoir "creusé" le problème du réglage de la hauteur des bâtiments.
En ce qui concerne la vigne, je suis d'accord,
L'alignement est une donnée essentielle et la plus visible vue d'avion.
On pourrait imaginer un objet de librairie ou objet autogène implanté dans un polygone de végétation scenproc filtré par le code Corine adéquat et qu'AGNMergetools dans un deuxième temps pourrait orienter dans une direction donnée (aléatoire ou orientée sud ?). Cet objet serait constitué d'un petit nombre de rangées de vigne dûment modélisées avec des variantes Cabernet, Sauvignon. Merlaut ou un mélange ... OK ---->sortie

Cordialement

Gropied

JpP · [↑]

Bonjour

La question de l'orientation me semble en effet la principale après celle de l'alignement; une distribution aléatoire serait peut-être la "moins mauvaise" solution. Mais je crains que la méthode procédurale ne nous mène pas bien loin.

Par ailleurs, est-ce la peine (hormis la satisfaction intellectuelle/créative) de poursuivre dans ce domaine (viticole, bien -hips- sûr) que seuls apprécieront les adeptes du crop-dusting? Retour à FSII (pour les vieux qu'ont ... d'la mémoire).

A ce niveau de vol, nous serons confrontés à l'échelle de résolution des textures de tous les éléments, que ce soient les végétaux eux-mêmes ou les bâtiments, mais aussi le tapis photographique.

Pour l'instant sous FSX mon oeil se satisfait de la texture du sol; quant à mes papilles (hors sujet), elles apprécient beaucoup les Alexandrie, Petit Grain, Carignan Noir, Grenache Noir, Syrah et Mourvèdre, Grenache Blanc, Macabeu, Roussanne, Marsanne, Vermentino et Malvoisie du Roussillon.

DR

JpP

jmg · [↑]

Et le pinot noir et le Chardonnay alors!
Vive la Bourgogne,
Sérieusement,pour voler régulièrement en Bourgogne,du côté de Chablis,à1500ft,c'est superbe,maison ne distingue pas les pieds de vigne!
JMG

Dernière modification par jmg (16-02-2013 19:21:19)

Vogel69 · [↑]

J'ai l'impression cette histoire de vigne demande encore beaucoup de travail avant de donner un effet satisfaisant sur notre simulateur. laissons donc murir vos bonnes idées... Elles ne pourrons que se bonifier avec le temps

Gropied · [↑]

@JpP , oui j'ai moi aussi pratiqué le crop-dusting sur FS2, c'était une innovation géniale pour l'époque mais si je relançais le ballon (non pas le verre) c'est parce que dans mes recherches actuelles sur comment profiter le mieux possible des codes Corine, je suis tombé (non je n'avais pas bu) dans la banque GG3D sur des rangs de pieds de vigne modélisés et un certain nombre de châteaux prestigieux 3D. Il n'y a pas que les châteaux de la Loire qui intéressent les touristes et ceux la méritent aussi d'être survolés. Qu'en penses tu JmG ?

@Vogel69 . Il est certain que ce n'est pas notre préoccupation majeure mais je pense que si on sait intégrer de la végétation, représentative d'une région, on aura fait un pas supplémentaire vers la qualité (qui vaut mieux que la quantité. Attention à l'abus).
Attendons la saison des vendanges !

Cordialement ,
Gropied

#651 [↑][↓] 31-01-2013 14:33:30

Re : [FSX]Comment améliorer un autogen de base

#652 [↑][↓] 31-01-2013 15:00:38

Re : [FSX]Comment améliorer un autogen de base

#653 [↑][↓] 31-01-2013 15:29:48

Re : [FSX]Comment améliorer un autogen de base

#654 [↑][↓] 31-01-2013 15:37:35

Re : [FSX]Comment améliorer un autogen de base

#655 [↑][↓] 31-01-2013 17:23:47

Re : [FSX]Comment améliorer un autogen de base

#656 [↑][↓] 31-01-2013 17:54:03

Re : [FSX]Comment améliorer un autogen de base

#657 [↑][↓] 31-01-2013 19:13:30

Re : [FSX]Comment améliorer un autogen de base

#658 [↑][↓] 01-02-2013 15:46:46

Re : [FSX]Comment améliorer un autogen de base

#659 [↑][↓] 02-02-2013 12:12:12

Re : [FSX]Comment améliorer un autogen de base

#660 [↑][↓] 02-02-2013 12:14:10

Re : [FSX]Comment améliorer un autogen de base

#661 [↑][↓] 02-02-2013 19:06:46

Re : [FSX]Comment améliorer un autogen de base

#662 [↑][↓] 02-02-2013 20:29:05

Re : [FSX]Comment améliorer un autogen de base

#663 [↑][↓] 03-02-2013 10:56:06

Re : [FSX]Comment améliorer un autogen de base

#664 [↑][↓] 05-02-2013 11:13:42

Re : [FSX]Comment améliorer un autogen de base

#665 [↑][↓] 10-02-2013 11:18:15

Re : [FSX]Comment améliorer un autogen de base

#666 [↑][↓] 12-02-2013 11:28:58

Re : [FSX]Comment améliorer un autogen de base

#667 [↑][↓] 12-02-2013 17:14:51

Re : [FSX]Comment améliorer un autogen de base

#668 [↑][↓] 15-02-2013 12:33:06

Re : [FSX]Comment améliorer un autogen de base

#669 [↑][↓] 15-02-2013 13:23:24

Re : [FSX]Comment améliorer un autogen de base

#670 [↑][↓] 15-02-2013 14:04:16

Re : [FSX]Comment améliorer un autogen de base

#671 [↑][↓] 16-02-2013 08:40:53

Re : [FSX]Comment améliorer un autogen de base

#672 [↑][↓] 16-02-2013 10:56:38

Re : [FSX]Comment améliorer un autogen de base

#673 [↑][↓] 16-02-2013 19:16:35

Re : [FSX]Comment améliorer un autogen de base

#674 [↑][↓] 17-02-2013 23:47:08

Re : [FSX]Comment améliorer un autogen de base

#675 [↑][↓] 18-02-2013 09:09:40

Re : [FSX]Comment améliorer un autogen de base

Pied de page des forums