[OSM-talk-fr] micro-maping de "surface"

[Philippe Verdy]

C'est bien dommage car on peut mapper des surfaces quand elles sont
désignées comme parkings. Mais si on essaye de fermer une zone de type
highway, pour l'instant c'est toujours considéré comme uniquement une
ligne de contour (que ce soit fait dans un seul way ou dans plusieurs
au sein d'une relation de type highway).

Effectivement cela vient d'une ambiguïté du modèle OSM, qui ne
différencie pas formellement les lignes des surfaces, mais suppose que
ce sont les autres tags qui permettront de faire la distinction. Pour
un type highway, c'est toujours une géométrie de type ligne qui est
prise en compte. Même quand on essaye de lever l'ambiguïté en marquant
area=yes, les moteurs de rendu n'en tiennet pas compte, ou en mettant
cela dans une relation de type=multipolygon (qui normalement ne
devrait être QUE de type surface, au contraire de
type=multilinestring) selon les normes GIS (Well-Known Text).

Bref l'ambiguïté doit être levée lorsqu'on convertit le modèle OSM
simplifié en modèle GIS (par exemple avec osm2pgsql, le principal
outil utilisé ensuite par les moteurs de rendus qui s'appuient sur le
modèle GIS normalisé et non le modèle OSM trop basique) : ce sont les
tags présents qui indiquent comment convertir un way ou une suite de
ways soit en MultiLineString ou LineString (linéaire), soit en
MultiSurface ou Surface.

Cela se complique en fait car le modèle GIS standard impose aussi
d'autres contraintes : il faut résoudre l'orientation des lignes si on
veut en faire une surface, car le modèle GIS différencie les surfaces
incluant soit leur intérieur (cas habituel : les lignes de la bordure
sont alors toutes à orienter dans le sens antihoraire sur nos
projections cartographiques visualisant la terre depuis un point
distant de l'espace) ou  leur extérieur (les lignes sont orientées
dans le sens horaire). Il faut aussi s'assurer que les surfaces
générées sont bien fermées par leur bordure (ce qui suppose aussi
ordonner les fdifférents ways d'une relation), et que ces contours
(devant former des anneaux sans aucune intersection entre deux anneaux
sauf sur un point isolé) ne forment aucune intersection (afin que ces
anneaux encercles soient des surfaces totalement incluses soient
totalement séparées, sauf pour les points isolés des bordures).

Là encore c'est à l'outil osm2pgsql de le faire, afin que les
géométries générées pour PostGIS (l'extension conforme GIS pour les
bases de données PostgreSQL) fonctionnent correctement : il calcule au
besoin des points supplémentaires en cas d'intersection, puis il
cherche à résoudre les contours internes et externes (il s'appuie un
peu aussi sur les indication "inner" et "outer", mais dans la
modélisation OSM, ces attributs ne servent pas à grand chose puisque
les anneaux d'OSM n'ont pas l'orientation demandée par le modèle GIS
quand un des anneaux désigne un trou dans la surface externe (GIS
demande alors un anneau horaire pour cette surface), mais sert aussi à
désigner une surface interne distincte (dans ce cas le même anneau
doit être orienté dans le sens antihoraire, ce qui génère donc deux
anneaux superposés, un pour chaque surface).

osm2pgsql doit conc faire beaucoup de calculs de géométrie au
préalable pour créer la géométrie GIS standard., en s'appuyant aussi
sur des règles à lui ajouter (pour savoir comment traiter les ways
fermés ou les relations contenant des ways qui pourraient être
fermés... ou pas). Les highways sont une difficulté si en plus il lui
faut distinguer en plus le cas lignes contre surfaces. Et toutes les
installations de osm2pgsql n'ont pas les mêmes règles.

Personnellement je trouve cela dommage. la base OSM devrait utiliser
une règle claire pour *tous* les tags en leur donnant une
interprétation soit comme géométrie de surfaces, soit comme géométrie
de lignes, même si on ne demande pas des tags séparés: le tag
"area=yes" ou "area=no" doit servir à changer l'interprétation par
défaut du tag, pour que ne soit **jamais** tenu compte de la "forme"
fermée ou non d'un way, ou des ways d'une relation. Malheureusement ce
n'est pas le cas, certains tags ont une double interprétation selon
que les ways forment un anneau fermé ou non. C'est trop ambigu et cela
n'aide pas à relever les problèmes de géométrie (par exemple à cause
d'un way qui a été supprimé ou coupé par erreur, ou d'un way ajouté et
formant une fermeture en anneau non désiré.

De même je trouve illusoire de vouloir documenter dans le wiki les
surfaces qui peuvent être mises ou non en relations: toutes les
surfaces (décrites par un way fermé muni de ses propres tags, ou en
plusieurs ways regroupés dans une relation donnant les tags de
l'ensemble) doivent être modélisables ***sans exception*** dans une
relation. Cette précision donnée dans le wiki est totalement superflue
: on doit toujours pouvoir utiliser une relation pour pouvoir scinder
un contour fermé complexe en plusieurs ways.

Le 6 avril 2012 01:58, Pieren <pieren3 at gmail.com> a écrit :
> Regarde du côté de cett proposition:
> http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway
>
> Mais autant dire que c'est de l'expérimental pour l'instant (peu de
> support et peu d'enthousiasme collectif). Avant d'en arriver à ce
> niveau de détail, pose toi la question de la précision de ta source
> (décalage) et des difficultés à éditer la zone pour les contributeurs
> suivants.
>
> Pieren
>
> On 4/6/12, Brice Hardy <hardybrice at gmail.com> wrote:
>> Et le lien pour nous montrer tout ça ? :)
>>
>> Le vendredi 6 avril 2012, Christian Quest a écrit :
>>
>>> Et moi, je viens de mapper mon potager: fraises, tomates, rhubarbe...
>>> et aussi un cerisier et 2 tilleuls ;)
>>>
>>> Depuis que je sais qu'on est limité à 11cm de précision avec nos 6
>>> décimales, ça m'a cassé dans mon élan de mapper chaque fraisier un à
>>> un :(
>>>
>>>
>>>
>>>
>>>
>>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr