Re: [GRASS-user] Temporal framework: calculating annual 5-day extremes

[Sitansu Pattnaik]

r.series for the computation and g.mlist for selecting the rasters is how I
have used in the past.
Sitansu

On Thu, Apr 6, 2017 at 10:01 AM, RichardCooper 
wrote:

> Hi,
>
> I have a data set containing multiple years of daily raster layers and
> would
> like to aggregate and output annual raster layers of 5-day extremes
> (maxima).
>
> Essentially, for each grid cell, I need to calculate rolling 5-day sums of
> each year and then find the annual max of the latter sums, and output as a
> series of raster layers of annual 5-day extremes.
>
> However, I'm trying to work out the best way in GRASS of doing this.
> Overall
> t.rast.aggregate comes closest to the type of functionality needed. I've
> also looked at t.rast3d.mapcalc, but unsure if calculating a rolling sum is
> possible.
>
> I'd be grateful for any suggestions on how I might approach this.
>
> Thanks,
>
> Richard
>
>
>
> --
> View this message in context: http://osgeo-org.1560.x6.
> nabble.com/Temporal-framework-calculating-annual-5-day-
> extremes-tp5316014.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Zonal Raster Statistics with overlapping polygons

[Sitansu Pattnaik]

I had understood that v.rast.stats converted the vector file into raster
and hence the order in which the vectors were drawn, only one value was
generated for the overlapping areas in the raster. This rasterized version
was then used to compute the statistics.
Hence, the overlapping areas matched for polygon 1 and not for polygon 3 as
the overlap area was coded to "1" in the overlap area during raster
conversion.
Regards,
Sitansu

On Mon, Feb 27, 2017 at 5:05 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> Le Mon, 27 Feb 2017 09:41:11 +0100,
> Leonardo  a écrit :
>
> > Thanks for your answer,
> > I had already thought of a solution of this type,
> > but I'm looking for a cleaner and smarter solution,
> > any hints?!
>
> Well the "smarter" in your case would imply to use non-topological
> vector format, which was decided for GRASS GIS to not be "smarter".
> Yes, this makes some operations a bit more complicated, but you get
> paid back with so much less hassle because of spaghetti data. And
> writing a simple loop over v.rast.stats is not that difficult. The only
> difficulty I see is that v.rast.stats does not have a where= nor cat=
> feature selection parameter. This implies that you have to run
> v.extract each time. Having these parameters would certainly be useful
> and you could file an enhancement wish for those/
>
> I don't know why this would be less "clean"...
>
> The IMHO "cleanest" solution is actually the one that GRASS GIS
> implements: When you import a file with overlapping polygons, GRASS GIS
> creates a vector map in which the overlapping parts of the polygons
> have the category ids of all the polygons that overlap in that area.
> And when you run v.rast.stats on that, it will fill the total of each
> category value in the attribute table.
>
> Attached you can find an image of a test map with polygon 3 overlapping
> both polygon 1 and 2. I also created a second file with only the 2
> non-overlapping polygons. Those two were created in QGIS so as to be
> able to have "nice" topologically incorrect data.
>
> I then imported the two files into GRASS GIS with v.in.ogr and ran
>
> v.rast.stats map=test raster=elevation column_prefix=e
> v.rast.stats map=test_nooverlap raster=elevation column_prefix=e
>
> And here are the results:
>
> > v.db.select test
> cat|id|e_number|e_minimum|e_maximum|e_range|e_average|e_
> stddev|e_variance|e_coeff_var|e_sum|e_first_quartile|e_
> median|e_third_quartile|e_percentile_90
> 1|1|242621|76.8941955566406|145.712738037109|68.8185424804688|114.
> 397437714797|13.5650727983398|184.01120002426|11.8578467047128|27755220.
> 7358017|104.996|115.337|124.654|131.38
> 2|2|131854|77.3364105224609|126.733070373535|49.3966598510742|99.
> 4588066985328|10.6819214497898|114.103445859479|10.7400458585508|
> 13114041.4984283|91.5773|98.7388|106.926|114.645
> 3|3|99039|71.4758224487305|139.941131591797|68.4653091430664|107.
> 223648245541|13.7481896908839|189.012719776527|12.8219752972784|10619322.
> 8985901|97.4993|105.891|118.752|126.703
>
> > v.db.select test_nooverlap
> cat|id|e_number|e_minimum|e_maximum|e_range|e_average|e_
> stddev|e_variance|e_coeff_var|e_sum|e_first_quartile|e_
> median|e_third_quartile|e_percentile_90
> 1|1|242621|76.8941955566406|145.712738037109|68.8185424804688|114.
> 397437714797|13.5650727983398|184.01120002426|11.8578467047128|27755220.
> 7358017|104.996|115.337|124.654|131.38
> 2|2|131854|77.3364105224609|126.733070373535|49.3966598510742|99.
> 4588066985328|10.6819214497898|114.103445859479|10.7400458585508|
> 13114041.4984283|91.5773|98.7388|106.926|114.645
>
> You can see that the values for polygons 1 and 2 are strictly
> identical. Overlapping areas are thus correctly taken into account.
>
> To test even further, I ran
>
> v.extract -d test cat=3 out=test3
>
> to get the entire polygon with cat=3.
>
> Then
>
> v.rast.stats test3 rast=elevation colprefix=e -c
> > v.db.select test3
> cat|id|e_number|e_minimum|e_maximum|e_range|e_average|e_
> stddev|e_variance|e_coeff_var|e_sum|e_first_quartile|e_
> median|e_third_quartile|e_percentile_90
> 3|3|224074|71.4758224487305|141.793502807617|70.
> 3176803588867|110.21428988784|13.2281044492473|174.
> 982747320197|12.0021681968|24696156.7923279|100.265|110.
> 004|120.916|127.836
>
> There thus seems to be a bug in v.rast.stats as it does not calculate
> the correct values for the polygon with cat=3 when there area polygons
> with multiple cat values.
>
> I'll post a bug report.
>
> Moritz
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Land-use mapping troubles

[Sitansu pattnaik]

At first glance, it looks like there is a problem with data import. If you
are able to see the imported bands clearly within GRASS, then there could
be problems with the signature collection process. Your current output
looks like the row numbers have been classified instead of the data values
stored in each pixel.
If you can share more information about the data source including format
and the steps you have taken for classification ( groups and subgroup
definiton ), someone can troubleshoot your problem.

Sitansu @ kCube

On Tue, Mar 19, 2013 at 3:22 PM, Devica Ranade devicaran...@gmail.comwrote:

 I have been trying to do some land use mapping using GRASS.
 While doing a supervised classification for my LANDSAT image, I got a very
 weird map shown below. (screenshot also attached with this email.)



 Can I please know if this problem is common and if yes, what is the best
 way of dealing with it?

 Thanks a lot,

 Devica..
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Land-use mapping troubles

[Sitansu pattnaik]

Please email to the group so that you get additional responses.

I do not think you need to group the rasterized training data with the
Landsat image group. Use i.group to define the group and the subgroup.
You need to also check how many pixels are within each training polygon. If
you have only chosen a few points, i.maxlik will not generate
any usable results.

http://grass.osgeo.org/grass64/manuals/i.group.html

Please share the actual commands which were used in the entire process.

Sitansu @ kCube

On Tue, Mar 19, 2013 at 4:55 PM, Devica Ranade devicaran...@gmail.comwrote:

 Hello,

 Thanks a lot for the reply!
 I can see the imported bands clearly within GRASS. They were LANDSAT
 images in tiff format.
 I created a polygon vector file using my ground-truthing data points in
 QGIS and converted it into a raster (tiff format) . I further imported this
 raster into GRASS and tried doing supervised classification using a group
 (my group included the newly made raster map and my original LANDSAT image
 that I wanted to be classified) and subgroup.
 On running Maximum Likelihood Classification, I got the result I have
 attached in the previous email!

 I have tried this quite a few times now, only to get the same map.

 Any help will be really appreciated!
 Thanks a lot again,
 Devica..



 On Tue, Mar 19, 2013 at 3:42 PM, Sitansu pattnaik sita...@gmail.comwrote:

 At first glance, it looks like there is a problem with data import. If
 you are able to see the imported bands clearly within GRASS, then there
 could be problems with the signature collection process. Your current
 output looks like the row numbers have been classified instead of the data
 values stored in each pixel.
 If you can share more information about the data source including format
 and the steps you have taken for classification ( groups and subgroup
 definiton ), someone can troubleshoot your problem.

 Sitansu @ kCube

 On Tue, Mar 19, 2013 at 3:22 PM, Devica Ranade devicaran...@gmail.comwrote:

 I have been trying to do some land use mapping using GRASS.
 While doing a supervised classification for my LANDSAT image, I got a
 very weird map shown below. (screenshot also attached with this email.)



 Can I please know if this problem is common and if yes, what is the best
 way of dealing with it?

 Thanks a lot,

 Devica..
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user



 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How I can solve the problem like spectral correlation maping

[Sitansu pattnaik]

http://grass.unibuc.ro/grass65/manuals/html65_user/r.regression.line.html

Regards,
Sitansu

On Nov 21, 2012 6:34 PM, SWAPAN GHOSH swap.g...@gmail.com wrote:

Dear sir,

yes it means affine function coefficients for two spectral bands. Please
give me suitable logic or command sequence so that I can build a single
command for this problem. I am c/c++ developer, I have not much knowledge
about GIS.

Thanks,

Swapan




On Wed, Nov 21, 2012 at 5:51 PM, Yann Chemin yann.che...@gmail.com wrote:

 Do you mean findi...

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user