Le mardi 24 janvier 2012 22:40:33, Jocelyn Jaubert a écrit : > Si j'ai bien compris le problème, il faudrait mettre dans la table > planet_osm_polygon un "way" qui correspondrait à l'union des relations > référencées par planet_osm_rels, et ceci de façon récursive. > > Est-ce que ça répondrait au problème originel ?
Exact. > On aurait du coup, pour la colonne "way" de l'osm_id -1362232 (France > Métropolitaine), un ST_Union des "way" des relations 76910, > 356747, ...). C'est ça, sauf qu'un st_union (de postgis) va juste agréger toutes les linestring pour faire un ensemble de type "multilinestring" qui ne sera pas un multipolygon > Ça devrait être transparent pour le rendu, et tous les > scripts qui ont besoin de connaître le "vrai" polygone représenté par > cette relation. > > Dit comme ça, ça a l'air assez simple de faire la requête SQL en > question: faut juste qu'on me confirme que je pars sur la bonne piste :) Selon moi, c'est bien ça. Mais je me suis creusé la tête pour le faire en SQL pour l'instant sans résultat. L'actuelle construction de multipolygon est implémentée en C il me semble. > Par contre, je ne sais pas trop comment ça se comporterait sur les > mises à jour: est-ce que osm2pgsql recalcule la colonne "way" des > relations qui ont changé ou pas ? Exact, c'est pour ça que c'est assez long d'ailleurs. Si tu bouges un noeud appartenant à un way qui appartient à 10 relations, alors osm2pgsql te reconstruit toutes les géométries des 10 relations c'est l'étape "pending relations" > Et il manquerait l'équivalent de la table actions d'osmosis, qui > indique tous les nodes/ways/relations modifiés lors de la dernière mise > à jour. il y a un champ dans les tables planet_osm_(rels/nodes/ways) qui s'appel pending=t/f je ne sais pas si c'est ça que tu cherches -- sly (sylvain letuffe) _______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
