> De : "sylvain letuffe" >
>> - un type=multipolygon se justifie si l'entité à construire est composée de >> polygones en "archipel" (des bâtiments disjoints comme par exemple sur un >> campus), > >Ben ça alors, c'est exactement le cas où je ne recommanderais pas >l'utilisation d'une relation. Mon exemple n'etait là que pour illustrer la configuration en archipel. Et ça n'était pas un bon exemple (mais je persiste sur l'archipel :-) >"Les relations ne sont pas des catégories" >http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories >(traduite pour l'occasion ;-) ) +1 Mais où donc es-tu aller chercher l'exemple de la Savoie, on se demande ???? >> (...) je ne vois pas quel(s) rôle(s) on pourrait assigner aux ways >> A et B. >simplement "rien" Soit. >> - une raison technique existe aussi : deux polygones adjacents >> (A et B ont un mur en commun) ne forment pas un multipolygon valide au >> sens de PostGIS (et de l'OGC) >ça pête ! Mais c'est du bluff ;-p >On parle bien ici du type=multipolygon de openstreetmap et pas de celui de >l'OGC, frédérik Ramm a d'ailleurs bien expliqué que le multipolygon au sens >OSM n'est pas du tout celui de l'OGC, on peut aller voir les dessins ici >http://wiki.openstreetmap.org/wiki/Multipolygon pour s'en convaincre. Tu y vas un peu fort en disant "pas du tout". On peut lire sur la page que tu cites (traduction synthétique du dernier item de "Usage") : "Ce qui n'est pas un polygone valide au sens de l'OGC ne sera pas une relation multipolygon valide [dans OSM] à la notable exception des polygones avec plusieurs 'inner' qui partagent une limite". Donc l'ideée est quand même de rester en phase avec ce qui se fait hors OSM, en gérant une exception. >> , ce qui a comme conséquence de produire des >> résultats incorrects quand on manipule cette donnée en base. > >C'est faux, il suffit d'utiliser le bon outil pour passer des géométries OSM à >un format de polygones compatible OGC et tout se passe bien. >osm2pgsql, depuis quelques corrections de bugs gère très bien la conversion. Non, c'est vrai dans le contexte Maposmatic, où l'idée est de respecter la donnée telle que stockée en base, et pas de la corriger. Thomas Petazzoni le disais il ya peu ici même [1] : "Du coté de MapOSMatic, nous nous refusons à faire des filtrages visant à "corriger" des problèmes de la base de données." Mais ma remarque n'est valable que dans ce contexte, en effet. Pour qui veut, il y a des fonctions de validation de géométrie qui permettent de filtrer les géométries erronées. >PS: Je me fais un peu l'avocat du diable, car je suis d'accord avec tout le >monde, sortir des relations pour deux petits bâtiments de 8 nouds est >ridicule, car consommateur de temps bien plus que la superposition, mais je >défend le principe comme étant tout à fait valable. En voilà une bonne conclusion, Et bon appétit... vincent [1] http://lists.openstreetmap.org/pipermail/talk-fr/2010-July/024263.html Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
