Tu dis que les moteur de rendu ignorent les rôles outer et inner : c'est faux, affirmé sans preuve.
La notion d'exclave même est ambiguë: quand une zone consiste en deux zones séparées, laquelle est une exclave de l'autre ? Il n'y a pas une sous-zone plus importante que l'autre, les deux sont membres à part égale, avec chacune un rôle "outer" (y compris pour les "petites" îles). Le rôle "inner" ne sert qu'à exclure une zone qui autrement serait reconnue comme faisant partie de la zone extérieure et qui serait donc remplie par la même couleur ou motif. Les rôles inner et outer fonctionnent parfaitement, même si les moteurs de rendu reconnaissent encore les rôles enclave (considérés comme inner), exclave et anonymes (considérés tous deux comme outer) qui persistent. De même, les moteurs doivent encore faire le tri des chemins et rechercher l'ordre normal ou inverse des noeuds pour interconnecter ces chemins (ce qui prend du temps dans le moteur de rendu si on ne mâche pas le travail en les préconnectant au moins entre deux chemins, sachant qu'il n'est pas possible de définir un sens unique pour un chemin quand le chemin sépare deux zones contigües: les rues à sens unique doivent donc avoir une propriété pour définir le sens de circulation: oneway=yes ou oneway=-1 quand c'est en sens inverse de la numérotation des noeuds dans le chemin), puis finalement déterminer un sens antihoraire unique de parcours des noeuds de chaque chemin membre pour remplir la zone: c'est un travail de géométrie obligatoire dans tout moteur pour le rendu correct d'une surface fermée, ou pour une recherche dans la base de donnée afin de savoir si un point est dans la zone (à l'exclusion des enclaves) ou pas. Notez que si le travail de calcul de géométrie d'un moteur est correct, il n'a même pas besoin non plus des rôles inner ou outer: quand un chemin en contient un autre enclavé (que ce chemin soit membre directement ou membre d'une relation fille "inner" ou "outer", et de type "boundary" totalement fermé ou de type "boudary_segment" non totalement fermé), la seule règle de parité suffit à déterminer si un point est dedans ou dehors. Algorithme : en traçant une ligne droite infinie de direction quelconque et passant par ce point à tester (par exemple horizontale: on ne suit que la ligne du parallèle à la latitude du point à tester par exemple), il suffit de compter le nombre de chemins traversés en commençant à zéro depuis un des côtés infinis de la droite (par exemple d'Ouest en Est) : si le compteur est pair à ce point alors le point est dehors, si le compteur est impair le point est dedans; un cas spécial est quand un point est sur le chemin lui-même (par exemple quand le point testé est un nœud du chemin) ; l'autre cas spécial est quand la ligne imaginaire passe par un segment entier (c'est-à-dire par deux nœuds successifs du chemin : il ne faut en compter qu'un). Il n'est même pas nécessaire dans cet algorithme de trier les nœuds (si on a utilisé comme ligne imaginaire un parallèle passant par le point à tester, il suffit juste de tester si les latitudes des nœuds du chemin: si la latitude du nœud est inférieure ou égale à la latitude compter -1, sinon compter +1, et faire cela pour tous les nœuds du chemin: le résultat est identique). Cependant le tri de nœuds (par exemple en sens antihoraire systématique pour les contours fermés) permet de gagner du temps et facilite non pas le dessin du remplissage des intérieurs, mais celui des contours (par exemple des bordures de zones en traits pointillés jointifs aux nœuds, ou l'ajout de flèches de direction), et évite des discontinuités dans le tracé de tuiles rendues séparément. Cet algorithme fonctionne déjà, et heureusement pour nous tous et OSM ! Un moteur de rendu qui ne fait pas ça est totalement bogué et sera totalement incapable de dessiner une carte correcte. Bref ton assertion est fausse. -- View this message in context: http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7218649.html Sent from the France mailing list archive at Nabble.com. _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
