On 16/06/09 18:50, Michael Barton wrote:
Many users writing to the lists seem baffled by GRASS layers. They are complicated to explain whatever we name them. My opinion--completely unsupported by any systematic data and only by anecdotal experience--is that these would be more understandable to more users if we used a term that emphasized the database nature of this feature rather than a term that suggests that it is most similar to multiple geospatial data layers combined into one file--the vector equivalent of a geotiff.
But this is _not_ - primarily - a database feature. It is a way of organising objects within the same file - thus allowing topological relationships - but with different meanings. The fact that you can then link these different meanings to different attribute table is just an additional - very useful - feature. But you can use the layer feature without connecting any of the layers to tables. In the examples Radim gives (for example in [1]), he always talks about attribute tables, but I never see them as central to the concept, but it is the possibility of attributing different "natures" to the same objects.
I think that when we think about layers as "purely" database-related, then we miss the main point, and it is actually debatable whether this database-related usage is best dealt with through a layers paradigm (see the thread starting with [2] and then moving to the -dev list with [3]
Yes, layers are complicated. I normally tell my students just to ignore them as when they come to a stage where they might actually need them, they should already be advanced enough in GRASS to be able to dig into the documentation/lists to learn more about them.
I also believe that many users will never need layers. They are useful for very specific needs, which are not database related. See [4] for an example.
Moritz [1]http://lists.osgeo.org/pipermail/grass-dev/2006-March/021650.html [2]http://lists.osgeo.org/pipermail/grass-user/2006-September/036284.html [3]http://grass.itc.it/pipermail/grass5/2006-September/025907.html [4]http://lists.osgeo.org/pipermail/grass-dev/2003-November/013091.html _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
