[OSM-talk-fr] [osmose] "too many ways in relation"

[Yoann ARNAUD]

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.