[GRASS5] v.in,dxf

[David D Gray]

"Roger S. Miller" wrote:
> 
> 
> [...]
> This is a considerable problem with DXF files.  The only "entities" I
> know of that actually define each vertex are the LINE -- a straight line
> defined by two points -- and POINT entities.
> 
> POLYLINE and LWPOLYLINE entities will often define all of the necessary
> vertices, but they can include curved segments (called bumps) that are
> specified with a "bump factor" and two vertices.  The application that
> interprets the DXF has to supply the actual vertices that form the
> curved segment.  I've never come a cross a polygon entity, but both
> POLYLINE and LWPOLYLINE entities can be closed to form polygons.
> 

This seems like relating the density of points along a line to curvature
where this has to be autogenerated from some parameterised line. 

> Other entities similarly don't define the necessary vertices.  A CIRCLE
> is defined with a center and a radius, and an ARC is defined with
> center, radius and beginning and ending azimuths.  Maybe the worst of
> all, a SPLINE is defined with a set of control points, and the actual
> curve passes near (not usually through) the control points.
> 

In each case, we could have an algorithm for generating a series of
coordinates of a true polyline from the parameters given. These would
have to relate the assigned positions to 1) the curvature as we move
along the line, and 2) the map scale as specified in PERMANENT. Maps at
different scales need different resolutions of curvature.

> 
> > Here Stages 2 - 5 correspond to my second phase. 2 is - because the same
> > procedure is used to process linework from arbitrary but adequately
> > defined lines to the GRASS area boundaries. 1 contains most of the
> > procedures unique to a particular import type.
> 
> I think with a DXF the idea is that the rendering software defines the
> actual vertices in the drawn objects at the time the entity is
> rendered.  Spacing between the vertices is selected to match the scale
> of the drawing and the resolution of the device they're being drawn on.
> When the entities are imported into GRASS the importing software must
> somehow calculate the vertices to provide sufficient resolution for most
> purposes.  That's why I figured conversion to a consistent internal raw
> data format would be part of the format-specific code, rather part of
> the generic import capability.
> 

There are really three stages of line data. 

1) the original, that can be anything.
2) polylines that have been assembled from the interpretation of the
spatial data in the original.
3) the polylines in the dig (vector) file that are in a correct coverage
format, but not yet indexed (built).

So the specific first-phase would need to handle the 1->2 import, and
the 2->3 import would be the generic stage. The lines in the
intermediate (2) stage would have the correct positions and links, but
can be chopped any way, and may be duplicated. For example, at one
extreme, they could be whole polygons, and here each vertex and link
would occur precisely twice, apart from a possible universal boundary.
At the other extreme, they could just be a list of the simple links,
which would occur once and the associated vertices 2 or more times. So
2->3 import really does some processing, it's not just a stream
converter. All this assumes the import stuff is `clean', the 2->3 import
should attempt some correction of common errors, such as degenerate
polygons of the type:

------X-----------------------------------X-------------
       ---------------X-------------------

in I hope an obvious convention.

> <snip>
> > This is a point, if we are importing actual topolgy, then there should
> > be a way of transferring the details from the original file to the GRASS
> > topo file. What formats are affected? Arc/Info binary/e00, DLG, SDTS
> > that I can think of. I don't know much about these modules, I assumed
> > they already do this OK. Perhaps these should remain in their own
> > development branches for now - only updated for 5.1 changes. The generic
> > module would cover shapefile, Mapinfo, DXF and A/I ungenerate at least.
> 
> I understand that SDTS can contain considerable complexity, but isn't
> DLG a pretty simple format?
> 

I've seen the DLG Optional format Level 3 spec. It seems much like A/I
binary/e00 in terms of the information given.

> It appears that the problem of importing a DXF may be substantially
> different from that of importing data from the GIS applications.
> Perhaps it won't fit the same generic model?
> 

The first stage is pretty unique, but the second phase will be the same
as shapefile, mif etc. as these also must be deconstructed and
re-assembled. But import of the true topo formats could be more direct
(or could be deconstructed and rebuilt, if the original data couldn't be
trusted).

David