Jacques, True, but circles as objects are ideal for testing, for example, whether a point is within a given distance from an object of any type. As far as I can tell ........ "Circle intersects any_object" .....tests the circle as a circle not a "circular region of current resolution", so by implication will be computed more quickly than a region. Circles are also stored in a compact form (center, 2 radii). Circles for small distance computations are invaluable. For larger distances, circles are of value depending on what they represent and how precise the radius is in the first place.
Some of the history of MI objects might be tied to their existance in MS GDI library - viz. circles, arcs, rounded rectangles. When it comes to objects of limited geographic value that relic from the past, the rounded rectangle - has survived into MapXtreme 2004! This does mean there is hope for layouts in MapXtreme though! The list of classes in the geometry namespace in mpx04 is a sight to behold. Trouble is I dont know yet whether to applaud or cringe (at the complexity). Phil. ----- Original Message ----- From: "Jacques Paris" <[EMAIL PROTECTED]> To: "Lawley, Russell S" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, June 12, 2004 1:05 AM Subject: RE: MI-L returning the coordinates of 2 intersection points of 2 overlapping circles > It is amazing that people want to handle "circles" as if they were > geographic objects. They do not exist in MI with properly defined > "contours", just a center and a radius, and they are displayed on the fly > with some approximation. Hence, my hesitation to the cartesian space > solution; the computed points may not exist really as part of the circles. > > Before Mi will "release" information about intersection between a circle and > another linear object, it internally transform it (them eventually) to > polyline(s) and will find the intersections between resulting objects, These > are approximation of the circle shape in a polyline with a number of nodes > defined by the "Set Resolution" statement (by default 100 nodes per circle); > in this implicit transformation, the original circles are not modified. The > coordinates of the intersections will vary thus for different resolutions, > and the corresponding points with not be on the "circles" except if by > chance, each intersection will find itself on a node for both > convertedtopline circles. > > One easy approximation will thus be to do the following > > Dim oint as object > Oint=overlap(circle1,circle2) > > X and y if the intersections would be > Objectgeography(oint, OBJ_GEO_LINEBEGINX) > Objectgeography(oint, OBJ_GEO_LINEBEGINY) > Objectgeography(oint, OBJ_GEO_LINEENDX) > Objectgeography(oint, OBJ_GEO_LINEENDY) > > One must make sure that an object was created (that there is an > intersection) either by testing previously that the distance between the two > centers is < sum of radii, or by error trapping on the objectgeography > function. > > Notice that the overlap function returns an object defined by its end points > (the intersections) of the circles, whereas the intersectnodes() will not > work on circles; they will have to be to previously converted explicitly to > polylines. > > A last detail. Experiment with two circles and add the results of the > operation to the map. Zoom on one of the extremities; you will most probably > see that it is not on any of the original circles. > > As a general conclusion: never consider circles as geographical objects and > process them thinking that are "precise". > > Jacques Paris > e-mail [EMAIL PROTECTED] > MapBasic-MapInfo support http://www.paris-pc-gis.com > > -----Original Message----- > From: Lawley, Russell S [mailto:[EMAIL PROTECTED] > Sent: 11-Jun-04 09:01 > To: [EMAIL PROTECTED] > Subject: RE: MI-L returning the coordinates of 2 intersection points of 2 > overlapping circles > > Erin, > > you should look at the intersectsnodes function (if you are using Mapbasic). > > this will return a polyline for two intersecting ellipses, the start and end > points of which will define the coordinates of the two 'crossing points'. > (use the objectinfo or objectgeography functions for finding these values > from teh line) > > > regards > r > > > > > > ********************************************************************* > This e-mail message, and any files transmitted with it, are > confidential and intended solely for the use of the addressee. If > this message was not addressed to you, you have received it in error > and any copying, distribution or other use of any part of it is > strictly prohibited. Any views or opinions presented are solely those > of the sender and do not necessarily represent those of the British > Geological Survey. The security of e-mail communication cannot be > guaranteed and the BGS accepts no liability for claims arising as a > result of the use of this medium to transmit messages from or to the > BGS. . http://www.bgs.ac.uk > ********************************************************************* > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Message number: 12153 > > > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Message number: 12156 > > --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 12172
