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

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)