[OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

verdy_p verdy_p at wanadoo.fr
Mar 24 Jan 01:39:27 UTC 2012


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.




Plus d'informations sur la liste de diffusion Talk-fr