[GRASSLIST:1488] Re: A different problem with v.in.mif

[Rich Shepard]

On Wed, 21 Feb 2001, David D Gray wrote:

> Pardon my tardy entry into this discussion - I have been away most of
> the last couple of days.

David,

  Always better late than never. :-)

> It seems v.in.mif has a lot of bugs. There are some petty errors to do
> with parsing the input directory and storing some paramater data.
> Because these can be worked around, I considered these to be of lower
> priority than the kinds that can corrupt data. The module attempts to
> simulate the structure of a `shape' in a shapefile by building a series
> of rings associated with a given region. It then attempts to distinguish
> between hulls and holes by checking the circulation, and what rings are
> contained in what - so one `region' could contain disjoint polygons,
> each with its own disjoint set of holes [am I right in thinking that
> Rich ?]. Then it calls GRASS's inbuilt vector function for determining a
> centroid.

  I'm not at all familiar with shapefiles, other than getting data in that
format. If I understand what you've written (and that's a very big "if"),
the answer is "generally, no".

  MapInfo calls their closed objects "regions". A region/polygon can have
holes in it. For example, a table of lakes in a county (or larger rivers)
could have islands in the lakes/rivers. Sometimes, folks just leave the lake
region whole (entire) and place the island region(s) on top of it for
display purposes. Other folks (and I'm in this category) "erase" the island
from the lake polygon so the area calculation is true and there's only one
ground type at any given point. What this babbling means is that usually
regions/polygons are distinct. They can share a common border, but MI
doesn't build or store topology so the common border has two identical
lines; one is part of each region/polygon object.

  I've no idea of what the rings are supposed to do. I'm trying to build a
mental picture, but I'm not sure that I'm doing it properly. I also have no
idea what algorithms are used to take arc-node lines and build topology from
them. That was my stumbling block a while ago.

  Now that I'm fully committed to working exclusively with GRASS, I do need
to get my MI data over. Especially the data I've sent you this past week for
those are client data and they need to see that GRASS can work for them.
They don't have MI, that's just the way they were given the data. They tried
using it with ARC/cad (the AutoCAD add-on), but the overlapping regions
killed them, too.

  I'll start reading the code this evening. If I follow with my finger and I
move my lips, too, I'll probably be able to understand what you're doing. We
can take this discussion off the list, too, and work together on making
v.in.mif work.

  I'm also having major problems with v.in.shape on the data translated from
MI. It just won't work. But, we can discuss this privately, too.

> This is a place where a standard re-usable R-tree structure would be
> useful.

  References for me to read and learn?

> I thought from my experience with shapefiles that it is better to work
> out the topological parameters from the data that is there rather than
> relying on what the import map says (boundary data is often bizarre).
> Also - a point I don't understand: if a region can consist of disjoint
> sets, why only allow one centroid record per region, and if so, what
> does it mean?

  In the case of MI, a region/polygon with holes, the centroid is the center
of mass of the entire region. So, it may well be located in a hole. Is this
what you mean?

> Hopefully we can get this stuff working - at last - soon.

  We will. There are a lot of GRASS users with MI data out here.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
 + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard at appl-ecosys.com