> Hum, je ne comprends pas tout au format de la base osm2pgsql > (j'utilise l'instance de osm7)...
Si tu ne comprends pas tout, c'est que tu as tout compris ;-) > 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 ? Exact. La liste des relations qui sont transformées en géométries est hard-codée dans output-pgsql.c, et sont les suivantes : type=multipolygon/boundary/road (et j'ai patché la version d'osm7 pour supporter les type=waterway) > Ç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é. exclaves est l'équivalent de outer en terme de gestion algo, c'est à dire qu'il faut bien les prendre en compte. Là où je m'interroge, c'est que toutes les constructions actuelles sont faites en C et pas en SQL. Je me demande pourquoi, j'en déduis donc que ça n'est pas forcément jouable. > 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. A mon avis, il faut garder à l'esprit que si on veut que ce patch soit accepté upstream il faut qu'il s'incorpore dans osm2pgsql "facilement" et qu'il soit une option facultative, mais je te laisse voir. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org _______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
