[GRASS5] Layers Clarification

[Radim Blazek]

On 3/6/06, twiens <twiens at interbaun.com> wrote:
> An example statement might read like:
> "In GRASS 6, vector files contain both topology data and
> thematic representations of that data referred to as layers.
> Layers do not actually contain any geographic objects but
> provide links (database keys) between geographic objects in
> the vector file and one or more attribute tables. In this
> way topologically related but thematically contrasting data
> can be stored in a single file.

OK.

> Essentially this feature
> provides some attribute management for systems using DBF
> files instead of an SQL database and is functionally
> identical to a thematic layer."

The system is the same for all database drivers. There is no difference
between how DBF and Postgres attributes are handled.
It is built in the system and it cannot be simply 'moved to database'
until you move everything to database, IMO.

The possibility to keep in a database the relation between geometry objects
in a map and more tables/records was considered during the development
of  GRASS 6.0. It does not appear to be better solutin because all the
geometry processing is done in files.
Example:  Say that we have one layer with 2 loverlapping lines
linked to 2 records in one table.
            1
+-----------------------+        2
                +-------------------------+

Now we want to clean data and remove the duplicated part,
we run v.clean tool=break,rmdupl result (in current implementation):
         1          1,2       2
 +--------------+--------+----------------+

and if we move  the relation to database we have to assign
unique cats to each segment
         1          2          3
 +--------------+--------+----------------+
and add another table , eg.

map id |  table id
1         |     1
2         |     1
2         |      2
3         |      2

OK, that is possible but we have to do the changes in the database
during the geoprocessing of file and that can make it complex
and probably slow (random acces to database is terribly slow).

Radim

> In the long term, rather than adding to this feature I think
> it should be removed and attribute management left with the
> database where it belongs. However since I don't have the
> time to commit to that level of work, my opinion obviously
> shouldn't carry much weight.
>
> To summarize, I'm happy to draft an explanation of this
> feature and contribute it to the documentation. I look
> forward to guidance as to the appropriate placement.
>
> T
> --
> Trevor Wiens
>
>
>