[OSM-talk-fr] Ancienne modélisation des multipolygones

Philippe Verdy verdy_p at wanadoo.fr
Lun 12 Déc 23:13:19 UTC 2016


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).

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.

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=.

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).

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.


Le 12 décembre 2016 à 23:34, Vincent de Château-Thierry <osm.vdct at free.fr>
a écrit :

> Bonsoir,
> 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.
>
> Plusieurs facettes d'un même projet pour mettre en évidence ces "vieux"
> multipolygones :
>
> la carte : http://area.jochentopf.com/map/index.html#16/48.8519/2.3124
> les données en téléchargement : http://area.jochentopf.com/
> les explications : https://github.com/osmlab/fixi
> ng-polygons-in-osm/blob/master/README.md
>
> La carte permet de visualiser où se situent les multipolygones taggués à
> l'ancienne. Sur la partie droite, ils sont masqués.
>
> À vos explorations...
>
> vincent
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161213/79c0ef47/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr