Pilote-Virtuel.com - Forum de simulation aérienne / [FSX] Les SIG, QGis et autres

JpP · [↑]

Bonjour

En création de scènes nous sommes confrontés à l'utilisation de données géographiques numériques et avons besoin d'outils pour les traiter. Il s'agit (dans le cas d'outils de cartographie générale et non pas d'outils dédiés à FS) des systèmes d'information géographique, les SIG dans notre langue, GIS pour les anglo-saxons.

Mon propos concerne essentiellement les programmes freeware, mais si vous utilisez des outils payants, rien ne vous empêche d'apporter votre contribution en vous exprimant dans ce fil.

QuantumGis est un SIG OpenSource largement utilisé ici.
Il dispose d'une interface en langue française, d'outils de traitements très diversifiés et efficaces, il est ouvert en entrée comme en sortie sur de nombreux formats autorisant des passerelles avec d'autres programmes.

Jusqu'à présent il était le seul SIG que j'utilisais, mais j'ai eu besoin de traiter d'importants volumes de données, et sur ma machine pourtant musclée, QGis n'était plus guère utilisable en termes de temps de calcul, que ce soit à l'affichage ou en traitement d'arrière-plan comme la fusion de fichiers. Cette faiblesse provient de l'utilisation du code (que l'on peut supposer bien pensé) en 32 bit.

Je me suis donc orienté vers des programmes, toujours freeware, en 64 bit natifs, et ai commencé à me familiariser avec MapWindow, en version 4.8.6

En ce qui concerne la puissance de traitement des données, je revis! Les affichages et les rafraichissements sont, à l'estime, cinq à dix fois plus rapides que sous QGis; je parle ici de gigaoctets de données.

Les outils sont nombreux et performants, même s'il faut le temps de s'accoutumer à l'ergonomie et aux dénominations.

Deux points négatifs associés aux .kml et à Google Earth me font cependant regretter QGis: MapWindow n'importe apparemment pas le format KML et semble bouder GoogleEarth jusque dans l'affichage d'une couche de fond d'imagerie géoréférencée. Je n'ai pas trouvé jusqu'ici le moyen (il existe, en statique et au prix dre trop de manipulations) d'obtenir simplement cet affichage.
Certains pourront par ailleurs regretter la francisation incomplète de l'interface.

Néanmoins, et pesant les avantages et les inconvénients, je préfère largement MapWindow. Il en existe une version 6 qui ne m'a pas convaincu d'abandonner la v4.

Quel que soit le SIG que vous utilisez, je vous invite à venir en témoigner ici, l'expérience et les astuces des uns pouvant être profitables aux autres.

JpP

Edit Mais en matière de rendu final, mon SIG préféré reste quand même... FSX.

Dernière modification par JpP (01-02-2013 15:41:29)

Vogel69 · [↑]

très intéressant ce post JpP, merci pour cette exposé détaillé eusa_clap

pour info ogr2ogr.exe(faisant partie des outils du projet GDAL), petit programme en ligne de commande DOS est plutôt efficace et rapide pour la manipulation des grosses données.

Il permet par exemple la fusion de fichiers, la conversion, l'extraction des données en fonction de divers filtres (sur les attributes, les coordonnées geographiques, en fonction de l'empreinte d'un autre fichier shp,ect..)

quelques exemple de commandes déjà abordé ici

1/ On isole une partie d'un fichier .shp après application d'un masque

Syntaxe: ogr2ogr -clipsrc FICHIER_MASQUE FICHIER_DESTINATION FICHIER_SOURCE

Création d'un fichier .shp après extractions des polygones d'un fichier .shp en fonction d'un polygone contenu dans un autre fichier (ici de type .kml). exemple: j'ai un fichier de végétation couvrant la partie Sud-est de la France et je veux isoler que la partie correspondant à la Loire.

exemple: ogr2ogr -clipsrc Loire.kml forets_Loire.shp forets_Sud_est.shp

2/ Creation de plusieurs fichiers .shp en fonction des "attributes" disponible

exemple: On isole les differents types de routes du fichier ROAD.shp dans des fichiers differents

// Autoroutes 4 voies (pour appliquer un "tampon" de 0.0001 dans Qgis par la suite)

ogr2ogr -where "type LIKE 'motorway' OR type LIKE 'trunk'" -f "ESRI Shapefile" roads_high.shp roads.shp

// routes principales et autres (pour appliquer un "tampon" de 0.00006 dans Qgis par la suite)

ogr2ogr -where "type LIKE 'primary' OR type LIKE 'secondary' OR type LIKE '%link' OR type LIKE 'tertiary'" -f "ESRI Shapefile" roads_prim.shp roads.shp

3/ Fusion de plusieurs fichiers .Shp en un seule

exemple: je veux fusionner mes fichiers Roads spécifques après avoir appliquer un tampon dans Qgis pour former le fichier complet des routes d'un département.

// fusion de 2 fichiers: roads_high_poly.shp + roads_prim_poly.shp => merge_road_poly.shp

ogr2ogr merge_road_poly.shp roads_high_poly.shp
ogr2ogr -update -append merge_road_poly.shp roads_prim_poly.shp -nln merge_road_poly

// puis on isole la partie correspondant au département de la Loire

ogr2ogr -clipsrc Area.kml merge_road_poly_loire.shp merge_road_poly.shp

plus d'info sur ogr2ogr et ses fonctions-> http://www.gdal.org/ogr2ogr.html

Dernière modification par Vogel69 (01-02-2013 19:09:33)

JpP · [↑]

Merci Vogel pour cet apport; je vais regarder ça de très près.
La ligne de commande doit justifier toute son utilité une fois qu'on a bien trouvé ses marques en visuel avec les SIG graphiques. Il va y avoir du paramètre à assimiler!

JpP

Dernière modification par JpP (01-02-2013 20:31:24)

jollyroger · [↑]

Sympa ton sceenshot !

un peu plus vers le haut et je voyais ma maison

JpP · [↑]

jollyroger a écrit:
Sympa ton sceenshot !

un peu plus vers le haut et je voyais ma maison

Bon, je vais refaire un passage bas, baisse la tête! wink

JpP

jollyroger · [↑]

JpP a écrit:
jollyroger a écrit:
Sympa ton sceenshot !

un peu plus vers le haut et je voyais ma maison
Bon, je vais refaire un passage bas, baisse la tête!

JpP

ok mais je ne me jette pas dans l'étang, elle est trop fraiche ! laugh

Gropied · [↑]

Merci JpP tes recherches amèneront certainement un progrès dans la conception de masse.
Mais je dois dire que c'est la première fois que je relis un post deux fois avant de réaliser. QGIS me paraissait l'outil incontournable et tu le remets en cause. Même chose pour Vogel69 ! J'ai l'impression d'être doublé simultanément par la gauche et par la droite comme en Formule1, d'être à l'arrêt, en panne de progrès. wacko
Chapeau tous les deux !
Oui le 64 bits est plus rapide, (je possède aussi une station 64) mais tout mon "plan de travail" est sur 32. Va vraiment falloir que je largue XP...et que je recolle les wagons pour rester dans la course !
Le Cherbourg et environs que je viens de mettre à dispo à été fait il y a un an avec les outils QGIS et OpenOffice selon la méthode de mon tuto que je n'ai plus qu'à jeter aux orties...presque tout est à réécrire
Je vais de ce pas télécharger Mapwindows...et continuez cette fuite en avant eusa_clap pour notre plus grand bien.

Cordialement,

Gropied

JpP · [↑]

Bonjour à tous

Meuuuuhhh non, Gropied! Il n'y a pas de compétition et tu n'es encore moins dépassé.

Pour ma part, et contrairement à vous, je ne suis qu'un fouineur, je cherche et je lance des idées la plupart du temps fausses ou irréalisables, et quand elles aboutissent, ce n'est pas par moi mais par vous, toi, Vogel et d'autres. En fait, j'apprends tous les jours à votre contact.

Mais tu évoques une fuite en avant, et là je suis pleinement d'accord avec toi; chaque petite ou grosse amélioration entraine une remise en chantier de ce que nous étions contents d'avoir produit et c'est en cela que l'équipe de France VFR est très performante en gardant deux ans d'avance (citation) sur ce que les autres commencent à faire; mais même eux sont confrontés à ce problème d'auto-dépassement permanent, sauf qu'ils en retirent une compensation financière justifiée.

J'ai rapidement jeté un oeil sur gdal/ogr; sans l'avoir vérifié, il me semble avoir vu qu'il en existe une version 64 bit; si c'est réellement le cas, pourquoi QGis ne passerait-il pas en 64 dans la mesure où sous son interface graphique il utilise le noyau ogr...

MapWindow est pour moi, pour l'instant, complémentaire de QGis dans la chaîne de traitement des données, en attendant que j'y intègre gdal. Tu vas mettre à jour dans MW des avantages et inconvénients que je n'ai pas vus et on pourra refaire le point; MW me semble être plus "jeune", moins abouti que QGis, un peu moins ergonomique, mais tellement plus rapide; laissons lui le temps de mûrir...

Merci d'avoir lu (et relu wink ) le post initial et la suite

JpP

gpf · [↑]

Hello tout le monde,

Désolé de m'immiscer dans la discussion.. mais je ne comprends pas bien ce que vous cherchez à faire ??

Du coup, quelques mots d'une méthode qui me semble très efficace pour découper un fichier de données OSM suivant un polygone défini (désolé si j'ai rien compris et que c'est hors sujet...)

1/ Tout d'abord on télécharge les données au format .osm et non pas .shp à partir de Geofabrik

2/ Le .osm est en général assez gros comme fichier donc si on pouvait le faire maigrir un peu sans perdre les données qui nous intéressent ça serait pas mal.
La solution nous est amenée par osmconvert : http://wiki.openstreetmap.org/wiki/Osmconvert

Petit utilitaire mais puissant ! osmconvert se lance en double-cliquant sur l'exe tout simplement (Pour ma part, je l'ai mis dans le même répertoire que Scenproc, et que mon fichier .osm !)

Une fois lancé, vous pouvez taper directement la ligne de commande correspondante à ce que vous souhaitez faire... Sinon entrer "a" et votre nouveau meilleur copain Bert arrive, et il ne reste plus qu'à se laisser guider !

On entre le nom du fichier que l'on souhaite triturer (exemple : MP.osm)

On choisit l'option 5 (en tapant 5 donc) et on valide. Cette action va faire maigrir votre fichier .osm en supprimant les informations de timestamp et les noms des auteurs (que l'on remercie mais là on va les couicker!) des modifications de la base données OSM. Et vous pourrez en juger par vous-mêmes ça représente quelques centaines de Mo, voire Go !! Les traitements futurs n'en seront qu'accélérés.

3/ Une fois fini, on relance osmconvert, on appelle notre ami Bert, on retape le nom du fichier .osm (Attention l'allegé cette fois !). Et nous allons utiliser l'option 4 => utilisation d'un polygone pour sélectionner les objets OSM dans notre fichier, et j'aimerais bien que mon polygone de sélection soit les contours d'un département par exemple !

Mais osmconvert ne comprend que les fichiers polygone de type .poly et les seuls découpages des départements français que j'ai trouvé sont soit des .kml (exemple : site Karamelise) soit des .shp (http://export.openstreetmap.fr/contours-administratifs/)

Pas de panique, un plugin QGIS (OSMPOLY_export) existe, dispo ici : http://plugins.qgis.org/plugins/plugins.xml

Après l'installation du plugin, on ouvre son fichier .shp de découpage du ou des département(s), on le sélectionne et on exporte tout ça en .poly
On peut choisir de le nom par son nom ou son numéro.. personnellement je choisis numéro, ça fait moins long à écrire ensuite

4/ Retour dans osmconvert :
- "a" pour avoir notre ami Bert
- nom de fichier allégé
- option 4

=> On tape le nom du fichier .poly (exemple : 31.poly), on valide... et on hallucine du peu de temps de traitement nécessaire pour découper notre fichier .osm suivant notre polygone .poly, j'ai pas trouvé plus efficace !

Le fichier est alors plus facilement manipulable dans QGIS pour faire d'autres traitements et le découpage a été fait "proprement"...

En espérant que cela vous aide,

Dernière modification par gpf (02-02-2013 14:21:24)

JpP · [↑]

Salut Guillaume

Voilà une contribution comme j'aime les lire, copieuse documentée ... et utile.

gpf a écrit:
.. mais je ne comprend pas bien ce que vous cherchez à faire ??

Initialement ce topic visait les outils de traitement numérique de l'information géographique (pompeux, is'nt it?)

donc davantage le "comment" on cherche à faire que le "quoi", mais je pinaille wink , ça se rejoint.

Le but (pour moi du moins) est de manipuler des données qui commencent à peser, de la manière la plus efficace en termes de possibilités et de rapidité; à propos de gdal/ogr Vogel avait expliqué l'extraction masquée, mais je suppose que c'était à titre d'exemple.

En tout cas ta contribution correspond tout-à-fait à mes attentes d'enrichissement partagé de ces moyens de traitement.

Merci

JpP

JpP · [↑]

gpf a écrit:
...quelques mots d'une méthode qui me semble très efficace pour découper un fichier de données OSM suivant un polygone défini ...
En espérant que cela vous aide

Bonjour Guillaume

Suite à ton post, je t'avais remercié pour ta contribution au fil que j'avais initié, et maintenant c'est au sujet de la mise en pratique de tes conseils que je viens te dire combien j'apprécie l'outil osmconvert et le tuto que tu as mis à notre disposition.

Faciles, rapides, ce programme et ta méthode facilitent bien les manipulations.
Merci encore

JpP

gpf · [↑]

JpP a écrit:
gpf a écrit:
...quelques mots d'une méthode qui me semble très efficace pour découper un fichier de données OSM suivant un polygone défini ...
En espérant que cela vous aide
Bonjour Guillaume

Suite à ton post, je t'avais remercié pour ta contribution au fil que j'avais initié, et maintenant c'est au sujet de la mise en pratique de tes conseils que je viens te dire combien j'apprécie l'outil osmconvert et le tuto que tu as mis à notre disposition.

Faciles, rapides, ce programme et ta méthode facilitent bien les manipulations.
Merci encore

JpP

Oups JpP, désolé mais je n'avais pas vu cette réponse avant aujourd'hui, content d'avoir pu t'aider wink

JpP · [↑]

Bonjour

La version 2.01 de QuantumGis est sortie sous le nom de QGis Dufour.
Elle est disponible en 32 et 64 bit, avec déjà un certain nombre de plugins disponibles pour ce dernier environnement.
http://qgis.org/en/site/

JpP

Dernière modification par JpP (03-10-2013 09:30:38)

#1 [↑][↓] 01-02-2013 12:03:45

[FSX] Les SIG, QGis et autres

#2 [↑][↓] 01-02-2013 16:34:18

Re: [FSX] Les SIG, QGis et autres

#3 [↑][↓] 01-02-2013 18:31:43

Re: [FSX] Les SIG, QGis et autres

#4 [↑][↓] 01-02-2013 20:15:03

Re: [FSX] Les SIG, QGis et autres

#5 [↑][↓] 01-02-2013 20:33:35

Re: [FSX] Les SIG, QGis et autres

jollyroger a écrit:

#6 [↑][↓] 01-02-2013 20:48:15

Re: [FSX] Les SIG, QGis et autres

JpP a écrit:

jollyroger a écrit:

#7 [↑][↓] 02-02-2013 09:13:19

Re: [FSX] Les SIG, QGis et autres

#8 [↑][↓] 02-02-2013 10:52:17

Re: [FSX] Les SIG, QGis et autres

#9 [↑][↓] 02-02-2013 14:14:40

Re: [FSX] Les SIG, QGis et autres

#10 [↑][↓] 02-02-2013 14:34:50

Re: [FSX] Les SIG, QGis et autres

gpf a écrit:

#11 [↑][↓] 16-02-2013 15:49:48

Re: [FSX] Les SIG, QGis et autres

gpf a écrit:

#12 [↑][↓] 25-03-2013 22:53:47

Re: [FSX] Les SIG, QGis et autres

JpP a écrit:

gpf a écrit:

#13 [↑][↓] 03-10-2013 09:29:37

Re: [FSX] Les SIG, QGis et autres

Pied de page des forums