[GRASS-dev] [GRASS GIS] #3476: Patch to fix various spelling errors

[GRASS GIS]

#3476: Patch to fix various spelling errors
+-
 Reporter:  Bas Couwenberg  |  Owner:  grass-dev@…
 Type:  enhancement | Status:  new
 Priority:  normal  |  Milestone:  7.4.0
Component:  Default |Version:  svn-releasebranch74
 Keywords:  |CPU:  Unspecified
 Platform:  All |
+-
 The lintian QA tool reported a couple of spelling errors for 7.4.0-RC2:

  * lenght  -> length
  * aditionally -> additionally

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3476: Patch to fix various spelling errors

[GRASS GIS]

#3476: Patch to fix various spelling errors
-+-
  Reporter:  Bas Couwenberg  |  Owner:  grass-dev@…
  Type:  enhancement | Status:  new
  Priority:  normal  |  Milestone:  7.4.0
 Component:  Default |Version:  svn-releasebranch74
Resolution:  |   Keywords:
   CPU:  Unspecified |   Platform:  All
-+-
Changes (by Bas Couwenberg):

 * Attachment "spelling-errors.patch" added.


--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Dear all,

the new release candidate GRASS GIS 7.4.0RC2 is out!

Please double check the announcement:
https://trac.osgeo.org/grass/wiki/Release/7.4.0-News

Next we need binary packages. Once we believe that things are in order
I'd like to promote RC2 to final (hence, no more relevant changes
allowed).

thanks!
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Mon, Jan 8, 2018 at 8:21 PM, Markus Metz
 wrote:
> On Mon, Jan 8, 2018 at 7:57 PM, Markus Neteler  wrote:
...
>> Anything else left for RC2?
>
> From my side, nothing. Let's get RC2 out!

ok, procedure started :-)

markusN

-- 
Markus Neteler, PhD
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce

[GRASS GIS]

#2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce
-+-
  Reporter:  dylan   |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-

Comment (by dylan):

 Replying to [comment:28 mmetz]:
 > This is a very simple r.mapcalc expression. You should be able to
 trigger the error by simply creating a number of maps in parallel with
 r.mapcalc, after that (serially) testing the outputs with r.univar. With
 r.mapcalc in daily-rad.sh, you are running several independent instances
 of r.mapcalc in parallel. With daily-rad.sh called by beam-rad-at-tile.sh
 you are not testing if GRASS is thread-safe, instead you are testing if
 your OS, filesystem and hard drive can handle multiple simultaneous IO
 requests. Please check your system messages and the health of your hard
 drives (e.g. with smartctl) first, before you proceed.

 Yeah, that is what I thought and what the original test scripts basically
 perform. As stated in [https://trac.osgeo.org/grass/ticket/2764#comment:2
 my update] circa 2 years ago, these tests run fine on both the RAID1 and
 SSD on this machine.

 I don't see any troubling messages reported by `dmesg` or `smrtctl`. Note
 that I don't have any issues with any other GRASS commands, or (as far as
 I can tell) general usage on this machine. I only see these errors when
 working with GRASS commands that:

   * take a long time to run: `r.sun` or `t.rast.mapcalc` ([http://osgeo-
 org.1560.x6.nabble.com/Error-reading-raster-data-for-row-xxx-only-when-
 using-r-series-and-t-rast-series-td5229569.html e.g. a couple of years
 ago])
   * operate on moderately large, floating-point maps
   * are done in parallel, either via GNU `parallel` or as implemented in
 the temporal suite of modules

 ...hence the extreme difficulty in recreating the errors or further
 debugging.

 For the record, I have been getting corrupt rows using LZ4 compression in
 1/8 attempts vs. 1/2 attempts when using ZLIB compression.

 Next error I'll re-compile without openmp (not using it, but just in case)
 and -g -Wall CFLAGS.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce

[GRASS GIS]

#2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce
-+-
  Reporter:  dylan   |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-

Comment (by mmetz):

 Replying to [comment:27 dylan]:
 > Replying to [comment:26 mmetz]:
 > >[...]
 > > That means r.sun has created corrupt output. BTW, considering that you
 are running several instances of r.sun in parallel, I wonder if you
 compiled GRASS with openmp and use the nprocs option of r.sun. In this
 case you would have several instances of r.sun and each instance of r.sun
 would be multi-threaded: no speed gain, more sources of potential errors.
 >
 > Note that this sometimes happens in the follow-up step where there
 output from `r.sun` is converted to MJ/sq.m by `r.mapcalc`: "beam.106"
 (`r.mapcalc`) vs. "temp_beam_106" (`r.sun`).

 This is a very simple r.mapcalc expression. You should be able to trigger
 the error by simply creating a number of maps in parallel with r.mapcalc,
 after that (serially) testing the outputs with r.univar. With r.mapcalc in
 daily-rad.sh, you are running several independent instances of r.mapcalc
 in parallel. With daily-rad.sh called by beam-rad-at-tile.sh you are not
 testing if GRASS is thread-safe, instead you are testing if your OS,
 filesystem and hard drive can handle multiple simultaneous IO requests.
 Please check your system messages and the health of your hard drives (e.g.
 with smartctl) first, before you proceed.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Metz]

On Mon, Jan 8, 2018 at 7:57 PM, Markus Neteler  wrote:
>
> On Mon, Jan 8, 2018 at 4:30 PM, Markus Metz
>  wrote:
> > On Mon, Jan 8, 2018 at 10:47 AM, Markus Neteler 
wrote:
> >>
> >> Hi devs,
> >>
> >> if there are no objections, I'll package 7.4.0RC2 in the next few days.
> >
> > I have just submitted a fix for i.atcorr in r72055, in the hope that it
> > still makes it into 7.4.0RC2.
>
> Yes, they are in! Thanks for the fixes.
>
> Anything else left for RC2?

>From my side, nothing. Let's get RC2 out!

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Mon, Jan 8, 2018 at 4:30 PM, Markus Metz
 wrote:
> On Mon, Jan 8, 2018 at 10:47 AM, Markus Neteler  wrote:
>>
>> Hi devs,
>>
>> if there are no objections, I'll package 7.4.0RC2 in the next few days.
>
> I have just submitted a fix for i.atcorr in r72055, in the hope that it
> still makes it into 7.4.0RC2.

Yes, they are in! Thanks for the fixes.

Anything else left for RC2?

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce

[GRASS GIS]

#2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce
-+-
  Reporter:  dylan   |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-

Comment (by dylan):

 Replying to [comment:26 mmetz]:
 >[...]
 > That means r.sun has created corrupt output. BTW, considering that you
 are running several instances of r.sun in parallel, I wonder if you
 compiled GRASS with openmp and use the nprocs option of r.sun. In this
 case you would have several instances of r.sun and each instance of r.sun
 would be multi-threaded: no speed gain, more sources of potential errors.

 Note that this sometimes happens in the follow-up step where there output
 from `r.sun` is converted to MJ/sq.m by `r.mapcalc`: "beam.106"
 (`r.mapcalc`) vs. "temp_beam_106" (`r.sun`).

 I had previously compiled using --with-openmp. I'll try disabling it. So
 far, I haven't used the `nprocs` argument to `r.sun`.


 > >
 > > Well crud, just got this after a 10 hour run, returned by `r.series`:
 > >
 > > {{{
 > > WARNING: LZ4 decompression error
 > > ERROR: Error uncompressing fp raster data for row 3929 of :
 error
 > >code -1
 > > }}}
 > >
 > > That is the first error using LZ4 compression after many successful
 tiles. I wonder if the faster compression results in a lower probability
 of row corruption? Within my current project, I seem to be encountering
 corrupt rows about 0.0001% of the time: 2 rows out of (5000 rows * 365
 calls to `r.sun`).
 >
 > Chances are very small that ZLIB and LZ4 have the same bug. It rather
 seems to be a write error when writing several files at (nearly) the same
 time.

 Right. Are there any functions below put_row.c where concurrent writes
 could be trouble? Is there anything else that I can do to help test?

 I just posted an [http://soilmap2-1.lawr.ucdavis.edu/dylan/temp/example-
 maps.tgz example tileset] containing elevation, slope, and aspect maps.
 Sorry for the large file sizes. Note that it takes my machine about 10
 hours per tile, with errors surfacing in the final call to `r.series`.
 I'll re-write my code to check the intermediate files in the meantime.

 Thanks!

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.rast.stats with multiple input

[Stefan Blumentrath]

Dear GRASS-devs,

I would like to extract statistics for vector geometries from a couple of maps 
derived from the same terrain model.
Unfortunately, v.rast.stats has two limitations for my use-case:

1)  the rasterization has a significant overhead when called several times

2)  only one percentile column can be produced (while I would like to get 
both 10 and 90% percentiles)

In order make v.rast.stats more efficient for use cases like mine, I would like 
to propose the following changes I could imagine:

1)  add an optional input option for a raster map representing the category 
values of the vector map

2)  make column_prefix and raster option multiple

3)  add additional columns for additional percentiles

Since v.rast.stats is a Python script I could try to come up with a solution, 
if you generally agree that the proposed changes make sense and are not 
problematic...
What do you think?

Cheers
Stefan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce

[GRASS GIS]

#2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce
-+-
  Reporter:  dylan   |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-

Comment (by mmetz):

 Replying to [comment:25 dylan]:
 > I'll post an example set of tile data shortly.

 OK.
 >
 > Most of the errors are encountered in the final call to `r.series`
 within:
 >
 > {{{
 > bash beam-rad-at-tile.sh $tile_i
 > }}}

 That means r.sun has created corrupt output. BTW, considering that you are
 running several instances of r.sun in parallel, I wonder if you compiled
 GRASS with openmp and use the nprocs option of r.sun. In this case you
 would have several instances of r.sun and each instance of r.sun would be
 multi-threaded: no speed gain, more sources of potential errors.

 >
 > Well crud, just got this after a 10 hour run, returned by `r.series`:
 >
 > {{{
 > WARNING: LZ4 decompression error
 > ERROR: Error uncompressing fp raster data for row 3929 of :
 error
 >code -1
 > }}}
 >
 > That is the first error using LZ4 compression after many successful
 tiles. I wonder if the faster compression results in a lower probability
 of row corruption? Within my current project, I seem to be encountering
 corrupt rows about 0.0001% of the time: 2 rows out of (5000 rows * 365
 calls to `r.sun`).

 Chances are very small that ZLIB and LZ4 have the same bug. It rather
 seems to be a write error when writing several files at (nearly) the same
 time.
 >
 > This makes me wonder about my hardware and OS...
 >
 > However, I recall having this kind of error (365 maps generated in
 parallel, and 1 or 2 rows in the entire set with corruption "discovered"
 by `r.series`) nearly every time I have used `r.sun` over the last 10
 years. It just so happens that this time I am performing the same
 operation 54 times vs. the typical single run. In every situation I was
 using some version of Debian or Xubuntu on fairly common (multi-processor
 or multi-core) hardware.
 >
 > Thinking back, all of the errors have been encountered with
 [https://en.wikipedia.org/wiki/Hyper-threading hyper-threading] enabled:
 both on a dual Xeon and currently i7 950.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Metz]

On Mon, Jan 8, 2018 at 10:47 AM, Markus Neteler  wrote:
>
> Hi devs,
>
> if there are no objections, I'll package 7.4.0RC2 in the next few days.

I have just submitted a fix for i.atcorr in r72055, in the hope that it
still makes it into 7.4.0RC2.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3469: i.atcorr: Sentinel-2 support broken on some systems

[GRASS GIS]

#3469: i.atcorr: Sentinel-2 support broken on some systems
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.atcorr
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [comment:21 mmetz]:
 >
 > This small patch makes sense and produces some visually reasonable
 output, therefore it could be applied to trunk and relbr74.

 Applied to trunk and relbr74 in r72054,5.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce

[GRASS GIS]

#2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce
-+-
  Reporter:  dylan   |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-

Comment (by dylan):

 The errors are typically encountered within the 365 calls to `r.sun`, any
 tile. I'll post an example tile today.

 Most of the errors are encountered in the final call to `r.series` within:

 {{{
 bash beam-rad-at-tile.sh $tile_i
 }}}

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce

[GRASS GIS]

#2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce
-+-
  Reporter:  dylan   |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-
Changes (by dylan):

 * Attachment "make-hz-maps.sh" added.


--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3469: i.atcorr: Sentinel-2 support broken on some systems

[GRASS GIS]

#3469: i.atcorr: Sentinel-2 support broken on some systems
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.atcorr
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [comment:20 sbl]:
 >
 > With the patch applied to clean and completely fresh svn checkout I get
 the following results (on UBUNTU 14.04):
 >
 > {{{
 > [...]
 >
 > i.atcorr -r input=B08 elevation=dem range=0,1 output=test_atcorr
 rescale=0,1 parameters=~/p6s.txt --v --o
 > (...)
 > Atmospheric correction...
 >  100%
 > Atmospheric correction complete.
 >
 > r.info -r test_atcorr
 > min=0.5415085
 > max=8514.146
 >
 > }}}

 I get on Fedora 27 slightly different results:

 {{{
 r.info -r test_atcorr
 min=0.5536021
 max=8514.16
 }}}

 The 6s code is still numerically unstable. The 27,159 lines of code in
 i.atcorr need to be reviewed ...

 This small patch makes sense and produces some visually reasonable output,
 therefore it could be applied to trunk and relbr74.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: Call for mentors for Google Summer of Code 2018

[Margherita Di Leo]

FYI

-- Forwarded message --
From: Margherita Di Leo 
Date: Mon, Jan 8, 2018 at 12:13 PM
Subject: Call for mentors for Google Summer of Code 2018
To: OSGeo Discussions 
Cc: "gsoc-adminosgeo.org" 


Dear members of the community,

while we're still very busy in Google Code-in, which is, by the way, a big
success so far, it's already time to apply for Google Summer of Code 2018!
In fact, the admins team is making shifts to cope with all these energetic
pre-school students and meanwhile preparing the application for next GSoC..

*We need you!*

At this time of the year, software communities should brush up their list
of ideas, create a new ideas page and send the URL to us admins at  <
gsoc-ad...@osgeo.org>. We need to receive your URLs by *Jan 20*.  If you
are willing to act as a mentor, fill in this form: https://goo.gl/forms/
jMvPl7ns2NG1BL6Q2

Please, forward this email to your developer mailing list.

Here [1] is the timeline.

Looking forward to another great GSoC edition!
Let's keep fingers crossed for our application!

Cheers

-The GSoC / GCI admins team


[1] https://developers.google.com/open-source/gsoc/timeline

-- 
Margherita Di Leo



-- 
Margherita Di Leo
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3469: i.atcorr: Sentinel-2 support broken on some systems

[GRASS GIS]

#3469: i.atcorr: Sentinel-2 support broken on some systems
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.atcorr
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by sbl):

 Thanks Markus for the swift reply!
 The patch works fine:

 {{{
 g.version -gr
 version=7.4.0svn
 date=2018
 revision=r72045M
 build_date=2018-01-08
 build_platform=x86_64-pc-linux-gnu
 build_off_t_size=8
 libgis_revision=70829
 libgis_date="2017-04-04 09:43:02 +0200 (Tue, 04 Apr 2017) "

 r.info -r B08
 min=83
 max=7110

 g.region raster=B08 align=B08 -p
 projection: 1 (UTM)
 zone:   33
 datum:  etrs89
 ellipsoid:  grs80
 north:  6649695
 south:  6647685
 west:   260495
 east:   262505
 nsres:  10
 ewres:  10
 rows:   201
 cols:   201
 cells:  40401

 i.atcorr -r input=B08 elevation=dem range=0,1 output=test_atcorr
 rescale=0,1 parameters=~/p6s.txt --v --o
 (...)
 Atmospheric correction...
  100%
 Atmospheric correction complete.

 r.info -r test_atcorr
 min=0.5415085
 max=8514.146

 }}}

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3469: i.atcorr: Sentinel-2 support broken on some systems

[GRASS GIS]

#3469: i.atcorr: Sentinel-2 support broken on some systems
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.atcorr
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [comment:18 sbl]:
 > Would it be an option to apply the patch to trunk / 7.4.0RC2 ?

 No, the patch was more meant as a diagnostic tool.

 The Sentinel-2 parameters are somewhat unusual with many zeroes in the
 spectral responses. For othjer sensors, the leading and trailing zeroes
 have been clipped off. The new patch i_atcoor_iwave.patch fixes these
 leading and trailing zeroes on initialization. This patch affects all
 sensors, not only Sentinel-2. There have been regular reports that the
 output of i.atcorr is all NULL, also for other sensors. This patch could
 fix this, and the previous patch converting float to double is no longer
 needed.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3469: i.atcorr: Sentinel-2 support broken on some systems

[GRASS GIS]

#3469: i.atcorr: Sentinel-2 support broken on some systems
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.atcorr
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mmetz):

 * Attachment "i_atcorr_iwave.patch" added.

 patch to fix reading spectral responses

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi devs,

if there are no objections, I'll package 7.4.0RC2 in the next few days.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce

[GRASS GIS]

#2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce
-+-
  Reporter:  dylan   |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-

Comment (by mmetz):

 Replying to [comment:23 dylan]:
 [...]
 >
 > As of 2017-12-30, I was again encountering the hard-to-reproduce "ERROR:
 Error reading raster data for row 1949 of " errors. Just as with last
 time in the context of parallel execution. I posted [http://osgeo-
 org.1560.x6.nabble.com/r-sun-daily-with-multiple-CPU-cores-error-
 uncompressing-raster-data-td5348054.html this message] to GRASS-user and
 then proceeded to document progress as of comment 8 in this ticket.
 >
 > I am attaching two scripts to illustrate the latest instance, `beam-rad-
 at-tile.sh` and `daily-rad.sh`, invoked like this:
 >
 > {{{
 > # ...
 >
 > ## try ZLIB compression:
 > # random errors as described in #2764
 > # export GRASS_COMPRESSOR=ZLIB
 >
 > ## try LZ4 compression:
 > # no errors!
 > export GRASS_COMPRESSOR=LZ4
 >
 > #
 > # ... looping code
 > #
 > bash beam-rad-at-tile.sh $tile_i
 >
 > # ...
 > }}}
 >
 > Essentially, I am iterating over 5000x5000 {elevation, slope, aspect}
 tiles,

 The script make-hz-maps.sh called by beam-rad-at-tile.sh is missing. Is
 the exact looping code needed in order to reproduce, or does it also
 happen with any given tile?

 > computing horizon angle maps in parallel, computing daily beam radiance
 maps in parallel, summing daily maps, and then proceeding to the next
 tile. With ZLIB compression, I am randomly encountering raster read errors
 generated by `r.horizon`, `r.sun`, or `r.mapcalc` in this context. This
 seems to happen with or without NULL cells in the active tile. Errors are
 not encountered when using LZ4 compression.
 >
 > The system is an 8-core Intel i7 950 @ 3.07Ghz with GRASS
 database/mapset residing on an SSD.
 >
 > I'll post one of the {elevation, slope, aspect} tiles if anyone is
 interested in tinkering with them.

 Test data, or a script to generate test data would help.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev