2012/1/25 Sören Gebbert <[email protected]>: > > 2012/1/25 Markus Metz <[email protected]>: >> >> 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. > > 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... 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 <[email protected]>: >>>> 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 >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
