<div dir="ltr">Cette carte masque beaucoup trop de choses : elle masque les polygones simples (avec un seul way fermé) qui n'ont aucune raison d'employer un multipolygone, et pour lesquels il est normal que ce soient les ways qui portent les attributs ! (Note: cela concerne même des polygones fermés qui ne partagent aucun noeud ou chemin avec un polygone voisin).<div><br></div><div>LA plupart des différences sont dues à ça, il reste en fait bien peu de multipolygones à "l'ancienne" dans OSM (raison de plus pour ne plus faire la "remontée" des attributs communs des ways membres vers la relation membre. Ce qu'il vaut mieux chercher ce sont les multipolygones sans attributs significatifs, et ceux dont les attributs sont identiques dans les ways membres (way membres à nettoyer): c'est ce que fait JOSM par exemple dans son validateur, au moins sur les chemins qu'on a modifiés ou les relations dont les chemins sont chargés.</div><div><br></div><div>Cependant au delà de JOSM, il me semble que c'est du boulot de nettoyage des chemins qu'Osmose devrait signaler (uniquement en cas de doublon d'attribut entre une relation et un way membre). Quand il n'y a pas de doublon mais que les attributs sont présents à l'identique dans les way membres, et ces attributs ne sont pas des highway=* et qu'il n'y a pas area=no dessus, on peut aussi signaler cette redondance. Sinon si un attribut est identique dans tous les ways membres mais avec area=no, il faudrait remonter ces attributs dans la relation QUE si celle-ci n'est PAS taguée avec area=yes ou si celle ci n'a renseigné aucun area=.</div><div><br></div><div>En pratique les "area=yes" sont rares et concernent surtout les aires piétonnes, limitées non pas par les rues qui les bordent mais toute leur surface, trottoirs inclus (et mobilier urbain inclus). Il y a peut-être quelques autres exceptions mais pas dans ce qu'on voit couramment. Les "area=no" ne devraient plut être nécessaires sauf pour des relations comprenant un ensemble de rues piétonnes, mais en général ce sont plutôt des polygones définissant des aires résidentielles ou des aires délimitant un secteur piétonnier où quelques rues les traversent en tant que "zones de rencontre", mais parsemé d'ilots pour les blocs d'immeubles et jardins privés ou cours intérieures: le secteur priéotnnier sert alors surtout de limite extrême d'application d'une régulation routière qui ne s'applique qu'aux voies publiques incluses dans le polygone: ce polygone n'est donc pas réellement une surface, mais plutôt une frontière (qui devrait donc plutôt être tagué comme "boundary" et non comme "multipolygon", et qui ne devrait donc être rendu que sur sa bordure et non dans toute la surface incluse, ou alors rendu sur une surface de façon semi-transparente mais pas totalement couvrante).</div><div><br></div><div>Note: je ne distingue jamais "frontière" ou "surface". Toute frontière intrinsèquement sert à délimiter une surface, ce n'est pas qu'un simple tracé linéaire (sinon on n'aurait jamais besoin de distinguer dans les "boundary" les deux rôles "inner" ou "outer". LEs deux interprétations sont possibles selon l'usage qu'on en fait. La différence c'est avant tout un choix de rendu: soit un ensemble de traits de bordure, soit une surface transparente, parfois les deux., avec possibilité d'inscrire les libellés soit le long de la bordure (côté intérieur comme sur le rendu OSM FR, et non extérieur comme le rendu OSM par défaut qui est très trompeur!), soit centré dans la surface incluse, soit à la position d'un noeud membre "label" si on ne veut pas qu'il soit exactement au centre où il pourrait déborder sur une enclave normalement exclue. Dans un rendu non cartographique, l'aspect "frontière" est le plus souvent ignoré, on se sert surtout de la propriété géométrique d'inclusion ou pas des points testés dans la surface circonscrite.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 12 décembre 2016 à 23:34, Vincent de Château-Thierry <span dir="ltr"><<a href="mailto:osm.vdct@free.fr" target="_blank">osm.vdct@free.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bonsoir,<br>
en echo à la discussion de ces jours-ci sur les parcelles forestières, voici une ressources dédiée au sujet des Multipolygons. On y voit l'influence du schema de tagging, notamment lorsque les attributs du polygone sont portés par les ways constituants. C'est transparent tant que les ways ont un jeu d'attributs homogène, ça devient beaucoup plus casse-tête dès que des valeurs divergent voire se contredisent.<br>
<br>
Plusieurs facettes d'un même projet pour mettre en évidence ces "vieux" multipolygones :<br>
<br>
la carte : <a href="http://area.jochentopf.com/map/index.html#16/48.8519/2.3124" rel="noreferrer" target="_blank">http://area.jochentopf.com/map<wbr>/index.html#16/48.8519/2.3124</a><br>
les données en téléchargement : <a href="http://area.jochentopf.com/" rel="noreferrer" target="_blank">http://area.jochentopf.com/</a><br>
les explications : <a href="https://github.com/osmlab/fixing-polygons-in-osm/blob/master/README.md" rel="noreferrer" target="_blank">https://github.com/osmlab/fixi<wbr>ng-polygons-in-osm/blob/master<wbr>/README.md</a><br>
<br>
La carte permet de visualiser où se situent les multipolygones taggués à l'ancienne. Sur la partie droite, ils sont masqués.<br>
<br>
À vos explorations...<br>
<br>
vincent<br>
<br>
______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-fr</a><br>
</blockquote></div><br></div>