[OSM-dev-fr] [OSM-talk-fr] Osm2pgsql et boundary_segment [was: Re: Re : Réflexions sur la modélisation dans osm des niveaux administratifs en france]

[Jocelyn Jaubert]

Le 24 janvier 2012, sly (sylvain letuffe) a écrit :
> > 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

Hum, je ne comprends pas tout au format de la base osm2pgsql
(j'utilise l'instance de osm7)...


osm=> select * from planet_osm_rels where id = 1362232;
    ---> la relation 90341 est bien dans members

osm=> select * from planet_osm_rels where id = 90341;
    ---> pas de problème, j'ai plein de trucs.

Mais je n'arrive pas à trouver 90341 dans planet_osm_line ou
planet_osm_polygon, que ce soit en positif ou négatif. Est-ce que c'est
parce que les type=boundary_segment ne sont pas gérés par osm2pgsql ?


Ça ne change pas grand chose en fait: ça veut dire qu'il faut d'abord
faire un ST_Union de tous les ways des boundary_segment, puis un
ST_MakePolygon et/ou ST_Polygonize pour obtenir le bon "way" du
type=boundary initial. Il restera le problème des exclaves, mais vu que
je n'ai pas compris comment c'est censé marcher dans OSM, je le
mettrais de côté.


Par contre, la technique de mettre à plat les tags et les membres dans
un array signifie que ça va être hyper merdique de faire ça en SQL. :(
Je vais plutôt m'attaquer du côté de python pour générer les requêtes
nécessaires.


-- 
Jocelyn