With MI6.5, a MIG file created by the Grid thematic tool reveals strange
things. If MI uses the xmin, ymax as the anchor point for the MIG (upper
left corner) the outer point is the multiple in number of cells just above
the observed xmax and below ymin from the anchor point. The first strange
things is that in the Settings windows of the Grid requester after adjusting
for cell size, the grid size is displayed with one less unit (in width as in
height) that would be necessary to cover the entire surface.

The next strange thing is revealed by some dll calls to the MIG file for
info (MiGrid.DLL) These calls return the number of cells as been 1 more than
the required number, but with a relatively exact set of coordinates for the
region covered. Some tests I ran with an oldie of mine (InfoExMig) and
particularly the conversion of the MIG file to a standard MI region TAB,
confirm that even if MI tells you that the grid should be say 121x115 cells
(settings) while it should be theoretically 122x116, it generates an image
of 123x117 cells that do not measure the set value of 1 (in this example)
but of 122/123 in width and 116/117 in height.

There does not seem to be a way to control this procedure. I have tested one
possible solution that of adding a fake "extreme" point with coordinates 1
cell units more in x, less in y than required. That will stretch the MIG so
that the required surface will be covered and that its "pixels" will
correspond exactly to the cell of the cellular map, which is satisfactory
even there might be an extra row or column beyond the required area.

If it works "geographically" speaking, I cannot say that the numerical
results would be good. The introduction of fake points may have an impact on
the interpolation at least in the surrounding areas, except if (not tested)
they can be given a zero value and that zeroes can be ignored. I am sure
that the grid is defined on the set of points, independently of their
z-values. However if zero is an acceptable value for a variable, that
approach falls through.

I do not believe that one should go to such an iffy extent for finding a way
around what I consider a faulty behavior. May be this has been corrected in
later versions. I would very much hear about your experience in that area.

Jacques Paris
e-mail  [EMAIL PROTECTED]
MapBasic-MapInfo support  http://www.paris-pc-gis.com





---------------------------------------------------------------------
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Message number: 10650

Reply via email to