[GRASS5] v.in,dxf

David D Gray ddgray at armadce.demon.co.uk
Tue May 22 10:16:46 EDT 2001


Radim Blazek wrote:
> 
> David D Gray wrote:
> >
> > 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.
> >
> > Of course this isn't necessarily a time separation. It's just a logical
> > or programmatic separation. Some stages may be carried out in parallel
> > as lines are imported or they may be sequential.
> >
> > David
> 
> Is it second stage more than v.spag + v.rmdup (if working correctly)?

The second stage works by loading the vertices into a structure that is
a kind of network, with some of the properties of a graph, and some of a
keyed database. The points can be loaded for the whole map, for a
specified segment or for a region based on a spatial query (the last two
not available yet). Then cleaning of various kinds can be done by
standard routines that we develop. ie. elliminate line-crossing if this
is not allowed, and remove duplicate and colinear tracks. So it provides
the functionality of v.spag and v.rmdup, but does it in a more
consistent way, and does much more. 

> 
> I would prefer two import stages separated into modules because second
> stage proces may be used for other (non import) tasks also
> (clening patched maps for example).
> 

We can also use this for carrying out the functions of things like
v.cutter and v.patch, and implement v.rmdup and v.spag this way.

> Cleaning proces will be always problem for dirty maps and so may be
> useful to have possibility to compare map before and after cleaning proces
> to find problems and occasionally edit by hand.
> 

I briefly included an option in v.in.shape for storing lines the import
registered as `bad' in some way, in an auxiliary line-only map called
<mapname>_rej, but it needed more work so is currently disabled. But
something along these lines is not too difficulkt to do.

David





More information about the grass-dev mailing list