[OSM-talk-fr] Priorite concernant les differents layers pour Corine
Emilie Laffray
emilie.laffray at gmail.com
Jeu 14 Mai 12:41:48 UTC 2009
Bonjour,
oui j'ai vu le thread sur la ML anglaise.
Ce qui est possible de faire (je verifierais une fois que j'aurais
importe la France dans ma base de donnee ce soir) c'est d'utiliser
postgres et de trouver tous les polygones qui se superposent.
C'est assez facile a faire avec Postgis. OpenJump utilise JTS comme
moteur geometrique, qui n'est autre que la version source de la
librairie utilisee dans Postgis.
LibGeos est le port C++ de JTS.
Une fois qu'on a trouve les polygones qui posent conflits il faut voir
ce qu'on veut faire avec. Il est potentiellement possible de creer une
table qu'on exporte en OSM via SHP avec les polygones superposes pour
montrer les erreurs. Apres, il faut voir comment on corrige cela.
Je pense que l'on peut automatiser la detection de conflit assez
facilement a partir du moment ou l'on travaille a partir de la base de
donnee. On peut peut etre commencer par ecrire les regles de detection
de conflits. Postgis est vraiment tres souple de ce point de vue la du
moment qu'on ecrit la bonne requete SQL. Pour avoir travailler sur
certaines choses sur l'Australie, je suis globalement assez contente
de la vitesse que Postgres a pour ce genre de chose.
Postgres gere bien malgre tout les tables atteignant facilement les
80M de lignes. Il est meme possible d'optimiser cela en utilisant des
partitions tables qui sont en fait des heritages d'une table mere.
Emilie Laffray
2009/5/14 Pieren <pieren3 at gmail.com>:
> 2009/5/14 Emilie Laffray <emilie.laffray at gmail.com>:
>
> Sinon, j'ai ouvert la discussion sur la ML anglaise et il y a
> différentes idées de ce qui été fait ailleurs mais aucune que je
> trouve satisfaisante pour l'instant:
> - tout transférer dans la base mais aucun tag qui rende les données
> visibles. Après, chacun décide au cas par cas d'ajouter les tags et de
> résoudre les conflits à la main. Une carte spéciale est créée avec un
> rendu particulier pour afficher les données non résolues.
> - certaines zones sont déclarées comme plus fiables que les données
> importées et ses zones ne sont pas inclues dans l'import
> - un serveur WMS est mis en place et chacun décide au cas pas cas de
> copier les objets du WMS vers OSM.
> - même en cherchant bien, je n'ai pas trouvé de script qui gère les
> conflits d'import dans OSM. Le wiki suggère d'utiliser un outil comme
> OpenJUMP automatch [1]. Mais ça se limite à de petites zones.
>
> Pour ma part, je verrais bien une solution de ce genre:
> - on importe toutes les forêts par exemple directement avec les bons
> tags, quitte à créer des superpositions dans OSM avec des données déjà
> existantes;
> - une carte spéciale est créée avec un rendu pointant les zones de
> conflit (par ex. les polygones de forêt CLC se superposant à d'autres
> polygones sont affichés en rouge).
> - les zones de conflit sont résolues à la main jusqu'à disparition
> totale des conflits sur le rendu spécial
> - on peut le faire couche par couche au niveau national ou plusieurs
> couches d'un coup sur un département. A voir.
> Vous en pensez quoi ?
>
> Pieren
>
> [1] http://wiki.openstreetmap.org/wiki/Bulk_import_as_a_data_layer
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
Plus d'informations sur la liste de diffusion Talk-fr