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

[David D Gray]

"Eric G. Miller" wrote:
> 
> On Tue, Feb 20, 2001 at 05:12:48PM -0800, Rich Shepard wrote:
> >   I'm really puzzled about this. In the project directory, I placed a
> > MapInfo .mif/.mid pair of files to add to the data already there. I can view
> > raster, vector and sites data in the directory with 5.0beta11.2. However,
> > each time I run v.in.mif, I'm told that the .mif file doesn't exist.
> >
> >   According to the man page, v.in.mif looks for the .mif file in the current
> > directory. That's where it is. I also tried it with the source files in the
> > dig/ directory, but that made no difference. Permissions on the source files
> > are 666.
> >
> >   Any ideas?
> 
> Nope.  I tried you files. Same result.  Among the things I noticed: No
> category file seems to be written, the program just exits silently if
> you don't specify a log file.  For this particular file, there seems to
> be alot of misplaced area attribute markers (not unusual with these darn
> non-topological spatial graphics files...) -- apparently a few islands
> too.
> 
> This is a very new module, so I'm sure David will be working on it
> more...  The conversion of these graphics type files to arc-node is hard
> to do well, while the reverse is easier.
> 

Hi Eric, Rich,

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

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.

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

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?

The state of the module was one of the reasons I had commented it out in
the first place, in fact I did that when I started to develop the code
for line-splitting, as that broke the module completely for a while. It
now compiles and runs, but clearly is not very usable yet. I will look
through the code this weekend and try and sort some of the more annoying
minor bugs. For now, I will change the code to use the map's value of
the centroid instead of the calculated one. That will elliminate the
need for the ring topolgy code - which I am _certain_ is the main source
of the bugs. Oh - there is the snapping problem, which affects both
v.in.shape and v.in.mif on large scale maps eg. lat/lon., but I think
I've tracked down what is causing that and it will be fixed first.

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

Regards

David