[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]

[sly (sylvain letuffe)]

> 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