ESRI Shape Output (v.out.shape) !

[Eric G . Miller]

On Wed, May 17, 2000 at 01:56:42PM -0700, Rich Shepard wrote:
<snipped>
>   I'm starting to design the MI<->GRASS filters from the MI side. I'll be
> very happy to use your code to get the data into GRASS once I get it out of
> MI, or vice-versa. No sense re-inventing the wheel, as you noted.
> 
>   The MI file format is very well documented and is easy to parse into data
> structures. The trick -- for me at least -- is understanding the GRASS data
> structures so I can put the right values in the proper files.
> 
>   The other hang up is my understanding of the "arc-node" format in
> practical terms. A MI region (polygon) is a list of nodes with the first and
> last nodes having identical values. I've no idea how to separate this one
> line into meaningful segments (arcs) for input into GRASS. I'm certainly
> open to ideas, thoughts or solutions, for I've never had to deal with this
> before.

This is part of the drag of both the shapefile and mif formats.  Here's
how ESRI itself deals with the problem in ARC/INFO -- it imports
polygons (and lines?) as "regions".  Then the data has to be
built/cleaned.  The problem with these "tuple" style formats is they
don't "share" data between objects.  They're essentially vector
graphics.  The arc-node idea is everything is a remapping of
relationships of points.  A line segment is a remapping of a start node,
a series of vertices and an end node. Polygons are mappings of line
segments (arcs) -- minimum of 3.  So a particular node can be shared by
multiple objects, and the same for a particular arc (or edge).  Note, a
node has a particular definition as having at least 3 connecting line
segments.  To get around that, there's a concept of a "psuedo node" to
handle the cases of island/hole polygons and lines that don't terminate
at a junction with another line (such as a cul-de-sac).  The problem is
the shapefile or mif can have overlapping polygons, unsplit line
segments and other such no-no's (I don't know if MapInfo has an idea of
cleaning data, but ArcView sure doesn't). 

While it's a bit of work, you could check for errors such as sliver
polygons, unsnapped nodes, etc. in the conversion.  When such errors are
within a suitable tolerance, you could correct them without warning.  If
they're greater than the tolerance (such as large slivers), you could
create a new polygon with a bogus category value and warn the user that
the data contains slivers.  But this may be more work than you want to
do (grass's v.support/v.digit can help the user with this).

Maybe, the solution is to create a temporary file or two, map out all of
the points in the input file, then make another pass (or two) to map out
the edges and areas (if you think you can "get" enough memory, that's,
obviously, much faster).  I'm not familiar enough with GRASS's format or
interface or the MIF format to comment on the specifics of the
translation.  I've, of course, been thinking of the 2d/2.5d world in
this discussion ;)

I'd be interested in what you come up with.

-- 
¶ One·should·only·use·the·ASCII·character­set·when·compos­

» ing·email·messages.