Date: Thu, 14 May 92 09:08:04 -0500
From: rewerts@ecn.purdue.edu (Chris C Rewerts)
Message-Id: <9205141408.AA29509@pasture.ecn.purdue.edu>
Sender: lists-owner@amber.cecer.army.mil
Reply-To: grassu-list@amber.cecer.army.mil
Precedence: Bulk
To: grassu-list@amber.cecer.army.mil
Subject: bdlg directoryI have been helping someone to import dlg files into GRASS.
After completing one of our sets of maps, I noticed in
the $LOCATION/bdlg directory hundreds of files with the names of
the original (ASCII) dlg files that were imported (however
the files in the bdlg dir are not ASCII).The individual dlg files were imported to grass vect,
then v.support was used to build topology, then individual
maps were joined into larger maps with the help of v.db.rim.
After the conglomerate maps were created g.remove was used to
nuke the small section maps created from the dlg files.My questions to those in the know: are the bldg files now
necessary? If not, why weren't they removed when the vector
maps of the same name were removed? What part of the operation
created them (v.in.dlg or v.support)?Chris Rewerts
This is a known problem (but not widely discussed). It is a residual of
the diverse past of MAPDEV. The bdlg files used to be the primary GRASS
vector format. They are currently only created as a by-projuct of
v.in.dlg. This program is really two different programs. They used to
not delete the file because they were a somewhat useful data file. That
functionality did not change in 4.0 when they were merged to support one
program (i.e. v.in.dlg). I am currently re-writing that program
to bypass the bdlg stage altogether. Until that time, the files do
accumulate. Guess we should put in a bug report to have the files
deleted automatically.
--
Dave Gerdes
US Army Construction Engineering Research Lab
Spatial Analysis & Systems Team
dpgerdes@cerl.cecer.army.mil
(217) 352-6511 x591