[GRASS-dev] Struggling using two layered vector maps with v.what.rast

[Markus Metz]

Hi Sören,

2012/1/25 Sören Gebbert <soerengebbert at googlemail.com>:
> Hi Markus,
>
> 2012/1/25 Markus Metz <markus.metz.giswork at googlemail.com>:
>> 2012/1/25 Sören Gebbert <soerengebbert at googlemail.com>:
>>>
>>> 2012/1/25 Markus Metz <markus.metz.giswork at 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?
>
Yes. But it is not recommended because the coor file will be filled up
with dead lines (waste of disk space, slowing down reading).
>>
>>>
>>> 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?

Not so hard ;) But with thousands of vector layers you could
experience slowed down operations involving categories, slowed down
exponentially with the number of layers. But maybe this only becomes
an issue with hundreds of thousands of vector layers.
>
> 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.

For the time being, you could run v.category option=transfer in a loop.

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 at 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 at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/grass-dev