[GRASS5] v.in,dxf

[David D Gray]

"Roger S. Miller" wrote:
> 
> On Fri, 18 May 2001, David D Gray wrote:
> 
> > No, it's substantially similar. But this is the reason why we should
> > separate out the two phases of the import - so that we don't have to
> > duplicate effort. The other advantage is that we can utilise suitable
> > 3rd party libraries to handle their respective formats. Which is the
> > gist of what you are saying I think.
> 
> Great, I think I'm on the same page with you :).  Is there any sort of
> timetable for that generic capability to be in place?
> 
> Roger Miller
> 

I see a time-table something like:

Work has started on the changes to the GRASS 5.1 level vector library.
This aims to address as quickly as possible the most glaring
deficiencies in the current vector libs. You've possibly seen the code
in the grass51 tree - we need to get a minimum but self-contained tree
working before there can be much co-operative effort on moving that
forward. Clearly the priority is to try and get 5.0 out the door first,
but it seems that will be on the way soon.

However I've been working on an importer, which at present has a
perl-based mif import as the front end, and this is essentially
complete, also is based on the current vector engine, so there is a form
that will be backward-compatible with 5.0 anyway. A first pass at a
generic line importer, based on techniques similar to those used in
v.in.shape/mif is also about ready to roll. (Both these will get
uploaded to the 5.1 tree at some point soon.) The part handling the
external routines is only a hack to get sufficient data in from the
external format to enable me to work on the important part which is the
routines for writing to the GRASS database.  The good news is that the
import stage can easily be modified to import other ascii types, though
they are intended to be only temporary. A more final solution for a
unified front end would be the OGR library which Frank Warmerdam is
working to integrate with GRASS. Hopefully all of that would be in 5.1 -
but your guess is as good as mine as to when that will freeze.

The other `big issue' is segmentation. I don't think that will be ready
for 5.1 in general terms, but I hope to have a provisional technique in
place just for import/export, so that we can deal with _much_ larger
maps. Of course, the real reward of this eventually will be that
processing parameters (time, memory) rise more linearly with map size.

Regards 

David