Re: [GRASS-dev] [GRASS GIS] #2019: v.voronoi Segmentation fault
#2019: v.voronoi Segmentation fault ---+ Reporter: DmitryKolesov | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.3 Component: Vector | Version: Keywords: v.voronoi |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by DmitryKolesov): Replying to [comment:1 hamish]: is it trying to make a triangle (with area==0) from two points? or were those two points extracted from a larger map having the problem? Yes, I tryed to create Voronoi diagram from 2 points. But I think (probably wrong): 1) Voronoi diagram of 2 points is possible (the line splits the plain in two half-planes) 2) In any case the module should print a message (the module crashes now). -- Ticket URL: https://trac.osgeo.org/grass/ticket/2019#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2022: wxGUI: r.in.wms wrapper tool not parsing section titles correctly
#2022: wxGUI: r.in.wms wrapper tool not parsing section titles correctly
---+
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: wxGUI | Version: svn-develbranch6
Keywords: r.in.wms, ogc_services.py |Platform: All
Cpu: All|
---+
Hi,
6.4.3svn wxGUI File-Import raster- r.in.wms -
url = http://neowms.sci.gsfc.nasa.gov/wms/wms?
{{{
r.in.wms -l maps=http://neowms.sci.gsfc.nasa.gov/wms/wms?; \
out=dummy neowms.nasa.wms.txt
}}}
in devbr6 and relbr64 (but not trunk) gui/wxpython/modules/ogc_services.py
was not parsing the section titles correctly, it thought they were layer
titles. If the section Title came before the first layer you got an error,
and if between layers they overwrote the previous layer's description.
hopefully fixed in devbr6 with r56965, please test so we can backport it
for 6.4.3.
Hamish
ps- this server might make a nice example for the r.in.wms help page,
since `OnEarth` is now tiled-only and the osgeo/flightgear one has limited
performance.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2022
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.segment error: Ri is 0
On 01/07/13 21:04, Markus Metz wrote: On Mon, Jul 1, 2013 at 3:56 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: Hi Eric and Markus, Trying to use i.segment in grass7 checked out and compiled a few days ago (rev 56918), I came upon the following error and the resulting segments file was not created. I can file this as a bug report, but wanted your feedback first to see if I'm misusing i.segment somehow. I haven't been able to find the error in the source code. command line: time i.segment group=xs out=seg_xs minsize=2 memory=3072 threshold=0.2 --o error: Segmentation converged after 16 iterations. Merging segments smaller than 2 cells ERREUR :Ri is 0 This should not happen. The ID of a segment is always positive or negative or NULL (Rast_is_c_null_value()) This is on a mosaic of Worldview 2 images with region specs as follows: g.region -p projection: 1 (UTM) zone: 33 datum: wgs84 ellipsoid: wgs84 north: 4876400 south: 4849792 west: 610056 east: 634648 nsres: 2 ewres: 2 rows: 13304 cols: 12296 cells: 163585984 The mosaic is only a narrow band within that region, so that actually there are only 34,755,878 non-null cells. Any hints ? Not really. I created a sample dataset with a MASK leaving only a narrow diagonal strip and everything went fine. I did not use a mask, the non-relevant cells were just nulls. Would it be better to create a mask ? Did you get any other warnings while running i.segment? No. I assume you are using 64 bit Linux $ uname -srvm Linux 3.2.0-4.drm-amd64 #1 SMP Debian 3.2.35-3~jcristau.1 x86_64 (Intel i3) with more than 3072 GB RAM Yes. I have 8GB. There were two segmentation processes running at the same time, both with memory=3072. The other process ran without error (but on a smaller region and image). and lots of free disk space on the partition with your GRASS data. 61G on the data partition. Can you provide data to replicate or commands using one of the sample datasets to replicate this error? I'll run the segmentation again without having something else running. If I can reproduce the error, I'll make the data available to you so you can test. Thanks ! Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.segment error: Ri is 0
On Tue, Jul 2, 2013 at 9:58 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 01/07/13 21:04, Markus Metz wrote: On Mon, Jul 1, 2013 at 3:56 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: Hi Eric and Markus, Trying to use i.segment in grass7 checked out and compiled a few days ago (rev 56918), I came upon the following error and the resulting segments file was not created. I can file this as a bug report, but wanted your feedback first to see if I'm misusing i.segment somehow. I haven't been able to find the error in the source code. command line: time i.segment group=xs out=seg_xs minsize=2 memory=3072 threshold=0.2 --o error: Segmentation converged after 16 iterations. Merging segments smaller than 2 cells ERREUR :Ri is 0 This should not happen. The ID of a segment is always positive or negative or NULL (Rast_is_c_null_value()) This is on a mosaic of Worldview 2 images with region specs as follows: g.region -p projection: 1 (UTM) zone: 33 datum: wgs84 ellipsoid: wgs84 north: 4876400 south: 4849792 west: 610056 east: 634648 nsres: 2 ewres: 2 rows: 13304 cols: 12296 cells: 163585984 The mosaic is only a narrow band within that region, so that actually there are only 34,755,878 non-null cells. Any hints ? Not really. I created a sample dataset with a MASK leaving only a narrow diagonal strip and everything went fine. I did not use a mask, the non-relevant cells were just nulls. Would it be better to create a mask ? No, i.segment tests with Rast_is_d_null_value() which is true for both NULL cells and MASK'ed cells. Can you provide data to replicate or commands using one of the sample datasets to replicate this error? I'll run the segmentation again without having something else running. If I can reproduce the error, I'll make the data available to you so you can test. Other processes should not be able to interfere, as long as enough system resources are available which seems to be the case. I suspect a problem with nodata handling, but the code looks ok to me. If need be, you can send me (a link to) the test data off-list. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Make grass 7 installable with brew on Mac?
Hi I just recently migrated to a Mac with OS X, and one think I am really missing is the package management. Therefore, I am now using homebrew [1] which works nicely - only that the recipe for installing grass from head does not work [2]. I would think that homebrew would be a nice addition to the ways of installing on OS X and it would make using GRASS much easied (all dependencies have a installation recipe, R has one as well, installation of rgdal is painless (from source)). According to adamv [3] the problem is the following: , | Looking at the source to the new version, it still tries to install | files into /Library, but it now does it in a separate OS X specific | Makefile. ` Is there any chance that somebody with a mac at hand and interest could take a look at this? It sounds like an easy to solve problem (the homebrew recipes are ruby), but I don't know anything about ruby. Thanks a lot, Rainer Footnotes: [1] http://mxcl.github.io/homebrew/ [2] error: , | patching file Makefile | Hunk #1 FAILED at 304. | 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej | Error: Failure while executing: /usr/bin/patch -f -p1 -i 000-homebrew.diff ` [3] https://github.com/mxcl/homebrew/issues/20665#issuecomment-19846487 -- Rainer M. Krug email: RMKrugatgmaildotcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Status of r.cva?
Dear Benjamin, a friend needs to use r.cva [0,1] (and r.viewshed [2]). What is the status of this add-on? Does it also work in G7? Only in G64 and previous releases? Thank you, Nikos --- [0] Link https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.cva/ does not exist anymore! [1] only here: http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html ? [2] Module/manual exists only for G7 http://grass.osgeo.org/grass70/manuals/r.viewshed.html, not for G64! ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1428: WinGRASS + how to deliver Microsoft Visual C++ Redistributable Package (vcredist)?
#1428: WinGRASS + how to deliver Microsoft Visual C++ Redistributable Package (vcredist)? --+- Reporter: dhastings | Owner: grass-dev@… Type: defect| Status: new Priority: major | Milestone: 6.4.3 Component: Installation | Version: 6.4.3 RCs Keywords: wingrass |Platform: MSWindows 7 Cpu: x86-64| --+- Comment(by hellik): Replying to [comment:70 hamish]: Hi, I heard back from Jürgen who made the change: Installation of the vc2005 runtime wasn't working with 2-byte characters in the username. See http://hub.qgis.org/issues/8197 hellik wrote: should we also update the winGRASS-installer-script? yes, I think so. done with r56979, r56980, r56981 -- Ticket URL: https://trac.osgeo.org/grass/ticket/1428#comment:71 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Make grass 7 installable with brew on Mac?
There are easy to install OS X installer packages for everything you need for GRASS, and other GIS software. I wouldn't call package managers easier and painless on OS X, just another way to do things. The /Library problems is the linking of the help files to the system help. For the help to be available to all users, it must be /Library. I've been thinking about it off and on and have a couple ideas, I just haven't had time to work on it. I don't do homebrew or any other package manager, and I don't do ruby, so I can't help you with that error, you should ask the homebrew folks. On Jul 2, 2013, at 4:27 AM, Rainer M Krug wrote: Hi I just recently migrated to a Mac with OS X, and one think I am really missing is the package management. Therefore, I am now using homebrew [1] which works nicely - only that the recipe for installing grass from head does not work [2]. I would think that homebrew would be a nice addition to the ways of installing on OS X and it would make using GRASS much easied (all dependencies have a installation recipe, R has one as well, installation of rgdal is painless (from source)). According to adamv [3] the problem is the following: , | Looking at the source to the new version, it still tries to install | files into /Library, but it now does it in a separate OS X specific | Makefile. ` Is there any chance that somebody with a mac at hand and interest could take a look at this? It sounds like an easy to solve problem (the homebrew recipes are ruby), but I don't know anything about ruby. Thanks a lot, Rainer Footnotes: [1] http://mxcl.github.io/homebrew/ [2] error: , | patching file Makefile | Hunk #1 FAILED at 304. | 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej | Error: Failure while executing: /usr/bin/patch -f -p1 -i 000-homebrew.diff ` [3] https://github.com/mxcl/homebrew/issues/20665#issuecomment-19846487 -- Rainer M. Krug email: RMKrugatgmaildotcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Status of r.cva?
On Tue, Jul 2, 2013 at 1:15 PM, Nikos Alexandris n...@nikosalexandris.net wrote: a friend needs to use r.cva [0,1] (and r.viewshed [2]). [2] Module/manual exists only for G7 http://grass.osgeo.org/grass70/manuals/r.viewshed.html, not for G64! r.viewshed is available as add-on for G6: http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.viewshed Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2020: r.volume gives wrong results on G7
#2020: r.volume gives wrong results on G7 --+- Reporter: madi | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Raster| Version: svn-trunk Keywords: r.volume |Platform: Linux Cpu: x86-64| --+- Comment(by mmetz): Replying to [comment:3 hamish]: The problem is with the handling NULL cells in the input map, or rather not handling them. It's this line in main.c: `sum[i] += data_buf[col];` Every now and then the value which is added is -2147483648 instead of in the range of ~ 0-36. That happens when the clump map exists but the input map does not. So for your test data the slope map is 1 cell smaller than the basins map around the edges of the area, and those cells which are non-NULL in the basins map but NULL in the slope map return corrupted values. fwiw between devbr6 and trunk there don't seem to be any module changes beyond the conversion of G_() to Rast_() in the function names. I notice even in grass7 it's still trying to make an old grass5 sites_list points map, and also that the input map is always opened and read as a CELL map, even when it is floating point, so the results will be.. less correct than they might otherwise be due to rounding/quantization errors. For 0.0-1.0 normalized data that might be fatal. (conversion of the input to int(map*1000) with r.mapcalc gives the same error for NULLs in 'sum' though) NULL handling fixed and fp support added to r.volume in trunk r56984. Markus M -- Ticket URL: http://trac.osgeo.org/grass/ticket/2020#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2020: r.volume gives wrong results on G7
#2020: r.volume gives wrong results on G7
--+-
Reporter: madi | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone: 7.0.0
Component: Raster| Version: svn-trunk
Keywords: r.volume |Platform: Linux
Cpu: x86-64|
--+-
Comment(by madi):
Hello Markus,
Thank you for that! Actually I still find that the results produced by G7
are different from the ones produced by G6. For the dataset attached,
(setting the region to match slope), i get:
From G7:
{{{
Volume report on data from slope using clumps on basin map
CatAverage Data # CellsCentroid Total
Number in clump Total in clump Easting Northing Volume
1 3.41268000 78593 635195.00 220715.00 26799969.96
Total Volume =26799969.96
}}}
and G6
{{{
Volume report on data from slope using clumps on basin map
CatAverage Data # CellsCentroid Total
Number in clump Total in clump Easting Northing Volume
1 3.43 298548715 635175.00 220725.00 26868600.00
Total Volume =26868600.00
}}}
Thanks, madi
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2020#comment:5
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2020: r.volume gives wrong results on G7
#2020: r.volume gives wrong results on G7 --+- Reporter: madi | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Raster| Version: svn-trunk Keywords: r.volume |Platform: Linux Cpu: x86-64| --+- Comment(by mmetz): Replying to [comment:5 madi]: Hello Markus, Thank you for that! Actually I still find that the results produced by G7 are different from the ones produced by G6. This is because r.volume in G7 has now floating point support and the slope map in your sample data is single precision floating point, thus correctly read only in G7. You can now file a bug for r.volume in G6. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2020#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1719: GRASS 7 Monitor command line support
#1719: GRASS 7 Monitor command line support --+- Reporter: annalisapg | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: |Keywords: d.mon Platform: Unspecified | Cpu: Unspecified --+- Comment(by wenzeslaus): Replying to [comment:23 hamish]: Also, with 'd.mon wx0' running I notice the process count in gkrellm is fluctuating rather loudly. ? C module `d.mon` calls Python script `gui/wxpython/mapdisp/main.py` which calls `d.vect`, `d.rast` and others to do the actual rendering. This, as well as other things, is a consequence of design choices which were made in GRASS rendering, i.e. rendering functionality distributed over modules and not a part of the library, so it is hard to use this functionality in GUI application such as monitor. Since this is complicated topic, I don't see a reason for mixing this topic with the hiding/showing toolbar/statusbar in the monitor or synchronizing of computational and display region. All these things needs discussion and we should not mix them. Different situation would be if we have subtickets but we don't (Trac version is too low). However, we can create tickets and note them here. That is IMO the way how to deal with wide tickets. If you want to collect ideas, you can create a Trac wiki page, e.g. wiki:wxGUIDevelopment/Monitors. To conclude, suggested enhancements (synchronization of regions, customizable GUI) are doable for any wxGUI developer, only problem is their time, I guess. However, we've discussed the rendering several times and we still don't have any idea what is the ideal solution (note for example, that the approach `wximgview` is using has some limitations, e.g. when you want to use opacity). Please see the Trac wiki page for all collected ideas: wiki:wxGUIDevelopment/MapRendering. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1719#comment:25 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
Hi, On Fri, Jun 28, 2013 at 2:29 AM, Helena Mitasova hmit...@ncsu.edu wrote: regarding the r.mapcalc issue in command console on wingrass - (sorry I did not make it clear it was for wingrass - it always worked well on Mac and linux) It is not critical, windows users can still use the mapcalculator GUI where it runs OK, but the r.mapcalc in the command console still does not seem to work - tried by a student using June 26 snapshot this is what she says: Here are examples of the commands run and the errors received: r.mapcalc urban2_30m=if(landuse96_28m==1 || landuse96_28m==2,landuse96_28m,null()) syntax error, unexpected $end, expecting ')' Parse error 'landuse96_28m' is not recognized as an internal or external command, operable program or batch file. r.mapcalc MASK=if((elevation100 elevation60) (landuse96_28m==1 || landuse96_28m==2),1,null()) 1 was unexpected at this time. This is the same we were getting in GRASS6.4.3RC2 and apparently the proposed solutions did not work http://lists.osgeo.org/pipermail/grass-dev/2013-February/062047.html http://lists.osgeo.org/pipermail/grass-dev/2013-March/062607.html I had the opportunity to test Glynn's patch (the second link above) on Windows and it seems to solve the problems. From the discussion I can see that Markus already tested it but he was not successful, so I applied the patch to 6.5 first. All the commands causing problems are now working with both (, ') quotes and without, only the command with || requires quotes. Anna if I get this confirmed I will file a bug report (I thought I already did, but it is not there). If it is not fixable it should be at least mentioned on the known issues web page http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Raster_modules Helena Helena: I am also wondering whether the r.mapcalc expressions with || (or) now run from the wxGUI command console. I just tried on linux 6.4.3svn wxGUI command console: r.mapcalc either = 0 || 1 and it worked. In general I wouldn't be surprised if full command line quoting took years and huge amounts of effort to (re)perfect. And even then, does it try to follow Bash conventions, or python, or DOS, or some mix of all those? How much do we try to (re)teach about command line techniques in our own docs? Will unquoted input=C:\Users\files\data.txt always be parsed to input=C:Usersfilesdata.txt (literal \U, \f, \d) in the command console in that case? best, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] --with-opencl without a GPU
W dniu 26.06.2013 18:08, Maciej Sieczka pisze: Thanks for sharing this. Unless anyone has more input I'll try to put this information together on the GRASS WiKi in the coming days. I hope I got it right: http://grasswiki.osgeo.org/grass-wiki/index.php?title=GPUaction=historysubmitdiff=19076oldid=18745. Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Status of r.cva?
Nikos Alexandris: ...(and r.viewshed [2]). [2] Module/manual exists only for G7 http://grass.osgeo.org/grass70/manuals/r.viewshed.html, not for G64! Markus Metz wrote: r.viewshed is available as add-on for G6: http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.viewshed Compiles and works :-) Thnx, N ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2020: r.volume gives wrong results on G7
#2020: r.volume gives wrong results on G7 --+- Reporter: madi | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Raster| Version: svn-trunk Keywords: r.volume |Platform: Linux Cpu: x86-64| --+- Comment(by hamish): You can now file a bug for r.volume in G6. we may as well continue with this ticket since it isn't too complicated. Is it ok to open a CELL map as DCELL in grass6, or do we need a switch statement to use the correct read/isnull commands? if skipping adding to sum because of a null, don't we need to 'count--' too? or else for the average sum/n has too big an n. ? thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2020#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2010: r.in.wms2 fails to install on 6.x
#2010: r.in.wms2 fails to install on 6.x
---+
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.4
Component: Addons | Version: svn-releasebranch64
Keywords: r.in.wms2 |Platform: Linux
Cpu: All|
---+
Comment(by hamish):
Hi,
I've now done a bit more on this in grass6 addons svn. It now installs
with 'make make MODULE_TOPDIR=$GISBASE' or similar from the source dir; I
haven't tried either of the g.extensions yet though.
Also I did a bit more on the port to G6, the module runs now using the
default settings, but I didn't test it heavily, just Richard's neowms
example using the default download method
{{{
r.in.wms2.py url=http://neowms.sci.gsfc.nasa.gov/wms/wms?; \
out=solar.8day layer=CERES_INSOL_E format=png
}}}
Probably a number of fixes there should be considered for porting back to
trunk.
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2010#comment:2
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2020: r.volume gives wrong results on G7
#2020: r.volume gives wrong results on G7 --+- Reporter: madi | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Raster| Version: svn-trunk Keywords: r.volume |Platform: Linux Cpu: x86-64| --+- Comment(by mmetz): Replying to [comment:7 hamish]: You can now file a bug for r.volume in G6. we may as well continue with this ticket since it isn't too complicated. Is it ok to open a CELL map as DCELL in grass6, or do we need a switch statement to use the correct read/isnull commands? I think it is ok to open CELL or FCELL maps as DCELL in grass6, IIRC various modules do so already. if skipping adding to sum because of a null, don't we need to 'count--' too? or else for the average sum/n has too big an n. ? Right, fixed in r56987. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2020#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Status of r.cva?
Nikos wrote: a friend needs to use r.cva [0,1] (and r.viewshed [2]). What is the status of this add-on? Does it also work in G7? Only in G64 and previous releases? ... [0] Link https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.cva/ does not exist anymore! [1] only here: http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html ? As I understand it, Mark's employer (university) would not let him release the work as GPL-compatible. Otherwise the module would have replaced r.los in the main GRASS source distribution years ago, and their institution would have been cited many many times from it, but oh well, he tried a number of times to convince them. Considering universities like Johns Hopkins and Columbia literally generate billions of dollars licensing IP (typically bio-med), and how underfunded most educational institutions are, you can understand a bit why the suits at other universities around the world have a hard time seeing very far past the $ signs for anything and everything. :-/ Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
