[GRASS-user] Computing continuous dry spell from strds

[Sajid Pareeth via grass-user]

Dear all

I have a temporal database of daily gridded rainfall for the last 40 years.

I want to find:
1. Number of times (count) the rainfall was 0 for 'atleast' *continuous *10
days in each year, in 5 years etc.
2. Max number of continuous (> 10days) dry days (rainfall=0) per year, per
5 years etc. In this I want to exclude continuous dry spells less than 10
days.

I am trying to use the `t.rast.algebra` following the example given here

.

# Create weekly mask to which we will add 1 or 0 according to
temperature in the days within it (each map in this week mask will
have a value of 7)
t.rast.aggregate input=temperature_daily output=weekly_mask
basename=mask_week granularity="1 weeks" method=count
# Calculate consecutive days with negative temperatures
t.rast.algebra base=neg_temp_days expression="consecutive_days =
weekly_mask {+,contains,l} if(temperature_daily < 0 &&
temperature_daily[-1] < 0 || temperature_daily[1] < 0 &&
temperature_daily < 0, 1, 0)"


The example works, but the above code counts every consecutive day in a
week even if there is a break in between.
I also didn't understand why the consecutive days are added to the total
number of days (+7) in the week in 'mask_week' strds.

I tried modifying the aggregate expression, but could not make it work to
my requirement as stated above.

Could anyone give a hint on how to go about this.

Many thanks in advance,

Best Regards

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

Re: [GRASS-user] Error with installing addons in Windows

[Sajid Pareeth]

Hi Stefan

Thanks for the reply. Sorry for the delay in response.

I solved it temporarily by asking the participants to install GRASS 7.8.5
into the OSGeo4W/apps folder and update the environment accordingly, and it
worked.
But your solution of downloading the addon and extracting it to "
C:\Users\%USER%\AppData\Roaming\GRASS7\addons\", is more elegant and it
works.

I also support the additional feature of installing the addon in Windows.

Thanks again for pointing out "find_program", it is the perfect solution to
check if an addon is installed or not.

Best regards,

Sajid


On Mon, Aug 2, 2021 at 1:56 AM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hi Sajid,
>
> On Windows, addons are distributed as precompiled binaries for a specific
> version.
> 7.8.6 is just a release candidate, so there are no pre-compiled addons yet.
> With OSGeo4W Version 1, which you can get here:
> https://download.osgeo.org/osgeo4w/osgeo4w-setup-x86-v1.exe
> you can get GRASS 7.8.5 where installation of addons works fine.
>
> In order to make addons work for GRASS 7.8.6 we would first need a release
> and then packaging of addons for that version. So no quick fix.
>
> As a workaround you could download the required addons for GRASS 7.8.5 and
> ask your students to extract them into their user profile, which is
> typically:
> C:\Users\%USER%\AppData\Roaming\GRASS7\addons\
> That is a hack of course but should work (though I have not tested)...
>
> As for your related questions:
> 1) Might be a good idea to support installation of addons from local zip
> files. At least for Python scripts that should generally work. There is
> already a similar feature request in here:
> https://github.com/OSGeo/grass/issues/625#issuecomment-797414504...
> 2) Not sure I understand the question correctly, but you could check if an
> addon is present (e.g. with
> https://grass.osgeo.org/grass79/manuals/libpython/script.html?highlight=find_#script.core.find_program
> )
>
> Hope that helps a bit (though it may be late for your course).
>
> Cheers
> Stefan
> --
> *Fra:* grass-user  på vegne av Sajid
> Pareeth 
> *Sendt:* torsdag 29. juli 2021 16:48
> *Til:* GRASS user list 
> *Emne:* [GRASS-user] Error with installing addons in Windows
>
> Dear all
>
> While installing an addon using g.extension in Windows 10, gives the
> following error.
>
> "ERROR: Cannot open URL:
>
>http://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.
> 8.6RC1/r.series.lwr.zip
> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwingrass.fsv.cvut.cz%2Fgrass78%2Fx86_64%2Faddons%2Fgrass-7.8.6RC1%2Fr.series.lwr.zip=04%7C01%7C%7C63bfed4d4eea4b708e4d08d9529fffdb%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637631669417533127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=7Z5m4E2VcKIdpehXbq%2F8b6prPQkB%2FLx2428jwRt7NsE%3D=0>
> "
>
>
> I see that the addons for 7.8.5 are accessible:
> http://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.5RC1/r.series.lwr.zip
> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwingrass.fsv.cvut.cz%2Fgrass78%2Fx86_64%2Faddons%2Fgrass-7.8.6RC1%2Fr.series.lwr.zip=04%7C01%7C%7C63bfed4d4eea4b708e4d08d9529fffdb%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637631669417543124%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=5pmClXaSPsn4ZmHKboj0P78vmoFkfDgR0ZoH8irx%2B5g%3D=0>
>  ;
> But not accessible for 7.8.6RC1.
>
> The latest OSGeo4W setup gives two GRASS GIS versions: 7.8.6RC1-4 and
> 7.8.6RC1-5.
>
> So there is no option to install 7.8.5 using OSGeo4W.
>
> Any quick work around for this issue? I am in the middle of providing
> training, and it would be great if there is a quick fix.
>
> *Related questions: *
> 1) Is there any way to install an addon from a local zip package or url in
> Windows? In the manual it says it works only for Linux and Mac.
>
> 2) Is there any way to skip installation of an addon, if it is already
> installed? Useful within a python script.
>
> Many thanks in advance
>
> Best
>
> Sajid
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Error with installing addons in Windows

[Sajid Pareeth]

Dear all

While installing an addon using g.extension in Windows 10, gives the
following error.

"ERROR: Cannot open URL:

   http://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.
> 8.6RC1/r.series.lwr.zip"


I see that the addons for 7.8.5 are accessible:
http://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.5RC1/r.series.lwr.zip

;
But not accessible for 7.8.6RC1.

The latest OSGeo4W setup gives two GRASS GIS versions: 7.8.6RC1-4 and
7.8.6RC1-5.

So there is no option to install 7.8.5 using OSGeo4W.

Any quick work around for this issue? I am in the middle of providing
training, and it would be great if there is a quick fix.

*Related questions: *
1) Is there any way to install an addon from a local zip package or url in
Windows? In the manual it says it works only for Linux and Mac.

2) Is there any way to skip installation of an addon, if it is already
installed? Useful within a python script.

Many thanks in advance

Best

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

Re: [GRASS-user] Using grass libraries in python outside of GRASS

[Sajid Pareeth]

Hi


> > > The model I need to use (which I did not write) requires python 2.7.
> > > I had tried pip install previously but then it still fails with
> ImportError: No module named grass.script.
> > > Do you know what could be causing that?
>
> Interestingly, our docker containers just started to suffer from a
> similar (same?) problem:
>
> File "/scripts/test_grass_session.py", line 3, in 
> import grass.script as grass
> ModuleNotFoundError: No module named 'grass'
>
> Weird, we need to investigate.
>

Grass_session works for me with both python2.7 and 3 in a Osgeo environment
with grass 7.8.3
For me, the import modules work in this order in both python versions after
pip installation.


> *>>> import grass_session>>> from grass_session import Session*

*>>> import grass.script as grass*


For the final script to work, you will have to set environment variables,
GISBIN (grass78 root folder) , GISRC (.grassrc78 file in demo location) and
add grass78 'lib', 'bin' and 'scripts' folders to PATH variable.
I run the script in python 3, where it worked without setting GISBIN and
GISRC variables. I have only tested this approach in Windows 10 yet, and
should work fine in Linux as well.

Regards

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

Re: [GRASS-user] r.hants and r.series.lwr in Windows

[Sajid Pareeth]

Dear Helmut

Thank you for testing and finding the issue. Both commands work well
without infinity in Windows.
Big help for continuing to use GRASS GIS in Windows for the course.

I have opened an issue in github.

Regards

Sajid


On Fri, Jun 26, 2020 at 11:05 AM Helmut Kudrnovsky  wrote:

> >there is somewhere an old ticket in trac.
>
> see
>
> https://trac.osgeo.org/grass/ticket/3432
> https://trac.osgeo.org/grass/ticket/2919
>
> 
> [...]
>  My guess - input.d8cut->answer contains extra chars (CR/LF issue?) and
> thus changing line to read:
>
> if (strncmp(input.d8cut->answer, "infinity", 8) == 0) {
>
> would solve the issue. Still, if it is so, then it is worth to digg deeper
> to see why it is failing as strcmp is used in many modules.
> [...]
> I guess that the MS Windows version of sscanf does not recognize infinity
> as a floating point number, while the Linux version does.
> [...]
>
> 
>
> IMHO it's still worth to fix the issue with inf/INF as this issue pops up
> from time to time.
>
> if it's not possible, the manual should be updated where needed that
> examples work also in winGRASS. PR welcome. :-)
>
> kind regards
> Helmut
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.hants and r.series.lwr in Windows

[Sajid Pareeth]

Hallo

I am trying to establish a workflow to gapfill temporal maps using r.hants
and r.series.lwr. It is important that the solution also works in windows
for the teaching.

The issue I am encountering is that both r.hants and r.series.lwr are
returning 0 values in Windows with a majority of the valid pixels in the
original raster converted to NULL() in outputs.
While in Linux it works well and gives the intended results.

*Specs:*
*Windows 10,  GRASS 7.8.3 *
*Ubuntu 18.04 LTS, GRASS 7.8.3*

Here are the commands I use:

>
> *r.series.lwr -l -h -i file=maps.txt suffix=_lwr order=2 weight=tricube
> range=0,inf fet=0.5 dod=3 maxgap=3 --or.hants -l -h -i file=maps.txt
> suffix=_hants range=0,inf nf=3 fet=0.5 --o*


I used the same mapset in both windows and Linux to run these modules. The
mapset was created in windows, tried running these commands and later
accessed the same mapset through Linux and ran the commands.
In windows r.univar returns:

> r.univar ETact_SEBAL_2019_03_mm_month_lwr
>  100%
>
>
>
>
>
>
>
>
>
>
>
>
>
> *total null and non-null cells: 1534326total null cells: 1473343Of the
> non-null cells:--n: 60983minimum: 0maximum: 0range:
> 0mean: 0mean of absolute values: 0standard deviation: 0variance: 0variation
> coefficient: nan %sum: 0*


In Linux after *RERUNNING* the r.series.lwr command, r.univar returns:

> r.univar ETact_SEBAL_2019_03_mm_month_lwr
>  100%
>
>
>
>
>
>
>
>
>
>
>
>
>
> *total null and non-null cells: 1534326total null cells: 28600Of the
> non-null cells:--n: 1505726minimum: 0maximum:
> 130.153range: 130.153mean: 11.7246mean of absolute values: 11.7246standard
> deviation: 21.0032variance: 441.136variation coefficient: 179.138 %sum:
> 17654069.6570365*


 Any hint on what must be going wrong?

Best Regards

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

Re: [GRASS-user] Calling all imagery (especially i.maxlik and i.smap) users

[Sajid Pareeth]

Hi Maris

Thank you for bringing this topic.

#2 Should i.maxlik add its output to the group?
>
Current implementation of i.maxlik adds classification result to the
> input group [2]. This prevents use of i.maxlik with imagery group from
> other mapset. I would vote to remove such feature. If you have a use
> case where such functionality is needed, speak now, or forever hold
> your peace.
>

In my experience, having the outputs stored in the group/subgroup is not
useful and we should remove this behavior. Don't see any particular
advantage of this.


> #3 Should signature files be handled similarly to raster colors?
> i.cluster, i.gensig and i.gensigset write signature files to imagery
> subrgoup. This is not possible if group is located in other mapset. My
> proposal — handle signatures as raster colours — signatures are always
> saved in current mapset. Thus signatures created for a group in other
> mapset would be not visible in other mapsets.


IMHO we should be able to list the signatures and should also be able to
use outside the group. There are cases where we want to use the same
signature with a different imagery group same spectral combination but from
a different date for example.
In this context want to point out these addons by Luca Delucchi, to move,
list the signatures.
i.signature.copy
:
Copies signature file from a group/subgroup to another group/subgroup.
i.signature.list
:
Lists signature file of a group/subgroup.
i.signature.remove
:
Removes signature file in a group/subgroup.
It would be nice if we can export/save (resue)  the signature (for example
.sig file) outside grass mapset like the color files.

best
Sajid
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] WinGRASS addons partly back

[Sajid Pareeth]

Thanks Martin,

It works now.

Regards

Sajid

On Tue, Sep 3, 2019 at 9:39 PM Helmut Kudrnovsky  wrote:

> Martin Landa wrote
> > Hi,
> >
> > after long time when WinGRASS builds were broken (since May 2019) I
> > have some good news. I pushed yesterday locally built WinGRASS addons
> > for latest GRASS stable release 7.6.1 (64bit only [1]). So the most
> > urgent issue is solved somehow. Meanwhile I will be working on
> > recovering whole daily builds infrastructure. I will keep you updated.
>
> thanks for your winGRASS update work.
>
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> 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] (no subject)

[Sajid Pareeth]

Dear Shivam rai

There is no module called "d.tile", So it won't work.
What did you try with d.what.rast? Please post the command you tried !!
Regards

Sajid


On Thu, Dec 6, 2018 at 9:38 AM SHIVAM RAI  wrote:

> Hi,
> please don't delay.
> please answer the question that i have asked recently
> when executing "d.tile" and "d.what.rast" in console or cmd
> error: not  implemented in the wxGUI. try to add as a layer command.
> thanks
> ___
> 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] r.tile behaviour

[Sajid Pareeth]

Thank you both,

I got confused between first and last row tiles and the middle ones.
The overlap is fine on first and last row tiles.

Regards

Sajid

On Wed, Nov 7, 2018 at 7:37 PM Markus Metz 
wrote:

>
>
> On Wed, Nov 7, 2018 at 7:06 PM Veronica Andreo 
> wrote:
> >
> > Hi Sajid,
> >
> > I have never used r.tile before, but checking the code [1], it
> multiplies the overlap by 2, so there's why. Now guesstimating, if I set an
> overlap of 50, I would expect to have that overlap on both sides of the
> desired size of the tiles, so maybe that's why it is doubled ?
>
> In princliple that's correct, but not for the first and last row and
> column of tiles.
>
> In Sajid's example, the first and last row of tiles should have 725 rows
> (675 + 50) and all other tiles 775 rows (675 + 2 * 50). Accordingly for
> columns.
>
> That should be relatively easy to fix.
>
> Markus M
> >
> > HTH,
> > Vero
> >
> > [1]
> https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.tile/main.c#L101
> >
> > El mié., 7 nov. 2018 a las 15:08, Sajid Pareeth ()
> escribió:
> >>
> >> Hi all
> >>
> >> The r.tile module don't have overwrite flag, so if we re run the module
> with different parameters but with same output prefix name, then it will
> rewrite output with out warning.
> >> Is this intentional?
> >>
> >> Another point is, if I use overlap option it adds double the overlap
> cells to the output maps.
> >>
> >> For example in the NC location:
> >>>
> >>> r.info elevation -g
> >>
> >> rows=1350
> >> cols=1500
> >>
> >>> r.tile input=elevation output=elev_tile width=750 height=675
> >>> r.info elev_tile-001-001 -g
> >>
> >> rows=675
> >> cols=750
> >>
> >>> r.tile input=elevation output=elev_tile width=750 height=675 overlap=50
> >>> r.info elev_tile-001-001 -g
> >>
> >> rows=775 (+ 100)
> >> cols=850 (+ 100)
> >>
> >> In the last case the rows and cols should be 725 and 800 respectively,
> as it should add 50 cells as overlap to each tile? Or am I missing
> something?
> >>
> >> Regards
> >>
> >> Sajid
> >>
> >>
> >>
> >>
> >> ___
> >> 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
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.tile behaviour

[Sajid Pareeth]

Hi all

The r.tile module don't have overwrite flag, so if we re run the module
with different parameters but with same output prefix name, then it will
rewrite output with out warning.
Is this intentional?

Another point is, if I use overlap option it adds double the overlap cells
to the output maps.

For example in the NC location:

> r.info elevation -g
>
rows=1350
cols=1500

r.tile input=elevation output=elev_tile width=750 height=675
> r.info elev_tile-001-001 -g
>
rows=675
cols=750

r.tile input=elevation output=elev_tile width=750 height=675 overlap=50
> r.info elev_tile-001-001 -g

rows=775 (+ 100)
cols=850 (+ 100)

In the last case the rows and cols should be 725 and 800 respectively, as
it should add 50 cells as overlap to each tile? Or am I missing something?

Regards

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

Re: [GRASS-user] in need of Help

[Sajid Pareeth]

 Hi

Have you followed the tutorial available in this link prepared by Yann:
https://trac.osgeo.org/grass/browser/grass-promo/tutorials/grass_landsat_ETa
Also attached the pdf with this email.

It gives you an overall picture on how to use ET modules in GRASS GIS to
estimate actual ET.

Please give it a try and ask questions you may have.

There is an external Python script using GRASS lib, applying SEBAL on
Landsat data (never tried !!)
https://github.com/wwolff7/SEBAL_GRASS/blob/master/Sebal70.py

Regards
Sajid

On Tue, May 29, 2018 at 8:08 AM, hindo kush  wrote:

> Dear Helmut,
>
> i wana use the i.evapo.mh. and i.eb.eta or actual evapotranspiration
> module.
>
> Regards
>
>
>
> On Tue, May 29, 2018 at 8:32 AM, Helmut Kudrnovsky  wrote:
>
>> >The version i use currently is winGRASS 7.4. 0
>>
>> I asked for the module you want to use?
>>
>>
>>
>> -
>> best regards
>> Helmut
>> --
>> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
>> ___
>> 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
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr with Sentinel2

[Sajid Pareeth]

>
>
>
> On Thu, Dec 21, 2017 at 8:18 AM, Stefan Blumentrath <
> stefan.blumentr...@nina.no> wrote:
> >
> > Thanks Markus,
> >
> > As a next try I updated my gcc and g++ to 5.4.1 (on Ubuntu 14.04) and I
> applied your compiler flags, Markus.
> > Unfortunately, I still get only NULL cells in i.atcorr output…
> >
> > Will try to test more recent OS (Ubuntu 16) and maybe get a Fedora live
> system…
>
> i.atcorr should produce identical results on all supported systems. These
> differences are a mystery to me. For a start, compiler warnings could be
> solved and the valgrind warnings need to be checked.
>


To confirm, I am getting identical results in Ubuntu (both grass74 and 75)
as obtained in Fedora, with the same command Markus used.


*i.atcorr in=s2a_b8 range=1,28001 elevation=dem parameters=p6s.txt
out=s2a_b8_corr_g75*
*r.info  -r s2a_b8_corr_g75*
*min=0.003232*
*max=255*

*r.info  -r s2a_b8_corr_g74*
*min=0.003232*
*max=255*

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

Re: [GRASS-user] i.atcorr with Sentinel2

[Sajid Pareeth]

Hi Stefan

I tested your data in different versions.

Now, I compiled both GRASS 7.4 and 7.5 on Ubuntu 14.04 (gcc (Ubuntu
> 4.8.4-2ubuntu1~14.04.1) 4.8.4).
>

I get the same output (with numbers) for both compiled 7.4 and 7.5
in Ubuntu 16.04.3 LTS (gcc version 5.4.0 20160609 (Ubuntu
5.4.0-6ubuntu1~16.04.5)).


> To test a completely different system I also tested GRASS 7.5 (daily) and
> 7.4.0RC1 on OSGeo4W. Both fail as well.
>

I tried both daily and 7.4.0RC1 in windows 7, installed using OSGeo4W.
Here I get different results:

With GRASS GIS 7.5.svn (r71953), I get NULL output.

With GRASS GIS 7.4 RC1 (r71752), the i.atcorr process crashed with
following error:


>
>
>
> *GRASS 7.4.svn> i.atcorr -r input=s2a_b8 range=0,1 elevation=dem
> parameters=p6s.txt output=s2a_b8_corr_2 rescale=0,1WARNING: Request for
> unsupported compressorWARNING: Request for unsupported
> compressorAtmospheric correction...ERROR: Request for unsupported
> compressor*




> Sajid, which code revision are you using? Maybe a change somewhere else
> interferes?
>

In Ubuntu, I used r71952 (latest trunk).

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

Re: [GRASS-user] i.atcorr with Sentinel2

[Sajid Pareeth]

>
> g.version
> GRASS 7.2.2 (2017)
> GRASS 7.2.2 (SB):~/work/tmp/Blumentrath > cat p6s.txt
> 25# originally 25
>
> 9 5 10.6728 10.73413 59.90647
> 4
> 3
> 50
> -0.055
> -1000
> 165# original 173
> GRASS 7.2.2 (SB):~/work/tmp/Blumentrath > i.atcorr --v -r --o
> input=S2A.B08 elev=dem output=test_atcorr param=p6s.txt range=1,1
> rescale=1,1
> ERROR: Unsupported/unreadable format in control file (found igeom=25)
>

I think support to sentinel 2A is not yet backported to GRASS 72 stable
version.
https://grass.osgeo.org/grass72/manuals/i.atcorr.html

https://grass.osgeo.org/grass73/manuals/i.atcorr.html
Markus, can you confirm?

Best
Sajid
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr with Sentinel2

[Sajid Pareeth]

Hi

> but I get only NULL values also for those data and settings and when
> running i.atcorr in GRASS 7.4.0RC1.
>

That's strange !!!

> I stumbled over the following line in i.atcorr output (see full verbose
> output below):
>
> *view zenith angle: 0.00 deg  view azimuthal angle: 0.00
> deg   *
>
> Do you get that as well?
>

Yes, I am getting the same atmospheric model description.


> Sajid, can you send me the output of your
>
> grass75 --config
>
Here it is:

x86_64-pc-linux-gnu
> ./configure  --enable-largefile=yes --with-nls --with-cxx --with-readline
> --with-proj-share=/usr/share/proj --with-geos=/usr/bin/geos-config
> --with-python=yes --with-wxwidgets --with-cairo --with-fftw
> --with-opengl-libs=/usr/include/GL --with-freetype=yes
> --with-freetype-includes=/usr/include/freetype2/ --with-postgresql=yes
> --with-postgres-includes=/usr/include/postgresql --with-sqlite=yes
> --with-mysql=yes --with-mysql-includes=/usr/include/mysql
> gcc
> /usr/local/src/grass7_trunk/dist.x86_64-pc-linux-gnu
> 70829
> 7.5.svn
>

Hope it helps.

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

Re: [GRASS-user] i.atcorr with Sentinel2

[Sajid Pareeth]

Hi


>>
>> Would you be able to provide me with the 1000 X 1000 clip of your data,
>> so I can check if it is my installation?
>>
>
here it is, including the dem and parameters text file: (epsg:32632)

http://scientificpubs.com/data_share/sen2data.tar.gz


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

Re: [GRASS-user] i.atcorr with Sentinel2

[Sajid Pareeth]

Hi Stefan

I tried with your data, and it works for me.

Check the output here:
http://www.scientificpubs.com/data_share/s2a_b8_corr.tif.tar.gz

I am running it in Ubuntu 16.04, and GRASS latest trunk version, inside a
EPSG:25833 location.

I will send you the other clipped data from my study area, shortly.

Regards

Sajid


On Tue, Dec 19, 2017 at 3:31 PM, Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Forgot to mention, my test data is tiny (< 3MB)…
>
>
>
> *From:* grass-user [mailto:grass-user-boun...@lists.osgeo.org] *On Behalf
> Of *Stefan Blumentrath
> *Sent:* tirsdag 19. desember 2017 15.24
> *To:* Sajid Pareeth <spare...@gmail.com>
> *Cc:* GRASS user list <grass-user@lists.osgeo.org>
>
> *Subject:* Re: [GRASS-user] i.atcorr with Sentinel2
>
>
>
> Dear Sajid,
>
>
>
> Thanks so much for your reply and confirming that the module works in
> principle!
>
>
>
> Would you be able to provide me with the 1000 X 1000 clip of your data, so
> I can check if it is my installation?
>
>
>
> I tried also two different boxes and GRASS versions (Ubunut 14.04 with
> GRASS 7.3 and 7.4 compiled from source and Ubuntu 16.04 with GRASS 7.4 from
> UbuntuGIS) and none of it worked.
>
> Also, altering the terrain model from floating point with negative values
> to integer without negative values did not change a thing…
>
> I still get only NULL pixels…
>
>
>
> In case someone would be willing to test my data (which I would be very
> grateful for), you can get it directly here:
>
> dem: http://www.filedropper.com/dem_1
>
> S2 band 8: http://www.filedropper.com/s2aoperprdmsil1cpdmc20160907t0
> 44118r008v20160905t10402220160905t104245b08
>
> 62 params: http://www.filedropper.com/p6s
>
> I also have it on FTP and can share username and password offlist…
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* Sajid Pareeth [mailto:spare...@gmail.com <spare...@gmail.com>]
> *Sent:* tirsdag 19. desember 2017 12.51
> *To:* Stefan Blumentrath <stefan.blumentr...@nina.no>
> *Cc:* Moritz Lennert <mlenn...@club.worldonline.be>; Žofie Cimburová <
> zoficimbur...@gmail.com>; GRASS user list <grass-user@lists.osgeo.org>
> *Subject:* Re: [GRASS-user] i.atcorr with Sentinel2
>
>
>
> To add, I have used the input as such with out applying the quantification
> value.
>
>
>
> >>
> >>  
> >>  6s file:
> >>  25- geometrical conditions=Sentinel-2A
> >>  9 5 10.6728 10.73413 59.90647- month day hh.ddd longitude
> latitude
> >>  4 - atmospheric model=subarctic summer
> >>  3- aerosol model=urban
> >>  50- visibility [km] (aerosol model concentration) (this is
> >>  estimated, I also tried with AOD specified)
> >>  -0.055- mean target elevation above sea level [km]
> >>  -1000- sensor height
> >>  166- Sentinel2A Blue band B2 (440nm - 535nm)
>
>
>
> Just noticed, the last parameter should be 167 for Sentinel B2.
>
>
>
> Sajid
>
>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr with Sentinel2

[Sajid Pareeth]

To add, I have used the input as such with out applying the quantification
value.

>>
>> >>  
>> >>  6s file:
>> >>  25- geometrical conditions=Sentinel-2A
>> >>  9 5 10.6728 10.73413 59.90647- month day hh.ddd longitude
>> latitude
>> >>  4 - atmospheric model=subarctic summer
>> >>  3- aerosol model=urban
>> >>  50- visibility [km] (aerosol model concentration) (this is
>> >>  estimated, I also tried with AOD specified)
>> >>  -0.055- mean target elevation above sea level [km]
>> >>  -1000- sensor height
>> >>  166- Sentinel2A Blue band B2 (440nm - 535nm)
>>
>
Just noticed, the last parameter should be 167 for Sentinel B2.

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

Re: [GRASS-user] i.atcorr with Sentinel2

[Sajid Pareeth]

Dear Stefan

I have applied i.atcorr to many S2A scenes last year and it worked. Today I
rechecked them again, and it worked on a older svn version (7.3) and also
on the latest trunk version.

All the steps I have taken is similar to what you have done, so I dont
really know whats going wrong with you.

Here is the command I used:

i.atcorr -r input="S2A_OPER_MSI_L1C_TL_MTI_20151012T101024457Z_T32TPR_B02"
> range=0,1 elevation="eudem_euregio_utm32_10m"
> parameters="S2_B02_T32TPR.txt"
> output="S2A_OPER_MSI_L1C_TL_MTI_20151012T101024457Z_T32TPR_02_6S"
> rescale=0,1
>


S2_B02_T32TPR.txt:
[image: Inline image 1]


The AOD value is coming from the output of Sen2cor (It was a trial approach
!). I tried with a visibility value of 15 and it works.

And the ouput of r.univar is:

[image: Inline image 2]


I also tried it on a smaller clip (1000 X 1000), and it is giving some
output.

Let me know if you need any more info.

Regards

Sajid


On Tue, Dec 19, 2017 at 11:33 AM, Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hi again,
>
> Even with constant spectral conditions and values for filter function from
> Sentinel-2, all combinations of input band ranges result in empty maps.
> Constant spectral conditions and values for filter function from  Landsat7
> however, give results in the expected scale (0-255) regardless input image
> and value ranges...
>
> Shall I open a ticket?
>
> Any idea/chance to get this new feature in G7.4 to work...?
>
> Any pointer/help would be very much appreciated!
>
> Cheers
> Stefan
>
> -Original Message-
> From: Stefan Blumentrath
> Sent: tirsdag 19. desember 2017 10.56
> To: Stefan Blumentrath ; Moritz Lennert <
> mlenn...@club.worldonline.be>; Žofie Cimburová 
> Cc: GRASS user list 
> Subject: RE: [GRASS-user] i.atcorr with Sentinel2
>
> Hi again,
>
> Still trying to track down the issue...
> I now ran i.atcorr with constant spectral condition and manually defined
> "wl inf" and "wl sup".
>
> First I got those values for Sentinel-2 band 2:
> *spectral condition
>  *
> *--
>  *
> *sentinel2a blue b2
>  *
> *value of filter function :
>  *
> * wl inf=0.300 mic   wl sup=2.600 mic
> *
>
> Then for Landsat 7 band 4 (that was known to give results):
> *spectral condition
>  *
> *--
>  *
> *etm+ 4
>  *
> *value of filter function :
>  *
> * wl inf=0.740 mic   wl sup=0.913 mic
> *
>
>
> If I then feed those values into a filter function for constant spectral
> conditions, and again the Sentinel-2 values:
> *spectral condition
>  *
> *--
>  *
> *constant
>  *
> *value of filter function :
>  *
> * wl inf=0.300 mic   wl sup=2.600 mic
> *
> lead to empty maps, while Landsat7 values:
> *spectral condition
>  *
> *--
>  *
> *constant
>  *
> *value of filter function :
>  *
> * wl inf=0.740 mic   wl sup=0.913 mic
> *
> work fine (with all other settings being equal).
>
> That makes me suspect that the values of the Sentinel-2 filter function
> are actually causing the issue here...
> I am currently testing all thinkable combinations of input band ranges to
> see if any of them works with wl inf=0.300 mic and wl sup=2.600 mic and
> will report back from that exercise.
>
> Meanwhile, can anyone confirm that i.atcorr in GRASS 7.4.0RC1 actually
> works with Sentinel-2 data?
>
> Cheers
> Stefan
>
>
>
> -Original Message-
> From: grass-user [mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of
> Stefan Blumentrath
> Sent: tirsdag 19. desember 2017 08.45
> To: Moritz Lennert ; Žofie Cimburová <
> zoficimbur...@gmail.com>
> Cc: GRASS user list 
> Subject: Re: [GRASS-user] i.atcorr with Sentinel2
>
> Hi again,
>
> A little update on the problem:
> Now I ran i.atcorr with all possible band values for Sentinel-2 in the 6s
> parameters (166-178) with input maps ranges scaled to 0-1, 0-255, 0-1
> All runs resulted in completely empty maps!
> Any ideas?
>
> Thanks for helping in advance!
>
> Kind regards,
> Stefan
>
> -Original Message-
> From: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
> Sent: mandag 18. desember 2017 16.58
> To: Stefan Blumentrath ; Žofie Cimburová <
> zoficimbur...@gmail.com>
> Cc: GRASS user list 
> Subject: Re: [GRASS-user] i.atcorr with Sentinel2
>
> On 18/12/17 16:35, Stefan Blumentrath wrote:
> > 

Re: [GRASS-user] imagery data: geometry shift validation

[Sajid Pareeth]

Hi Martin

thanks, very interesting! BTW, is the bash script somewhere accessible
> as a plain text file (mdpi offers only images :-(, eg. [1])?
>

Attached  those scripts given in the paper.
I haven't provided them in any public repo yet.

regards

Sajid


AppendixA.py
Description: Binary data


AppendixB.sh
Description: Bourne shell script
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] imagery data: geometry shift validation

[Sajid Pareeth]

Hi Martin

We did similar work to correct the geometry shift of time series of AVHRR
data. Entire workflow was developed in GRASS GIS except for the homologous
point extraction, for which we used SIFT algorithm implemented in Orfeo
Toolbox.

You can find the details in this paper [1] including the scripts.

[1] http://www.mdpi.com/2072-4292/8/3/169/htm

regards

Sajid


On Sun, Dec 3, 2017 at 7:36 PM, Martin Landa  wrote:

> Hi,
>
> one colleague of mine was asking me about possibilities in GRASS how
> to validate geometry shift in imagery data similar to [1]. I would
> appreciate any tips where to start, thanks! Martin
>
> [1] https://geoacca.enveo.at/about/
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> 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] GRASS GIS and alternative command line terminals in Windows

[Sajid Pareeth]

Hi again


> >
> > Standalone winGRASS
>
> would you mind to open a ticket where we list such differences between
> standalone/OSGeo4W, between trunk and stable winGRASS?
>

Yes, those msys tools are not packaged with standalone winGRASS.

Do you think it is a packaging issue or not supposed to be included??

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

Re: [GRASS-user] GRASS GIS and alternative command line terminals in Windows

[Sajid Pareeth]

Dear Helmut

Thank you for the detailed reply.

It really helped and finally I am able to run the unix based
commands/scripts in GRASS in windows.

So as you said, the key is to install GRASS from OSgeo4W installer, install
msys too along with GRASS.
The best part is bash.exe in msys/bin, which mimic the unix behavior very
well :)


> and furthermore, since win 10 there is also linux for windows [3]  ;-)
>

Yes I have tried this and it works really well. As I said we are forced to
work in Windows 7 with the students.

Thanks again

Regards

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

Re: [GRASS-user] GRASS GIS and alternative command line terminals in Windows

[Sajid Pareeth]

Dear Moritz


> Can't this be configured with the environment variable GRASS_SH ?


I tried it, but GRASS crashes with warning about unsupported shell, and
"LOCATION_NAME  variable not set" error. I think it require more settings
than just the GRASS_SH variable.

Regards

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

Re: [GRASS-user] GRASS GIS and alternative command line terminals in Windows

[Sajid Pareeth]

> OSGeo4W-winGRASS or standalone winGRASS? maybe something with packaging?
>

Standalone winGRASS
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS and alternative command line terminals in Windows

[Sajid Pareeth]

Dear Helmut


> I use this bundled unix tools here all the time in winGRASS. sometime you
> can the use the windows equivalennt of these tools.
>

Now I see these tools with the daily build version of GRASS GIS 7.5.svn.
Thanks for the tip.

Though these are not available with the current stable version 7.2.2. Any
reason why these are not bundled with the stable version?

Regards

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

Re: [GRASS-user] GRASS GIS and alternative command line terminals in Windows

[Sajid Pareeth]

On Thu, 23 Nov 2017 at 18:06, Helmut Kudrnovsky  wrote:

>  >>   I use this bundled unix tools here all the time in winGRASS. sometime
> you
>  >>   can the use the windows equivalennt of these tools.
> >
> >
> >Did you installed these bundled unix tools separately?
>
> no, these tools are bundled with winGRASS.


Oh sorry, I got confused. I understand, let me check.

>
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> 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] GRASS GIS and alternative command line terminals in Windows

[Sajid Pareeth]

Hi Helmut

Thank you for your detailed answer.
That's interesting, I know significant improvement in this regard with
Windows 10, but was not aware of this in Win 7.

The issue is none of these commands are available with the Windows 7 we
have (laptops are provided pre-installed with some customized windows 7 by
our IT, both to staff and students.).
The system configuration says, Windows 7 Enterprise, Service pack 1.

Do we have to enable these features , or by default available?


I use this bundled unix tools here all the time in winGRASS. sometime you
> can the use the windows equivalennt of these tools.
>

Did you installed these bundled unix tools separately?

Regards

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

Re: [GRASS-user] GRASS GIS and alternative command line terminals in Windows

[Sajid Pareeth]

On Thu, Nov 23, 2017 at 4:22 PM, Helmut Kudrnovsky  wrote:

> >But for command line, Is there anything better than cmd.exe?
>
> what is missing in MS cmd?
>

It is not user friendly compared to UNIX shell. For example copy and paste
is complicated there or tab completion. What I am looking for is a way to
use GRASS GIS in UNIX like third party terminals in windows, so that I can
use basic UNIX based commands.

Regards
Sajid
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] GRASS GIS and alternative command line terminals in Windows

[Sajid Pareeth]

Hi all

I need to teach students GRASS GIS in Windows 7. Of course the GUI part
works and all good.

But for command line, Is there anything better than cmd.exe?

There are many Console emulators available now a days, like Cmder (
http://cmder.net/)  and ConEmu (https://conemu.github.io/) in windows which
are rich in features. GRASS GIS works in those, but wont inherit the
features of those terminals as it opens with cmd.exe as shell.

Is there any way to get GRASS GIS work with those features of the terminals
too?

I see in the startup script that cygwin is still given as an optional
shell. I have never used it. How easy is to setup grass 7 with cygwin
considering that students also have to follow it?

Thanks in advance for any pointers.

Regards

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

Re: [GRASS-user] Color equalization after patching/mosaicking the satellite data from multiple scenes

[Sajid Pareeth]

Hi Nikos,

Thank you for the reply.

some normalisation, before patching, is what "needs" to be done, I think.
> Relative
> normalisation here (either for images of different dates over the same
> area, or neighbouring images of the same date).
>

Yes I also agree with that, I tried doing histogram matching before running
r.patch, though I am not sure if it is right way. Any idea on how the
change in values due to matching will affect further processing?

>
> I never finished implementing some very simple process as described in
> user manual(s) for QuickBird2 imagery, if I remember well.
>
> I have a draft module which I named i.radio.balance. In short:  the
> major difference between two scenes of the same area is the solar
> geometry.  This difference can be minimized by correcting imagery for
> Earth-sun distance and solar zenith angle.


> I can send you off-list, if you want, the on-going script (incomplete, yet
> well
> documented I believe it to be).
>
> I would be happy to test your code and let you know the results. Let me
know.


Regards

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

Re: [GRASS-user] Extracting vegetation phenology from Landsat-based time series

[Sajid Pareeth]

Thanks Markus,

Will try it soon.

Sajid

On Mon, Nov 28, 2016 at 9:03 AM, Markus Metz 
wrote:

> There is a new addon r.seasons which determines the number of seasons per
> pixel and extracts start and end dates for the given number of seasons from
> a time series.
>
> The module is designed for noisy input, e.g.
>
> time|value
> 0|0
> 1|0
> 2|1
> 3|0
> 4|1
> 5|1
> 6|1
> 7|0
> 8|1
> 9|1
> 10|1
> 11|1
> 12|0
> 13|0
>
> with threshold 0.5 and minimum season length set to 3 would detect one
> season. Core season start is at 4, end at 10. Full season start is at 2,
> end at 10.
>
> Markus M
>
>
> On Wed, Nov 9, 2016 at 4:17 PM, Nikos Alexandris 
> wrote:
>
>> Nikos Alexandris:
>>
>> Is the number of cycles per year in the Wiki as well?  Going through,
> last time, I think I didn't grasp that.  Can you pin-point?  It's
> exactly what we need at the moment.
>

>> Veronica Andreo:
>>
>> Yes, maybe it is not well explained, but it is here:
 https://grasswiki.osgeo.org/wiki/Temporal_data_processing#Fi
 lling_and_reconstructing_time_series_data_with_gaps_-_HANTS

>>>
>> and also in the manual under "NOTES"
 https://grass.osgeo.org/grass70/manuals/addons/r.hants.html

>>>
>> The idea is, once you are happy with the result of hants, you ask for
 amplitude outputs and with those amplitude maps (you'll have one map per
 frequency) you run r.series method=max_raster. This will give you the
 most
 important frequency (according to amplitude value of that frequency) in
 each pixel. If the result is that the most important frequency is 0,
 then
 you have one cycle per year (that, if you use a base period of one year
 of
 course).

>>>
>> Hope it is clearer now :)

>>>
>> Nikos:
>>
>> Yes. It was even before -- just me read through quickly.
>>>
>>> r.hants is awesome!
>>>
>>> We have 24 Landsat 8 derived EVI2 maps (2 for each month) for one year.
>>> Clouds and Water surfaces removed. Another set of "relatively normalised
>>> images, using `i.histo.match` is also ready.  We really need to "fix"
>>> `i.histo.match` to crunch floats directly.  The resulting ranges worry
>>> me a bit -- I just followed the "old" way as discussed some years ago in
>>> a relevant thread (floats > integers > histo-matching > floats).
>>>
>>> Anyhow, I am testing the following:
>>>
>>> for NF in 4 5 6 7 8 ;do r.hants file=evi2_maps nf=$NF fet=0.05 dod=3
>>> base_period=24 suffix=_hants_nf_$NF amplitude=amplitude_hants_nf_$NF
>>> phase=phase_hants_nf_$NF ;done
>>>
>>> (thinking loudly... it would be super-nice to have `t.rast.hants`)
>>>
>>> Not sure about `dod`. Perhaps it should also follow a patten like 3 4 5
>>> 6 and 7 for the above?
>>>
>>> for NF in 5 6 7 8 ; do t.rast.series evi2_hants_nf_$NF method=max_raster
>>> output=dominant_frequencies_hants_nf_$NF --o
>>>
>>
>> Just in case, the above *should* read:
>>
>> for NF in 4 5 6 7 8 ;do r.series input=`g.list rast
>> pattern=amplitude*nf_${NF}* separator=comma` method=max_raster
>> output=dominant_frequencies_hants_nf_${NF} --o ;done
>>
>>
>> "Dominant" frequencies 0, 1, 2 and 3 appear to be within the areas
>>> of our interest (agricultural surfaces).  Very good.  And convincing.
>>> Yet I am learning to interpret this correctly. And the "phase" as well.
>>> Reminds math studies, years ago.
>>>
>>
>> It is a "good" thing to actually have similar dominant frequency "maps"
>> for all of the experimented Number of Frequencies.
>>
>> A confirmation would be reassuring.
>>
>> Thanks, Nikos
>>
>> [rest deleted]
>>
>> ___
>> 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] importing Mars DEM takes too long

[Sajid Pareeth]

Hi Anna

I am not sure if it is related, but I had similar issues with Sentinel JP2
files.
The solution was to use the ECW library to read the JP2 files instead of
JP2OpenJPEG/JPEG-2000 driver with OpenJPEG library.

I had to recompile gdal to add the ECW support.

## Add ECW support to GDAL
./configure --with-ecw=/usr/local
...
## To read a jp2 file using ecw plugin, switch off the other two drivers
export GDAL_SKIP=JP2OpenJPEG,JPEG2000


Ofcourse you have to install libecw before recompiling gdal.

Hope it helps.

Sajid



On Fri, Nov 18, 2016 at 10:08 PM, Anna Petrášová 
wrote:

> Hi,
>
> I was trying to import Mars DEM with r.in.gdal, and it takes forever
> to finish it (It showed 3% after 10 minutes). This is what gdalinfo
> says:
>
> > gdalinfo /tmp/ESP_035583_2060_RED.JP2
> Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
> Files: /tmp/ESP_035583_2060_RED.JP2
>/tmp/ESP_035583_2060_RED.JP2.aux.xml
> Size is 13094, 26340
> Coordinate System is:
> PROJCS["Equirectangular MARS",
> GEOGCS["GCS_MARS",
> DATUM["unknown",
> SPHEROID["unnamed",3392593.6110435,0]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433]],
> PROJECTION["Equirectangular"],
> PARAMETER["latitude_of_origin",25],
> PARAMETER["central_meridian",180],
> PARAMETER["standard_parallel_1",0],
> PARAMETER["false_easting",0],
> PARAMETER["false_northing",0],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]]]
> Origin = (3889293.250,1519463.750)
> Pixel Size = (0.500,-0.500)
> Corner Coordinates:
> Upper Left  ( 3889293.250, 1519463.750) (114d18'56.57"W, 50d39'41.21"N)
> Lower Left  ( 3889293.250, 1506293.750) (114d18'56.57"W, 50d26'20.49"N)
> Upper Right ( 3895840.250, 1519463.750) (114d12'18.52"W, 50d39'41.21"N)
> Lower Right ( 3895840.250, 1506293.750) (114d12'18.52"W, 50d26'20.49"N)
> Center  ( 3892566.750, 1512878.750) (114d15'37.55"W, 50d33' 0.85"N)
> Band 1 Block=1024x1024 Type=UInt16, ColorInterp=Undefined
>   Overviews: 6547x13170, 3273x6585, 1636x3292, 818x1646, 409x823,
> 204x411, 102x205
>   Overviews: arbitrary
>   Image Structure Metadata:
> NBITS=10
>
> GRASS location was created from this file:
>
> projection: 99 (Equirectangular MARS)
> zone:   0
> datum:  ** unknown (default: WGS84) **
> ellipsoid:  a=3392593.6110435 es=0
> north:  1519463.75
> south:  1506293.75
> west:   3889293.25
> east:   3895840.25
> nsres:  0.5
> ewres:  0.5
> rows:   26340
> cols:   13094
> cells:  344895960
>
> I tried to open it in QGIS and it appeared instantly. Then, I tried to
> export it from QGIS as Geotiff, but that took again very long (I
> didn't wait for it to finish). Running gdal_translate in command line
> can't finish either. I tried to debug r.in.gdal and it seems to be
> stuck on line 1103 in  GDALRasterIO call. Any advice? I can send the
> data privately.
>
> Thank you,
>
> Anna
> ___
> 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] Retaining the raster name, while exporting a group to other formats

[Sajid Pareeth]

Hi all

I am exporting a group of rasters to single stacked GTiff and ENVI format
files.

Here is my group:
i.group S2A_OPER_MSI_L1C_TL_MTI__20160810T122618_A005911_T30SWJ_10m -l
group 
references the following raster maps
-




-

I use the following export command:
r.out.gdal input=${BASE}_10m
output="${MYDATA}/${FOLDER}Barrax/20m/${BASE}_10m" format=ENVI


But the band names in the output ENVI or GTiff files are changed to "Band
1", "Band 2", "Band 3", "Band 4".

Is there any way to retain the original raster names for the individual
bands in the final stacked image?


Thanks in advance

Regards

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

Re: [GRASS-user] Extracting vegetation phenology from Landsat-based time series

[Sajid Pareeth]

Hi Markus

>
> [ currently trying to get a grip on MODIS version 6 time series ]
>
> In theory, extracting seasons such as cropping cycles is quite easy to
> implement: whenever a parameter in a time series is above/below a
> given threshold, start/stop the season. The question is how to store
> the results for multiple cropping cycles: a separate raster for each
> cycle and each start and stop date?
>
>
Yes, Output could be number of rasters equal to the maximum crop cycles
found in the scene. For those pixels with only one dominant cycle can be
represented with null() in the start and stop DOY maps of the next cycles.

I couldnt find any tool or study which captures multiple SOS and EOS in
case of crops. This would be really great to have. For example the
phenology parameters computed using R package greenbrown (
http://greenbrown.r-forge.r-project.org/phenology.php) considers only one
cycle (Not really for the crop phenology change). The method they use is
explained in page 5 of the associated paper:

Quoting the paper:

"In the third step, we used the smoothed and daily interpolated time series
to estimate start of growing season (SOS) and end of growing season (EOS)
by either using 50% thresholds on the seasonal greenness curve (approach
Trs) (White et al., 1997) or the derivative of the seasonal curve (approach
Deriv) (Tateishi & Ebata, 2004) (Data S1). Both approaches are based on the
definition of
*SOS and EOS as the mid-points of springgreenup and autumn senescence*,
respectively"

*Co-dominant water control on global inter-annual variability and trends in
land surface phenology and greenness*. Available from:
https://www.researchgate.net/publication/275050767_Co-dominant_water_control_on_global_inter-annual_variability_and_trends_in_land_surface_phenology_and_greenness
[accessed Oct 31, 2016]."
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Extracting vegetation phenology from Landsat-based time series

[Sajid Pareeth]

Hi all

Thanks MarkusM and Vero for the detailed follow up.

I also use r.hants a lot, and recently was trying to make use of amplitude
and phase outputs to infer some of the phenological parameters from the
annual cycle (still not sure, if it is a feasible approach).

But it seems inadequate when it comes to determine the *start and end time
of the growing season* in a year. I am looking for a solution along the
line as given in this paper:

https://www.researchgate.net/publication/238418948_Measuring_Phenological_Variability_From_Satellite_Imagery

I think once we have the start and end of growing season, rest of the
related parameters are easy to compute.

May be, there already exists a way in GRASS to do it using TGRASS !!.

Regards

Sajid







On Mon, Oct 31, 2016 at 10:40 AM, Veronica Andreo <veroand...@gmail.com>
wrote:

> Hello Nikos and all :)
>
> Don't know exactly which parameters you would like to extract from your
> time series, Nikos, but if helpful, what I did was to use a combination of
> r.hants and temporal modules to get some phenological indicators such as,
> number of cycles per year, yearly max and min values, dates of yearly max
> and min values, period that the variable was above a certain threshold, max
> rate of change (slope between every pair of maps and then aggregate per
> year with method=maximum). Some of those examples are in the wiki [0]. I
> believe that much more could be done with t.rast.algebra (it seems very
> powerfull), but I haven't yet tested enough.
>
> @Sajid, I agree it would be great to have such functionalities as
> "ready-to-use" module in GRASS, too. Therefore, we could avoid all the
> steps of moving a time series into r and then back again into GRASS [1]
>
> @MarkusM, local weighted regression sounds cool. +1 for that! It would be
> also very useful to have DINEOF [2] natively implemented. It is very nice
> when you want to keep the variation of the series instead of smoothing it
> out [1].
>
> Best,
> Vero
>
> [0] https://grasswiki.osgeo.org/wiki/Temporal_data_processing
> [1] https://grasswiki.osgeo.org/wiki/Temporal_data_processing/
> GRASS_R_raster_time_series_processing
> [2] http://modb.oce.ulg.ac.be/mediawiki/index.php/DINEOF
>
> 2016-10-31 10:06 GMT+01:00 Nikos Alexandris <n...@nikosalexandris.net>:
>
>> * Markus Metz <markus.metz.gisw...@gmail.com> [2016-10-30 22:30:46
>> +0100]:
>>
>>
>> On Sun, Oct 30, 2016 at 12:37 PM, Nikos Alexandris
>>> <n...@nikosalexandris.net> wrote:
>>>
>>>> Nikos Alexandris:
>>>>
>>>> is there a GRASS-native, of GRASS-friendly, practical tool or tutorial
>>>>>> or implementation of models, as in the TIMESAT [0] software or SPIRITS
>>>>>> [1], to exctract phenological parameters from NDVI (or, preferrably
>>>>>> EVI2) times series?
>>>>>>
>>>>>> Thank you, Nikos
>>>>>>
>>>>>> [0] http://web.nateko.lu.se/timesat/timesat.asp
>>>>>> [1] http://spirits.jrc.ec.europa.eu/download/software/
>>>>>>
>>>>>
>>>>
>>>> Sajid Pareeth:
>>>>
>>>>>
>>>>> I was also looking for the same functionalities very recently. Closest
>>>>> solution i could find is the 'greenbrown' package in R. Atleast we
>>>>> could
>>>>> make use of the GRASS-R interface to implement the work flow.
>>>>>
>>>>> Phenology function in this package has a good comprehensive list of
>>>>> functions as in timestat and spirits.
>>>>> See fig4 here: http://greenbrown.r-forge.r-project.org/phenology.php
>>>>>
>>>>> If you find anything else, please do post here.
>>>>>
>>>>> And above all, it would be really great to have these functionalities
>>>>> in
>>>>> GRASS ;)
>>>>>
>>>>
>>>>
>>>> Thank you Sajid.
>>>>
>>>> As I am not an expert in cropping cycles monitoring, I
>>>> naively thought there would be more or less some ready to use tools in
>>>> the GFOSS domain (TIMESAT requires Matlab, SPIRITS works only under
>>>> Windows).
>>>>
>>>> R is good, but there is still the back-and-forth step.  There is also a
>>>> "french" tool for QGIS:
>>>> https://plugins.qgis.org/plugins/VERSAO_VegaMonitor/
>>>>
>>>> At the moment I am looking for an over-simplified way to just
>>>> hint/classify surfaces on which multiple cropping cycles pe

Re: [GRASS-user] Extracting vegetation phenology from Landsat-based time series

[Sajid Pareeth]

Dear Nikos

I was also looking for the same functionalities very recently. Closest
solution i could find is the 'greenbrown' package in R. Atleast we could
make use of the GRASS-R interface to implement the work flow.

Phenology function in this package has a good comprehensive list of
functions as in timestat and spirits.
See fig4 here: http://greenbrown.r-forge.r-project.org/phenology.php

If you find anything else, please do post here.

And above all, it would be really great to have these functionalities in
GRASS ;)

Regards

Sajid



On Sat, Oct 29, 2016 at 2:58 PM, Nikos Alexandris 
wrote:

> Dear list,
>
> is there a GRASS-native, of GRASS-friendly, practical tool or tutorial
> or implementation of models, as in the TIMESAT [0] software or SPIRITS
> [1], to exctract phenological parameters from NDVI (or, preferrably
> EVI2) times series?
>
> Thank you, Nikos
>
> [0] http://web.nateko.lu.se/timesat/timesat.asp
> [1] http://spirits.jrc.ec.europa.eu/download/software/
> ___
> 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] Auto-detection of GCP for rectifying image

[Sajid Pareeth]

Hi Johannes


> However, as I want to automatize the step of rectifying/georeferencing I
>> am looking for a way to autodetect these six points in the image. I am
>> thinking of tools like pattern/face recognition that are able to
>> autodetect objects (e.g. eyes, points etc.) and extract their position
>> (coordinates) within that image. I assume these coordinates together
>> with their "true" position could then be used for rectifying the picture
>> using e.g. i.rectify.
>>
>> Has anyone done this or a similar exercise before and can recommend
>> tools and approaches to auto-detect GCP from an image?
>>
>
>
For a similar purpose, to automatize image to image registration, I have
used the library OTB toolbox(https://www.orfeo-toolbox.org/) along with
GRASS GIS.

OTB has a module called homologous point extraction which uses algorithms
like SIFT and SURF.
https://www.orfeo-toolbox.org//Applications/HomologousPointsExtraction.html
After getting the gcp's, I used grass plugin m.gcp.filter to filter out the
outliers, followed by i.rectify.

On a GRASS environment, following is what I used - representative code:

> #GCP extraction using OTBcli_homologous points
> otbcli_HomologousPointsExtraction -in1 input_b1.tif -band1 1 -in2
> reference_b1.tif -band2 1 -algorithm sift -mode full -out OUTB1.txt
> # Making the text file GRASS compatible
> awk '{$5="1\t"$5}1' ${MYTMPDIR}/OUTB1.txt > ${MYTMPDIR}/OUTB1.txt
> # importing the input TIFF files
> r.in.gdal input=${y}_b1.tif output=${i}_b1 memory=${MEMORY}

#Moving the POINTS file to the GRASS group folder
> mv ${MYTMPDIR}/OUTB1.txt ${GRASSLOC}/group/${i}/POINTS
> #GCP filtering
> m.gcp.filter group=${i} order=1 threshold=500 -b
> i.rectify -a group=${i} extension=_rectified order=1 method=nearest --o
>

In this paper (http://www.mdpi.com/2072-4292/8/3/169/htm) , the steps are
explained and main codes are provided in appendix.

Here is a good link on SIFT, I guess it is more apt for your case with
digital photographs. In the above case, we tried on satellite data.
http://www.aishack.in/tutorials/sift-scale-invariant-feature-transform-introduction/

Hope this helps!!

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

Re: [GRASS-user] create location from CLI

[Sajid Pareeth]

Hi

>
>I'm trying to understand the simplest way in GRASS7 to create a
> location from the command line without using a georeferenced file.  So far,
> it appears to be
>
> % grass70 -c newLocation
>

Did you try parsing the EPSG code of the location you want to create?

For example:

grass71 -c epsg:3035 /home/user/grassdata/mynewlocation

The above command will create a new location in epsg 3035 projection.
You can find some details here:
https://grasswiki.osgeo.org/wiki/GRASS_Location_Wizard#GRASS_GIS_7:_Creating_locations_from_command_line


Best

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

Re: [GRASS-user] new addon for multivariate surface interpolation from sparse points with smoothing

[Sajid Pareeth]

Hi Markus

Thank you for this excellent addon.

I was testing it with some trmm data, and getting this error with default
"thin" value of 1.5.

ERROR: knn: inserting duplicate

Then if I increase the thinning factor, it works, but the algorithm thinned
out quite a lot of points.

Any lead would be helpful, thanks

Regards

Sajid




On Thu, Aug 25, 2016 at 9:02 PM, Markus Metz 
wrote:

> The new addon v.surf.tps performs multivariate thin plate spline
> interpolation of sparse points with smoothing. If you ever wondered
> why worldclim data (http://worldclim.org) follow so nicely elevation,
> the reason is multivariate thin plate spline interpolation of
> meteorological station data with elevation as a covariate. The module
> can also be used for gap filling of remote sensing data, e.g. MODIS
> LST reconstruction of cloud-covered areas, after fine-tuning the
> module's parameters. The module works only with GRASS 7.2+.
>
> Markus M
> ___
> 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] use of g.list inside r.mapcalc expression

[Sajid Pareeth]

Hi Vero

If I got you right, may be this could be a better approach,
#Assuming you are using MOD13Q1 product, and for example maps from
MOD13Q1.A2015353.h18v05.006.2016007180711.hdf;

map=`g.list rast pat=MOD13*_EVI`
for tile in ${map}; do
## Put the common part (In this case - MOD13Q1.A2015353.h18v05) of the
map name into a variable.
i=`echo $map|cut -c1-23`
r.mapcalc --o expression="${map} = if(${i}_pixel_reliability` == 0,
${map}, null())"
done


Sajid


On Wed, Jun 15, 2016 at 2:58 PM, Veronica Andreo 
wrote:

> Hello everybody,
>
> Is it possible to use r.mapcalc with `g.list` as part of the
> expression??? Something like:
>
> tiles=(h11v11 h12v11 h12v12)
> for tile in ${tiles[*]}
> do
> r.mapcalc --o expression="`g.list rast pat=MOD13*$tile_EVI` =
> if(`g.list rast pat=MOD13*$tile_pixel_reliability` == 0, `g.list rast
> pat=MOD13*$tile_EVI`, null())"
> done
>
> it worked only once in a test case with one image per tile... when I
> tried to run it again for the whole set, i get parse error:
>
> syntax error, unexpected ';', expecting '('
> syntax error, unexpected ';', expecting ')'
> Parse error
> ERROR: parse error
>
> Which would be best practice in this case? Is this use even possible?
>
> I know I can register maps in temporal framework and use
> t.rast.mapcalc, but I want to keep year and doy in mapnames and
> neither t.rast.mapcalc nor t.rast.algebra have granularity suffix
> option yet (only numerical suffix).
>
> Ah, I use grass trunk (7.3) freshly updated to r68692.
>
> thanks much in advance!
>
> Vero
> ___
> 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] Fwd: i.atcorr: Returns empty raster

[Sajid Pareeth]

Missed the list
-- Forwarded message --
From: Abhishek Manandhar <abhishek.ad...@gmail.com>
Date: Thu, Mar 17, 2016 at 1:38 PM
Subject: Re: [GRASS-user] i.atcorr: Returns empty raster
To: Sajid Pareeth <spare...@gmail.com>


-I checked the region and it matches with the image's. I am totally
confused what exactly is making the problem. I got the Sentinel-2 Spectral
response curve from ESA, which I used to register new sensor. (If this
information might help)
-We can get quantification value from Level 1C product metadata. Besides
that, I have found many images with the mean values of whole scene above 12
bit range, generally snow covered areas. In the link below, the conversion
is explained where it says the default quantification value is 1000 . (
https://sentinel.esa.int/web/sentinel/technical-guides/sentinel-2-msi/level-1c/algorithm
)






On Thu, Mar 17, 2016 at 12:36 PM, Sajid Pareeth <spare...@gmail.com> wrote:

>
>
> On Thu, Mar 17, 2016 at 12:12 PM, Abhishek Manandhar <
> abhishek.ad...@gmail.com> wrote:
>
>> Hi,
>> Thanks for your reply.
>> -Empty raster file have NULL pixels.  But when I remove "-i" flag the
>> pixels are -nan. On both cases, the univar command returns nothing. Can you
>> assume, why it is happening?
>>
>
> Usually it happens when the region is not proper. Check your mapset
> projection and that of the data.
> Please post "g.region -p"
>
>
>> -Sentinel 2A data are captured in 12 bit but later converted to
>> reflectance (0-1) and is converted to integer with quantification value
>> 1 (which used to be 1000 before). So the value ranges from 0-1 at
>> current state.
>>
> I am not sure about this. I think quantification is done while converting
> from level 1C to level 2A  in their toolbox - SNAP. Do you have any source
> for this info?
>
> I have a similar sentinel band 2 (March) with data ranging from 0 to 22132
> but histogram shows the absurd high values are only single pixels and I
> dont know why they exists. 99 percent of the pixels are below 1500. If the
> quantification is done with 1, i would expect much higher values spread
> over my histogram.
>
> to check the histogram:
> d.mon wx0
> d.histogram S2AB02
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.spec.sam error

[Sajid Pareeth]

Hi Jaya

>
> Sorry to bother you again. But I was thinking of using Spectral Angle
> Mapper in RStudio's RSToolbox package as an alternative. So I followed the
> steps at the link
> https://grasswiki.osgeo.org/wiki/R_statistics/rgrass7#Using_RStudio_in_a_GRASS_GIS_session
> but am unable to run RStudio at the GRASS command prompt. The error is
> again * 'rstudio' is not recognized as an internal or external
> command,operable program or batch file *(attaching error below).
>

Please try by entering entire path in the GRASS session instead of
"rstudio.exe".

> C:\Program Files\RStudio\bin\rstudio.exe
>


Regards

-- 
Sajid Pareeth
https://it.linkedin.com/in/spareeth
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Need help in reprojecting raster images

[sajid pareeth]

Hi Uttam

If I understand you correctly you want to reproject a landsat image from
sinusoidal to laea projection!!
You dont have to manually set the bounding box while reprojecting a raster,
as GRASS will take care of it.

First you create a new location and mapset with desired output projection ,
which in this case is Lamberts Azimuthal Equal Area.
Then get into this mapset, use the following r.proj command.
r.proj location*=input_location* mapset=*input_mapset* input=*input_raster
name* output=
*output_raster*

More details here: https://grass.osgeo.org/grass70/manuals/r.proj.html

If you then need to set your working area to a particular bounding box, use
g.region

g.region raster=*output_raster*

regards

Sajid

On Tue, Sep 22, 2015 at 11:07 PM, Uttam Sinha 
wrote:

>
>
> Hi All,
>
> I have a set of Landsat images in Sinusoidal Projection, WGS84 Datum. I
> know the north, south, east and west extent of the boundary of the image.
>
> I want to reproject the image to Lamberts Azimuthal Equal Area, WGS84
> Datum. I do not know what will be the coordinates of the north, south, east
> and west bounds in this projection.
>
> 1.) How do I convert upper left coordinates and bottom right coordinates
> of Sinusoidal Projection to  Lamberts Azimuthal Equal Area to create a new
> destination Location?
>
> 2.) How do I reproject the images from Sinusoidal to Lamberts without
> georeferencing the image at source location (in sinusoidal projection)
>
> Appreciate any reply.
>
> Uttam.
>
> ___
> 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] Questions on TGRASS; t.rast.gapfill , GRASS 71

[sajid pareeth]

Hi Soeren

Thank you for the great addition; I tested with the test data and it works
as expected.
I will let you know if I find something unusual when I apply the command on
my data.


On the related topic, I have another query;
When I do t.rast.list with method=gran the where condition is not
working. With all the other methods it works.

Based on the same demo data;

 t.rast.list input=mapT3 column=name,start_time method=gran
 where=start_time  '2012-08-30 00:00:00'
 id|name|mapset|start_time|end_time|interval_length|distance_from_begin
 map1@ecmwf|map1|ecmwf|2012-08-20 00:00:00|2012-08-21 00:00:00|1.0|0.0
 gap_10_1@ecmwf|gap_10_1|ecmwf|2012-08-21 00:00:00|2012-08-22
 00:00:00|1.0|1.0
 map2@ecmwf|map2|ecmwf|2012-08-22 00:00:00|2012-08-23 00:00:00|1.0|2.0
 gap_11_1@ecmwf|gap_11_1|ecmwf|2012-08-23 00:00:00|2012-08-24
 00:00:00|1.0|3.0
 gap_11_2@ecmwf|gap_11_2|ecmwf|2012-08-24 00:00:00|2012-08-25
 00:00:00|1.0|4.0
 map3@ecmwf|map3|ecmwf|2012-08-25 00:00:00|2012-08-26 00:00:00|1.0|5.0
 gap_12_1@ecmwf|gap_12_1|ecmwf|2012-08-26 00:00:00|2012-08-27
 00:00:00|1.0|6.0
 gap_12_2@ecmwf|gap_12_2|ecmwf|2012-08-27 00:00:00|2012-08-28
 00:00:00|1.0|7.0
 gap_12_3@ecmwf|gap_12_3|ecmwf|2012-08-28 00:00:00|2012-08-29
 00:00:00|1.0|8.0
 map4@ecmwf|map4|ecmwf|2012-08-29 00:00:00|2012-08-30 00:00:00|1.0|9.0
 gap_13_1@ecmwf|gap_13_1|ecmwf|2012-08-30 00:00:00|2012-08-31
 00:00:00|1.0|10.0
 gap_13_2@ecmwf|gap_13_2|ecmwf|2012-08-31 00:00:00|2012-09-01
 00:00:00|1.0|11.0
 gap_13_3@ecmwf|gap_13_3|ecmwf|2012-09-01 00:00:00|2012-09-02
 00:00:00|1.0|12.0
 gap_13_4@ecmwf|gap_13_4|ecmwf|2012-09-02 00:00:00|2012-09-03
 00:00:00|1.0|13.0
 map5@ecmwf|map5|ecmwf|2012-09-03 00:00:00|2012-09-04 00:00:00|1.0|14.0


But when I change the method to any other type, say delta, it works

t.rast.list input=mapT3 column=name,start_time method=delta
 where=start_time  '2012-08-30 00:00:00'
 id|name|mapset|start_time|end_time|interval_length|distance_from_begin
 gap_13_2@ecmwf|gap_13_2|ecmwf|2012-08-31 00:00:00|2012-09-01
 00:00:00|1.0|0.0
 gap_13_3@ecmwf|gap_13_3|ecmwf|2012-09-01 00:00:00|2012-09-02
 00:00:00|1.0|1.0
 gap_13_4@ecmwf|gap_13_4|ecmwf|2012-09-02 00:00:00|2012-09-03
 00:00:00|1.0|2.0
 map5@ecmwf|map5|ecmwf|2012-09-03 00:00:00|2012-09-04 00:00:00|1.0|3.0


Regards

Sajid




On Mon, Feb 16, 2015 at 3:51 PM, Sören Gebbert soerengebb...@googlemail.com
 wrote:

 Hi Sajid,
 until today, t.rast.gapfill did not support interpolation by granularity.
 However, please try revision r64651 in grass7.1 trunk. This feature
 has now been implemented and should work as you would expect.
 Of course, heavily testing is still needed.

 I am still investigating the case when no gaps are found using the
 where condition.

 Best regards
 Soeren

 2015-02-05 19:23 GMT+01:00 sajid pareeth spare...@gmail.com:
  Hi
  I am trying to use the module t.rast.gapfill to fill the gaps in my
  temporal datasets. I have couple of doubts on getting my tasks done.
 
  I am using GRASS 71 svn, latest.
 
  ##Q1:
 
  In my temporal data , there are multiple continuous gaps. In this case,
 I am
  not getting the interpolated results. Please check the below work flow:
 
  r.mapcalc expr=map1 = 1 --o
  r.mapcalc expr=map2 = 3 --o
  r.mapcalc expr=map3 = 5 --o
  r.mapcalc expr=map4 = 7 --o
  r.mapcalc expr=map5 = 9 --o
  t.register type=raster maps=map1 start=2012-08-20 end=2012-08-21 --o
  t.register type=raster maps=map2 start=2012-08-22 end=2012-08-23 --o
  t.register type=raster maps=map3 start=2012-08-25 end=2012-08-26 --o
  t.register type=raster maps=map4 start=2012-08-29 end=2012-08-30 --o
  t.register type=raster maps=map5 start=2012-09-03 end=2012-09-04 --o
  t.create type=strds temporaltype=absolute output=mapT1 title=test for
 all
  the gaps filled together description=test for all the gaps filled
  together
  t.register type=raster input=mapT1 maps=map1,map2,map3,map4,map5 --o
  t.rast.list input=mapT1 columns=name,start_time,min,max
  t.rast.list input=mapT1 method=gran
  id|name|mapset|start_time|end_time|interval_length|distance_from_begin
  map1@testtgrass|map1|testtgrass|2012-08-20 00:00:00|2012-08-21
  00:00:00|1.0|0.0
  None|None|None|2012-08-21 00:00:00|2012-08-22 00:00:00|1.0|1.0
  map2@testtgrass|map2|testtgrass|2012-08-22 00:00:00|2012-08-23
  00:00:00|1.0|2.0
  None|None|None|2012-08-23 00:00:00|2012-08-24 00:00:00|1.0|3.0
  None|None|None|2012-08-24 00:00:00|2012-08-25 00:00:00|1.0|4.0
  map3@testtgrass|map3|testtgrass|2012-08-25 00:00:00|2012-08-26
  00:00:00|1.0|5.0
  None|None|None|2012-08-26 00:00:00|2012-08-27 00:00:00|1.0|6.0
  None|None|None|2012-08-27 00:00:00|2012-08-28 00:00:00|1.0|7.0
  None|None|None|2012-08-28 00:00:00|2012-08-29 00:00:00|1.0|8.0
  map4@testtgrass|map4|testtgrass|2012-08-29 00:00:00|2012-08-30
  00:00:00|1.0|9.0
  None|None|None|2012-08-30 00:00:00|2012-08-31 00:00:00|1.0|10.0
  None|None|None|2012-08-31 00:00:00|2012-09-01 00:00:00|1.0|11.0
  None|None|None|2012-09-01 00:00:00|2012-09-02 00:00:00|1.0|12.0
  None|None|None

[GRASS-user] Questions on TGRASS; t.rast.gapfill , GRASS 71

[sajid pareeth]

Hi
I am trying to use the module t.rast.gapfill to fill the gaps in my
temporal datasets. I have couple of doubts on getting my tasks done.

I am using GRASS 71 svn, latest.

##Q1:

In my temporal data , there are multiple continuous gaps. In this case, I
am not getting the interpolated results. Please check the below work flow:














*r.mapcalc expr=map1 = 1 --or.mapcalc expr=map2 = 3 --or.mapcalc
expr=map3 = 5 --or.mapcalc expr=map4 = 7 --or.mapcalc expr=map5 = 9
--ot.register type=raster maps=map1 start=2012-08-20 end=2012-08-21
--ot.register type=raster maps=map2 start=2012-08-22 end=2012-08-23
--ot.register type=raster maps=map3 start=2012-08-25 end=2012-08-26
--ot.register type=raster maps=map4 start=2012-08-29 end=2012-08-30
--ot.register type=raster maps=map5 start=2012-09-03 end=2012-09-04
--ot.create type=strds temporaltype=absolute output=mapT1 title=test for
all the gaps filled together description=test for all the gaps filled
togethert.register type=raster input=mapT1 maps=map1,map2,map3,map4,map5
--ot.rast.list input=mapT1 columns=name,start_time,min,maxt.rast.list
input=mapT1 method=gran*
*id|name|mapset|start_time|end_time|interval_length|distance_from_begin*
*map1@testtgrass|map1|testtgrass|2012-08-20 00:00:00|2012-08-21
00:00:00|1.0|0.0*
*None|None|None|2012-08-21 00:00:00|2012-08-22 00:00:00|1.0|1.0*
*map2@testtgrass|map2|testtgrass|2012-08-22 00:00:00|2012-08-23
00:00:00|1.0|2.0*
*None|None|None|2012-08-23 00:00:00|2012-08-24 00:00:00|1.0|3.0*
*None|None|None|2012-08-24 00:00:00|2012-08-25 00:00:00|1.0|4.0*
*map3@testtgrass|map3|testtgrass|2012-08-25 00:00:00|2012-08-26
00:00:00|1.0|5.0*
*None|None|None|2012-08-26 00:00:00|2012-08-27 00:00:00|1.0|6.0*
*None|None|None|2012-08-27 00:00:00|2012-08-28 00:00:00|1.0|7.0*
*None|None|None|2012-08-28 00:00:00|2012-08-29 00:00:00|1.0|8.0*
*map4@testtgrass|map4|testtgrass|2012-08-29 00:00:00|2012-08-30
00:00:00|1.0|9.0*
*None|None|None|2012-08-30 00:00:00|2012-08-31 00:00:00|1.0|10.0*
*None|None|None|2012-08-31 00:00:00|2012-09-01 00:00:00|1.0|11.0*
*None|None|None|2012-09-01 00:00:00|2012-09-02 00:00:00|1.0|12.0*
*None|None|None|2012-09-02 00:00:00|2012-09-03 00:00:00|1.0|13.0*
*map5@testtgrass|map5|testtgrass|2012-09-03 00:00:00|2012-09-04
00:00:00|1.0|14.0*

# Doing the gapfill:

*t.rast.gapfill input=mapT1 base=gapt.rast.list input=mapT1 method=gran*
*id|name|mapset|start_time|end_time|interval_length|distance_from_begin*
*map1@testtgrass|map1|testtgrass|2012-08-20 00:00:00|2012-08-21
00:00:00|1.0|0.0*
*gap_10@testtgrass|gap_10|testtgrass|2012-08-21 00:00:00|2012-08-22
00:00:00|1.0|1.0*
*map2@testtgrass|map2|testtgrass|2012-08-22 00:00:00|2012-08-23
00:00:00|1.0|2.0*
*gap_11@testtgrass|gap_11|testtgrass|2012-08-23 00:00:00|2012-08-24
00:00:00|1.0|3.0*
*gap_11@testtgrass|gap_11|testtgrass|2012-08-24 00:00:00|2012-08-25
00:00:00|1.0|4.0*
*map3@testtgrass|map3|testtgrass|2012-08-25 00:00:00|2012-08-26
00:00:00|1.0|5.0*
*gap_12@testtgrass|gap_12|testtgrass|2012-08-26 00:00:00|2012-08-27
00:00:00|1.0|6.0*
*gap_12@testtgrass|gap_12|testtgrass|2012-08-27 00:00:00|2012-08-28
00:00:00|1.0|7.0*
*gap_12@testtgrass|gap_12|testtgrass|2012-08-28 00:00:00|2012-08-29
00:00:00|1.0|8.0*
*map4@testtgrass|map4|testtgrass|2012-08-29 00:00:00|2012-08-30
00:00:00|1.0|9.0*
*gap_13@testtgrass|gap_13|testtgrass|2012-08-30 00:00:00|2012-08-31
00:00:00|1.0|10.0*
*gap_13@testtgrass|gap_13|testtgrass|2012-08-31 00:00:00|2012-09-01
00:00:00|1.0|11.0*
*gap_13@testtgrass|gap_13|testtgrass|2012-09-01 00:00:00|2012-09-02
00:00:00|1.0|12.0*
*gap_13@testtgrass|gap_13|testtgrass|2012-09-02 00:00:00|2012-09-03
00:00:00|1.0|13.0*
*map5@testtgrass|map5|testtgrass|2012-09-03 00:00:00|2012-09-04
00:00:00|1.0|14.0*

For example; between *2012-08-29 and **2012-09-03 *there are 4 days of gap,
but the gap filling is providing the same image at all the 4 gaps. It seems
to be generating only one image between two valid temporal images, no
matter how long the gap is!!

So is the gap filling will work only for *one gap* between *2 valid
temporal images*?


###2.

When I try to do gap fill with the where condition, I am getting no
results in some cases.
For example when I try:

t.rast.gapfill input=mapT1 where=start_time = '2012-08-21 00:00:00'
base=gap
*No gaps found*

OR when I try;

*t.rast.gapfill input=mapT1 where=start_time  '2012-08-20 00:00:00'
base=gap*

It misses the first gap and fills the other gap, see below:

*t.rast.list input=mapT1 method=gran*
*id|name|mapset|start_time|end_time|interval_length|distance_from_begin*
*map1@testtgrass|map1|testtgrass|2012-08-20 00:00:00|2012-08-21
00:00:00|1.0|0.0*
*None|None|None|2012-08-21 00:00:00|2012-08-22 00:00:00|1.0|1.0*
*map2@testtgrass|map2|testtgrass|2012-08-22 00:00:00|2012-08-23
00:00:00|1.0|2.0*
*gap_8@testtgrass|gap_8|testtgrass|2012-08-23 00:00:00|2012-08-24
00:00:00|1.0|3.0*
*gap_8@testtgrass|gap_8|testtgrass|2012-08-24 00:00:00|2012-08-25
00:00:00|1.0|4.0*
*map3@testtgrass|map3|testtgrass|2012-08-25 00:00:00|2012-08-26