Opened 16 years ago

Closed 16 years ago

#344 closed task (fixed)

TODO: move high priority incubated modules into main

Reported by: hamish Owned by: grass-dev@…
Priority: blocker Milestone: 6.4.0
Component: Default Version: svn-develbranch6
Keywords: Cc: mpavlovsky@…
CPU: All Platform: All

Description

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

Attachments (1)

r.w2.diff (31.7 KB ) - added by hamish 16 years ago.
cleaned-up diff of r.watershed2 and 1 in today's devbr6 SVN

Download all attachments as: .zip

Change History (21)

comment:1 by hamish, 16 years ago

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

in reply to:  description ; comment:2 by wolf, 16 years ago

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

in reply to:  2 comment:3 by pkelly, 16 years ago

Cc: mpavlovsky@… added

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.

in reply to:  2 ; comment:4 by neteler, 16 years ago

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

in reply to:  4 comment:5 by msieczka, 16 years ago

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.

in reply to:  4 comment:6 by hamish, 16 years ago

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

comment:7 by neteler, 16 years ago

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

in reply to:  4 comment:8 by neteler, 16 years ago

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

comment:9 by neteler, 16 years ago

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

Markus

by hamish, 16 years ago

Attachment: r.w2.diff added

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

comment:10 by hamish, 16 years ago

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

in reply to:  10 comment:11 by neteler, 16 years ago

Replying to hamish:

update:

r.viewshed: code not ready yet?

No, see trac bug #390

Markus

comment:12 by hamish, 16 years ago

Priority: majorblocker
  • 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

comment:13 by hamish, 16 years ago

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

in reply to:  13 ; comment:14 by martinl, 16 years ago

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

in reply to:  14 ; comment:15 by mlennert, 16 years ago

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

in reply to:  15 comment:16 by martinl, 16 years ago

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

comment:17 by hamish, 16 years ago

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

comment:18 by hamish, 16 years ago

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

Hamish

in reply to:  17 comment:19 by martinl, 16 years ago

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

comment:20 by martinl, 16 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.