[GRASS5] Recommended tweak for 5.1

[David D Gray]

Michel Wurtz wrote:
> 
> Markus Neteler wrote:
> >
> > On Thu, Mar 29, 2001 at 09:24:40AM +0000, Michel Wurtz wrote:
> > > Looks also good to me... in fact, this is how m.in.e00 was written :
> > > the default location of the input file is "where you are" (i.e. pwd)
> > > That's the default behaviour of the unix "open" function. You can also
> > > use a relative path (input=foo/bar.e00) or an absolute path
> > > (input=/tmp/bar.e00).  I really don't understand what you want to
> > > change in m.in.e00...
> > >
> > > It's different for r.in.ascii or r.in.arc that use directories in
> > > $LOCATION path, respectively $LOCATION/ascii and $LOCATION/arc.
> > > BTW, you can use the same name for the binary and the ascii vector
> > > file and both use $LOCATION/dig_att for the line's or area's attribute.
> > > I think this was done because you need an ascii file for the import
> > > or export of DXF files.
> >
> > What about taking this chance and modifying the import modules to
> > all using the unix "open" function? This v.in.dxf/2 etc. behaviour
> > is quite inconvenient (and many users struggle here).
> > I don't see much sense in keeping this oldish method and ignoring
> > the unix "open" function.
> 
> In fact, i used fopen(), because it's more convenient (and probably
> more effective) for reading/writing text data, but fopen() calls
> open() and do some bufferisation as "extra".  The code looks like :
> 
>     fde00 = fopen (infile, "r");
>     if (fde00 == NULL)
>     {
>         sprintf (msg, "%s - not found\n", infile);
>         G_fatal_error (msg);
>     }
> Where "infile" is the parameter given as "input=...".  I think this
> is the right way to do things...
> 
> By the way, what function (apart v.in.dxf and v.out.dxf) uses the ascii
> vector format ?  If they are alone, we can also change v.[in|out].ascii
> in order to store the ident attribute of lines and polygons in the same
> file...
> 

Michel

Work has already begun on changing the v.*.ascii spec. You can see code
and examples in the grass51 tree. The whole setup uses indexing to refer
to attributes (including if required ID), and will also be able to hold
multiple types of vector primitive. 

> This could also lead to a complete rewrite of v.[in|out].dxf, because
> you must use the vector library for input/output on grass side.
> Probably a good idea, but it will take some time I have not yet !
> 

As a separate thread recently discussed, hopefully all vector import
will be merged into one module that will share as much functionality as
possible. For text based formats (apart maybe from native ones), it
might be a good idea to import data initially with a scanner utility -
possibly lex/yacc-based. That would make updating import easy without
having to alter core functionality significantly, and also be able to
more easily support multiple versions of the import format.

Of course, DXF is complex, and the problem would be the initial
investment in creating a lex/yacc pair for the initial import, which is
much more than for simple formats like Mapinfo MIF or ungen.

Regards 

David

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'