> De : "Vincent Pottier" > Le 13/01/2011 14:46, sly (sylvain letuffe) a écrit : > > On jeudi 13 janvier 2011, Vincent Pottier wrote: > >> Pour faire avancer le shmilblik, > >> Même si on ne mappe pas pour... > >> Quel est le traitement par osm2psql d'une relation dont les membres > >> seraient les relations communes actuelles ? > > ça ne marcherait pas, mais tu l'as dis : "on ne mappe pas pour X" > > > > Il est cependant envisageable de coder un programme pour déterminer > > la "bordure extérieure" et construire le bon polygone. > Bon, alors je ne suis pas favorable à la relation qui contient les > relations communes... > Avant que le programme qui va bien soit intégré à osm2pgsql, ou que > j'arrive à l'implémenter sur ma machine... > > Les utilisateurs de postGIS, Qgis, osmose et autres seront handicapés > par cette méthode.
Il y a la complexité pour les outils (relations récursives) et aussi la complexité pour ceux qui doivent saisir en base ces relations. Le côté gigogne est parfait pour se perdre dans les imbrications. Bref, sur ces aspects, une enfilade de ways 'limites' est plus facile à appréhender en l'état des outils comme JOSM. Et puis, mine de rien, si on basculait en modèle 'somme de surfaces', on aurait les constructions suivantes : - les départements sont les sommes des surfaces des communes - les régions sont les sommes des surfaces des départements - la France est la somme des surfaces des régions. Avec ce modèle, la métropole se réduirait aujourd'hui à.... l'Alsace, seule région complète en terme de surfaces communales. Donc le modèle par somme de surface, peut-être, mais seulement le jour où notre carto des limites sera complète. Avant cela, le modèle par frontières reste plus efficace. vincent 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
