<br><font size=2><tt>> Thanks. It works.  </tt></font>
<br>
<br><font size=2><tt>Right on - I thought we were just talking theory,
nice to see it works :)</tt></font>
<br>
<br><font size=2><tt>> Could you tell me why the following SQL does
not working?<br>
> <br>
> SELECT bridge.gid <br>
> FROM bridge, highway <br>
> WHERE intersects(bridge.the_geom, highway.the_geom) and highway.gid
= 49;</tt></font>
<br>
<br><font size=2><tt>This takes me back to the question of how you define
"on the line".  I would bet (others can verify) that if
the bridge point did actually fall exactly on the road line vector (highly
unlikely in my opinion) then this should work.  </tt></font>
<br><font size=2><tt><br>
> For your information, the operation with "intersecting"
in ArcGIS worked.</tt></font>
<br>
<br><font size=2><tt>Interesting.  I then assume that the ArcGIS buffers
your points and then looks for the intersections.  It's really a matter
of scale which.  Zoom in as far as you possibly can and tell me if
the point and line directly overlap.  I assume that they do not!  This
brings up the question of whether or not ArcGIS "should" work
or not.  But we're not taught to question ;)</tt></font>
<br>
<br><font size=2><tt>In my opinion, the user should have to think about
a search radius between features like this and not default to software
to guess.  </tt></font>
<br>
<br><font size=2><tt>This reminds me of an old problem I had with Arcview
3 - we were programmatically grabbing and zooming to the extent of features.
 We hit lots of problems, only to finally discover that AV was extending
the extent so that it "looked good" on the screen.  Oh well,
I've heard that legacy GIS applications like AV and Arc Map are still good
for some tasks :)</tt></font>
<br>
<br><font size=2><tt>Tyler</tt></font>