[GRASS5] v.in,dxf

[David D Gray]

"Roger S. Miller" wrote:
> 
> On Mon, 21 May 2001, David D Gray wrote:
> 
> > Michel Wurtz wrote:
> > >
> > > I'll probably look stupid, but what is the second phase of the import ?
> > > The process of importing vector is mainly a stream (with some exceptions
> > > when reading the imput file).  If not, you will need a temporary storage
> > > format (on disk, because storing everything in core memory will allways
> > > limit the size of the imput file)
> > >
> >
> > It's only a direct import if the original format supports component
> > arcs. Many formats record the data as whole polygons, so must be 'split'
> > to arcs before writing to dig files, so some kind of intermediate is
> > necessary.
> >
> > The first stage is substantially diffferent for different formats. Also
> > there is often pre-processing or different fields to be read. A Mapinfo
> > import has to record the Pen and Brush attributes (or will if we are
> > going down the road of incorporating these). More significantly, you
> > have to `deconstruct' the topology of a set of components in a shapefile
> > as a shape can be compound. So stage 1 reads the original format,
> > pre-processes the data and deals with spatial and data attributes. Stage
> > two imports the linework as arcs regardless of the original format, from
> > a common intermediate.
> 
> I find this a little confusing for the case of a dxf import.  DXF files
> contain no topology, but they do contain a large number of different kinds
> of drawn objects, none of which are polygons and none of which interpret
> to GRASS polylines without some computation.
> 

The form of the original points is not important - it only requires that
the position of each vertex be given and that there is some way of
knowing how they are linked. The problem with importing DXF as polygons
is that usually (as you point out) they don't represent a polygon
coverage - that's not generally what CAD is for. If it is being used for
that purpose however, then the import would assume that it is in a
suitably correct form, or near enough to be corrected. So if you import
a layer from a DXF with the instruction to build it as an area coverage,
GRASS will try to do that and assume that any lines that do not conform
to the required topology are errors.

> I nearly asked the same question that Michael asked, but held off.  Before
> reading your answer I had envisioned a five step process.
> 
> 1)  Read the vector data from it's native format
> 2)  Recalculate the lines specified in the native format to GRASS
> polylines, and store the raw data.
> 3)  Check each object against objects already imported and remove
> non-unique object
> 4)  Build GRASS database support files
> 5)  Write the GRASS database
> 

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.

> In this breakdown the first 2 steps would be specific to the format and
> would result in a raw database, probably resident in temp files.  The last
> three steps could be part of a generic import capability.  The generic
> part of the process would start with the information stored in the temp
> files and result in a final imported database.
> 
> In the case of a DXF file, this is OK, but the same procedure applied to a
> format that included topology would result in the loss of the original
> topology.  I presumed that a topology would be rebuilt with a new
> v.support.
> 

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.

> David, is an "arc" in your usage similar to a polyline?  I found the term
> initially a little confusing.  Autocad uses the same term to refer to a
> section of a circle specified with a center, a radius and beginning and
> ending azimuths.

Well, `arc' is a confusing term. It is sometimes referred to a line
segment, and, as in the phrase `arc-node' , sometimes has to be
interpreted as a polyline, and also it's usual geometric meaning of a
curve segment. But polyline is also ambiguous. In the context I mean
here, I mean a single non-overlapping, non-crossing and
non-self-crossing line segment that constitutes the boundary of an area
between two nodes (or pseudonodes) in an area coverage that is a
correctly formed 2-dimensional manifold (... rare as hens' teeth these
days...  ;) )

David