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

[Pieren]

2012/1/23 verdy_p <verdy_p at wanadoo.fr>:

Stoppez le massacre ! C'était déjà le bordel avant mais là, ça devient
le pompon.

> Il n'y a aucun problème signalé par JOSM, ni warning, ni error; d'ailleurs
> les notions d'enclave/exclave sont obsolètes, il n'y a plus que "outer"
> (partie principale et toutes les exclaves d'une zone) et "inner" (toutes les
> enclaves d'une zone principale externe ou toutes les autres zones
> principales enclavées)...

On pourrait aussi totalement ignorer les roles "outer" et "inner"
puisque ces roles sont ignorés par les logiciels de rendu. Mais JOSM
se plaindra quand même si le role n'est pas défini. Alors oublions les
couinements du validator.

> JOSM vérifie cependant toujours l'ordonnancement des relations et noeuds de
> segments: d'une façon générale on doit toujours préférer le sens
> trigonométrique (anti-horaire), car c'est sinon un tri que doit faire tous
> les systèmes de rendus de tuiles, et cela prend du temps. Ce sens est à
> garder même pour les zones "inner" (puisque ces enclaves sont aussi des
> chemins ou relations ayant leur propre définition en tant que zone "outer",
> ces chemins en sens anti-horaire sont normalement partagés).

L'ordre et l'orientation des ways qui définissent un polygone n'ont
aucune importance. Les logiciels qui traitent ces données partent du
principe qu'elles ne sont pas forcément triées par l'éditeur et elles
sont capables de les remettre dans l'ordre automatiquement et très
rapidement. Aucun type de relation n'impose un ordre précis dans ses
membres, excepté certains itinéraires (type 'route').

>
> Pour les éditeurs, il est essentiel de s'assurer que les chemins ou segments
> d'une relation sont aussi connectés et dans l'ordre

Connectés, oui. Dans l'ordre, non. Même si JOSM propose une fonction
bien pratique de tri dans l'éditeur de relations qui permet de
vérifier que la boucle est bouclée, ça n'est pas indispensable.

> A l'avenir, il devrait aussi y avoir l'utilisation des membres de type
> "subarea" (mais pas avant que le découpage d'une zone soit une partition
> exacte). Cela permettra aussi des navigations dans la carte et des
> vérifications supplémentaires de cohérence: une relation qui comporte des
> "subarea" doit avoir un contour couvrant exactement l'ensemble des
> "subarea", sans trou car sinon ce sont des zones "subarea" oubliées, et ces
> subareas doivent n'avoir aucune intersection de surface entre elles.

Très confus, là. Il faut aussi dire que le terme "subarea" est
extrêmement mal choisi. Cette notion représente une somme de surfaces
dans son usage alors que l'unique documentation que je trouve
(http://wiki.openstreetmap.org/wiki/Relation:boundary) parle de
"boundaries of sublevels". J'aimerais avoir des statistiques de son
usage (marginal, ama) mais il est urgent de ne pas utiliser un tag qui
casse tous nos polygones de limites administratives car ce role n'est
reconnu par AUCUN logiciel à part le validator de JOSM (peut-être
parce que ça vient de la même personne Dirk Stocker) !

Pieren