> > 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=*). >
J'ajoute en plus que le fait qu'OSM n'impose pas l"orientation GIS des chemins membres d'un "multipolygon" pose un problème non seulement dans les rendus, mais aussi dans les éditeurs utilisés (à cause de limite mémoire, que ce soit dans un éditeur web comme iD où la limite est imposée par le navigateur utilisé ou un éditeur externe comme JOSM (par exemple la limite mémoire des VMs Java) : on ne peut pas charger la totalité de la géométrie d'un multipolygone san imposer une charge lourde au serveur OSM, et sans saturer en plus la mémoire de l'éditeur. On doit donc pouvoir travailler dans un éditeur avec une géométrie partiellement téléchargée pour les relations. Le rendu dans l'éditeur du coté "intérieur" ou "extérieur" n'est donc pas toujours exact et l'utilisateur doit se guider sur les indications des rôles "inner" et "outer" pour éviter de casser la géométrie de ces relations surfaciques (mais c'est un guide partiel qui ne répond pas à toutes les questions, le rendu dans l'éditeur peut rester malgré tout incorrect tant que la géométrie de la relation n'est pas téléchargée en totalité en mémoire...) C'est pour ça qu'on demande aux utilisateurs de limiter la géométrie des multipoygones afin que le nombre total de points ne dépasse pas quelques milliers de points. Sinon on leur demande de scinder les multipolygones en plusieurs parties. Ce sera à l'export GIS de préparer les géométries complètes de polygones afin d'en faire un rendu exact (et pour cela il n'a absolument pas besoin de la distinction des rôles "inner" et "outer"....), en défusionnant les ways OSM partagés (pour les importer dans des polygones surfaciques complets et correctement orientés plaçant l'intérieur à gauche, quelque soit l'orientation des chemins utilisés dans OSM). Bref on a un compromis dans OSM favorisant plutôt les utilisateurs afin de leur permettre d'éditer la carte sans avoir nécessairement une machine puissante avec plein de mémoire (ou beaucoup de stockage dans une base locale externe : c'est ce qu'a fait iD en ne chargeant plus tout en mémoire dans le navigateur, mais en utilisant une fonctionnalité "base de données locale" offerte par les navigateurs web récents, où des données peuvent être stockées sur disque et pas gardées en mémoire, ce qui le rend utilisable même dans des navigateurs limités en 32 bits mais disposant d'un stockage local généralement plus confortable). En attendant les rôles "inner" et "outer" restent utiles car on continue de l'utiliser sans avoir forcément téléchargé la totalité de la géométrie des relations (même via une "base de données externe" locale) et parce que le rendu local dans l'éditeur ne s'en sert pas (cela imposerait trop de données en mémoire ou nécessiterait que l'éditeur précalcule une "orientation GIS" et la mette en cache dans sa base externe locale)
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
