Le samedi 18 juillet 2009 21:57, Yoann ARNAUD a écrit :
> > Salut les vacanciers d'osmose,
>
> Coucou,
Ben alors ? alala, ces passionnés, impossible d'être "vraiment" en vacances et
de tout laisser de coté.
Tant pis pour toi :
> et ce, en optant pour la
> superposition des ways.
+
> On peut, ça limite le nombre de faux, mais ça ne résoud pas ce que je
> cherche à résoudre :(
<mode philosophe à 2 balles>
A résoudre ? mais y'a-t-il un problème ? Ou alors "aiguiller" vers une méthode
pour tagguer (qui consiste à superposer des ways) ?
Il y a plusieurs méthodes différentes, et quand on gère une outil qui commence
à être bien utilisé par autrui (rendu, détecteur d'erreur, éditeur avec
presets, ...) on peut vite avoir tendance à s'en servir pour influencer. (Et
j'en sais quelque chose, faites ce que je dis pas ce que je fais ;-) )
</fin validator="oui, je sais c'est pas une syntaxe xml valide">
> Mon idée à moi est d'éxécuter dans postgis une requête qui fait ça :
>
> - Trouver dans une relation admin_level = 8,
> - deux ways successifs (qui se touchent),
> - qui appartiennent tous les 2 exactement aux mêmes relations
> admin_level = 8
fiuuu, ça m'a l'air coton... j'ai pas d'idée
> > PS: quid du test d'intersection de way boundary ou de même
> > natural/landuse ? qui monteraient à coup sûr un croisement pas normal ?
>
> Pareille, si on m'aide pour la requête, je le testerai.
Etienne avait déjà fait pas mal d'essais mais on a découvert que osm2pgsql
(qui est le plus abouti pour faire du osm->objet GIS) n'était pas fichu
d'enregistrer de manière cohérente les coordonnées dans la base et on se
retrouvait avec des erreurs d'arrondi.
De sorte que la fonction GIS classique pour faire ça : un tout "bête"
st_intersects sortait plein de faux positif car 1 cas sur deux, deux ways qui
se touchent uniquement étaient considérés comme s'intersectant.
(je sais pas si je suis clair sans dessin)
Solution 1, propre et dure : patcher osm2pgsql pour corriger le problème
solution 2, bidouille douteuse et lente alternative que j'ai trouvé :
****************
select astext(st_transform(st_intersection(l1.way,l2.way),4020)) as
point_insersection, l1.osm_id,l2.osm_id from planet_osm_line as l1,
planet_osm_line as l2 where
st_intersects(ST_RemovePoint(ST_RemovePoint(l1.way,st_npoints(l1.way)-1),0),ST_RemovePoint(ST_RemovePoint(l2.way,st_npoints(l2.way)-1),0))
and l1.way && l2.way and l1.boundary='administrative' and
l2.boundary='administrative' and l1.osm_id>0 and l2.osm_id>0 and
l1.osm_id!=l2.osm_id and st_npoints(l1.way)>4 and st_npoints(l2.way)>4 and
l1.way && st_transform('SRID=4020;LINESTRING(0 40,4 45)',900913) limit 5;
****************
Bien que cette requête semble marcher, elle n'est pas du tout optimisée et son
temps de traitement est abominable. Je cherche toujours...
> J'ai l'impression qu'il est temps de créer une page wiki... je me lance.
Yes !
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
