sylvain letuffe a écrit :
> Ben alors ? alala, ces passionnés, impossible d'être "vraiment" en vacances
> et
> de tout laisser de coté.
Héhé, en fait je retappe une maison à la campagne, il faut bien que je
m'occupe le soir ;)
>> 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) ?
Mon "problème" est d'écrire la requête ci-dessous, en fait.
>> 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
Etienne a fait ça récemment, cependant il faut réimporter entièrement la
base postgis car elle est pleine d'arrondis. Il fera ça en septembre sur
le backend d'Osmose.
> 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...
Bon ben attendons septembre alors...
--
Yoann.
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
