Il faudrait un outil qui, - avec la sélection de deux polygones ou multipolygones, les sépare automatiquement en trois parties (polygone ou multipolygone, la partie en intersection étant détachée des parties sans intersection des relations ou polygones d'origine. - avec la sélection de deux polygones ou multipolygones (ou plus), permet de les fusionner un un seul (par exemple refusionner la partie intersection créée dans le premier cas avec un des deux polygones d'origine) (qu'ils soient jointifs ou non, et permettant aussi d'éliminer leur intersection commune.
Dans les deux cas, il y a des fusions d'attributs à faire (dans le premier cas sur la partie en intersection seulement) et il peut y avoir des confits sur des tags incompatibles, l'outil devrait prévenir même s'il fait une fusion simple en accolant les valeurs avec des point-virgules (pas toujours valide, selon le cas il faudra choisir les valeurs à garder et ôter celles en trop. Et l'outil devrait prévenir pour des tags où cette fusion de valeur ne peut pas marcher (tags name=* par exemple). ans doute passer aussitôt un validateur sur la sélection pour signaler les anomalies. Outil intéressant assez compliqué à faire au plan du travail de géométrie, pour cerner les rôles inner/outer à créer et former des "rings" correctement fermés et sans autre auto-intersection que des noeuds isolés (élimination des paires de segments superposés). En évitant aussi dds multipolygones à un seul way membre. Mais qui ferait effectivement gagner du temps en évitant aussi un certain nombre d'erreurs. L'outil doit aussi vérifier avant de scinder ou fusionner un multipolygone que celui-ci a ses ways membres tous chargés. S'il laisse des nœuds isolés après un redécoupage, il doit éviter de les supprimer sans faire un certain nombre de vérification (leurs tags ou le fait qu'ils sont liés à un autre chemin ou membres d'une autre relation. Il devrait aussi prévenir sur ces nœuds ne sont pas dans une zone chargée, et dans le doute devrait les inclure dans une relation de "type=collection"+"collection=residual" plus un "FIXME=*" explicatif, collectant les "résidus" pour faciliter le travail de nettoyage et éviter de laisser des nœuds orphelins sans attribut utile difficile à resituer après la transformation. Si le noeud a des tags utiles (de type POI), ce n'est pas un résidu (exemple; passage piéton, feux de signalisation, noeud d'adresse, poteau ou pylone, lieu-dit: ces attributs devraient être gérés dans une "whitelist" et ne pas être dans la collection de résidus. Ou bien utiliser la "blacklist" des attributs qu'on peut valablement ignorer comme "history=" ou "created_by=*", et "source=*" aujourd'hui déprécié par la mention des sources plutôt dans les changesets). Si la collection de résidus n'est pas désirable, ou moins un tag pourrait être ajouté (exemple FIXME=residual node after splitting/merging polygons") afin qu'ils soient bien visibles dans l'éditeur ou dans les outils d'analyse pour expliquer leur présence (il est possible aussi que cet outil fasse d'autres vérifications automatiques comme télécharger les ways et relations dépendants qui ne seraient pas encore chargés, afin d'éviter d'introduire ces FIXME). Mais je pense qu'une collection de résidus facilite davantage le travail de nettoyage (les vérifs ne peuvent pas facilement se faire sur des groupes de nombreux noeuds dispersés, on doit les traiter quasiment un par un, donc on perd les sélections courantes) que des tags "FIXME" dispersés qu'on peut facilement oublier si les polygones sont assez étendus dans une région déjà dense en données. Le but étant bien de gagner du temps surtout dans les polygones complexes (l'exemple avec un lac et une forêt, ou ente une plage et la ligne de côte peut facilement produire des géométries assez étendues, avec des tas de vérifications à faire sur les relations dépendantes comme les relations de frontières administratives. Le 9 juillet 2014 12:28, Jean-Baptiste Holcroft <jb.holcr...@gmail.com> a écrit : > Je profite de la discussion pour poser quelques questions josm : > * comment peut on découper automatiquement deux landuse qui sur > superposent partiellement ? Exemple : une foret qui mange légèrement un > lac. Actuellement il faut rejoindre chaque point à la main, il peut en > avoir beaucoup selon les cas ... > * comment créer d'un coup un multipolygone avec beaucoup de polygones > intérieurs ? Typiquement cette histoire de building invisibles. > * comment créer un objet qui possède la même emprise que plusieurs autres > ? Exemple basique : trois bâtiments distincts mais collés, qui constituent > un même usage : école, église, bibliothèque, stade. Fusionner les zones > fait perdre des informations et j'imagine que les personnes qui font de la > 3d ont le même problème ... > > Des idées ? > Le 9 juil. 2014 11:59, "Pieren" <pier...@gmail.com> a écrit : > >> 2014-07-09 11:40 GMT+02:00 Antoine Riche <antoine.ri...@ymail.com>: >> > Je suis assez d'accord avec Teuxe pour penser que c'est un problème de >> rendu >> >> Non, non, les règles de rendu ont (encore) changé récemment sur ce >> point. Les building dans des area pedestrians nécessitent à nouveau la >> création d'un multipolygon pour l'area pedestrian. Je dis "à nouveau" >> parce que ça ne l'était pas aux débuts d'OSM puis ça l'était devenu il >> y a 4..5 ans puis ça ne l'était plus avec l'adoption du nouveau style >> carto-css puis ça vient d'être rétabli il y a quelques jours. >> >> Voir l'annonce ici: >> https://lists.openstreetmap.org/pipermail/tagging/2014-June/018043.html >> >> Le ticket sur le dépôt (repository github) de la feuille de style: >> https://github.com/gravitystorm/openstreetmap-carto/pull/623 >> >> Et fait, ce changement ne fait que rétablir la règle qui prévalait >> avant la migration vers carto-css. L'usage du tag "layer" pourrait se >> justifier sur le building dans certains cas très rares (comme des >> bâtiments sur pilotis/piliers avec circulation pédestre possible au >> niveau du sol sous la structure; voir la discussion sur le fil >> anglais). >> >> Mais comme cette règle a souvent varié, ça explique qu'on trouve dans >> OSM ce mélange entre area pedestrian et building en relations >> multipolygons qui, elles, ont toujours fonctionné et des cas plus >> récents qui n'ont pas la relation multipolygon et qui brutalement >> n'affichent plus les buildings comme dans le cas présent. >> >> >> Par contre, en regardant sur Bing, je suis d'accord pour dire que le >> area pedestrian est trop grand. Il ne doit pas inclure la partie >> herbeuse identifée par ce polygone: >> http://www.openstreetmap.org/way/157853597 et qui n'est pas une zone >> pédestre en libre circulation. >> >> Le way identifiant le mémorial >> http://www.openstreetmap.org/way/157853589 doit rester mais il faut >> faire un autre polygone pour la partie pédestre en libre circulation >> (qui n'existe pas actuellement), le faire en multipolygone pour y >> mettre les bâtiments dans son emprise en "inner" ring et y migrer les >> tags "highway=pedestrian" et "area=yes". >> Le tag "name=Mémorial de l’Abolition de l’Esclavage" + >> "historic=memorial" restent sur le grand polygone. Perso, je >> supprimerais le tag "tourism=attraction" contre lequel je me bat >> depuis longtemps (trop subjectif et souvent péjoratif). >> Y-a-pu-ka >> >> Pieren >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
