[GRASS-dev] New module r3.neighbors
Dear devs, just to inform you: there is now a neighborhood analysis module for 3D raster maps available in trunk: r3.neighbors[1]. [1] http://trac.osgeo.org/grass/changeset/56960 Best regards Soeren ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[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: |Platform: Unspecified
Cpu: Unspecified|
---+
The next lines cause crash report:
{{{
echo 7414297.17458|6180640.72109|242
7414836.48276|6179963.8034|817
| v.in.ascii in=- out=test_tmp x=1 y=2 cat=3 --o
g.region vect=test_tmp
v.voronoi -t in=test_tmp out=test_tmp_v --o
WARNING: Vector map test_tmp_v already exists and will be overwritten
Reading sites...
Voronoi triangulation...
Segmentation fault (core dumped)
}}}
The version GRASS GIS is
{{{
g.version -r
GRASS 6.4.3RC3 (2013)
Revision: 50937
Date: 2012-02-25 14:14:51 +0100 (Sat, 25 Feb 2012)
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2019
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] #2018: Provide a way to edit the PERMANENT/MYNAME file
#2018: Provide a way to edit the PERMANENT/MYNAME file ---+ Reporter: nikosa | Owner: grass-dev@… Type: enhancement| Status: new Priority: normal | Milestone: 6.4.4 Component: Default| Version: unspecified Keywords: location, description, ps.map |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by nikosa): Replying to [comment:2 hamish]: try new -n and descr= options in g.setproj with r56961 in devbr6. Works :-) Not sure about in grass7, I feel g.proj is already a bit overloaded wrt functionality, but it's not enough for its own g.support module. any ideas? The ones who know the internals very well have a better idea on that. Would it be really too much to add the description= to g.proj in G7? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2018#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] #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|
--+-
simple test with r.volume. Small testing dataset here:
http://ubuntuone.com/2Odq6BDeQDdQhIJX2D8sHn
On Grass 6.4
{{{r.volume --overwrite data=slope clump=basin centroids=centroid1
CatAverage Data # CellsCentroid Total
Number in clump Total in clump Easting Northing Volume
1 2.92229610 78593 635195.00 220715.00 22961000.00
Total Volume =
22961000.00}}}
On Grass 7.0
{{{r.volume --overwrite input=slope clump=basin centroids=centroid1
CatAverage Data # CellsCentroid Total
Number in clump Total in clump Easting Northing Volume
1-57817810.36-4544075169558 78593 635195.00 220715.00
-454407516955800.00}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2020
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 nikosa):
In grass64 I get,
{{{
CatAverage Data # CellsCentroid Total
Number in clump Total in clump Easting Northing Volume
1 3.41268147 78593 635195.00 220715.00 26814700.00
Total Volume =26814700.00
}}}
in grass70,
{{{
CatAverage Data # CellsCentroid Total
Number in clump Total in clump Easting Northing Volume
1-57817809.87-4544075131021 78593 635195.00 220715.00
-454407513102100.00
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2020#comment:1
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] i.segment error: Ri is 0
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 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 ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.statistics in G7
On Sun, Jun 30, 2013 at 3:20 AM, Hamish hamis...@yahoo.com wrote: Helmut wrote: r.statistics2 is intended to be a partial replacement for r.statistics, with support for floating-point cover maps at the expense of not support quantiles. [1] r.statistics3 is intended to be a partial replacement for r.statistics, with support for floating-point cover maps. It provides quantile calculations, which are absent from r.statistics2. [2] Glynn wrote: r.statistics2 and r.statistics3 are intended to replace r.statistics. But those two modules have almost nothing in common. r.statistics2 calculates statistics which are based upon accumulators (i.e. count, sum of x^n, sum of (x-mean)^n), while r.statistics3 calculates quantiles. If you want a work-alike replacement for r.statistics, it would be simpler to create a script which just runs r.statistics2 and/or r.statistics3 to do the work. In the event that you want both types of statistics, there could be some efficiency gains to be had by merging the two, but only at the cost of creating a module which is noticeably more complex than the sum of its parts. Madi: Thank you for the explanation! I perfectly agree that it's better to keep a couple of modules instead of a very complex one. But from the user's POV their names at the moment are not very informative. If you consider also r.stats... how could the user guess what's the purpose of them all at the first glance? Perhaps names like r.stats.*, where * is the particular function that they perform, would be a bit easier to understand (?) perhaps - r.stats.cover and r.stats.quantile? we should also add r.stats (and perhaps r.univar) into this discussion. r.stats - r.stats.summary ? +1 Thanks, madi -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2021: encoding information in locale gets lost
#2021: encoding information in locale gets lost
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Startup | Version: svn-trunk
Keywords: locale encoding |Platform: Linux
Cpu: Unspecified |
-+--
My locale settings before launching GRASS 7:
{{{
$ locale
LANG=fr_BE.UTF-8
LANGUAGE=fr_BE:fr
LC_CTYPE=fr_BE.UTF-8
LC_NUMERIC=fr_BE.UTF-8
LC_TIME=fr_BE.UTF-8
LC_COLLATE=fr_BE.UTF-8
LC_MONETARY=fr_BE.UTF-8
LC_MESSAGES=fr_BE.UTF-8
LC_PAPER=fr_BE.UTF-8
LC_NAME=fr_BE.UTF-8
LC_ADDRESS=fr_BE.UTF-8
LC_TELEPHONE=fr_BE.UTF-8
LC_MEASUREMENT=fr_BE.UTF-8
LC_IDENTIFICATION=fr_BE.UTF-8
LC_ALL=
}}}
locale settings after launching GRASS 7:
{{{
locale
LANG=fr_BE
LANGUAGE=fr_BE
LC_CTYPE=fr_BE
LC_NUMERIC=C
LC_TIME=fr_BE
LC_COLLATE=fr_BE
LC_MONETARY=fr_BE
LC_MESSAGES=fr_BE
LC_PAPER=fr_BE
LC_NAME=fr_BE
LC_ADDRESS=fr_BE
LC_TELEPHONE=fr_BE
LC_MEASUREMENT=fr_BE
LC_IDENTIFICATION=fr_BE
LC_ALL=
}}}
Thus the special characters in translated messages are not displayed
correctly.
This is with svn revision 56918.
Moritz
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2021
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] New module r3.neighbors
This is the link to the correct commit: http://trac.osgeo.org/grass/changeset/56959 2013/7/1 Sören Gebbert soerengebb...@googlemail.com Dear devs, just to inform you: there is now a neighborhood analysis module for 3D raster maps available in trunk: r3.neighbors[1]. [1] http://trac.osgeo.org/grass/changeset/56960 Best regards Soeren ___ 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: closed Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: fixed|Keywords: d.mon Platform: Unspecified | Cpu: Unspecified --+- Changes (by wenzeslaus): * status: new = closed * resolution: = fixed Comment: Current ticket summary: * zoom - works using mouse wheel * query - works with ''Query tool'' in toolbar * speed of display - subject to separate ticket but since it is wide topic a Trac wiki page was created (wiki:wxGUIDevelopment/MapRendering) which also contains summary of discussion above It is partially fixed, so I'm closing the ticket (as fixed since the is no more suitable option). Please create new tickets if needed (for example, for insufficient zoom possibilities). -- Ticket URL: https://trac.osgeo.org/grass/ticket/1719#comment:21 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 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. Did you get any other warnings while running i.segment? I assume you are using 64 bit Linux with more than 3072 GB RAM and lots of free disk space on the partition with your GRASS data. Can you provide data to replicate or commands using one of the sample datasets to replicate this error? Markus M ___ 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
[..] Markus Metz wrote: Not really. I created a sample dataset with a MASK leaving only a narrow diagonal strip and everything went fine. Did you get any other warnings while running i.segment? I assume you are using 64 bit Linux with more than 3072 GB RAM and lots of free disk space on the partition with your GRASS data. Sorry for breaking the flow here :-/. Besides the memory= parameter, could/would it be useful for i.segment to provide an option to make use of an external directory where to store temporary files? Like in r.viewshed stream_dir=? Thanks, Nikos ___ 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 --+- Changes (by hamish): * status: closed = reopened * resolution: fixed = Comment: wish: for 'd.mon wx0' be able to turn off the toolbar and replace it a right-click context menu. a menu item there to also turn on/off the lower status bar. right now those are avoided with grass- addons/grass7/display/d.mon2/d.mon2.py, but it's not an ideal solution. Since this is near to the original wish mentioned early in it, g.region is not respected upon d.redraw, and the redraw speed is still too slow, I'm reopening instead of creating a new ticket saying the same things. thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1719#comment:22 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] #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: |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by 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? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2019#comment:1 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] #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| ---+ Changes (by hamish): * keywords: = v.voronoi -- Ticket URL: https://trac.osgeo.org/grass/ticket/2019#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] #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 hamish): Also, with 'd.mon wx0' running I notice the process count in gkrellm is fluctuating rather loudly. ? -- Ticket URL: http://trac.osgeo.org/grass/ticket/1719#comment:23 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 hamish): Hi, 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) Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/2020#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
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 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. thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1428#comment:70 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 nikosa): Replying to [comment:22 hamish]: wish: for 'd.mon wx0' be able to turn off the toolbar and replace it a right-click context menu. a menu item there to also turn on/off the lower status bar. Yes, please :-). I know, I cannot code this stuff... can I do, however, anything else to support this cause? right now those are avoided with grass- addons/grass7/display/d.mon2/d.mon2.py, but it's not an ideal solution. Can't draw anything in d.mon2 currently (rev.=56960) :-? Since this is near to the original wish mentioned early in it, g.region is not respected upon d.redraw, and the redraw speed is still too slow, I'm reopening instead of creating a new ticket saying the same things. Same experiences here using G7 the last months. When I learned about ximgview (via the ML) I was really happy just because of the speed difference! And, yes, launching d.mon wx0 moves the CPUs a bit up. Otherwise, the wx monitor(s) are great -- all of the pan, d.zoom, g.region and d.histogram operations at your fingertips. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1719#comment:24 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] Unexpected EVI range from i.vi
MM: I think I figured it out: The EVI formula in i.vi is for MODIS. NA: That's precise, EVI is MODIS specific. We should clearly describe this in the manual (I will try to alter the respective text). MM: From the literature, I gor the impression that EVI can be calculated from other sensors as well, as long as you get the coefficients right. NA: Yes, but this is not an easy job, is it? This is (also) why, I think, they (MODIS science team) developed the EVI2, which is cross-sensor. MM: I am pretty sure that the EVI2 formula in i.vi is not cross-sensor, but also tailored to unscaled MODIS input bands: EVI2 = G * ( nir - red) / (nir + C1 * red + L) again, L needs to be adjusted to the actual input scale. AFAIU, both EVI and EVI2 can be applied to different sensors, given that the required bands are available and that the coefficients are adjusted if need be. Right. Yet, i.vi defines EVI and EVI2 (the latter suggested by me) with the MODIS-specific coefficients. We do need to explain this in the manuals. The generic formula is G * ( nir - red) / (nir + C1 * red - C2 * blue + L) where G is a gain factor, C1, C2 are coefficients to correct for aerosol influences in the red band using the blue band and L is the canopy background adjustment that addresses non-linear, differential NIR and red radiant transfer through a canopy. I had a look back in papers I have read in the past. There is one by Hui qing Liu and Huete, A. [1], I only came to discover now. According to it, the origins of EVI date back to 1995! Assuming that the input to i.vi should be properly preprocessed bands with a theoretically maximum range of [0, 1], you could set L to 0.0001 and would get reasonable EVI values, sensor-independent. This reminds, if I am not wrong (didn't check) the scale factor for MOD09 surface reflectance products. Makes sense. I suggested L = 0.0001 exactly because this is the MODIS scale factor. BTW, the satellite data you mentioned are ETM, not MODIS, thus applying the EVI formula developed for MODIS to ETM bands is a bit adventurous. In any case, EVI was developed for tropical rain forests because NDVI can saturate there. The Landsat scene you mentioned has only ocean and desert, no forest of any kind. NDVI should be just fine in this area. True. Was just testing... not real work (yet). However, from my last work using Landsat TM over Greece (fuel type mapping, where vegetation density is important), the experience (based on visual interpretation, no real assessment) was that using EVI2 helped more than the NDVI in visually discriminating forest vegetation types (of different degrees of density). Which, in turn, suggested (to me :-p) that using EVI2 could improve further the performance of i.cluster and subsequent classification attempts for example. I never got to test/evaluate the idea though. I would suggest to test the EVI(2) formulas in i.vi with a MODIS NDVI product which also includes the required input bands. All bands in the MODIS NDVI product would need to be scaled according to the documentation prior to feeding them to i.vi, or r.mapcalc with adjusted formulas. ToDo. Just adding stuff from the literature: EVI2 is supported to be a formula that can be used with other sensors as well. Taken from Development of a two-band enhanced vegetation index without a blue band (by Zhangyan Jianga, Alfredo R. Huetea, Kamel Didana, Tomoaki Miurab [2]): EVI2 can be used for sensors without a blue band, such as the Advanced Very High Resolution Radiometer (AVHRR), and may reveal different vegetation dynamics in comparison with the current AVHRR NDVI dataset. There is also a study Using lidar and effective LAI data to evaluate IKONOS and Landsat7 ETM+ vegetation cover estimates in a ponderosa pine forest [3] that derives EVI from IKONOS imagery by using the parameters suggested by Huete et al. (1997) of L=1, C1=6, C2=7.5, and G=2.5 ?! -- didn't read carefully the whole of it though. Nikos --- [1] A feedback based modification of the NDVI to minimize canopy background and atmospheric noise: http://dx.doi.org/10.1109/36.377946. [2] http://dx.doi.org/10.1016/j.rse.2008.06.006 [3] http://dx.doi.org/10.1016/j.rse.2003.11.003 signature.asc Description: This is a digitally signed message part. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.statistics in G7
Hamish wrote: perhaps - r.stats.cover and r.stats.quantile? I'm not sure about the first one. Is there a generic name for aggregates which involve sums (count, sum, mean, variance, standard deviation, skew, kurtosis)? r.statistics3 was derived from r.quantile by keeping a separate state for each category in the base map. Note that neither r.statistics2 nor r.statistics3 can calculate the mode. I'm not sure if the concept of mode is even meaningful when the inputs are floating-point maps (both modules automatically promote the cover maps to DCELL, and always generate DCELL outputs (even for method=count)). However, r.mode still exists (maybe we should rename it to r.statistics4 for consistency). we should also add r.stats (and perhaps r.univar) into this discussion. r.stats - r.stats.summary ? r.collate? r.stats basically groups the input values (or the cartesian product of multiple inputs) into bins then dumps the value(s),count pairs. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
