Tu ne dis pas quelles sont ces deux façons de faire, Même si on lisant ta réponse sommaire j'ai l'impression qu'on défend la même chose. Mais faute de détail dans ton message (pusique tu n'as rien cité avec) impossible de le savoir ce que tu défends réellement. Si tu dis ici que j"ai défendu selon toi la duplication de ways, ce n'est pas du tout ce que j'ai écrit et tu as mal lu.
Pour moi le seul cas où des polygones dupliqués sont justifiés c'est quand leurs tags sont incompatibles ensembles sur le même objet et ça concerne essentiellement le cas où un même tag doit prendre deux valeurs simultanées alors que logiquement ces des valeurs sont incompatibles (exemple : deux hauteurs différentes : cas qui survient avec les étages d'un même bâtiment par exemple; cas de batiments-ponts, ou de certaines données 3D simples non modélisées dans une base à part) Et pourtant on devrait pouvoir éviter la duplication en utilisant une relation et en permettant d'avoir deux fois le même membre avec des rôles différents (à condition de codifier les rôles avec une partie donnée); ou en autorisant pour ce cas là des relations à 1 seul membre (le même pour toutes) pour y mettre sur chacune des tags différents, puis référencer ces relations dans une relation mère construisant l'objet complet. Je pense qu'on peut toujours s'arranger pour éviter la duplication des polygones à condition d'accepter les relations à 1 seul membre (qu'on ne peut pas fusionner dans l'objet membre qu'elles référencent). Et sur ce point il est alors justifier d'apporter une modif à JOSM ou les outils d'analyse pour qu'il ne "râlent" pas sur toutes les relations à membre unique, en lui faisant détecter les tags qui sont incompatibles entre eux pour une telle fusion vers le membre hors de la relation. Le 13 mai 2014 10:29, Pieren <pier...@gmail.com> a écrit : > Je trouve ces deux façons de faire horriblement compliquées et > injustifiées. Il n'y a aucune raison valable de dupliquer le way > "inner" ou faire un multipolygone qui n'est pas "multi" autre que > celle de palier un problème de rendu. Il vaudrait mieux trouver la > solution du côté d'osm2pgsql (en acceptant les inner avec les mêmes > tag que le outer) plutôt que d'imposer ces bricolages aux > contributeurs. > > 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
