<html>
<head>
</head>
<body>Hallo<br />
<br />
Here ST_DFulltwithin will give wrong result. It is easily done to think wrong about this function. It will cause a measuring from the point to the furthest part of the line instead of the closest. In this case it will cause a measure like the first illustration in the documentation of ST_Longestline.<br />
http://postgis.org/documentation/manual-1.5/ST_LongestLine.html<br />
<br />
Since one of the geometries is a point it is possible to use ST_DWithin instead. If the point is within, it is also fullywithin.<br />
<br />
So, just use ST_DWithin indead of ST_DFullywithin in strk's suggestion. It should be much faster than the buffer solution.<br />
<br />
<br />
/Nicklas<br />
<br />
2010-04-01 strk wrote:<br />
<br />
On Thu, Apr 01, 2010 at 02:35:09AM -0700, iKey wrote:<br />
>> <br />
>> Hey,<br />
>> I've set up a Postgres database with Postgis support.<br />
>> Now I try to excecute the following query:<br />
>> <br />
>> SELECT DISTINCT p.*<br />
>> FROM punkte p, lines l<br />
>> WHERE l.tags LIKE '%"highway"="footway"%'<br />
>> AND CONTAINS(BUFFER(l.the_geom, 500), p.the_geom)<br />
><br />
>Blind guess:<br />
><br />
>- Use ST_DFullyWithin instead of buffer (major improvement expected)<br />
>- Use equality operator and an OR for tags rather than like (minor)<br />
>- Avoid the DISTINCT if not needed (minor)<br />
><br />
>--strk;<br />
><br />
> () Free GIS & Flash consultant/developer<br />
> /\ http://strk.keybit.net/services.html<br />
>_______________________________________________<br />
>postgis-users mailing list<br />
>postgis-users@postgis.refractions.net<br />
>http://postgis.refractions.net/mailman/listinfo/postgis-users<br />
><br />
>
</body>
</html>