Thanks for all the very useful feedback - I've used a lot of the suggestions to thoroughly investigate this annoying seperation. My conclusion is that the precision effect (explained by the 'detail' of the grid i.e. MBR etc) is NOT the problem in this case. The problem is actually to do with the difference in values reported by the ObjectGeography and ObjectNodeX/ObjectNodeY functions. Heres the scenario: Back to my program that's extending a line. Obviously extending a polyline with more than two nodes is a bit hard so before I extend the line I reduce the number of nodes in the polyline to two. (Which I believe is the minimum number of nodes you can have in a polyline). Because I'm dealing with nodes (I average all the nodes at each end of the line to reduce the line to two nodes), I use the ObjectNodeX/ObjectNodeY functions in this sub procedure. Testing this conversion sub was obviously necessary to I processed a line that only had two nodes, thereby expecting the converted line to be IDENTICAL to the original line. I asked ObjectGeography to calculate X1,Y1 and X2,Y2 (using linebegx etc) and then asked ObjectNodeX and ObjectNodeY to return values for the SAME line. The values are different which, I believe is where the error is coming from. See the results below. I then set up a file containing numerous 2-node polylines, each one at a different bearing. The error is erratic, between 0 and 90 degrees there's a difference between both reported x & y coordinates, between 90 and 180 just the x coordinates are different, between 180 and 270 they're both OK and between 270 and 360 just the y coordinates are different. This explains why I was sometimes getting a seperation error of 0.5cm and other times getting an error of 5cm plus. I've checked my code, I can't see anything wrong. Is this a problem in mapbasic? Using ObjectGeography(linebegx etc, though minx gives the same result) X1 = 2717952.07 Y1 = 5988296.66 X2 = 2717954.8 Y2 = 5988366.06 Using ObjectNodeX/ObjectNodeY on the same line: X1 = 2717954.8 Y1 =5988366.06 X2 = 2717952.07 Y2 = 5988296.66 Thanks, Michelle. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "MapInfo Discussion Group" <[EMAIL PROTECTED]> Sent: Friday, April 13, 2001 12:28 AM Subject: Re: MI-L: MB: Spherical surface mapinfo versus flat surface mapinfo > > Michelle, > > Although it is not 100% possible for me to determine without investigating > the exact scenario (with data, projections, etc.), what you are seeing > does appear to be more related to precision than to projection. MapInfo > coordinate data is stored as scaled integers, regardless off the coordinate > system used. The integers are scaled based on the bounds of the coordinate > system used. You can think of the coordinate system as a big sheat of grid > paper, where the only legal values are at the grid intersection points. > The reasons for using this scheme are historical - partly related to older > PC's not always having FPU's, thus making floating point arithmetic very > slow, and partly due to saving disk space (a 4 byte integer compared to a 8 > byte double precision floating point number). Changing newer TAB files to > use floating point number has implications, such as backward compatibility, > that I won't get into here. > > In this example, you start out with a line segment and get the coordinates > of the endpoints of the line as floating point numbers. You then extend > the line using floating point arithmetic, and feed the numbers back into > MapInfo. MapInfo will convert them to the integer grid, which may move the > point slightly as viewed as a floating point number. You may be able to > see this if you re-extract the coordinates of your "extended" line. What > you would see is that the lines appear to line up from a distance, but as > you zoom in, you will likely see the small variation in the line that you > have created. > > There are a couple of things that you can do to help this problem. One > would be to make the new line that you create be at least a 3 node polyline > - containing the first 2 nodes of the original line, plus the new extended > point. Then this new polyline will line up exactly with the old line, > although it will not be quite straight - it should appear to be straight, > but it will be ever so slightly non-linear. > > The other thing you can do is to increase the resolution of the data. This > can be done by tightening the bounds of the data - remember, the integer > cooordinates are scaled numbers based on the bounds. This can be > accomplished using the CoordSysBounds.MBX tool that comes with MI Pro. > Making the bounds smaller will essentially produce a finer grid. This will > not totally eliminate the problem, as the floating point coordinates will > still snap to a grip coordinate, but it can substantially reduce the > problem. > > I would warn against making the bounds too tight. Once the bounds are set, > nothing can exist or be added to the table that is outside that bounds. > So, when adjusting bounds, always ensure that there is sufficient room for > any expansion in the table. > > Derek Snyder > MapInfo Corporation > > > > Mail List:[EMAIL PROTECTED] > > From: [EMAIL PROTECTED] on 04/12/2001 04:01 > PM ZE10 > > > To: "MapInfo Discussion Group" > <[EMAIL PROTECTED]> > > cc: > > Subject: MI-L: MB: Spherical surface mapinfo versus flat > surface mapinfo > > > > > I'll admit to being a complete novice when it comes to map > projections/datums etc (Prof. Cliff - if you're out there, please don't > shout at me ;-) !). > > I've always worked on the basic assumption that if I'm using a > longitudinal/latitudanal setup I'm working on a spherical surface, and if > I'm in a map projection (usually AGD or New Zealand Map Projection) that > I'm > working on a flat surface. > > I've written a few mapbasic programs (mapbasic defaults to Long/Lat) and > have re-set the coordinate system to that of my mapdata (i.e. a map > projection), assuming that by doing so trigonometry/vectors etc wouldn't be > so difficult (i.e. I could discount the entire "maths on top of a sphere" > scenario). However, although small, errors are introduced that I can't > explain. An example: > > One of my programs takes a linear object (i.e a two-node line, not a > polyline) and uses vectors to extend it by a factor of 10. I can then open > the layer with the original (short) line and and the layer with the newly > created extended line. From a distance they appear to overlap exactly. > However if I zoom right in I'll find that they're actually parallel to one > another, but with a separation of anything between 0.5 and 5cm. Pretty > small, but its causing problems with the rest of the program. (I'm not > just > extending lines for the hell of it!). > > Have I reached a limit of precision in MapInfo? Or is my assumption about > using "flat maths" on map projected data incorrect? > > Thanks for any help, > > Michelle > > > > _______________________________________________________________________ > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, send e-mail to [EMAIL PROTECTED] and > put "unsubscribe MapInfo-L" in the message body. > > > > > > _______________________________________________________________________ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
