[GRASS-dev] Re: [GRASS-user] RE: Problem querying layers other than '1' in gi s.m

[Radim Blazek]

On 9/27/06, Michael Barton <michael.barton at asu.edu> wrote:
> Trevor,
>
> I won't belabor this, because I think you and Moritz both have important
> points. But want mention a couple things.
>
> Doing what you suggest *is* 'cleaner' in a pure database sense. However, you
> can do that now by simply using GRASS tools to assign unique cat values to
> layer 1, and forgetting about the other layers.

Yes. It was forseen and considered that multilayer concept can
be difficult for some users and all modules are using default layer 1.
If you don't like layers you can completely forget about them
and do whatever you want with tables attached in database
and unique cat assigned to each geometry.

In general, I only ask you not remove some functionality just because
it seems to be difficult/useless/not used until you have a better replacement.
For me it is completely OK if you implement the same functionality on
DB side and show us that it has better performance and it is simpler code.

My only wish is that existing functionality (in core libs) is not removed
without replacement just for "I dont need that" reasons.

I know about problems with current vectors, but this is not one
of them. It would be better to solve real problems.

OK, that is all from me on this issue.

Radim

> Layers *are* shortcuts, that are especially handy for one-to-many and
> many-to-one relationships between vector objects and attribute records. They
> make intermediary tables unnecessary and can help save space for vector
> files with large numbers redundant objects linked to an attribute table with
> few records (many-to-one join). They also save a link, sort of like a view
> (see below), between vector objects and attribute table records so that you
> can query with specifying one of the join clauses in a where statement. The
> 'where [vector key]=[table key]...' is implied once you've run v.db.connect.
> But I suppose that this is where the cleaner joins that you mention come in.
>
> It would be nice to be able to do multi-table joins. But I'm not sure you
> cannot do that already if you're working with a DBMS that supports true SQL
> queries, like PostgreSQL or SQLite. I think that GRASS will simply pass on
> an SQL query to the DBMS. If so, then multi-table joins might be doable. Has
> anybody tried this?
>
> There seems to be some confusion in your statement about not liking GRASS as
> a database and so switching to PostgreSQL. Perhaps what you really mean is
> that you find dbf limiting for attribute management and prefer PostgreSQL. A
> dbf format table structure and database driver is included with the standard
> GRASS build. However, the dbf tables link to vectors exactly like PostgreSQL
> tables--via the key we call a cat value in a layer. They are
> interchangeable, structurally, with PostgreSQL, MySQL, SQLite, etc. For each
> of the supported DBMS's there needs to be a GRASS driver. The dbf driver is
> fairly limited in terms of SQL, but the drivers for other systems are much
> richer. But in any case, you can link different PostgreSQL tables to each
> GRASS key field that you create as a layer (You probably already know that,
> but others might want to have this clarified). We are seriously considering
> switching to SQLite as the database driver and table structure that comes
> with the default build. This would offer a much richer set of SQL, although
> tables still have to link up with vector objects somehow.
>
> It would indeed be nice to be able to save views, although this has nothing
> to do with keys. By semi-permanently linking multiple tables with the
> objects of a vector file, layers can sort of serve as views, but they don't
> have the richness or flexibility of real views.
>
> It would also be nice to be able to select vector objects and their linked
> attribute records interactively from a map. This is one nice feature of
> ArcGIS and MapInfo that GRASS lacks.
>
> What I think Moritz is getting at is that you can simply ignore layers 2
> through whatever and do exactly what you are proposing. Or you can use
> layers as a short cut to joining multiple tables to vectors.
>
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
>
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>