Lars, There's no doubt that 'truth' is relative to your frame of reference - water views to a real estate agent might amount to potholes in the street on a rainy day, my up is your down, religion, politics (sigh).... and the only time a point is really on a line is if sitting astride a barbed wire fence. So, maybe the best we can ever hope for is consistency??
In this case: Let's say you have a cable network layer and a junction box layer. Built properly in the GIS, a box intended to be shown as connected to the network will be snapped to one of the line mid/end points on the layer. Incomplete portions of the network will have boxes floating. We want an SQL to find all junction boxes connected to the network: "Select JunctionBoxes where JunctionBoxes.obj intersects any(select obj from cables) ", the result is correct for a cable network of polylines and unpredicable for a network with lines in it. (a junction box not connected to the network will be selected because it is within the MBR of one line) ---------------------------------------------------------------------------- --------------------------- Point on Line is an interesting one. A definition of a line in the digital world (cartesian system) could be: 1. a straight line connecting 2 points in a grid space. The grid space is defined by the stored precision of the coordinate system you are using (approx 4 cm for an unbounded lat/long coordsys). AND 2. A thickness represented by a buffer of width (half-width?) of the precision of the coordinate system. "thickness" means that operations on the line are performed on a region of this thickness. The "point" is that a program could place a point on a line as long as it was on or within the buffer (in pt 2) and a program could test for point on line without needing an artificial point created on the line. Regardless of the precision of the coordinate system you are working with : 2 bits, 32, 64 etc, the same approach applies. (The beauty of MI is that the Float data type has a few extra significant digits than the stored coord, so testing for within the line 'thickness' ought to be simple - of course, the actual thickness is known but arbitrarily small). To take my pedantry one step further: If you have 2 points on the surface of the earth and a "straight" line between them, this line is strictly only defined by the end points and the fact that the connecting "arc" is a great circle. Placement of a point on the line between the ends should be a mathematical placement of the point which meets the line definition above (for spherical geometry). As soon as you create an artificial intermediate node in the line, the line direction (and definition) changes because of snapping to the nearest point (in the grid space). ---------------------------------------------------------------------------- --------------------------- >From a practical point-of-view there is no reason why a point cant lie on a line between nodes. ---------------------------------------------------------------------------- --------------------------- Discussion of coordinate systems and precision confirms my thinking that MapInfo designers decision on 32 bit precision for stored coordinates with their use of bounds was a masterstroke. The performance benefits significantly outweigh any perceived artificial benefit of greater stored coordinate precision. (In the case above, the only relevance of precision is knowing what it is!) Often, when we criticize MapInfo technology I think it tends to be somewhat nitpicky stuff or things that could be fixed in the next rev. The important thing is that the foundations are so good. I might conclude my ramble now but a topic for another day is "why arcs and ellipses (parametrically defined objects) should not be poor cousins to points, lines and regions". Phil. ----- Original Message ----- From: "Lars V. Nielsen (GisPro)" <[EMAIL PROTECTED]> To: "Phil Waight" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, May 08, 2004 7:04 PM Subject: Re: MI-L MI6.5: 'LINEobject INTERSECTS POINTobject' actually evaluated as 'MBR(LINEobject) INTERSECTS POINTobject' > Hi Phil, > > It's not quite as simple as that. In my opinion, the result of an intersect operation between a line and a point is really logically > undefined, regardless of the respective positions of the line and the point. If it works that's great, but I wouldn't depend on it. > Sort of like the case with the draw order of geographically identical objects. > > But if your assumption holds, two simple lines (for which an intersection is definitely defined logically), which have overlapping > MBR's but not an actual intersection, should yield True when querying with "intersects". But it doesn't. > > dim lineobj1 as object > dim lineobj2 as object > set coordsys nonearth units "m" bounds (-10,-10)(10,10) > create line into variable lineobj1 (0,0) (1,1) > create line into variable lineobj2 (1,0) (0.6,0.4) > print str$(lineobj1 intersects lineobj2) ' << returns False > > If I change the definition of lineobj2 to > > create line into variable lineobj2 (1,0) (0.4,0.6) > > the result is now True, as it should be. > > So simple line objects _are_ valid map objects, and they do behave like so. > > But the logic definitely doesn't cover the cosmetic objects - arc, rects, roundrects, and allipses - because they're not real map > objects, just MBR's with a certain draw mode. For those objects it makes perfect sense to treat them as their MBR. And as you > suggest, ConvertToPline and ConvertToRegion is the only way to make them behave like real map objects. > > Best regards/Med venlig hilsen > Lars V. Nielsen > GisPro, Denmark > http://www.gispro.dk/ > http://www.gispro.biz/ > > ----- Original Message ----- > From: "Phil Waight" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, May 08, 2004 2:22 AM > Subject: MI-L MI6.5: 'LINEobject INTERSECTS POINTobject' actually evaluated as 'MBR(LINEobject) INTERSECTS POINTobject' > > > List, > > Further to a previous email on arc objects not behaving well with spatial operators ..... > > A LINE object seems to be treated as an MBR of itself during an intersect test with a POINT object. > '--------------------------------------------------------------------------- ----------------- > set coordsys earth > > dim lineobj as object > dim plineobj as object > dim otherobj as object > dim pointobj as object > dim point_on_lineobj as object > create line into variable lineobj (0,0) (1,1) > create pline into variable plineobj 2 (0,0) (1,1) > > create point into variable point_on_lineobj (0.6,0.6) > create point into variable pointobj (0.5,0.7) ' any point not on line but within MBR > create pline into variable otherobj 2 (0.5,0.7) (0.5,0.8) ' another obj not on line but within MBR > > print "Should evaluate FALSE: " + str$(lineobj intersects pointobj) ' FAILS > print "Should evaluate FALSE: " + str$(plineobj intersects pointobj) > print "Should evaluate TRUE: " + str$(plineobj intersects point_on_lineobj) > print "Should evaluate FALSE: " + str$(lineobj intersects otherobj) > > '--------------------------------------------------------------------------- ----------------- > As in the case of the ARC object, the workaround is to use CONVERTTOPLINE(lineobj) first. > > Phil. > > --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 11664
