2012/1/24 Christian Quest <cqu...@openstreetmap.fr> > Le sujet semble sensible vu le ton de plusieurs messages... > > J'avoue que je découvre les sub_area. > > Quand on travaille sur la base de données, c'est quand même plus simple de > passer par des liens logiques entre relations pour naviguer dans les > hiérarchies administratives, non ? Les requêtes spatiales sont coûteuses en > calcul et c'est de pire en pire vue le nombre croissant d'objets dans les > bases, autant s'en passer quand on peut. > > Je ne vois pas trop quel problème cela pose de mélanger au sein d'une même > relation des objets géographiques et logiques (sémantiques). Emilie tu peux > développer ce qui est vraiment horrible dans ces immondices ? ;) > Il faut faire le tri pour utiliser l'un ou l'autre selon ses besoins ? > > Les deux types d'infos sont utiles. On peut considérer que c'est > redondant, c'est vrai, mais cette redondance permet aussi de vérifier la > cohérence et d'assurer un contrôle de qualité. > > Si ce mélange au sein d'une même relation est vraiment source de problème, > devrait-on créer 2 relations, une purement logique (niveau N -> niveau N+1 > avec les sub_area et autres choses du même ordre) et une géographique pour > avoir juste les contours ? > > > En ayant rajouté bon nombre d'EPCI ces derniers jours, je trouve > l'approche uniquement "frontière" trop limitée. > > Personnellement, mon probleme avec l'implementation des sub area est le fait que l'on melange des inner/outer et des sub areas. Enfin bon j'attends avec impatience le jour ou on aura des objects polygones ce qui permettra d'eviter le melange entre le semantique et le geographique. L'idee meme d'un sub area est tres bonne, l'implementation est calamiteuse a mes yeux.
Emilie Laffray
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
