2012/1/23 verdy_p <[email protected]>: 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 _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
