sly (sylvain letuffe) wrote:
> On jeudi 8 juillet 2010, Gilles Bassière wrote:
>
>> Il y a tout de même moyen de faire un rendu correct en faisant un
>> pré-traitement sur les données exportées pour le rendu.
>
> Pour tout te dire, c'est bien à ça que je pensais. Un calcul d'intersection
> temps réél ne me semble pas vraiment pertinent, par contre une construction
> dynamique à l'import des polygones à trous me semble tout à fait réalisable.
>
> Certes, yaka, et je n'ai certainement pas les compétences pour aller
> trifouiller le osm2pgsql pour lui faire créer les polygones à trous
>
Pas besoin d'aller modifier osm2pgsql, il suffit de manipuler les
données en SQL dans la base. Voilà un exemple de requête postgis pour
créer les trous dans les polygones landuse :
select osm_id, landuse, way_area, coalesce(
st_difference(way, (
select st_union(way)
from planet_osm_polygon
where way_area < p.way_area
and landuse is not null
and st_intersects(way, p.way))
),
way
)
from planet_osm_polygon p
where landuse is not null
order by way_area asc
Mieux vaut créer un index spatial sur way au préalable.
La requête est susceptible de créer des multpolygone dans certains cas,
il faudrait donc l'améliorer pour extraire chaque polygone simple mais
il faut alors pouvoir gérer de nouveaux osm_id (si c'est pour réinjecter
dans la base en tout cas).
Dans l'exemple ci-dessus, je m'appuie sur la surface de la parcelle (les
plus petits au dessus des plus grands) mais on peut utiliser d'autres
critères plus pertinents si on veut, la densité de point par exemple. On
peut aussi améliorer en gérant le z_order, etc.
Si le but est seulement d'influencer le rendu et que le seul critère
d'ordonnancement des polygones est la surface, alors il n'y a pas besoin
de s'embêter autant, un order by way_area devrait suffir.
Cordialement,
--
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
