J'ai un fichier de formes assez détaillé avec des fonctionnalités de polygone / multipolygone (le fichier fait environ 500 Mo). C'est en fait un fichier de formes du monde entier, avec les caractéristiques représentant les côtes. J'ai besoin de diviser ces données à l'aide d'une grille. Pour être clair, je ne veux pas «trier» les données, mais découper les polygones en tuiles. Je réalise que cette question a déjà été posée mais les solutions que j'ai trouvées n'ont pas fonctionné pour moi.
J'ai essayé:
En utilisant QGIS et en croisant le contenu de mon fichier de formes avec une grille vectorielle - les résultats sont terribles. La plupart des principales terres émergées disparaissent comme par magie, bien qu'il semble que de plus petits morceaux de terre y parviennent parfois. Je dois noter que cette méthode fonctionne très bien avec des données beaucoup plus simples (c'est-à-dire moins de points)
Utilisation des outils d'intersection d'OGR. Je l'ai essayé à la fois via ogr2ogr et même en faisant rouler mon propre outil C ++. Les deux ont le même problème que QGIS. Ils ne présentent pas non plus ce problème pour les fichiers simples, mais échouent aux plus complexes. Pour référence, j'utilise un fichier de formes de l'Australie et de la Nouvelle-Zélande, de moins de 20 Mo, et QGIS et OGR ne parviennent pas à le `` mailler ''.
Quelqu'un a suggéré d'utiliser PostGIS à un moment donné, car il a une fonction d'intersection - mais ST_Intersect de PostGIS utilise le même back-end GEOS que OGR. En fait, ils appellent tous les deux la même fonction pour autant que je sache, donc je ne pense pas que PostGIS produira des résultats différents.
Je cherchais des suggestions sur ce que je pouvais essayer d'autre. J'ai besoin d'une application ou d'une boîte à outils robuste qui peut diviser des fichiers de formes très détaillés en tuiles.
EDIT: Ajout d'informations supplémentaires
En réponse à Simbamangu:
Le fichier de formes est essentiellement des données côtières d'OpenStreetMap. C'est une version fusionnée du fichier 'processor_p' (donc ce n'est pas divisé en tuiles) que j'ai obtenu en envoyant un e-mail à leur liste de développeurs. Notez que leur division des tuiles (en morceaux de 100 km x 100 km avec chevauchement) n'est pas nécessairement ce que je veux - je ne veux pas de chevauchement, et je veux la liberté de choisir la taille de la grille, ou j'utiliserais simplement le traitées par défaut_p.
Par défaut, les données du littoral comportent des erreurs de géométrie signalées par QGIS. Je corrige ces erreurs avec un petit outil que j'ai mis en place à l'aide d'un code que j'ai trouvé conçu pour résoudre spécifiquement ce problème (réparation des erreurs de géométrie dans les données du littoral: https://github.com/tudelft-gist/prepair ). Le fait de parcourir les fichiers avec cet outil corrige pratiquement toutes les erreurs détectées par QGIS. J'essaie seulement de faire l'intersection après avoir nettoyé les fichiers.
Exactement ce que j'ai fait en utilisant QGIS: ouvrez les données pour vous assurer qu'elles sont correctes dans QGIS. Essayez de le diviser en tuiles en créant une couche de tuiles à l'aide de la grille vectorielle avec un espacement spécifié, puis en coupant les deux couches - pas question. Essayez d'utiliser un ensemble de données plus petit - sélectionnez des fonctionnalités en Océanie (Aus, NZ) pour essayer un ensemble de données plus petit - ce fichier de forme a une taille <20 Mo. Essayez à nouveau de le diviser, cela ne fonctionne pas.
Ce que j'ai fait avec OGR: ogr2ogr en utilisant directement les options '-spat' et '-clipsrc' avec spat_extent. A également écrit un petit outil C ++ qui fonctionne sur WKT, donc je convertis le fichier de formes en WKT en utilisant ogr2ogr, puis j'alimente le fichier texte dans mon application. Il parcourt le fichier et appelle la méthode Intersection () documentée ici: http://www.gdal.org/ogr/classOGRGeometry.html . Je pense que cela finit par faire exactement la même chose que d'utiliser directement ogr2ogr.
En réponse à Brent:
- Cela fait. Tout est en WGS84 Lat / Lon
- J'aurais pensé que le contraire est vrai - que pour un ensemble donné de tuiles de grille, il faudrait beaucoup plus de temps pour croiser un multipolygone géant plutôt qu'un tas de caractéristiques fragmentées qui pourraient être plus spatialement localisées sur chaque tuile, mais c'est une suggestion intéressante - je vais l'essayer et faire rapport.
- Aucun champ d'attribut n'est conservé pendant le processus, je ne m'intéresse qu'à la géométrie.
- Je ne suis pas sûr, mais je pense que vous dites que je devrais sélectionner les polygones qui chevauchent une tuile de grille donnée, puis effectuer l'intersection. C'est trop lourd manuellement avec QGIS. Mon outil le fait déjà dans une certaine mesure avec une case à cocher englobante. Il y a un peu d'accélération, mais le résultat final est toujours médiocre et pas sensiblement différent.
- Ce n'est pas une option. En ce moment, j'essaie de diviser les données de manière à ce que leur 1 deg lat x 1 deg lon, et je cherche une méthodologie générale / robuste qui fonctionne avec tous les cas. J'ai essayé d'augmenter la taille de la grille (c'est-à-dire 10 x 10) pour voir si j'obtiendrais de meilleurs résultats et je ne vois aucune corrélation entre la taille de la grille et la qualité de la sortie.
Édition n ° 2:
J'ai essayé de jouer avec cela plus et en général, il semble que les résultats ne soient pas fiables à la fois en utilisant GEOS et avec QGIS (qui utilise fTools, je ne sais pas si cela utilise à son tour GEOS à nouveau). J'ai eu tort de dire que la taille de la grille n'a rien à voir avec les résultats - plus la grille est grande, meilleurs sont les résultats (c'est bon à savoir mais toujours pas une solution). Voici une capture d'écran d'une grille très espacée qui a fonctionné principalement, mais a échoué partiellement sur une seule tuile:
La géométrie est propre - QGIS affiche 0 erreur avec l'outil "Vérifier la validité". Je ne cherche pas à aborder ce problème pas à pas; vérifier si certaines entités ont échoué ou non l'intersection sur un jeu de données si grand quand il n'est pas visuellement apparent (et ce ne sera pas avec des tuiles plus petites) n'est pas pratique.