[GRASS-dev] GRASS vector and vector layer handling

[Markus Metz]

2012/1/22 Sören Gebbert <soerengebbert at googlemail.com>:
> Dear all,
> what do you think about a new approach of handling vector maps and
> assigned database layer?
>
> To access the vector/layer combination in a vector module, the user
> must separately define the vector name and its layer number/name.
> My suggestion is to combine the vector map and the layer identifier
> using a colon for separation:
>
> Example:
> Vector map = roads
> Layer = 1
> Current mapset = user1
>
> roads:1
> or
> roads:1 at user1
>
> Instead of:
> v.db.select map=roads at user1 layer=1 ...
> we can use
> v.db.select map=roads:1 at user1 ...

This would change the concept of fully qualified name, i.e. everything
that uses the current concept of fully qualified name would need to be
changed. This is a lot. The current concept applies to all elements,
not only raster and vector maps, also e.g. region, group.
>
> In case no layer is provided, layer one is used as default ... . Hence
> the definition of a layer is optional.
> The explicit definition of a layer on module base will overwrite the
> layer provided in the map identifier. Or maybe we can skip the layer
> option?

I think most modules that have a layer option already have a default
answer, usually 1 or -1 for all.

>
> This will of course make the handling of timestamped layer of a single
> vector map much easier in the temporal GIS extension. :)

...but changes the user interface for every module that works with
vectors. Does it really matter how layers are defined through module
options? Within the temporal GIS extension, the representation of
vectors and their layers is surely independent of module options?

>
> What do you think? How large would be the effort to implement this in grass7?
>
Massive I guess. The vector lib and libgis would need modifications,
and pretty much all modules working with vectors. And it breaks the
universal concept of a fully qualified name.

Not so convinced,

Markus M

> Best regards
> Soeren
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev