Hi Markus,
2012/1/25 Markus Metz <markus.metz.giswork@googlemail.com>:
2012/1/25 Sören Gebbert <soerengebbert@googlemail.com>:
2012/1/25 Markus Metz <markus.metz.giswork@googlemail.com>:
Note that a GRASS layer is defined by the existence of at least one
vector feature with at least one category value in that layer. That
layer may or may not be attached to an attribute table. For examples,
see v.in.ogr when importing several layers at once, the LiDAR
filtering tools, or the vector output of r.stream.extract.
I will have a look.
Also the v.net.* modules, which make use of layers to distinguish
between line and node costs with the help of layers.
Why is a full vector copy needed in case of category transfer from one
to another layer?
Because category transfer takes place in the vector feature, i.e.
modifies the coor file of the vector. v.category option=transfer does
not add an attribute table (AFAIK).
Maybe this function:
off_t Vect_rewrite_line(struct Map_info *Map, int line, int type,
const struct line_pnts *points, const struct line_cats *cats)
can be used to add new layer using existing categories (from layer 1?)
to an existing vector map?
Adding a new layer always means adding new categories, also if they
are identical to categories in a different layer. The difference
between Vect_rewrite_line and the combination of Vect_delete_line,
Vect_write_line is only that Vect_rewrite_line is supposed to check if
the new line fits into the space used by the old line.
If i understand this correctly the vector library provides the
mechanism to implement vector modules to add new layer and copying
existing categories into the new layer using the same vector map?
My problem is that i want to successively add new layers (tables) to
existing vector maps using existing categories.
The problem is that the categories are not existing for a new layer
because of the definition of a new layer. If there would be categories
existing for that layer, the layer would already exist.
I guess you must either use v.category option=transfer or have a bunch
of tables but only one vector with one layer and disconnect/reconnect
the tables as needed, only one table would then be connected to the
vector at any given time. I have used that successfully for time
series points some time ago, it's the fastest solution but needs some
care in handling the tables. Probably not an option for the temporal
database unless you want to introduce db.table.timestamp...
This is currently not an option.
But i guess i can modify v.category to support the transfer of
categories to more than a single layer of a new map:
v.category --o input=soils output=soils1 option=transfer
layer=1,2,3,4,5,6,7,8,9,...,2000
This will copy the cats of vector map soils from layer 1 into the new
layer 1 - 2000 of vector map soils2.
Can you estimate how hard the implementation will be?
Best regards
Soeren
btw:
* v.timestamp with layer support is in svn
* Vector layer timestamp support in the temporal GIS implementation is
in my local svn copy and needs more testing -> i need to create
vector maps with multiple categorized layer.
Markus M
Additionally i need to
timestamp the layer in the temporal database. It would be meaningful
to timestamp layers at file level using v.timestamp too.
An approach which i have in mind is to extent v.timestamp with a layer
option, so that timetsamp text files can be created for each layer in
the vector map directory.
An application in the temporal GIS and for environmental modelling
would be the observation of raster time series at specific vector
point locations. The vector location do not change over time, but the
attribute tables. Hence, for each observed time step a new timestamped
layer and table will be added to the observation vector map and filled
with raster values.
i just started to investigate the
new shiny world of multiple layer usage.
I hope you enjoy it!
I do. 
Best regards
Soeren
Markus M
Best regards
Soeren
2012/1/25 Martin Landa <landa.martin@gmail.com>:
Hi,
db.copy from_table=soil to_table=soil_2
-> makes copy of `soil` table
v.db.addtable map=soil table=soil_2 layer=2
-> it would overwrite `soil_2` table, but do nothing in this case, no
feature have category defined in layer 2.
Proposal:
v.random --o -z seed=1 output=soil n=20 zmin=0 zmax=100 column=clay
v.category input=soil out=soil2 option=transfer layer=1,2 --o
db.copy from_table=soil to_table=soil_2
v.db.connect map=soil2 table=soil_2 layer=2
v.db.addcolumn map=soil2 layer=1 columns='sand_frac DOUBLE PRECISION'
v.db.addcolumn map=soil2 layer=2 columns='sand_frac DOUBLE PRECISION'
...
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
But with thousands of vector layers you could