Re: [GRASS-user] v.generalize failing on some geoms

[Paolo Cavallini]

Thanks Markus for the hint.
Replies below.

Il 10/02/2018 22:53, Markus Metz ha scritto:
> This seems to be a reprojection problem.
> 
> If you reprojected the vector data in GRASS with v.in.ogr + v.proj, this
> is a problem of GRASS, granted that v.in.ogr did not complain about
> vector topology.
> 
> If you reprojected non-topological polygons, this is a common problem
> when reprojecting non-topological polygons. Please import these polygons
> first into GRASS, then reproject within GRASS and run v.generalize on
> the reprojected GRASS vector.

I'm not explicitly reprojecting it. I tried the command from within
QGIS>Processing. Here the relevant commands:

g.proj -c proj4="+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
+x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs"
v.in.ogr min_area=0.0001 snap=-1
input="/tmp/processing63c3c94ab569415fba39f41c12e3e48f"
layer=1518196447.565 output=tmp1518196448046 --overwrite -o
g.region n=5538851.39594 s=5150937.66442 e=1377191.37538 w=1004373.60434
res=100
v.generalize input="tmp1518196448046" method=douglas threshold="1000"
look_ahead="7" reduction="50" -l
output="output081005b4fafd473bbfa438a964de80f1" --overwrite

All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.generalize failing on some geoms

[Paolo Cavallini]

Il 09/02/2018 19:25, Markus Neteler ha scritto:
> On Fri, Feb 9, 2018 at 6:19 PM, Paolo Cavallini  wrote:
>> Hi all,
>> v.generalize is failing to simplify some of my geometries when in
>> EPSG:3857. Same geoms in EPSG:3003 were simplified correctly.
>> Incorrect borders were reported, unclear to me why.
> 
> Please let us know which GRASS GIS version you use.

7.4.0-1
thanks
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.generalize failing on some geoms

[Markus Metz]

On Fri, Feb 9, 2018 at 6:19 PM, Paolo Cavallini 
wrote:
>
> Hi all,
> v.generalize is failing to simplify some of my geometries when in
> EPSG:3857. Same geoms in EPSG:3003 were simplified correctly.
> Incorrect borders were reported, unclear to me why.
> All the best, and thanks for any hint.

This seems to be a reprojection problem.

If you reprojected the vector data in GRASS with v.in.ogr + v.proj, this is
a problem of GRASS, granted that v.in.ogr did not complain about vector
topology.

If you reprojected non-topological polygons, this is a common problem when
reprojecting non-topological polygons. Please import these polygons first
into GRASS, then reproject within GRASS and run v.generalize on the
reprojected GRASS vector.

HTH,

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

Re: [GRASS-user] i.atcorr range and rescale parameters for Sentinel 2 images

[Markus Metz]

On Sat, Feb 10, 2018 at 6:11 PM, roberta fagandini 
wrote:
>
> Hi Markus and Žofie,
>
> thank you for your hints!
>
> I tested i.atcorr with range=1,1 and rescale=1,1. In this way,
value 1 is assigned to all those pixels with reflectance greater than
1 in the not-corrected image band (I'm using a blue band with min=1 and
max= 21604). If I set range=1,21604 and rescale=1,1 in this case, the
output is an image with values ranging from 1 to 1 (because of the
rescale parameter) but all the pixels with reflectance > 1 in the
not-corrected image band have different values near 1 and
proportionally rescaled but not rigidly set to 1.

This is correct because some few pixels might have values > 1.
Rescaling the input with 1 means reflectance = pixel_value / 1,
i.e. values larger than 1 can occur which is correct. Internally, i.atcorr
produces values in the range [0, 1]. These values are rescaled with the
rescale option. If you use rescale=1,1, output values will be within
the range [1, 1], not exceeding this range. The correct range option
for i.atcorr with sentinel2 is 1,QUANTIFICATION_VALUE. As Zofie said, you
can set the rescale option to your needs.

Markus M

>
> Just to be clearer, here some examples querying some pixels of the images
:
>
> #B02_not_corrected (original blue band)
>
> px1_value: 21604
>
> px2_value: 17869
>
> px3_value: 18500
>
> #B02_range_rescale_1,1 (i.atcorr output with range=1,1 and
rescale=1,1)
>
> px1_value: 1
>
> px2_value: 1
>
> px3_value: 1
>
> #B02_range1,21604_rescale1,1 (i.atcorr output with range=1,21604 and
rescale=1,1)
>
> px1_value: 1
> px2_value: 9055
> px3_value: 9352
>
> Therefore the meaning of the range parameter is still not so clear to me.
Do you have other information about it and how it works?
>
> Thank you for your help!
> Roberta
> 
> Da: Žofie Cimburová 
> Inviato: venerdì 9 febbraio 2018 21:01
> A: roberta fagandini
> Cc: grass-user@lists.osgeo.org
> Oggetto: Re: [GRASS-user] i.atcorr range and rescale parameters for
Sentinel 2 images
>
> Hi Roberta,
>
> On Thu, Feb 8, 2018 at 8:54 PM, roberta fagandini <
robifagand...@hotmail.it> wrote:
>
> Hi all,
>
> I'm testing i.atcorr (grass 7.4) with Sentinel 2A images and i have some
trouble defining the right values for range and rescale parameters. I read
in other posts and lists that the suggested value for both range and
rescale is '0,1' while in other posts someone else suggests to use min
and max values (from r.info) for range and '1,1' or '0, 1' for
rescale.
>
> It's not clear to me the right meaning of these parameters and thus the
most correct values to be used.
>
> Can anyone better explain me the meaning of these two parameters?
>
>
> When I was running i.atcorr for Sentinel2 data, I used range=1,1
(i.e. the min/max theoretical values the input data can reach).
> As for rescale, this in my understanding just sets what the output range
of the reflectances will be. So you can use for example 1-255, 0-1,
1-1, whatever suits best to your further analysis. Relatively, the
result will be identical.
>
> Hope that helps a bit!
> Zofie
>
>
> I tested all the values suggested in other posts but I can't understand
what they exactly do.
>
>
> Thank you in advance for your help!
>
>
> Roberta
>
>
> ___
> 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] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Helmut Kudrnovsky]

>I have had a go with a Windows 10 (64 bit) machine with Grass version 7.0.5.

could you update to:

GRASS GIS 7.4.0 (current stable)
or
GRASS GIS 7.2.2 (old stable)

?

Grass version 7.0.5 is now really very old.



-
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

Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Dinarzarde Raheem]

Hi Paulo & Helmut,

I have had a go with a Windows 10 (64 bit) machine with Grass version 7.0.5. I 
copied the r.vif patch into the location 
C:\Users\YourUserName\AppData\Roaming\GRASS7\addons\scripts.

I get the following error message (I tried with the existing installation, 
uninstalled this and then tried again after re-installing grass). Would it make 
sense to wait until the server makes the new version of r.vif available through 
the g.extension option and try again? 

Dinarzarde

--error message---

(Sat Feb 10 21:46:00 2018)  
 
r.vif 
maps=2011_01_precip@climate_1970_2012,2011_02_precip@climate_1970_2012,2011_03_precip@climate_1970_2012,2011_04_precip@climate_1970_2012,2011_05_precip@climate_1970_2012,2011_06_precip@climate_1970_2012,2011_07_precip@climate_1970_2012,2011_08_precip@climate_1970_2012,2011_09_precip@climate_1970_2012,2011_10_precip@climate_1970_2012,2011_11_precip@climate_1970_2012,2011_12_precip@climate_1970_2012
 maxvif=10 file=C:\Users\draheem\Desktop\Jan 2017\results1.csv
Reading in the data ...
ERROR: Error reading reclass file for raster map 
<2011_01_precip@climate_1970_2012>
Traceback (most recent call last):
  File "C:\Users\draheem\AppData\Roaming\GRASS7\addons/scrip
ts/r.vif.py", line 361, in 
sys.exit(main(*gs.parser()))
  File "C:\Users\draheem\AppData\Roaming\GRASS7\addons/scrip
ts/r.vif.py", line 222, in main
p = ReadData(IPF, n)
  File "C:\Users\draheem\AppData\Roaming\GRASS7\addons/scrip
ts/r.vif.py", line 150, in ReadData
quiet=True, separator="comma").rstrip('\n'))
  File "C:\Program Files\GRASS GIS
7.0.5\etc\python\grass\script\core.py", line 446, in
read_command
return handle_errors(returncode, stdout, args, kwargs)
  File "C:\Program Files\GRASS GIS
7.0.5\etc\python\grass\script\core.py", line 313, in
handle_errors
returncode=returncode)
grass.exceptions.CalledModuleError: Module run None
['r.stats', '--q', '-1n', 'input=2011_01_precip@climate_1970
_2012,2011_02_precip@climate_1970_2012,2011_03_precip@climat
e_1970_2012,2011_04_precip@climate_1970_2012,2011_05_precip@
climate_1970_2012,2011_06_precip@climate_1970_2012,2011_07_p
recip@climate_1970_2012,2011_08_precip@climate_1970_2012,201
1_09_precip@climate_1970_2012,2011_10_precip@climate_1970_20
12,2011_11_precip@climate_1970_2012,2011_12_precip@climate_1
970_2012', 'separator=comma'] ended with error
Process ended with non-zero return code 1. See errors in the
(error) output.
(Sat Feb 10 21:46:02 2018) Command finished (1 sec) 




From: grass-user [grass-user-boun...@lists.osgeo.org] on behalf of Helmut 
Kudrnovsky [hel...@web.de]
Sent: 10 February 2018 16:27
To: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI 
installations (stand-alone v. 7.2.2 and 7.0.5)

>> Did you consider using cStringIO, if you need a file-object?
>>
>> That would avoid the temporary file and thus should be more efficient
>> too. See attached diff (it is probably not necessary to remove the last
>> line break though).
>Implemented your patch, thanks.  Dinarzarde, can you test?

tested here in OSGeo4W-winGRASS:

--
r.vif
maps=2011_01_precip,2011_02_precip,2011_03_precip,2011_04_precip,2011_05_precip,2011_06_precip,2011_07_precip,2011_08_precip,2011_09_precip,2011_10_precip,2011_11_precip,2011_12_precip
maxvif=10 file=D:\wd\rvif\test,csv
Reading in the data ...

Statistics are written to D:\wd\rvif\test,csv
VIF round 1
--
variablevif  sqrtvif
2011_01_precip 6.86 2.62
2011_02_precip 2.77 1.66
2011_03_precip33.17 5.76
2011_04_precip10.81 3.29
2011_05_precip 4.82 2.20
2011_06_precip 2.72 1.65
2011_07_precip 1.44 1.20
2011_08_precip10.04 3.17
2011_09_precip 3.16 1.78
2011_10_precip 2.50 1.58
2011_11_precip16.71 4.09
2011_12_precip50.81 7.13
VIF round 2
--
variablevif  sqrtvif
2011_01_precip 6.74 2.60
2011_02_precip 2.54 1.59
2011_03_precip18.23 4.27
2011_04_precip 8.99 3.00
2011_05_precip 4.72 2.17
2011_06_precip 2.69 1.64
2011_07_precip 1.40 1.18
2011_08_precip 9.11 3.02
2011_09_precip 3.08 1.75
2011_10_precip 2.42 1.55
2011_11_precip16.20 4.03
VIF round 3
--
variablevif  sqrtvif
2011_01_precip 5.63 2.37
2011_02_precip 2.14 1.46
2011_04_precip 5.71 2.39
2011_05_precip 4.63 2.15
2011_06_precip 2.52 1.59
2011_07_precip 1.33 1.15
2011_08_precip 9.01 3.00
2011_09_precip 3.08 1.75
2011_10_precip 2.14 1.46
2011_11_precip10.42 3.23
VIF round 4
--
variablevif  sqrtvif
2011_01_precip 5.53 

Re: [GRASS-user] i.atcorr range and rescale parameters for Sentinel 2 images

[roberta fagandini]

Hi Markus and Žofie,

thank you for your hints!

I tested i.atcorr with range=1,1 and rescale=1,1. In this way, value 
1 is assigned to all those pixels with reflectance greater than 1 in 
the not-corrected image band (I'm using a blue band with min=1 and max= 21604). 
If I set range=1,21604 and rescale=1,1 in this case, the output is an image 
with values ranging from 1 to 1 (because of the rescale parameter) but all 
the pixels with reflectance > 1 in the not-corrected image band have 
different values near 1 and proportionally rescaled but not rigidly set to 
1.

Just to be clearer, here some examples querying some pixels of the images :

#B02_not_corrected (original blue band)

px1_value: 21604

px2_value: 17869

px3_value: 18500

#B02_range_rescale_1,1 (i.atcorr output with range=1,1 and 
rescale=1,1)

px1_value: 1

px2_value: 1

px3_value: 1

#B02_range1,21604_rescale1,1 (i.atcorr output with range=1,21604 and 
rescale=1,1)

px1_value: 1
px2_value: 9055
px3_value: 9352

Therefore the meaning of the range parameter is still not so clear to me. Do 
you have other information about it and how it works?

Thank you for your help!
Roberta

Da: Žofie Cimburová 
Inviato: venerdì 9 febbraio 2018 21:01
A: roberta fagandini
Cc: grass-user@lists.osgeo.org
Oggetto: Re: [GRASS-user] i.atcorr range and rescale parameters for Sentinel 2 
images

Hi Roberta,

On Thu, Feb 8, 2018 at 8:54 PM, roberta fagandini 
> wrote:

Hi all,

I'm testing i.atcorr (grass 7.4) with Sentinel 2A images and i have some 
trouble defining the right values for range and rescale parameters. I read in 
other posts and lists that the suggested value for both range and rescale is 
'0,1' while in other posts someone else suggests to use min and max values 
(from r.info) for range and '1,1' or '0, 1' for rescale.

It's not clear to me the right meaning of these parameters and thus the most 
correct values to be used.

Can anyone better explain me the meaning of these two parameters?

When I was running i.atcorr for Sentinel2 data, I used range=1,1 (i.e. the 
min/max theoretical values the input data can reach).
As for rescale, this in my understanding just sets what the output range of the 
reflectances will be. So you can use for example 1-255, 0-1, 1-1, whatever 
suits best to your further analysis. Relatively, the result will be identical.

Hope that helps a bit!
Zofie


I tested all the values suggested in other posts but I can't understand what 
they exactly do.


Thank you in advance for your help!


Roberta

___
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] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Helmut Kudrnovsky]

>> Did you consider using cStringIO, if you need a file-object?
>>
>> That would avoid the temporary file and thus should be more efficient
>> too. See attached diff (it is probably not necessary to remove the last
>> line break though).
>Implemented your patch, thanks.  Dinarzarde, can you test?

tested here in OSGeo4W-winGRASS:

--
r.vif
maps=2011_01_precip,2011_02_precip,2011_03_precip,2011_04_precip,2011_05_precip,2011_06_precip,2011_07_precip,2011_08_precip,2011_09_precip,2011_10_precip,2011_11_precip,2011_12_precip
maxvif=10 file=D:\wd\rvif\test,csv
Reading in the data ...

Statistics are written to D:\wd\rvif\test,csv
VIF round 1
--
variablevif  sqrtvif
2011_01_precip 6.86 2.62
2011_02_precip 2.77 1.66
2011_03_precip33.17 5.76
2011_04_precip10.81 3.29
2011_05_precip 4.82 2.20
2011_06_precip 2.72 1.65
2011_07_precip 1.44 1.20
2011_08_precip10.04 3.17
2011_09_precip 3.16 1.78
2011_10_precip 2.50 1.58
2011_11_precip16.71 4.09
2011_12_precip50.81 7.13
VIF round 2
--
variablevif  sqrtvif
2011_01_precip 6.74 2.60
2011_02_precip 2.54 1.59
2011_03_precip18.23 4.27
2011_04_precip 8.99 3.00
2011_05_precip 4.72 2.17
2011_06_precip 2.69 1.64
2011_07_precip 1.40 1.18
2011_08_precip 9.11 3.02
2011_09_precip 3.08 1.75
2011_10_precip 2.42 1.55
2011_11_precip16.20 4.03
VIF round 3
--
variablevif  sqrtvif
2011_01_precip 5.63 2.37
2011_02_precip 2.14 1.46
2011_04_precip 5.71 2.39
2011_05_precip 4.63 2.15
2011_06_precip 2.52 1.59
2011_07_precip 1.33 1.15
2011_08_precip 9.01 3.00
2011_09_precip 3.08 1.75
2011_10_precip 2.14 1.46
2011_11_precip10.42 3.23
VIF round 4
--
variablevif  sqrtvif
2011_01_precip 5.53 2.35
2011_02_precip 2.13 1.46
2011_04_precip 3.09 1.76
2011_05_precip 4.10 2.03
2011_06_precip 2.52 1.59
2011_07_precip 1.24 1.11
2011_08_precip 4.26 2.06
2011_09_precip 3.01 1.74
2011_10_precip 2.14 1.46
/n
selected variables are: 
--
2011_01_precip, 2011_02_precip, 2011_04_precip, 2011_05_precip,
2011_06_precip, 2011_07_precip, 2011_08_precip, 2011_09_precip,
2011_10_precip
(Sat Feb 10 17:24:14 2018) Command finished (31 sec)
---

to use the new version by g.extension, you have to wait until tomorrow when
the server delivers the precompiled addons for winGRASS.

or just download it manually from

https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.vif

and copy r.vif.py into

C:\Users\YourUserName\AppData\Roaming\GRASS7\addons\scripts



-
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

Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Paulo van Breugel]

On 2/3/18 1:33 PM, Stefan Blumentrath wrote:


Hi Paulo and Helmut,

Did you consider using cStringIO, if you need a file-object?

That would avoid the temporary file and thus should be more efficient 
too. See attached diff (it is probably not necessary to remove the 
last line break though).



Implemented your patch, thanks.  Dinarzarde, can you test?


Just a suggestion.

Yet, there might be even more efficient solutions. For example 
raster2numpy from pygrass…


https://grass.osgeo.org/grass74/manuals/libpython/pygrass.raster.html#pygrass.raster.raster2numpy

Here however, you would have to mask NULL and I am not sure how to 
(platform-independent) determine values that represent NULL in a 
raster map. This gives pointers but there are again issues with 
Windows it seems: 
https://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library#Interfacing_with_NumPy


And it leaves the question how to find out if a raster is Integer or not…

With pygrass you could do:

from grass.pygrass import raster as r

p = np.ma.masked_equal(r.raster2numpy(raster), np.nan)) # For floating 
point rasters on Linux


or

p = np.ma.masked_equal(r.raster2numpy(raster), -2147483648)) # For 
integer rasters


Hints from experienced Python/Numpy developers would be appreciated…

That makes me wonder if it would be worth to add/collect 
recommendations for how to solve such common operations (like e.g. 
parsing table output from grass commands) either e.g. here: 
https://trac.osgeo.org/grass/wiki/Submitting/Python 
 or here: 
https://grasswiki.osgeo.org/wiki/GRASS_and_Python 
 ?


Cheers

Stefan

*From:*grass-user [mailto:grass-user-boun...@lists.osgeo.org] *On 
Behalf Of *Paulo van Breugel

*Sent:* lørdag 3. februar 2018 09.14
*To:* Helmut Kudrnovsky ; grass-user@lists.osgeo.org
*Subject:* Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI 
installations (stand-alone v. 7.2.2 and 7.0.5)


On February 2, 2018 8:52:03 PM Helmut Kudrnovsky > wrote:


>>Any idea how I can do that in such a way that it works on both Linux and
> Windows?
>
> in r.vif script I've changed the relevant lines:
>
> <
> # Get the raster values at sample points
> fd, tmpcov = tempfile.mkstemp()
> with open(tmpcov, "w") as text_file:
> text_file.write(
> gs.read_command("r.stats", flags="1n", input=raster,
> quiet=True, separator="comma"))
> p = np.loadtxt(tmpcov, skiprows=0, delimiter=",")
>
> # Clean up
> text_file.close()
> os.close(fd)
> os.remove(tmpcov)
> if not n == "100%":
> gs.run_command("r.mask", flags="r", quiet=True)
> if exist_mask['fullname']:
> gs.run_command("g.rename", raster=[mask_backup, "MASK"],
>    quiet=True)
> return(p)
> >
>
> and tested the script in winGRASS; it seems to work in windows; not 
tested

> on linux and mac.
>
>
Ok, thanks Helmut, I'll see if that works in Linux too
>
> -
> 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