Dernière note importante : les surfaces "riberbank" peuvent être des relations "multipolygon", mais leur complexité géométrique s'accroît vite et peut poser des difficultés au rendu s'ils couvrent des surfaces très étendus. En effet un rendu ne peut pas se contenter de chercher les ways présents dans sa "bounding box" d'intérêt, pour détecter des chemins membres d'une relation avec des rôles "inner" et "outer" même correctement définis car il peut encore manquer des chemins pour savoir quel est le côté intérieur ou extérieur.
En effet il pourrait trouver dans sa "bounding box" d'intérêt (celle qu'il veut tracer) seulement deux chemins avec un rôle "outer" et ne peut PAS conclure que la surface entre les deux (dans sa "bounding box") est couverte en eau, car un cours d'eau peut faire des méandres et donc la surface en eau pourrait s'étendre en fait de chaque côté des deux chemins "outer" trouvés (jusqu'au moins les limites de la "bounding box") mais justement pas entre les deux chemins. Un rendu doit alors charger les relations au complet pour énumérer tous les chemins et déterminer correctement le côté intérieur ou extérieure des chemins. Cela pose des difficultés de performance justement pour les cours d'eau qui formeraient une surface "riverbank" unique. Pour ces raisons, il est admis que les surfaces "riverbank" d'un cours d'eau peuvent ne pas être uniques, afin de rendre la complexité géométrique des surfaces moins grande. De plus les relations "riverbank" ne suivent pas exactement les restrictions des "multipolygon" car ils est admis que ces relations peuvent inclure des polygones jointifs (partageant des chemins ou ayant des chemins fermés partiellement superposés). Ces relations "riverbank" n'imposent donc pas de déplacer les attributs "riverbank" de leurs way membres vers la relation qui les collecte tous. Les "riverbank" sont donc à traiter de la même façon que les surfaces de "landuse=*" et "natural=*", qui ont les mêmes difficultés : il a été décidé de limiter la complexité géométrique des multipolygones et de ne les réserver qu'à des objets pas trop étendus, dont la géométrie global ne totalise pas plus de quelques milliers de noeuds (quel que soit le nombre de chemins qui les joignent et sont les membres des multipolygones). Une telle complexité en revanche a été admise pour les relations "boundary" qui ne posent pas de problème aux rendus (en vectoriel ou bitmap) : les frontières ne sont jamais rendues comme surface (ou seulement un prétraitement de "simplification géométrique" pour les niveaux de zoom faibles) mais seulement en filaire (qui peut lui aussi avoir un prétraitement de simplification géométrique). La complexité géométrique des "coastlines" en revanche fait objet d'une exception : on ne représente pas la mer comme une surface, mais pour contourner le problème, on y impose l'orientation des chemins pour que le côté "mer" soit à droite (cette conditions supplémentaire n'existe pas pour les autres surfaces d'OSM, c'est tout le problème, contrairement aux spécifications GIS standard qui imposent la même orientation à toute surface délimitée par des contours fermés, avec le côté intérieur à gauche et le côté extérieur à droite dans le sens du parcours du chemin). De ce fait les coastlines font l'objet du côté d'OSM d'un prétraitement spécifique qui les extrait dans une base à part destinée aux moteurs de rendus, pour qu'ils n'utilisent pas les mêmes règles que les autres surfaces OSM et conservent l'orientation indiquée dans cette base. Alors que pour tous les autres objets OSM l'orientation des chemins reste à déterminer par un algorithme coûteux devant prendre en compte la totalité de la géométrie des objets (et qui ne peut pas se contenter des deux roles "outer" et "inner" pour distinguer les cas, car ils ne suffisent pas à déterminer comment réorienter des chemins en plaçant l'intérieur à gauche et l'extérieur à droite, afin de pouvoir ensuite en faire un rendu surfacique, ou à déterminer si un autre point quelconque est à l'intérieur ou à l'extérieur de la surface). Le coût de cet algorithme s'accroît vite quand les surfaces sont représentées par des mulitpolygones dont les chemins membres comptent plus de quelques milliers de points, et il impose d'utiliser des requêtes lourdes en volume à la base de données (pour les mers cela représenteraient à chaque fois des millions de points, et c'est pour ça qu'une exception a été faite au "modèle OSM" pour les coastlines: le serveur de données ne peut pas répondre "en ligne" à de telles demandes, cela doit être fait par un export spécifique. Les choses seraient plus simples si OSM ne permettait plus de représenter une surface avec des chemins d'orientation quelconque et imposait la même restriction que le GIS standard. On n'aurait même pas besoin non plus des rôles "inner" et "outer" qui ne sont qu'indicatifs (pour les humains) mais même pas réellement distinctifs (pour tous les moteurs de rendus ou d'analyse, qui de toute façon doivent ignorer cette distinction apparente et les traiter de la même façon). Mais alors pourquoi OSM ne l'impose pas ? Simplement parce que les chemins dans OSM sont "partagés" et peuvent être réutilisés en tant que membres par plusieurs relations de surface (chacune définissant une "orientation GIS" différente au sens surfacique) et avoir en plus une orientation ne dépendant pas des relations de surface mais de ce qu'impose d'autres objets "filaires" (par exemple : orientation des cours d'eau waterway=*, ou sens unique des rues highway=*, ou voies ferrées railway=*). Le jeu. 18 oct. 2018 à 23:57, François Lacombe <fl.infosrese...@gmail.com> a écrit : > Bonsoir, > > Une petite question sur les deux relations qui qualifient Le Rhône : > La 1ere pour sur le filaire river : > https://www.openstreetmap.org/way/34907146 > La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve : > https://www.openstreetmap.org/relation/660056 > > Je ne comprends pas l'intérêt de la deuxième. > Ne faudrait-il pas mettre le wikidata sur la 1ere relation et supprimer la > 2nde pour ne laisser que des polygones riverbanks continus sans relation ? > > On dirait que ça met le bazar sur des rendus comme Positron : > https://www.maptiler.com/maps/#positron//vector/15.12/5.81699/46.054843 > (même si on ne tag pas pour le rendu) > > Merci par avance pour vos retours, bonne soirée > > François > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
