[OSM-talk-fr] Explosion d'un carrefour

[Philippe Verdy]

Le 30 septembre 2013 11:21, V de Chateau-Thierry <vdct at laposte.net> a écrit
:

> Bonjour,
>
> > De : "Pieren"
> >
> > 2013/9/30 Philippe Verdy :
> >
> > > Je maintiens que c'est une erreur de ne pas taguer le multipolygon
> lui-même
> > > alors qu'il est crée spécifiquement pour créer un "trou" dans la
> surface
> > > qu'il décrit,
> >
> > Ben, c'est juste un problème de définition. On peut aussi bien dire
> > que la relation de type "multipolygon" se contente de décrire une
> > géométrie, une surface, avec ou sans trous, et que les tags restent
> > sur le way externe. Après tout, cela donne une certaine cohérence avec
> > les autres surfaces sans trou. On pourrait aussi dire que la relation
> > décrit l'objet dans son ensemble, en plus de sa géométrie. C'est donc
> > juste un point de vue et les deux sont acceptables.
>
> Sauf qu'en parlant du "way externe" (au singulier), tu raisonnes sur un
> cas particulier.
> Et même si ce cas est largement implémenté, par exemple pour les bâtiments
> avec une cour
> intérieur, ça reste un cas particulier.
>

J'ai exactement le même point de vue. La cuisine de l'outil de conversion
ne sert qu'à réparer sommairement des anomalies, mais cela reste des
anomaies et les réparations peuvent être fausses à cause justement du tri à
faire entre les tags à remonter ou pas.

Heureusement JOSM fait les choses bien quand on crée un multipolygone à
partir d'un polygone fermé pour le découper et y ajouter ensuite des îlots
internes.

La "solution" de Pieren marche seulement très temporairement (masi cette
façon de faire est une solution de facilité, vraiment paresseuse, en plus
du fait qu'lel demande pour marcher une redondance très importante (qui
vite entrainera des conflits).

Mais l'absence de correction finit toujours par causer des problèmes
d'interprétation (et si plus tard le mulpolygone est cassé on ne sait même
plus pourquoi il était là et ce qu'il décrivait, il n'y a plus moyen de
réparer et ce multipolygone sans aucune signification regroupant des
chemins non fermés et ayant des tags disparâtres sera condamné à être
effacé. Bref ça sent aussitôt des gros dégats ou des nettoyages où il faut
recommencer les taggings dans la zone car on ne sait plus ni où ni quoi
chercher !

A mon avis l'outil de conversion OSM vers GIS ferait bien de tenir un log
de ces corrections qu'il tente de faire, sous une forme qui puisse être
réimporté vers un outil de gestion qualité comme Osmose, chaque fois qu'il
décide d'importer des tags de chemins vers un polygone GIS de surface, fin
de lver les doutes ou confirmer au moins que c'est correct.

Il devrait ensuite relever (mais c'est beaucoup moins grave si on ne fait
qu'un rendu, mais c'est assez sérieux pour une analyse destinée à savoir si
un point est dans une surface ou pas...) les tags redondants des chemins
quand ils sont identiques à une relation membre).

Enfin il ne faut pas oublier qu'OSM n'est pas destiné uniquement à générer
des rendus pour Mapnik ! L'outils en question dont parlait Pieren n'est en
fait taillé qu'en fonction de Mapnik et rien d'autre. Et pour des rendus
plus personnalisés (comme ceux de Mapbox), il a aussi été remanié
spécifiquement. Tous les outils ne peuvent pas utiliser les mêmes jeux de
règles pour leur heuristique de correction car ils auront leurs propres
besoin et n'exploiteront pas les mêmes sous-ensembles de données ou
reclassifications.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130930/a034a559/attachment.htm>