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 <[email protected]> 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 <[email protected]> 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 > [email protected] > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
