TODO: move high priority incubated modules into main

[hamish]

Hi,

before 6.4.0 we should move high priority incubated modules into main. For replacements, if the svn-addons still has issues which makes it poorer than the old version, we can call it "g.module2", otherwise we replace. If still known to be beta-ware but still functional we can add a G_warning() to the beginning of the module as an absolution.

Just having a quick look through

 https://trac.osgeo.org/grass/browser/grass-addons

Modules to consider: d.frame.split? r.colors.stddev? r.viewshed r.sun2+horizon r.watershed2 v.buffer2 v.colors? v.delaunay2 v.parallel2?

v.out.ascii.db -> v.out.ascii C code !! r.pack rewrite using method similar to r.convert (#84) + tar.gzip? put together a quick v.to.3d wrapper script?

others?/add?/remove?/replacement or "g.module2"?

Hamish

[hamish]

Also, it may be useful to categorize "must-do"s as blocker bugs, or as tasks:

Tasks TODO for 6.4.0:  https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=6.4.0&type=task&order=priority

realizing that pet-wishes and bugs require an interested & active developer to remain high-priority. (note to self)

Hamish

[wolf]

Replying to hamish:

Modules to consider:

v.buffer2 v.parallel2?

Definitely! SoC 2008 project that is ready. Maybe some more testing is needed. It works better than v.buffer (it actually works ;)) It contains some fixes that we should consider putting into Vlib in develbranch_6.

v.delaunay2

Another SoC 2008 project that is ready. Paul is the code production-quality?

--Wolf

[pkelly]

Replying to wolf:

v.delaunay2

Another SoC 2008 project that is ready. Paul is the code production-quality?

Well I haven't *thoroughly* tested it, but Martin (the author) has, and anyway I'm very confident about the quality of it. It is all in GRASS style already and has even been indent'ed correctly. It needs some copyright statements put into the source code though.

[neteler]

Given the feedback here, I suggest to actually replace v.buffer, v.parallel and v.delaunay with v.buffer2, v.parallel2, v.delaunay2 from Addons using the former names.

Since all of the original modules are broken for larger maps, there is little to lose.

Markus

[msieczka]

Replying to neteler:

Given the feedback here, I suggest to actually replace v.buffer, v.parallel and v.delaunay with v.buffer2, v.parallel2, v.delaunay2 from Addons using the former names.

+1. Working v.buffer is a must have.

[hamish]

Given the feedback here, it appears that r.viewshed is not yet ready for release.

v.out.gps[babel] is pretty much ready to be activated, it just waits on the v.out.ogr bugfix (#354). It does something necessary that gpsbabel and the QGIS GPS plugin do not: automatically reproject to WGS84 LL.

Markus, thoughts about r.sun2 + r.horizon?

r.watershed.fast2 is still high on my list for testing+inclusion, but as always deadlines distract...

Hamish

[neteler]

r.sun2 + r.horizon are ready in my opiniom, I have made tests even with a 450Mpixels DEM and we fixed some memory issues for those large maps. I'll take care of that.

Markus

[neteler]

Replying to neteler:

Given the feedback here, I suggest to actually replace v.buffer, v.parallel and v.delaunay with v.buffer2, v.parallel2, v.delaunay2 from Addons using the former names.

Done in 6.4.svn and 7. The old modules have been disactivated. Please check and fix if necessary.

Markus

[neteler]

For easier maintenance, I have created: http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan

Markus

[hamish]

cleaned-up diff of r.watershed2 and 1 in today's devbr6 SVN

[hamish]

update:

r.sun2, r.horizon added.
v.buffer2, v.parallel2, v.delaunay2 added.
r.watershed.fast merged.
d.frame.split, r.colors.stddev, v.colors added.
v.out.gpsbabel added.

r.viewshed: code not ready yet?

TODO high priority:

• v.out.ascii.db -> v.out.ascii C code

TODO lower priority:

• r.pack rewrite using method similar to r.convert (#84) + tar.gzip
• put together a quick v.to.3d wrapper script

[neteler]

Replying to hamish:

update: r.viewshed: code not ready yet?

No, see trac bug #390

Markus

[hamish]

• r.pack: not for inclusion in GRASS 6.4. to prevent future confusion the saved file format will not be formalized until the grass7 file format has been. prototype script available in svn addons as r.pack2.

Hamish

[hamish]

done (for the purposes of reserving the namespace, enhancements may come later):

• v.to.3d prototype written by Martin

remaining TODO for this ticket:

• v.out.ascii.db -> v.out.ascii C code

Hamish

[martinl]

Replying to hamish:

remaining TODO for this ticket: - v.out.ascii.db -> v.out.ascii C code

done in r34917. Please test it out...

Martin

[mlennert]

Replying to martinl:

Replying to hamish:

remaining TODO for this ticket: - v.out.ascii.db -> v.out.ascii C code

done in r34917. Please test it out...

In trunk, I get the following error during compile:

VERSION_NUMBER=7.0.svn /home/mlennert/SRC/GRASS/grass_trunk/tools/g.html2man/g.html2man.py /home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-gnu/docs/html/v.out.ascii.html /home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-gnu/man/man1/v.out.ascii.1
/home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-gnu/docs/html/v.out.ascii.html:90:0: Error ({'args': ()}): <o>

make: *** [/home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-gnu/man/man1/v.out.ascii.1] Erreur 1
rm v.out.ascii.tmp.html

In devel6, I can compile, but I get a segmentation fault using NC demo data and running:

v.out.ascii in=hospitals out=hospitals.ascii colu=NAME

but not with

v.out.ascii in=hospitals out=hospitals.ascii colu=PHONE

GRASS 6.4.svn (nc_spm_06):~ > v.info -c hospitals
Displaying column types/names for database connection of layer 1:
INTEGER|cat
INTEGER|OBJECTID
DOUBLE PRECISION|AREA
DOUBLE PRECISION|PERIMETER
INTEGER|HLS_
INTEGER|HLS_ID
CHARACTER|NAME
CHARACTER|ADDRESS
CHARACTER|CITY
CHARACTER|ZIP
CHARACTER|COUNTY
CHARACTER|PHONE
CHARACTER|CANCER
INTEGER|POLYGONID
DOUBLE PRECISION|SCALE
DOUBLE PRECISION|ANGLE


GRASS 6.4.svn (nc_spm_06):~ > v.db.connect -p hospitals
Vector map <hospitals@PERMANENT> is connected by:
layer <1> table <hospitals> in database </home/mlennert/GRASS/DATA/nc_spm_06/PERMANENT/dbf/> through driver <dbf> with key <cat>

Running

for col in `v.info -c hospitals | awk -F"|" '{print $2}'`; do echo $col; v.out.ascii in=hospitals out=hospitals_$col colu=$col; done

gives segfaults with NAME and ADDRESS and "Illegal instruction" with CITY. The same script on comm_colleges causes seg faults for the columns ADDRESS1 and "Illegal instruction" on CC_NAME and ADDRESS2.

Moritz

[martinl]

In trunk, I get the following error during compile: {{{ VERSION_NUMBER=7.0.svn /home/mlennert/SRC/GRASS/grass_trunk/tools/g.html2man/g.html2man.py /home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-gnu/docs/html/v.out.ascii.html /home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-gnu/man/man1/v.out.ascii.1 /home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-gnu/docs/html/v.out.ascii.html:90:0: Error ({'args': ()}): <o>

Fixed in r34924.

In devel6, I can compile, but I get a segmentation fault using NC demo data and running:

v.out.ascii in=hospitals out=hospitals.ascii colu=NAME

strange no segfault here...

but not with

v.out.ascii in=hospitals out=hospitals.ascii colu=PHONE

also OK

> GRASS 6.4.svn (nc_spm_06):~ > v.db.connect -p hospitals
> Vector map <hospitals@PERMANENT> is connected by:
> layer <1> table <hospitals> in database </home/mlennert/GRASS/DATA/nc_spm_06/PERMANENT/dbf/> through driver <dbf> with key <cat>

same...

for col in `v.info -c hospitals | awk -F"|" '{print $2}'`; do echo $col; v.out.ascii in=hospitals out=hospitals_$col colu=$col; done

everything OK

gives segfaults with NAME and ADDRESS and "Illegal instruction" with CITY. The same script on comm_colleges causes seg faults for the columns ADDRESS1 and "Illegal instruction" on CC_NAME and ADDRESS2.

??

Martin

[hamish]

Martin:

done in r34917. Please test it out...

great!

It works for me; I don't get any segfaults.

I notice that the column names are case sensitive; and could the column check be moved before any output? and the error message should be like "column <%s> not found" ?

GRASS64> v.out.ascii in=hospitals col=name,phone
ERROR: Column <name>: unsupported data type
697237.5638615|182012.65540056|1GRASS64> 

cheers, Hamish

[hamish]

Moritz: any chance to give a gdb backtrace? http://grass.osgeo.org/wiki/GRASS_Debugging#Using_GDB

Hamish

[martinl]

Replying to hamish:

I notice that the column names are case sensitive; and could the column check be moved before any output? and the error message should be like "column <%s> not found" ? {{{ GRASS64> v.out.ascii in=hospitals col=name,phone ERROR: Column <name>: unsupported data type 697237.5638615|182012.65540056|1GRASS64> }}}

fixed in r34926 (6.4) r34927 (7.0).

[martinl]

Closing this tickets. Create separate ticket for v.out.ascii if needed.