Note: l'usage des subarea ne CASSE PAS les boundary actuelles. Ce sont des rôles totalement indépendants: les boundary ou boundary segment décrivent le contour extérieur d'une zone, alors que les subarea décrivent ce qui est à l'intérieur de la zone (le sous-découpage qui contient des frontières supplémentaires).
Les deux sont utiles, sachant qu'à terme tout de même la somme des subarea doit produire une partition de la zone principale et l'union de ces subareas devrait correspondre exactement au contour de la zone principale (après élimination des frontières internes entre subdivisions). Je ne vois rien de confus là-dedans. Si un outil ne sait pas quoi faire d'un membre d'une relation avec un rôle nommé (comme subarea, admin_center, label), il doit l'ignorer et cela ne doit pas l'empêcher de tracer le contour de la zone et la remplir dans une couleur ou un motif donné. En revanche: * Il DOIT savoir utiliser les rôles inner et outer pour remplir la surface correctement (enclave/exclave devraient fonctionner encore mais sont obsolètes; de même les chemins membres sans rôle nommés devraient encore être traités comme s'ils avaient le rôle outer; même s'il est préférable de mentionner ce rôle outer explicitement dans les données). Ces rôles doivent servir aussi à savoir si un point est dans une zone ou pas (cela concerne Nominatim...). * Qu'un rôle inner ou outer soit effecté à un membre de type boundary (zone fermée) ou boundary_segment (portion de contour, membre lui-même d'une ou plusieurs relation de zones fermées), ne doit pas influer sur le rendu ou le test d'inclusion d'un point dans une zone fermée * Il DOIT utiliser les rôles outer (et exclave ou anonymes pour compatibilité ascendante), inner (et enclave pour compatibilité ascendante) pour tracer les traits de contours (ou pour savoir si un nouveau noeud est sur le contour ou pas; principalement dans l'éditeur pour détecter une intersection possible) Certes des outils facilitant la modification des zones partitionnées en sous-zones serait le bienvenu, mais pour l'instant ce travail reste possible, la modélisation est claire cela moi, et peut se faire à la main avec les outisl actuels (même si ces outils ne vérifient pas encore leur cohérence, mais de toute façon ils ne savent pas non plus faire cette vérification car justement il manque des données de modélisation, ce que les membres polygones de type boundary_segments et les membres de rôle subarea devraient permettre de très bien modéliser avec précision, et en facilitant énormément aussi le travail sur la carte). -- View this message in context: http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7218352.html Sent from the France mailing list archive at Nabble.com. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr