checking for point/line intersection

[Thomas Bacon]

I’m trying to check whether a line passes through a point (or pair of coordinates more specifically) using MapBasic. I’ve done the following:

 

1)      Selected from a polyline table where the object intersects with my line object into selection called ‘Intersections’

2)      Determined the line/polyline point of intersection using:

            _x = (yIntercept2 - yIntercept1) / (slope2 - slope1)

               _y = (slope1 * _x) + yIntercept1

This is causing me some trouble for starters… the x coordinate comes out negative to its actual value when I plot the lines and check against the map. This in turn makes my y value incorrect. If I invert (set to negative) either the difference in slope or difference in intercept then the correct x value comes out. I have no idea why?!

3)      Once I have my X and Y coordinates using the above, I then check these against each line section from the intersecting polyline object to determine which section intersects with the point:

     slope = GetSlope(_lineSection)

      intercept = GetYIntercept(_lineSection, slope)

     

      v = _y - (slope * _x) - intercept

     

      If v = 0 then

            PointIntersectsLine = true

      else

            PointIntersectsLine = false

      End If

 

 

The second step obviously has a problem but I can get it to work by inverting one of the calculated differences. The third step seems to work for some intersections but not others. All my variables (coordinates, slope, intercept, etc.) are floats but I’m wondering whether this might be a problem with rounding. This is all done in British National Grid.

 

Any ideas what might be going wrong?

 

Thanks,

 

Tom Bacon

GIS Engineer, Mouchel

T 01444 472380 │ E thomas...@mouchel.com │ W www.mouchel.com

Our values: innovation │ excellence │ integrity │ responsibility

 

Mouchel Limited (Mouchel) is registered in England and Wales with registered number 01686040 at Export House, Cawsey Way, Woking, Surrey, UK, GU21 6QX.  The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. Any views or opinions expressed in this e-mail may be solely those of the author and are not necessarily those of Mouchel. No contracts may be concluded on behalf of Mouchel by means of email communications. Mouchel reserves the right to monitor and intercept emails sent and received on our network.

[Tony Pilkington]

The basic equation for a line is y=mx+c

Rewriting this it becomes y-mx-c=0

 

Generalising: v=y-mx-c

 

For a point on the line, v = 0 always.

For a point not on the line v <> 0.

If a point is on the left of a line the v value is always negative, on the right always positive. (or the other way round maybe)

 

This can be developed to give side values for points and lines.

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4765 / Virus Database: 4025/8276 - Release Date: 09/26/14

--
--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en

---
You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapinfo-l+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Bacon]

Thanks Tony, that’s what I’m using (v = _y - (slope * _x) – intercept). I think I’ve determined that the intersection check failure is down to rounding of the coordinate, slope and intercept values. I’m going to have to rethink how I’m calculating this as a very tiny difference in one of those values means that v will no longer equal 0 in some instances where I know it should. Back to the drawing board…

 

Tom Bacon

GIS Engineer, Mouchel

T 01444 472380 │ E thomas...@mouchel.com │ W www.mouchel.com

Our values: innovation │ excellence │ integrity │ responsibility

 

[Warren Vick]

Having revised linear functions with my daughter this week, I thought I'd chip in.

 

The general equation for a straight line is indeed y = mx+c. For those that don't use this kind of stuff daily, and for whom High School was a long, long time ago... m is the gradient and c is the intercept with the y axis. For a road and stream that are represented by simple lines and running side-by-side, the gradient should be quite similar. However, given the vast space of a country- or state-wide Cartesian coordinate system, even a minor difference in the gradient could make a big difference when the line is extended to the y-axis.

 

Another problem is that of representation. A road or stream would typically be represented by a polyline, so you may have many line sections representing meanderings in the road. On top of that you have polyline direction. The stream may well be expressed as flowing downstream, but if the road is two-way, it could be "flowing" in the opposite direction. This has a real impact on your relative notions of "on the left" and "on the right".

 

So, while derivations of y=mx+c are mathematically sound, you may have to go a long way to develop this. I Googled "measuring parallelism" and there are lots of pages you might find useful for alternative approaches.

 

Regards,

Warren Vick

Europa Technologies Ltd.

http://www.europa.uk.com

[Peter Horsbøll Møller]

You could use to ConnectObjects() function to get a shortest line between two objects, or a similar one that just measures the shortest distance between objects.

This will give the option of adding a tolerance to you formular

Peter Horsbøll Møller

---

Fra: Warren Vick
Sendt: ‎26-‎09-‎2014 17:25
Til: mapi...@googlegroups.com
Emne: RE: [MI-L] checking for point/line intersection

[Tony Pilkington]

Another approach uses the parametric forms;

 

y=Y1 + t*(Y2-Y1) and X=X1 + t*(X2-X1) where t normally varies from 0 to 1

The point has coordinates (x,y)

 

for the y form t=(y-Y1)/(Y2-y1)

and for the x form t=(x-X1)/(X2-X1)

 

Taking into account that objects have width, then if the two calculated t values are the same to 3 decimal places (t=round(t,.001)), that may be good enough. However ,if they then diverge at the 4th place they may well cause a failure in some MB functions such as enclose.

 

 

Since polylines are being used, another approach is to create a circle of radius r at the point (x,y)and overlap this with the polyline. If the resulting objectlen of the overlap is equal to 2*r then it’s on the line; if less than 2*r it is near the line.

Version: 2014.0.4765 / Virus Database: 4025/8278 - Release Date: 09/26/14

[Thomas Bacon]

Thanks all. I decided to just take the simple route and use MapInfo’s intersection analysis and buffer the point slightly; works quite well now.

 

Function PointIntersectsLine(ByVal _x as Float, ByVal _y as Float, ByVal _line as Object) as Logical

 

Dim slope, intercept as Float

Dim v as Float

Dim bufferPoint as Object

 

      bufferPoint = Buffer(CreatePoint(_x, _y), 50, 0.5, "m")

     

      If bufferPoint intersects _line then

            PointIntersectsLine = true

      Else

            PointIntersectsLine = false

      End If

 

End Function

 

Regards,

 

Tom Bacon

GIS Engineer, Mouchel

T 01444 472380 │ E thomas...@mouchel.com │ W www.mouchel.com

Our values: innovation │ excellence │ integrity │ responsibility

 

[Thomas Bacon]

Looking at that, I think I went a bit overboard on the resolution. 50 nodes for a 1m diameter circle is probably a bit much… might drop that down a bit.

 

Tom Bacon

GIS Engineer, Mouchel

T 01444 472380 │ E thomas...@mouchel.com │ W www.mouchel.com

Our values: innovation │ excellence │ integrity │ responsibility

 

[Warren Vick]

There's a feature I'd love to see in Pro/MB, that might be helpful to Thomas, which is a one-sided buffer. It's been discussed before from time-to-time. It's would be useful for both regions and lines/polylines for a number of applications where "side" is important. Additionally, the notion of advancement perpendicular to a line. e.g. the movement of a burn line for a wildfire.

 

Anyway, one more for the wish list.

 

Regards,

Warren Vick

Europa Technologies Ltd.

http://www.europa.uk.com