"Eric G . Miller" wrote:
On Wed, Oct 18, 2000 at 02:18:31PM +0000, David D Gray wrote:
> Hi all,
>
> Is there a definitive spec for the formatting of a line in a dig_att
> database file? There are several options in src/include/dig_att.h. You
> could use that to format the lines with write_att() but that truncates
> the decimal digits to 2, which is not satisfactory in many instances.
> Also it does not produce lines the same length as those created by some
> other modules.
I didn't find one in the grassprogman50.pdf, so I assumed there wasn't.
But, yes 2 decimals is often not sufficient. When I updated s.to.vect,
I just followed the example of writing the file directly. This, of
course, seems really bad form. The structure of this file is described
in the programming manual. Frankly, I think it is fairly limiting.
This and the dig_cats thing need to be addressed in any update to the
Vect_lib.
That is what most people seem have to done, so perhaps in spite of the
warnings about it being a rigid format, for now we just format each
entry at the module level.
In fact, there will be inline categories for the binary file that will
do away with dig_att and dig_cats for a 5.x release that Radim and
myself are working on. The inline values will be indices relating to
fields in an `external' database.
On a related note: Since I know you're pretty familiar with vector
processing in GRASS, I've a little question. There's this idea that a
site_list can have a floating point category value. While it doesn't
make any sense to me, I've been trying to accomodate it. Anyway, when I
updated s.to.vect, I ran into the problem that vectors can't really have
floating point category values. s.to.vect, for instance, currently
writes a floating point dig_att like 'P <east> <north> DD.dddd' and a
dig_cat that matches like 'DD.dddd:"Yankee Doodle Dandy"'. Anyway, when
v.support is run, the category file is left untouched, but all of the
floating point category numbers in the dig_att are truncated. Of
course, then you have a broken "link" between the two. Perhaps this
problem is really this conception that a site can have a floating point
category (wouldn't it be better for any raster to site program to write
an integer cat [or none] and put any float values in either a
"dimension" field or a "decimal" attribute (also redundant as well
IMHO)). I'd appreciate an insight you might have.
All this seems to arise from the confusion about category value, which
as the word implies should mean an index assigning the entry to a
descrete category, such as record no, site ownership etc. This was in
the old versions confused with attributes of entities. GRASS5 was
supposed to do away with the confusion, but allowing fp categories just
brings it back because you can't reliably use an fp value as an index. I
think ideally category should only ever be an ID code, but unfortunately
because of GRASS's current extremely limited attribute support, we often
have to use it for something else.
It _would_ be better for all database types to write integer categories.
fp info in a raster should be written to a fp attribute column in the
sites-list, and to a dig_cats file in a vector (so it must be referenced
by an index code in v.digit etc. and we can't use an ID - these are the
problems we are trying to address).
I don't think the attribute columns are redundant, unless you hold as
some do, that the sites-list is redundant. Sites are a simplified form
of locational data, repeating to some extent the vector sites, but the
simpler format is ideal for some circumstances, for example if you have
a multi-layered vegetation survey map, you might want to hold different
sets of relevee location data in site-lists.
David
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
