[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
jocelyn.jaubert at gmail.com
Mar 24 Jan 21:40:33 GMT 2012
Le 24 janvier 2012, sly (sylvain letuffe) a écrit :
> Je me permet de migrer vers dev-fr, je sens que ça va partir en
> sucette
Yep, bonne idée :)
> > Ce n'est possible que si on garde la liste des membres de relations
> > dans la base: je ne sais pas trop si c'est déjà le cas.
>
> osm2pgsql dispose en fait de deux schémas :
> Un qui est une version bijective de la base osm (_osm_rel, _osm_nodes
> et _osm_ways), l'autre qui contient les géométries de manière a être
> utiliser par le rendu.
On a donc toutes les informations nécessaires en base de donnée.
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 ?
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, ...). Ç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 :)
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 ?
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.
--
Jocelyn
Plus d'informations sur la liste de diffusion dev-fr