Ian,
This example is fixable, at least back to MI Pro 5.0 functionality, and we
will look into incorporating it into future MI Pro releases.
However, I'll make a distinction between "One Buffer for Each Object" and
"One Buffer for All Objects". This functionality will be fairly easy to
change for the "One Buffer for Each Object" functionality, and I don't
think it will have much impact on performance. However, such a change to
"One Buffer for All Objects" could have a noticable impact on performance.
That is because, in this case, we first perform a Combine, and then buffer
the resulting combined object. This is a change from the MI Pro 5.0
functionality. Buffers done in Latitude/Longitude are inheriently
inaccurate (see below).
We calculate one X value and one Y value per object for the buffer width.
While the Y width value (Longitude) will remain constant, the X width value
(Latitude) will vary by the location on the Earth. This is compounded by
the spherical distance calculation used (which while a very good
approximation, is still an approximation). Thus, even for a single object,
the buffer will be an approximation. You should be able to see this by
running your test program in MI Pro 5.0 and seeing that the distances vary
slightly within an object. This could be improved by re-calculating the
distance for each point along the buffer, and moving the node
appropriately. But, this would be prohibitively expensive.
My suggestion is, for buffers that are of a more local scope, to use a
projected coordinate system. This will eliminate the Lat/Long X value
varience, and you can use a more accurate cartesian distance calculation.
The resulting buffers should be more accurate.
Derek Snyder
MapInfo Corporation
---------------------- Forwarded by Derek Snyder/MapInfo Corp on 12/21/99
10:39 AM ---------------------------
Mail List:[EMAIL PROTECTED]
From: Ian Erickson <[EMAIL PROTECTED]> on 12/17/99
05:42 PM CST
To: [EMAIL PROTECTED]
cc:
Subject: MI Buffers with problems...
Here's a challenge for those of you who are willing to accept:
I know there has been extensive documentation of buffers created in the
Cosmetic Layer being elliptical. I understand that MapInfo is aware of the
problem and is working to fix it. The proposed work-around is to create
the
buffers in a MapInfo table that has a projection. So if I was 'Joe User',
I
might find a point layer make the layer editable, select Objects->Buffer...
and then create the buffers in the same layer as the points. Once the
buffers are created I would save the selected buffers as a new table, and
all is good right? Wrong!
When 'Joe User' does this, (ie the Objects->Buffer... menu command) MapInfo
executes the command:
Create Object As Buffer
From Selection
Into Table {sourcetable}
Width 200
Units "mi"
Resolution 50
Group By RowID
Guess what, if your layer is somewhat dispersed over the earth, the objects
on the edges are more and more deformed. Meaning: they become elliptical.
I've attached an .MBX, source code and the MapInfo table used to recreate
the problem. All this program does is compute the distance from the center
of the circle, to the nodes on the edge of the circle. In an ideal world,
you would expect to see the 200 miles from the center of the circle to each
of the points comprising the buffer. For those of you out there who are
experts in the field of projections, datums and spherical coordinates, help
me out here. I ran the same program on a version of 4.5 and the problem
did
not occur, however, 5.5 really messes things up. I've got a work-around
for
myself, which is slower and more time consuming, but I suggest that this is
a bug NOT a feature.
Ian Erickson
GIS Analyst
<<AllPoints.DAT>> <<AllPoints.ID>> <<AllPoints.IND>> <<AllPoints.MAP>>
<<AllPoints.TAB>> <<test.mb>> <<test.MBX>>
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
