v.out.ascii: export all columns

[lucadelu]

Hi,

I'd like that v.out.ascii export all columns in a simple way. This could be fixed using * in columns option or adding a flag to export all columns.

Thanks

[martinl]

v.out.ascii columns=*

make sense to me. Of course documented in the manual and probably also noted as in description.

[martinl]

Please try out r53279. Martin

[martinl]

Replying to martinl:

Please try out r53279. Martin

See also r53278 for implementation issues.

[hamish]

This is very useful, thank you both for the suggestion and the patch.

did v.out.ascii columns= ever get fast? It used to be unusably slow when there was > ~10000 db rows since it was opening and closing the db for every entry. I have a vague recollection that MarkusM commented at some point that this was needed to ensure data integrity? (I may be confusing that with a similar situation elsewhere in the db code)

Hamish

[lucadelu]

Replying to martinl:

Replying to martinl:

Please try out r53279. Martin

See also r53278 for implementation issues.

It works for me, thanks. The ticket could be close and mark as fixed after answering to Hamish questions

Luca

[martinl]

Replying to hamish:

did v.out.ascii columns= ever get fast?

v.info n1 -t
points=100000

v.db.connect n1 -g
1/n1|n1|cat|/home/martin/grassdata/nc_spm_08/user1/sqlite/sqlite.db|sqlite

time v.out.ascii n1 out=n1-nocols --o

real    0m0.305s
user    0m0.288s
sys     0m0.012s

time v.out.ascii n1 out=n1-cols columns=* --o
real    0m56.643s
user    0m32.658s
sys     0m28.166s

Could be probably optimized.

It used to be unusably slow when there was > ~10000 db rows since it was opening and closing the db for every entry. I have a vague recollection that MarkusM commented at some point that

DB is open once grass/trunk/lib/vector/Vlib/ascii.c#L378​. For every feature is open select cursor grass/trunk/lib/vector/Vlib/ascii.c#L639​.

Martin

[mmetz]

Replying to martinl:

Replying to hamish:

did v.out.ascii columns= ever get fast?

Testing welcome;) At least it got faster, question is if this is fast enough:

In nc_spm_08, using sqlite mapset:

g.copy vect=geonames_NC,my_geonames_N

# GRASS 7
time v.out.ascii input=my_geonames_NC layer=1 output=geonames_NC_7.ascii format=point columns=cat,GEONAMEID,NAME,ASCIINAME,ALTERNATEN,FEATURECLA,FEATURECOD,COUNTRYCOD,CC2,ADMIN1,POPULATION,ELEVATION,GTOPO30,TIMEZONE,MODIFICATI,PPLKEY,SRC_ID,MAINT_ID
Fetching data...

real	0m18.990s
user	0m7.942s
sys	0m21.478s

# GRASS 6.4.svn
time v.out.ascii input=my_geonames_NC layer=1 output=geonames_NC_64.ascii format=point columns=cat,GEONAMEID,NAME,ASCIINAME,ALTERNATEN,FEATURECLA,FEATURECOD,COUNTRYCOD,CC2,ADMIN1,POPULATION,ELEVATION,GTOPO30,TIMEZONE,MODIFICATI,PPLKEY,SRC_ID,MAINT_ID

real	5m24.340s
user	2m9.232s
sys	6m8.719s

@Martin, r53278 and r53315: I know you don't want to test your own changes, but you could at least fix obvious compile warnings introduced by changes to be submitted...

Markus M

[martinl]

Replying to mmetz:

@Martin, r53278 and r53315: I know you don't want to test your own changes, but you could at least fix obvious compile warnings introduced by changes to be submitted...

sorry, I just overlooked this issue. Nobody is perfect ;-) But it doesn't mean that I don't *want* to test my own changes...

Thanks for fixing it.

[mmetz]

Replying to martinl:

Replying to mmetz:

@Martin, r53278 and r53315: I know you don't want to test your own changes, but you could at least fix obvious compile warnings introduced by changes to be submitted...

sorry, I just overlooked this issue. Nobody is perfect ;-)

Sure. But you changed the this particular line of the old code for no reason, thus introducing a bug, that change caused the only compiler warning in lib/vector/Vlib/ascii.c which was after quick inspection justified, and testing that existing functionality is not broken took me seconds.

But it doesn't mean that I don't *want* to test my own changes...

But you nearly never do...

Trying to convince you that investing a couple of seconds for testing is not that bad an idea ;-)

Markus M

[martinl]

Replying to mmetz:

@Martin, r53278 and r53315: I know you don't want to test your own changes, but you could at least fix obvious compile warnings introduced by changes to be submitted...

sorry, I just overlooked this issue. Nobody is perfect ;-)

Sure. But you changed the this particular line of the old code for no reason, thus introducing a bug, that change caused the only compiler warning in lib/vector/Vlib/ascii.c which was after quick inspection justified, and testing that existing functionality is not broken took me seconds.

well, sometimes everyone can do the mistake...

But it doesn't mean that I don't *want* to test my own changes...

But you nearly never do...

huh ;-) I can hardly comment it...

[martinl]

Back to the original topic, can we close this ticket?

[martinl]

Closing, please re-open if needed.