> Si ça avait été un point, une surface... ça aurait qualifié un lieu, une > aire... Mais là, avec un segment de droite... ça indique tout sauf le nom > d'un lieu !
Si, si ! une ligne électrique, une route, un chemin, une voie de service, une frontière, un cours d'eau, et sur lequel des logiciels de rendus savent afficher un trait et un nom dessus, à condition de savoir à quoi ça se rapporte. Mais un parc naturel n'est jamais rien de tout ça. En principe un seul point n'indique pas non plus précisément le lieu (il faudrait avoir un rayon indicatif au moins), sinon l'objet désigné est le plus petit polygone contenant le point. De même un seul trait pour une rue, une route ou un cours d'eau n'est acceptable qu'à partir du moment où on peut estimer une largeur minimale indicative (3 mètres maxi par défaut ?), sinon il faut tracer un polygone autour (ce qu'on fait pour les cours d'eau, dont on garde cependant un trait central pour indiquer le centre du cours, ou parce que ce centre virtuel est utilisé aussi comme membre d'une relation de frontière administrative, laquelle devrait aussi être un polygone fermé). === La seule ambiguïté vient des chemins utilisés tout seul et fermés sur eux-mêmes : dans certains cas cela désigne uniquement le chemin lui-même (avec une largeur de part et d'autres si on l'interprète en rue ou cours d'eau), dans d'autre cela désigne la zone contenue dans ce chemin fermé. Normalement il faudrait toujours l'interpréter comme un chemin uniquement, et créer une relation de polygone référençant le chemin comme membre. Mais on évite souvent de créer un multipolygone ne contenant qu'un seul chemin membre, et au lieu de cela on ajoute "area=yes" pour changer l'interprétation par défaut du chemin. Ou alors on indique par exemple type=building dans les tags du chemin, car ce type ne "devrait" (noter le conditionnel...) pas être interprété comme une simple ligne, de sorte que "area=yes" est la valeur "par défaut" (et à priori superflu dans l'état actuel des moteurs de rendus). Pourtant on peut très bien imaginer un objet "building" uniquement linéaire, réduit à un seul mur (mais alors il faut estimer sa largeur par défaut pour le convertir en surface, à priori de l'ordre de 30 cm), ce qui devrait alors nécessiter "area=no" pour ce cas (l'autre solution est de tracer les deux contours fermés intérieur et extérieur de ce mur, et de les mettre dans un multipolygone (qui prend alors la valeur type=building, et non chacun des chemins membres intérieur et extérieur, et dans ce cas pas besoin de "area=no" ni besoin d'estimer une largeur, puisque la surface de ce mur est alors complètement décrite par ce polygone. Tout cela manque de cohérence et de solidité : les chemins ne devraient jamais avoir à être réinterprétés avec une largeur indicative s'ils désignent une surface. Ce devrait être le cas aussi des rues, routes, voies ferrées (qui désignent normalement une surface et pas un simple trait). Mais il y aurait beaucoup de travail pour créer tous leurs contours externes. Mais même dans ce cas, cela ne dispenserait pas de devoir tracer aussi un ou plusieurs chemins intérieurs, pour les différentes voies et sens de circulation ; ainsi que pour le routage qu'on ne sait pas encore faire avec des surfaces (qui de plus ne mentionnent aucune orientation, ce qui reste nécessaire pour définir les restrictions de sens de circulation sur les voies à sens unique). Pour simplifier le problème, on estime "à vue de nez" dans le moteur de rendu une largeur de rue ou de route minimale de l'ordre de 3 mètres, sur une voie à sens unique, ou voisine de 6 mètres pour les voies en double sens, un peu plus s'il y a en plus une voie cyclable et/ou une voie bus de chaque côté, ou un stationnement latéral (pour le faire il faudrait aussi savoir si le stationnement est parallèle à la chaussée ou en épi, savoir s'il y a un trottoir, un terre-plein ou une bordure de séparation avec le trottoir...), encore un peu plus s'il s'agit d'une autoroute à cause de la bande d'arrêt d'urgence et de la barrière centrale... (Cette estimation "à vue de nez" de largeur d'une route est pourtant largeur très allègrement dépassée sans un rendu à un niveau de zoom faible, ou un trait peut couvrir plusieurs centaines de mètres voire des dizaines de kilomètres à l'échelle du pays entier). Si l'estimation "à vue de nez" est loin de la réalité qui est nettement plus large, on "tague" explicitement la largeur moyenne de chaque troncon (incluant toutes ses voies parallèles) si elle est plus large (et on tague aussi le nombre de voies de circulation avec "lanes"). Cependant pour les routes, autoroutes, rocades, ponts, ou tunnels à chaussée, il vaut mieux tracer chaque direction séparément comme des chemins plus ou moins parallèles (qui peuvent s'écarter parfois, au delà d'une simple barrière ou d'un terre-plein centrale de l'ordre du mètre), en les traçant dans chaque sens au centre des voies centrales de circulation générale (ne pas tenir compte des zones zébrées, bas-côtés, jonctions de voies d'accélération ou de sortie). Pour des carrefours très complexes (avec des voies dans tous les sens, de types divers entre voies bus, tram, pistes cyclables, chemins piétons, le tout généralement sur une grande place et où les voies entrecroisées ne portent pas de noms clairs autre que la contour de la place entière où elles sont toutes construites...), on devrait pouvoir tracer les voies comme des surfaces avec leurs contours respectifs dans le contour de cette place, au lieu de tout mélanger, afin d'avoir assez de données pour pouvoir tracer un plan de circulation un peu lisible. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
