v.out.ascii with sql where option exports only centroids and not areas

[marisn]

It's not possible to export areas selected by SQL WHERE clause. Example from NC data set. Let's export only lake with CAT=5109:

v.out.ascii input=lakes@PERMANENT layer=1 output=vbuffer_fail_on_area3 where=cat=5109 format=standard

Output vector part:

C  1 1
 627457.82440791 231495.92575519
 1     5109      

[mlennert]

Replying to marisn:

It's not possible to export areas selected by SQL WHERE clause. Example from NC data set. Let's export only lake with CAT=5109:

> v.out.ascii input=lakes@PERMANENT layer=1 output=vbuffer_fail_on_area3 where=cat=5109 format=standard

Output vector part:

> C  1 1
>  627457.82440791 231495.92575519
>  1     5109      

This is logicial in the sens that only the centroid has a cat=5109. No boundary has this cat. So this would mean implementing a specific algorithm to check which boundary needs to be exported together with this centroid.

As a workaround: v.extract and then v.out.ascii. Maybe this can be coded in a script ?

Moritz

[martinl]

Replying to mlennert:

Replying to marisn: This is logicial in the sens that only the centroid has a cat=5109. No boundary has this cat. So this would mean implementing a specific algorithm to check which boundary needs to be exported together with this centroid.

Basically it could be possible. Currently v.out.ascii opens vector map on level 1 (without topology). This would require level 2 (topology). I can imagine special flag which writes out also areas (boundaries and centroids), not only centroids. The problem is that boundaries of adjacent areas will printed twice. I am not sure whether it's a good idea to extend functionality of this module in this direction. Any opinion?

[mmetz]

Replying to martinl:

Replying to mlennert:

Replying to marisn: This is logicial in the sens that only the centroid has a cat=5109. No boundary has this cat. So this would mean implementing a specific algorithm to check which boundary needs to be exported together with this centroid.

Basically it could be possible. Currently v.out.ascii opens vector map on level 1 (without topology). This would require level 2 (topology). I can imagine special flag which writes out also areas (boundaries and centroids), not only centroids. The problem is that boundaries of adjacent areas will printed twice. I am not sure whether it's a good idea to extend functionality of this module in this direction. Any opinion?

There is enough code in GRASS (other modules, libs) that takes care of such cases, boundaries would not be written twice. Basically a boundary would be written out if the centroid of any of its two areas has a cat value which is in the list. I would like to see that option/functionality in v.out.ascii because most of the time the vector objects a user works with are points, lines, areas. Modules/libs then take care of appropriate handling of boundaries and centroids.

my2c

Markus M

[martinl]

Replying to mmetz:

There is enough code in GRASS (other modules, libs) that takes care of such cases, boundaries would not be written twice. Basically a boundary would be written out if the centroid of any of its two areas has a cat value which is in the list. I would like to see that option/functionality in v.out.ascii because most of the time the vector objects a user works with are points, lines, areas. Modules/libs then take care of appropriate handling of boundaries and centroids.

right, please try out r48886 and r48887 (trunk).

[mmetz]

Replying to martinl:

Replying to mmetz:

There is enough code in GRASS (other modules, libs) that takes care of such cases, boundaries would not be written twice. Basically a boundary would be written out if the centroid of any of its two areas has a cat value which is in the list. I would like to see that option/functionality in v.out.ascii because most of the time the vector objects a user works with are points, lines, areas. Modules/libs then take care of appropriate handling of boundaries and centroids.

right, please try out r48886 and r48887 (trunk).

I have modified r48886 to avoid segfaults and r48887 to open vectors with topology only when needed (partially restoring original behaviour to support fast export of massive point vectors).

Markus M

[martinl]

Replying to mmetz:

I have modified r48886 to avoid segfaults and r48887 to open vectors with topology only when

ops, thanks. Martin

[martinl]

Replying to martinl:

Replying to mmetz:

I have modified r48886 to avoid segfaults and r48887 to open vectors with topology only when

small fix in r48894

[mmetz]

Replying to martinl:

Replying to martinl:

Replying to mmetz:

I have modified r48886 to avoid segfaults and r48887 to open vectors with topology only when

small fix in r48894

ops, thanks;) Markus M

[martinl]

Backported to devbr6 for testing (r48914)

[martinl]

backported also to relbr64 (-> GRASS 6.4.3), testing welcomed (r50981)

[neteler]

The export is now:

v.out.ascii input=lakes output=vbuffer_area where=cat=5109 format=standard
grep 'B  \|C  ' vbuffer_area
B  93
B  152
B  162
B  3
B  3
C  1 1

Reimport:

v.in.ascii vbuffer_area out=myarea format=standard
Building topology for vector map <myarea>...
Registering primitives...
6 primitives registered
414 vertices registered
Building areas...
 100%
1 areas built
1 isles built
Attaching islands...
 100%
Attaching centroids...
 100%
Number of nodes: 6
Number of primitives: 6
Number of points: 0
Number of lines: 0
Number of boundaries: 5
Number of centroids: 1
Number of areas: 1
Number of isles: 1
v.in.ascii complete.

Looks correct. Closing since it appears to be fixed. Reopen if needed.