Opened 12 years ago

Closed 12 years ago

#1744 closed enhancement (fixed)

v.out.ascii: export all columns

Reported by: lucadelu Owned by: martinl
Priority: normal Milestone: 7.0.0
Component: Vector Version: svn-trunk
Keywords: v.out.ascii, columns Cc: grass-dev@…
CPU: Unspecified Platform: All

Description

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

Change History (13)

comment:1 by martinl, 12 years ago

v.out.ascii columns=*

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

comment:2 by martinl, 12 years ago

Cc: grass-dev@… added
Owner: changed from grass-dev@… to martinl
Status: newassigned

comment:3 by martinl, 12 years ago

Please try out r53279. Martin

in reply to:  3 ; comment:4 by martinl, 12 years ago

Replying to martinl:

Please try out r53279. Martin

See also r53278 for implementation issues.

comment:5 by hamish, 12 years ago

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

in reply to:  4 comment:6 by lucadelu, 12 years ago

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

in reply to:  5 ; comment:7 by martinl, 12 years ago

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

in reply to:  7 ; comment:8 by mmetz, 12 years ago

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

in reply to:  8 ; comment:9 by martinl, 12 years ago

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.

in reply to:  9 ; comment:10 by mmetz, 12 years ago

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

in reply to:  10 comment:11 by martinl, 12 years ago

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...

comment:12 by martinl, 12 years ago

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

comment:13 by martinl, 12 years ago

Resolution: fixed
Status: assignedclosed

Closing, please re-open if needed.

Note: See TracTickets for help on using tickets.