[Please keep discussions on the list]

On 07/11/13 08:35, Pietro wrote:
Hi Moritz,

On Tue, Nov 5, 2013 at 5:20 PM, Moritz Lennert
<mlenn...@club.worldonline.be>  wrote:
And what happens to the categories? should I rewrite the categories to
link the new layer with the geometry features? Or if not define the
geometry features inherit the categories from the previous layer?




If you want to use the same category values in each layer, than you have the
"transfer" option in v.category (only grass7) to copy category values from
one layer to another.

Ok, I transformed the i.segment results into a vector map, add a table
with the shape and raster statistics for each segment (segment_data),
and then I have another table with the class for each segment that I
want to use for the training (segment_training),

$ v.db.connect -p map=segments@final table=segments_data_training
Vector map<segments@final>  is connected by:
layer<1/segments_data>  table<segments_data>  in database
</data/gis/edi/final/sqlite/sqlite.db>  through driver<sqlite>  with
key<cat>
layer<2/segments_data_training>  table<segments_data_training>  in
database</data/gis/edi/final/sqlite/sqlite.db>  through driver
<sqlite>  with key<cat>

After the classification I will ad a Table with a classification
results for each column, or maybe better a new table for each
classification method. What do you think?
The problem is when I try to use the v.category module.

$ v.category input=segments option=report
Layer: 1
type       count        min        max
point          0          0          0
line           0          0          0
boundary       0          0          0
centroid 2726635          1    2726635
area     2726635          1    2726635
face           0          0          0
kernel         0          0          0
all      2726635          1    2726635
Layer: 2
type       count        min        max
point          0          0          0
line           0          0          0
boundary  261842          0          0
centroid       0          0          0
area           0          0          0
face           0          0          0
kernel         0          0          0
all       261842          0          0

Now I would like to copy the categories, from the layer 1 to layer 2.
I tried with:

v.category input=segments output=segm option=transfer layer=1,2

Is it not possible to work on the input map without generating a new
one, isn't it?
Perhaps we can modify the v.category module, that if output is not
set, then open the input vector map in read-write mode and update all
the categories of the input map.

Any way lets check the output:

$ v.category input=segm option=report
v.category input=segm option=report
Layer/table: 1/segm_segments_data
type       count        min        max
point          0          0          0
line           0          0          0
boundary       0          0          0
centroid 2726635          1    2726635
area           0          0          0
face           0          0          0
kernel         0          0          0
all      2726635          1    2726635
Layer/table: 2/segm_segments_data_training
type       count        min        max
point          0          0          0
line           0          0          0
boundary       0          0          0
centroid 2726635          1    2726635
area           0          0          0
face           0          0          0
kernel         0          0          0
all      2726635          1    2726635

All the area are missing... but are missing non only on the categories
level, they are missing from the output map!

$ v.info segments -t
nodes=4779720
points=0
lines=0
boundaries=7250355
centroids=2726635
areas=2726635
islands=256000
primitives=9976990
map3d=0
$ v.info segm -t
nodes=0
points=0
lines=0
boundaries=0
centroids=2726635
areas=0
islands=0
primitives=2726635
map3d=0

I'm doing something wrong or is it a bug?

I thought that maybe you forgot to use the type parameter, but I just tried in the NC dataset and can confirm your issue:

v.category boundary_county op=report
Layer/table: 1/boundary_county
type       count        min        max
point          0          0          0
line           0          0          0
boundary       0          0          0
centroid     926          1        926
area         926          1        926
face           0          0          0
kernel         0          0          0
all          926          1        926

And then, whatever the combination of types I chose, I get

v.category boundary_county op=transfer out=bc2 layer=1,2

v.category bc2 op=reportLayer/table: 1/bc2
type       count        min        max
point          0          0          0
line           0          0          0
boundary       0          0          0
centroid     926          1        926
area           0          0          0
face           0          0          0
kernel         0          0          0
all          926          1        926
Layer: 2
type       count        min        max
point          0          0          0
line           0          0          0
boundary       0          0          0
centroid     926          1        926
area           0          0          0
face           0          0          0
kernel         0          0          0
all          926          1        926


So I would guess that it's a bug. In the source code, when you look at the part for the 'add' option, you see that there is specific code for areas. I would guess that the same or similar needs to be added to the 'transfer' option to make sure that boundaries are also copied into the output map.

Is it not possible to work on the input map without generating a new
one, isn't it?
Perhaps we can modify the v.category module, that if output is not
set, then open the input vector map in read-write mode and update all
the categories of the input map.

I know that it can be annoying to have to create new maps, but at the same time it is a failsafe that makes sure that even if you make a mistake in the call to v.category, you still keep your original data.

I think that the overhead of a g.rename --o is a price worth paying for that security.

Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Reply via email to