from:"Helmut Kudrnovsky"

>Am I
>missing an option?

nothing obvious.

try the same steps as I've done (with adjusted paths) and _post the command and 
the command output_ here.

- grass78/grass80 -e -c columbia_2010_e_dtm_35.tif \grassdata\rastertest
- enter into the location just created
- g.region -p
- r.in.gdal input=columbia_2010_e_dtm_35.tif output=columbia_2010_e_dtm_35
- g.region -p -a raster=columbia_2010_e_dtm_35 align=columbia_2010_e_dtm_35
- r.stats -l input=columbia_2010_e_dtm_35
- r.report map=columbia_2010_e_dtm_35

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

[GRASS-user] imported .tif maps lose all data



>Then the issue is with 8.0.dev.

just tested with 8.0.dev.; it works here the same as in 7.8

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

[GRASS-user] imported .tif maps lose all data



>Where can I download the 7.8.x source so I can build it here? Following
>links from the web site's download for gneric linux
>https://grass.osgeo.org/grass78/binary/linux/snapshot/> I find a zip file
>and an install shell script, but not the source that allows me to build it
>on this Slackware-14.2/x86_64 host. Are the source files available just like
>the 8.0.dev source tree is?

a simple github checkout of the grass78_releasebranch?

https://github.com/OSGeo/grass/tree/releasebranch_7_8

Helmut

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

[GRASS-user] imported .tif maps lose all data


>>The data file sizes are all in the low 100Ks. I could upload an example to
>>fileconvoy.com if that's helpful.
>
>could you make one of the data files available?
>
>Helmut

for me it works

Driver: GTiff/GeoTIFF
Files: columbia_2010_e_dtm_35.tif
Size is 10745, 15264
Coordinate System is:
PROJCRS["NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet",
BASEGEOGCRS["GCS_North_American_1983_HARN",
DATUM["North_American_1983_HARN",
ELLIPSOID["GRS_1980",6378137,298.257222101,
LENGTHUNIT["metre",1,
ID["EPSG",9001,
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433,
ID["EPSG",9122,
CONVERSION["Lambert Conic Conformal (2SP)",
METHOD["Lambert Conic Conformal (2SP)",
ID["EPSG",9802]],
PARAMETER["Latitude of false origin",45.3,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8821]],
PARAMETER["Longitude of false origin",-120.5,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8822]],
PARAMETER["Latitude of 1st standard parallel",45.8,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8823]],
PARAMETER["Latitude of 2nd standard parallel",47.3,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8824]],
PARAMETER["Easting at false origin",50,
LENGTHUNIT["metre",1],
ID["EPSG",8826]],
PARAMETER["Northing at false origin",0,
LENGTHUNIT["metre",1],
ID["EPSG",8827]]],
CS[Cartesian,2],
AXIS["easting",east,
ORDER[1],
LENGTHUNIT["US survey foot",0.304800609601219,
ID["EPSG",9003]]],
AXIS["northing",north,
ORDER[2],
LENGTHUNIT["US survey foot",0.304800609601219,
ID["EPSG",9003
Data axis to CRS axis mapping: 1,2
Origin = (1512164.000,152311.000)
Pixel Size = (3.000,-3.000)
Metadata:
  AREA_OR_POINT=Area
  DataType=Generic
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 1512164.000,  152311.000) (121d 0' 8.57"W, 45d44'59.58"N)
Lower Left  ( 1512164.000,  106519.000) (121d 0' 4.46"W, 45d37'27.52"N)
Upper Right ( 1544399.000,  152311.000) (120d52'34.01"W, 45d45' 1.35"N)
Lower Right ( 1544399.000,  106519.000) (120d52'30.94"W, 45d37'29.29"N)
Center  ( 1528281.500,  129415.000) (120d56'19.49"W, 45d41'14.50"N)
Band 1 Block=512x256 Type=Float32, ColorInterp=Gray
  Min=159.316 Max=1037.520 
  Minimum=159.316, Maximum=1037.520, Mean=262.041, StdDev=157.494
  NoData Value=-3.40282306073709653e+38
  Overviews: 5373x7632, 2687x3816, 1344x1908, 672x954, 336x477, 168x239
  Metadata:
BandName=Band_1
RepresentationType=ATHEMATIC
STATISTICS_COVARIANCES=24804.31297971113
STATISTICS_MAXIMUM=1037.5201416016
STATISTICS_MEAN=262.04051816209
STATISTICS_MINIMUM=159.31565856934
STATISTICS_SKIPFACTORX=1
STATISTICS_SKIPFACTORY=1
STATISTICS_STDDEV=157.49385060919


D:\wd\testgpkg>grass78 -e -c columbia_2010_e_dtm_35.tif D:\grassdata\rastertest
Starting GRASS GIS...
Creating new GRASS GIS location ...
WARNUNG: Sperren gleichzeitiger Zugriffe auf ein Mapset ist unter Windows
 nicht möglich.
Cleaning up temporary files...
Cleaning up temporary files...


g.region -p 
projection: 99 (NAD83(HARN) / Washington South (ftUS))
zone:   0
datum:  ** unknown (default: WGS84) **
ellipsoid:  grs80
north:  152311
south:  106519
west:   1512164
east:   1544399
nsres:  3
ewres:  3
rows:   15264
cols:   10745
cells:  164011680



r.in.gdal input=D:\wd\testgpkg\columbia_2010_e_dtm_35.tif 
output=columbia_2010_e_dtm_35
WARNING: Datum  von GRASS nicht erkannt und keine 
Parameter gefunden.
Importing raster map ...


g.region -p -a raster=columbia_2010_e_dtm_35@data 
align=columbia_2010_e_dtm_35@data
projection: 99 (NAD83(HARN) / Washington South (ftUS))
zone:   0
datum:  ** unknown (default: WGS84) **
ellipsoid:  grs80
north:  152311
south:  106519
west:   1512164
east:   1544399
nsres:  3
ewres:  3
rows:   15264
cols:   10745
cells:  164011680


r.stats -l input=columbia_2010_e_dtm_35@data
159.315659-162.759598 from  to 
162.759598-166.203537 from  to 
166.203537-169.647476 from  to 
169.647476-173.091415 from  to 
173.091415-176.535354 from  to 
176.535354-179.979293 from  to 
179.979293-183.423233 from  to 
183.423233-186.867172 from  to 


r.report map=columbia_2010_e_dtm_35@data
+-+
| RASTER MAP CATEGORY REPORT

[GRASS-user] imported .tif maps lose all data

>The data file sizes are all in the low 100Ks. I could upload an example to
>fileconvoy.com if that's helpful.

could you make one of the data files available?

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

[GRASS-user] error in g.proj on Windows 10 via R (rgrass7) in GRASS 7.8

2021-05-26 Thread Helmut Kudrnovsky

>The problem occurs using GRASS 7.8 but NOT using 7.6. Likewise, there is
>no problem under Linux, only Windows 10.
>
>It might be related to some Windows environmental variables, but I don't
>have a clue which ones. As the older version works, I wonder if it is
>due to any changes from GRASS 7.6 to 7.8. Could anybody give me a hint?

QGIS bundled GRASS here:

GRASS Version: 7.8.5
Code revision: 2b6ab2893
Build date: 2020-12-21
Build platform: x86_64-w64-mingw32
GDAL: 3.1.4
PROJ: 6.3.2

see https://github.com/rsbivand/rgrass7/issues/27

it may be a mismatch between the GRASS bundled proj version and the R spatial 
packages bundled proj version.

please check the proj version in GRASS and R.

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

[GRASS-user] winGRASS tester needed ... to fix upcoming releases :-) .... nobody out there willing to test?

2021-05-06 Thread Helmut Kudrnovsky

mail below was sent on Wed Apr 14 2021 => no reaction, no one a minute to test?

if no one of the community has a minute to test winGRASS, then I guess it's 
time to propose to the PSC dropping winGRASS at all

kind regards
Helmut

---
dear GRASS GIS community,

testing of winGRASS is a important piece of puzzle to guarantee a stable and 
useable software on the MS windows platform in the future.

For this, we would need the help of the community now. :-)

background is an _error in g.extension while installing i.fusion.hpf in windows_

some more information

https://github.com/OSGeo/grass/issues/1477
https://github.com/OSGeo/grass/pull/1496

it's an encoding issue while opening files via python.

a possible solution may be set PYTHONUTF8=1 as environment variable.

and a way how you could help, just add

set PYTHONUTF8=1

in C:\OSGeo4W64\apps\grass\grass79\etc\env.bat just before GRASS_PYTHON is set. 
(or in the same file in the standalone winGRASS installation).

it would look like:

[...]
set PYTHONUTF8=1
set GRASS_PYTHON=%OSGEO4W_ROOT%\bin\python3.exe
[...]

and then happy GRASS GIS working :-) and report back if there are any issues in 
your daily winGRASS work.

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

[GRASS-user] winGRASS tester needed ... to fix upcoming releases :-)

2021-04-14 Thread Helmut Kudrnovsky

dear GRASS GIS community,

testing of winGRASS is a important piece of puzzle to guarantee a stable and 
useable software on the MS windows platform in the future.

For this, we would need the help of the community now. :-)

background is an _error in g.extension while installing i.fusion.hpf in windows_

some more information

https://github.com/OSGeo/grass/issues/1477
https://github.com/OSGeo/grass/pull/1496

it's an encoding issue while opening files via python.

a possible solution may be set PYTHONUTF8=1 as environment variable.

and a way how you could help, just add

set PYTHONUTF8=1

in C:\OSGeo4W64\apps\grass\grass79\etc\env.bat just before GRASS_PYTHON is set. 
(or in the same file in the standalone winGRASS installation).

it would look like:

[...]
set PYTHONUTF8=1
set GRASS_PYTHON=%OSGEO4W_ROOT%\bin\python3.exe
[...]

and then happy GRASS GIS working :-) and report back if there are any issues in 
your daily winGRASS work.

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

Re: [GRASS-user] Creating a png file with multiple vector maps

2021-03-21 Thread Helmut Kudrnovsky

>Helmut ... thank you for your example however I think there is a misunderstanding of what I am trying to do.
>I am using >GRASS on Linux (on a cluster) and the issue I am experiencing is overlaying two polygon maps (layers in Arc-speak).
>Points and lines on top of ONE set of polygons works fine as you have shown, however using two or more polygon maps
>(layers) does not seem to work. I attached an example of what i am trying to achieve: Take for instance a polygon
>representing Italy and you wanted it colored dark gray, then you want to overlay on top of that an administrative map
>showing only the areas of Lazio and Liguria colored in blue but no other administrative areas. The result would look
>like the Italy_sample.png file i attached (I made is using ArcPro as i am not in the office with access to our cluster).
>This is what is not working using the d.mon=png, d.vect tools. Could you please try something similar and see if it works for you (on linux)?

I'm not on linux, though I think it works there too.

testing here in with winGRASS 7.8.5 and overlaping vector polygon layers by following commands:

---

REM start of the batch file

set GRASS_RENDER_IMMEDIATE=png
set GRASS_RENDER_WIDTH=640
set GRASS_RENDER_HEIGHT=480
set GRASS_RENDER_TRANSPARENT=true
set GRASS_RENDER_TRUECOLOR=true
set GRASS_RENDER_FILE_COMPRESSION=9
set GRASS_MESSAGE_FORMAT=plain
set GRASS_RENDER_FILE_READ=TRUE

g.region vector=x006441899_100_VGD_AT@data

d.vect map=x006441899_100_VGD_AT@data fill_color=192:192:192:255 width=1
d.vect map=x006441899_100_VGD_BL@data color=0:0:0:255 fill_color=128:255:0:255 width=1
d.vect map=x006441899_100_VGD_PG@data color=255:0:0:255 fill_color=0:0:255:255 width=2

REM end of the batch file

---

see attached file, overlaying several polygones works here.

maybe others can test it on linux.

kind regards
Helmut___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error in g.extension while installing i.fusion.hpf in windows

2021-03-21 Thread Helmut Kudrnovsky

>So the solution in the meantime is to:
> 
>1. download the zip file from 
>https://wingrass.fsv.cvut.cz/grass78/x86_64/addons/latest/
>2. unzip and remove the __pychache__ folder
>3. copy everything to C:\Users\YourUserName\AppData\Roaming\GRASS7\addons\
 
yes; the contents of following folders

D:\dl\i.fusion.hpf>dir /b
bin
docs
etc
scripts

into the corresponding folders in 
C:\Users\YourUserName\AppData\Roaming\GRASS7\addons\

>@Helli would you mind opening an issue for that, please?

done: https://github.com/OSGeo/grass/issues/1477

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

[GRASS-user] error in g.extension while installing i.fusion.hpf in windows

2021-03-19 Thread Helmut Kudrnovsky


>that's the reason of g.extension failing
>
>downloading the zip-file (see link above) and copying the files into the 
>corresponding folders in
>
>C:\Users\YourUserName\AppData\Roaming\GRASS7\addons\
>
>should help.

now tested in this way:
 

g.region -p -a raster=lsat7_2002_80@PERMANENT align=lsat7_2002_80@PERMANENT
---
i.fusion.hpf pan=lsat7_2002_80@PERMANENT 
msx=lsat7_2002_10@PERMANENT,lsat7_2002_20@PERMANENT,lsat7_2002_30@PERMANENT,lsat7_2002_40@PERMANENT
 suffix=_hpf
|! Region's resolution matched to Pan's (14.25)
Processing image: lsat7_2002_10@PERMANENT
|1 Determining ratio of low to high resolution
> Retrieving image resolutions
>> Resolution ratio low (28.500) to high (14.250): 2.0
|2 High Pass Filtering the Panchromatic Image
|3 Upsampling (bilinearly) low resolution image
|4 Weighting the High-Pass-Filtered image (HPFi)
> Weighting = StdDev(MSx) / StdDev(HPFi) * Modulating Factor
>> StdDev of : 20.702
>> StdDev of HPFi: 257.949
>> Modulating Factor: 0.25
|5 Adding weighted HPFi to upsampled image
|+ Quantile scaling of Pansharpened image to lsat7_2002_10@PERMANENT
Processing image: lsat7_2002_20@PERMANENT
|1 Determining ratio of low to high resolution
> Retrieving image resolutions
>> Resolution ratio low (28.500) to high (14.250): 2.0
|2 High Pass Filtering the Panchromatic Image
|3 Upsampling (bilinearly) low resolution image
|4 Weighting the High-Pass-Filtered image (HPFi)
> Weighting = StdDev(MSx) / StdDev(HPFi) * Modulating Factor
>> StdDev of : 23.325
>> StdDev of HPFi: 257.949
>> Modulating Factor: 0.25
|5 Adding weighted HPFi to upsampled image
|+ Quantile scaling of Pansharpened image to lsat7_2002_20@PERMANENT
Processing image: lsat7_2002_30@PERMANENT
|1 Determining ratio of low to high resolution
> Retrieving image resolutions
>> Resolution ratio low (28.500) to high (14.250): 2.0
|2 High Pass Filtering the Panchromatic Image
|3 Upsampling (bilinearly) low resolution image
|4 Weighting the High-Pass-Filtered image (HPFi)
> Weighting = StdDev(MSx) / StdDev(HPFi) * Modulating Factor
>> StdDev of : 34.711
>> StdDev of HPFi: 257.949
>> Modulating Factor: 0.25
|5 Adding weighted HPFi to upsampled image
|+ Quantile scaling of Pansharpened image to lsat7_2002_30@PERMANENT
Processing image: lsat7_2002_40@PERMANENT
|1 Determining ratio of low to high resolution
> Retrieving image resolutions
>> Resolution ratio low (28.500) to high (14.250): 2.0
|2 High Pass Filtering the Panchromatic Image
|3 Upsampling (bilinearly) low resolution image
|4 Weighting the High-Pass-Filtered image (HPFi)
> Weighting = StdDev(MSx) / StdDev(HPFi) * Modulating Factor
>> StdDev of : 20.479
>> StdDev of HPFi: 257.949
>> Modulating Factor: 0.25
|5 Adding weighted HPFi to upsampled image
|+ Quantile scaling of Pansharpened image to lsat7_2002_40@PERMANENT
|! Original Region restored
>>> Hint, rebalancing colors (via i.colors.enhance) may improve appearance of 
>>> RGB composites!
WARNING: No data base element files found
(Fri Mar 19 21:27:40 2021) Befehl ausgeführt (15 Sek)  
 
the script itself (downloaded from 
https://wingrass.fsv.cvut.cz/grass78/x86_64/addons/latest/) works.
 
now we have to solve the g.extension issue.
 
kind regards
helli
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] error in g.extension while installing i.fusion.hpf in windows

2021-03-19 Thread Helmut Kudrnovsky

>I know well the issue(s).  I don't run a WinBox currently.

as already mentioned in an earlier mail, the culprit is not with the script 
itself, though with some leftovers in the pre-compiled zip files used by 
g.extension in winGRASS, see

https://lists.osgeo.org/pipermail/grass-user/2021-March/082299.html

>downloading the zipped addon, which is used by g.extension in windows, from 
>here:
>https://wingrass.fsv.cvut.cz/grass78/x86_64/addons/latest/
>
>in the subfolder i.fusion.hpf\etc\i.fusion.hpf, there is a subfolder 
>__pycache__
>
>i.fusion.hpf\etc\i.fusion.hpf\__pycache__>ls
>
>constants.cpython-37.pyc
>high_pass_filter.cpython-37.pyc
>
>the compiled python bytecode shouldn't be there in the zip file.
>
>@Martin: anything to change on the compilation server?

that's the reason of g.extension failing

downloading the zip-file (see link above) and copying the files into the 
corresponding folders in

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

should help.

kind regards
Helli

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

[GRASS-user] error in g.extension while installing i.fusion.hpf in windows

2021-03-18 Thread Helmut Kudrnovsky

>What surprises me a bit:
>
>file *
>constants.py:Python script, UTF-8 Unicode text executable
>high_pass_filter.py: Python script, ASCII text executable
>i.fusion.hpf.html:   HTML document, ASCII text
>i_fusion_hpf_lsat7_hpf_rgb.png:  PNG image data, 1327 x 840,
>8-bit/color RGB, non-interlaced
>i_fusion_hpf_lsat7_orig_rgb.png: PNG image data, 1327 x 840,
>8-bit/color RGB, non-interlaced
>i.fusion.hpf.py: Python script, ASCII text executable
>licenses:directory
>Makefile:ASCII text
>README.md:   UTF-8 Unicode text
>test_high_pass_filter.py:Python script, ASCII text executable
>
>--> some .py files are UTF-8, some are not shall this be streamlined?

downloading the zipped addon, which is used by g.extension in windows, from 
here:
https://wingrass.fsv.cvut.cz/grass78/x86_64/addons/latest/

in the subfolder i.fusion.hpf\etc\i.fusion.hpf, there is a subfolder __pycache__

i.fusion.hpf\etc\i.fusion.hpf\__pycache__>ls

constants.cpython-37.pyc
high_pass_filter.cpython-37.pyc

the compiled python bytecode shouldn't be there in the zip file.

@Martin: anything to change on the compilation server?

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

Re: [GRASS-user] Creating a png file with multiple vector maps

2021-03-02 Thread Helmut Kudrnovsky

>I don't see anything immediately wrong. Maybe it is a specific MS
>Windows issue I cannot reproduce here in GNU/Linux.
>
>@Helmut any ideas ?

tested here in the following way in OSGeo4W-winGRASS 7.8.5

(1) changing the working directory via GUI > change working directory
 
 cd "D:\temp\testgrassrender"   
 
Working directory changed to:   
"D:\temp\testgrassrender"

(2) in OSgeo4W-winGRASS-windows console (no msys needed!), also change here to 
the new wd:

C:\>cd D:\temp\testgrassrender
C:\>d:

(3) put the variables and d.-commands into a bat-file into the working 
directory (D:\temp\testgrassrender\mytest.bat):

REM start of the batch file

set GRASS_RENDER_IMMEDIATE=png
set GRASS_RENDER_WIDTH=640
set GRASS_RENDER_HEIGHT=480
set GRASS_RENDER_TRANSPARENT=true
set GRASS_RENDER_TRUECOLOR=true
set GRASS_RENDER_FILE_COMPRESSION=0
set GRASS_MESSAGE_FORMAT=plain
set GRASS_RENDER_FILE_READ=TRUE

g.region vect=census_wake2000
d.vect map=census_wake2000 fill_color=none
d.vect map=roadsmajor color=255:0:0:255
d.vect map=schools_wake fill_color=0:128:0:255 icon=basic/circle size=10

REM end of the batch file

=> see here: in order to set a variable in the windows world, use e.g. set 
GRASS_RENDER_IMMEDIATE=png instead if export GRASS_RENDER_IMMEDIATE=png in the 
*nix world

(4) start your batch file in the windows command line:

D:\temp\testgrassrender>mytest.bat

D:\temp\testgrassrender>set GRASS_RENDER_IMMEDIATE=png
D:\temp\testgrassrender>set GRASS_RENDER_WIDTH=640
D:\temp\testgrassrender>set GRASS_RENDER_HEIGHT=480
D:\temp\testgrassrender>set GRASS_RENDER_TRANSPARENT=true
D:\temp\testgrassrender>set GRASS_RENDER_TRUECOLOR=true
D:\temp\testgrassrender>set GRASS_RENDER_FILE_COMPRESSION=0
D:\temp\testgrassrender>set GRASS_MESSAGE_FORMAT=plain
D:\temp\testgrassrender>set GRASS_RENDER_FILE_READ=TRUE
D:\temp\testgrassrender>g.region vect=census_wake2000
D:\temp\testgrassrender>d.vect map=census_wake2000 fill_color=none
d.vect komplett.

D:\temp\testgrassrender>d.vect map=roadsmajor color=255:0:0:255
d.vect komplett.

D:\temp\testgrassrender>d.vect map=schools_wake fill_color=0:128:0:255 
icon=basic/circle size=10
d.vect komplett.

(5) see attached the result png - it looks like the same as Moritz's example

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

[GRASS-user] [osgeo4w-dev] QGIS 3.18.0 and QGIS 3.14.4 (LTR) packages released and OSGeo4W reboot (64 bit only)

2021-02-23 Thread Helmut Kudrnovsky

taken from the OSGeo4W ML
[https://lists.osgeo.org/pipermail/osgeo4w-dev/2021-February/004050.html]


Hi there,

I'm happy to announce that the QGIS packages of 3.16.4 (LTR) 'Hannover' and
the
our latest release 3.18.0 'Zürich' are ready on
https://qgis.org/de/site/forusers/download.html.  This includes Linux, Mac
and
Windows packages.  With the availability of a new regular release the
current
long-term release 3.16 replaces the previous long-term release 3.10 in the
long
term package repositories.

The Windows standalone installer are as usual made from the OSGeo4W
packages.

In OSGeo4W there has lately been a big effort to reboot it, meaning that it
has 
been completely rebuilt using newer source versions of mostly every package 
using a newer compiler.  As this happened shortly before the QGIS release
the
new packages are still in a separate repository for testing.

You can install them using the osgeo4w installer on
http://download.osgeo.org/osgeo4w/testing/osgeo4w-setup.exe (note the
testing -
the old installer will also work, if you point it to the new site, but it
will
default to the old).

Within the reboot a lot of old packages were dropped (including dependencies
to 
old microsoft runtimes), new packages were introduced and also package names
were revised.

Long story short: you cannot upgrade from old installs and have to remove
and
reinstall or use a separate directory.  As the new OSGeo4W only supports
64bit
the default root directory was changed to C:\OSGeo4W, which might help with
that if you were on 64bit earlier.

Also note that it now only has one version of Python - namely 3.9, which
doesn't support Windows 7 anymore.  Other updates include Qt 5.15, GDAL 3.2,
PROJ 7.2 and SAGA 7.8.

It also has PDAL 2.2 which is required for native support of point clouds in 
QGIS - something that you find lacking in the "old" OSGeo4W repository and
in
turn in the current standalones.

The new installer also doesn't require administrator privileges anymore.  
Unless you run it elevated (ie. as Administrator) the option to create 
shortcuts for all users will be unavailable.

The testing repository will eventually replace the old repository and also
be
used to make standalone installers.   As it has grown to exceed the 2GB
limit 
of NSIS the standalone installers will then be switched to MSI.

The package recipes currently reside at https://github.com/jef-n/OSGeo4W.

Please test and report packaging issues to the OSGeo4W TRAC at
https://trac.osgeo.org/osgeo4w.

Jürgen





-
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] r.futures.potential - unable to open select-cursor

2021-02-10 Thread Helmut Kudrnovsky

now testing here with the standalone winGRASS installer 7.8.5

C:\Users\myuser>echo %PATH%
C:\Program Files\GRASS GIS 7.8\lib;C:\Program Files\GRASS GIS
7.8\bin;C:\Users\myuser\AppData\Roaming\GRASS7\addons\bin;{app};C:\Program
Files\GRASS GIS 7.8\extrabin;C:\Program Files\GRASS GIS 7.8\bin;C:\Program
Files\GRASS GIS 7.8\Python37;C:\Program Files (x86)\Common
Files\Oracle\Java\javapath;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files (x86)\NVIDIA
Corporation\PhysX\Common;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program
Files\TortoiseSVN\bin;C:\Program Files\Git\cmd;C:\Program
Files\Intel\WiFi\bin\;C:\Program Files\Common
Files\Intel\WirelessCommon\;C:\Program
Files\dotnet\;C:\WINDOWS\System32\OpenSSH\;C:\Users\myuser\AppData\Local\Microsoft\WindowsApps;C:\Users\myuser\.dotnet\tools;C:\Program
Files\R\R-4.0.3\bin\x64;C:\Program Files\GRASS GIS
7.8\Python37\lib\site-packages\pywin32_system32


C:\Users\myuser>R

R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R ist freie Software und kommt OHNE JEGLICHE GARANTIE.
Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten.
Tippen Sie 'license()' or 'licence()' f├╝r Details dazu.

R ist ein Gemeinschaftsprojekt mit vielen Beitragenden.
Tippen Sie 'contributors()' f├╝r mehr Information und 'citation()',
um zu erfahren, wie R oder R packages in Publikationen zitiert werden
k├Ânnen.

Tippen Sie 'demo()' f├╝r einige Demos, 'help()' f├╝r on-line Hilfe, oder
'help.start()' f├╝r eine HTML Browserschnittstelle zur Hilfe.
Tippen Sie 'q()', um R zu verlassen.

Beim Start - Warnmeldungen:
1: Setting LC_CTYPE=de_AT.cp1252 failed
2: Setting LC_COLLATE=de_AT.cp1252 failed
3: Setting LC_TIME=de_AT.cp1252 failed
4: Setting LC_MONETARY=de_AT.cp1252 failed
> library("MuMIn")
>

now RScript:

C:\Users\myuser>RScript
Usage: /path/to/Rscript [--options] [-e expr [-e expr2 ...] | file] [args]

--options accepted are
  --help  Print usage and exit
  --version   Print version and exit
  --verbose   Print information on progress
  --default-packages=list
  Where 'list' is a comma-separated set
of package names, or 'NULL'
or options to R, in addition to --no-echo --no-restore, such as
  --save  Do save workspace at the end of the session
  --no-environDon't read the site and user environment files
  --no-site-file  Don't read the site-wide Rprofile
  --no-init-file  Don't read the user R profile
  --restore   Do restore previously saved objects at startup
  --vanilla   Combine --no-save, --no-restore, --no-site-file
--no-init-file and --no-environ

'file' may contain spaces but not shell metacharacters
Expressions (one or more '-e ') may be used *instead* of 'file'
See also  ?Rscript  from within R


to sum up, R/RScript and loading libraries are working here in winGRASS
standalone 7.8.5 and OSGeo4W winGRASS 7.8.5

important, in both cases it's installed in the standard standalone/OSGeo4W
installation paths.

>It is weird though, as it references mostly data on the D:\ disc although I
saved all the installation data >on

are you sure that you're starting the right winGRASS installation? maybe the
start menue entry points to the old installation and not to the new one?

open start menue, right click on the GRASS GIS menue entry => more
information, open the folder where the menue entry is stored and again right
click GRASS GIS for properties.

standalone points to:

"C:\Program Files\GRASS GIS 7.8\grass78.bat" --gui

OSGeo4W points to:

C:\OSGeo4W64\bin\grass78.bat --gui

>So this might already be the problem? Does it make sense to just delete all
the GRASS files on D:\ ?

a clean installation is needed in order to be able seeing which installation
is used.

>C:\>set PATH=%PATH%;C:\Program Files\R\R-4.0.3\bin

that's not needed as it's already in %PATH%. in standalone as well in
OSGeo4W; see my ECHO %PATH% in OSGeo4W and standalone.


>> install.packages(c("MuMIn", "lme4", "optparse", "rgrass7"))
>Warnung: Paket ‘MuMIn’ wird gerade benutzt und deshab nicht installiert
>Installiere Pakete nach ‘C:/Users/txhac/Documents/R/win-library/4.0’
>(da ‘lib’ nicht spezifiziert)

that's definitely a R issue and not a winGRASS issue. this has to be solved.

>So neither in R nor in Grass anything happens trying to run
library("MuMIn").
>Any idea what the problem might be? I also uninstalled and reinstalled R
now and nothing has changed.

as MuMIn may be installed C:/Users/txhac/Documents/R/win-library/4.0 and you
try to install it also in the R systemwide installation path; maybe there is
some library mismatch.

libraries aren't deinstalled if you deinstall R.

thus, you h

Re: [GRASS-user] r.futures.potential - unable to open select-cursor

2021-02-09 Thread Helmut Kudrnovsky

>- set PATH=%PATH%;C:\Program Files\R\R-4.0.3\bin has been included

start winGRASS and type into the console:

C:\>ECHO %PATH%

here in OSGeo4W-winGRASS, it's something like:

C:\OSGEO4~1\apps\grass\grass78\lib;C:\OSGEO4~1\apps\grass\grass78\bin;C:\Users\hkmyr\AppData\Roaming\GRASS7\addons\bin;C:\OSGEO4~1\apps\Python37;C:\OSGEO4~1\apps\Python37\Scripts;{app};C:\OSGEO4~1\apps\Python27\Scripts;C:\OSGEO4~1\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBem;C:\OSGEO4~1\apps\msys\bin;C:\Program
Files\R\R-4.0.3\bin\x64;C:\OSGEO4~1\apps\Python37\lib\site-packages\pywin32_system32

post your result here.


>- R libraries have been installed, but when I type in library("MuMIn") in
the terminal, nothing happens

are you're sure you have installed the library systemwide via R in
administrator mode?

just open R (outside any GRASS session) and try to load the library.

what is the result?

here: 

> library("MuMIn")
> 

library loaded

then start R within a GRASS session in the console and load the library.

here:

Welcome to GRASS GIS 7.8.5
GRASS GIS homepage:  https://grass.osgeo.org
This version running through:Command Prompt
(C:\WINDOWS\system32\cmd.exe)
Help is available with the command:  g.manual -i
See the licence terms with:  g.version -c
See citation options with:   g.version -x
If required, restart the GUI with:   g.gui wxpython
When ready to quit enter:exit

Launching  GUI in the background, please wait...
Microsoft Windows [Version 10.0.19042.746]
(c) 2020 Microsoft Corporation. Alle Rechte vorbehalten.

C:\>R

R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R ist freie Software und kommt OHNE JEGLICHE GARANTIE.
Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten.
Tippen Sie 'license()' or 'licence()' f├╝r Details dazu.

R ist ein Gemeinschaftsprojekt mit vielen Beitragenden.
Tippen Sie 'contributors()' f├╝r mehr Information und 'citation()',
um zu erfahren, wie R oder R packages in Publikationen zitiert werden
k├Ânnen.

Tippen Sie 'demo()' f├╝r einige Demos, 'help()' f├╝r on-line Hilfe, oder
'help.start()' f├╝r eine HTML Browserschnittstelle zur Hilfe.
Tippen Sie 'q()', um R zu verlassen.

Beim Start - Warnmeldungen:
1: Setting LC_CTYPE=de_AT.cp1252 failed
2: Setting LC_COLLATE=de_AT.cp1252 failed
3: Setting LC_TIME=de_AT.cp1252 failed
4: Setting LC_MONETARY=de_AT.cp1252 failed
> library("MuMIn")

library loaded here also

>- when I run R or Rscript in the terminal the right response is shown, but
only if I run them separately. >If i try to run Rscript after running R in
the terminal, Rscript will not be found. Maybe this is the problem?

tested here:

Welcome to GRASS GIS 7.8.5
GRASS GIS homepage:  https://grass.osgeo.org
This version running through:Command Prompt
(C:\WINDOWS\system32\cmd.exe)
Help is available with the command:  g.manual -i
See the licence terms with:  g.version -c
See citation options with:   g.version -x
If required, restart the GUI with:   g.gui wxpython
When ready to quit enter:exit

Launching  GUI in the background, please wait...
Microsoft Windows [Version 10.0.19042.746]
(c) 2020 Microsoft Corporation. Alle Rechte vorbehalten.

C:\>R

R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R ist freie Software und kommt OHNE JEGLICHE GARANTIE.
Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten.
Tippen Sie 'license()' or 'licence()' f├╝r Details dazu.

R ist ein Gemeinschaftsprojekt mit vielen Beitragenden.
Tippen Sie 'contributors()' f├╝r mehr Information und 'citation()',
um zu erfahren, wie R oder R packages in Publikationen zitiert werden
k├Ânnen.

Tippen Sie 'demo()' f├╝r einige Demos, 'help()' f├╝r on-line Hilfe, oder
'help.start()' f├╝r eine HTML Browserschnittstelle zur Hilfe.
Tippen Sie 'q()', um R zu verlassen.

Beim Start - Warnmeldungen:
1: Setting LC_CTYPE=de_AT.cp1252 failed
2: Setting LC_COLLATE=de_AT.cp1252 failed
3: Setting LC_TIME=de_AT.cp1252 failed
4: Setting LC_MONETARY=de_AT.cp1252 failed
> q()
Workspace sichern? [y/n/c]: n

C:\>RScript
Usage: /path/to/Rscript [--options] [-e expr [-e expr2 ...] | file] [args]

--options accepted are
  --help  Print usage and exit
  --version   Print version and exit
  --verbose   Print information on progress
  --default-packages=list
  Where 'list' is a comma-separated set
of package names, or 'NULL'
or options to R, in addition to --no-echo --no-restore, such as
  --save  Do save workspace at the end of the session
  --no-environDon't read the site and user environment files
  --no-site-file  Don't

Re: [GRASS-user] Elections results and new GRASS GIS PSC

2021-02-09 Thread Helmut Kudrnovsky

Moritz Lennert wrote
> [Online version of this announcement: 
> https://grass.osgeo.org/news/2021_02_05_new_grass_psc/ 
> ;]
> 
> 
>   New GRASS GIS Project Steering Committee
> 
> By the end of last year, the GRASS GIS project called for PSC members 
> election. A total of/13 GRASS GIS contributors/were nominated by the 
> community to cover the nine PSC positions.
> 
> After the election itself, the new GRASS GIS PSC is composed of the 
> following nine members ranked by number of votes:
> 
>   * Markus Neteler (95)
>   * Anna Petrášová (88)
>   * Helena Mitášová (86)
>   * Martin Landa (83)
>   * Verónica Andreo (76)
>   * Moritz Lennert (74)
>   * Václav Petráš (68)
>   * Michael Barton (58)
>   * Huidae Cho (56)
> 
> For completeness, all relevant candidacy communications, as well as 
> details about the voting process, have been published 
> at:https://trac.osgeo.org/grass/wiki/PSC/Election2020 
> ;
> 
> On behalf of the GRASS GIS project, we would like to thank/Hernán De 
> Angelis/who agreed to serve as Chief Returning Officer (CRO) and all 
> community members for their participation. Furthermore, we want to 
> acknowledge the contributions of former PSC members and all nominees. 
> The development of GRASS GIS is a collective effort and we are all part 
> of it regardless of our role. So,*CONGRATS to everyone!*
> 
> 
>   New PSC chair person
> 
> There’s yet one more change to report. GRASS GIS PSC has a new chair 
> person:*Veronica Andreo* ;. She works
> as a 
> researcher in Argentina focusing on environmental drivers of 
> vector-borne disease outbreaks and works primarily with satellite 
> imagery and GIS-based time series analysis. For years, Vero has been 
> very active in the GRASS GIS project, especially with documenting 
> complex topics in a user friendly way, testing, development of the new 
> website, coding of addons, outreach, social media and more. She 
> regularly introduces GRASS GIS to new users and teaches introductory and 
> advanced courses and workshops. We thank Vero for accepting this
> challenge!
> 
> We want to acknowledge and thank*Markus Neteler* 
> for his enormous efforts and 
> passionate work on pushing the GRASS GIS development for more than 20 
> years. While Markus was re-elected as PSC member, he preferred to pass 
> on the position of chairperson to a new PSC member. Markus is one of the 
> long runners in the project, as he already started to discover the 
> software in 1993 as a student. In 1998, he set up a “European GRASS 
> site” at the University of Hannover, which evolved into an international 
> development team. From manual source code management, he was part of the 
> journey to a modern, GitHub-based development system including code 
> quality testing. Markus is known to be active in conferences, code 
> sprints, bug fixing, user support, infrastructure management, project 
> and release management, etc. He will continue to do so!
> 
> 
>   PSC roles & tasks
> 
> In addition to the chair role, in the firstPSC 
> meeting, we have defined some 
> basic areas/tasks and PSC members responsible for them:
> 
>   * Treasurer - Moritz
>   * Release manager - Markus, Martin
>   * Infrastructure manager - Markus
>   * Translation manager - Huidae
>   * Website & Marketing manager - Michael, Vero
>   * Github manager - Vaclav
> 
> Of course, *everyone is invited to join and contribute*in these and 
> other areas:https://trac.osgeo.org/grass/wiki/PSC/Roles 
> ;.
> 
> /The GRASS Development Team, Feb 2021/

congratulations to the new project PSC! let's keep GRASS GIS growing! :-)



-
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] Availability of windows builds with OpenMP - suggestions for linux alternatives?

2021-02-07 Thread Helmut Kudrnovsky

Jean-Roc Morreale (ml) wrote
> Hi,
> 
> I would to know if there is a Windows installer built with OpenMP
> support, the need is to use v.surf.rst parallelization (nprocs) to
> produce a DTM using (without this support, only one cpu core out of
> 48).
> 
> Neither osgeo4w's build or wingrass is compiled with it, is it due to a
> platform instability ? If no build is available, which linux
> distribution has grass' package with this support (will use a live usb
> then) ?

I'm not aware of any OpenMP enabled winGRASS builds. AFAIK it was never
tested enough to provide such winGRASS binaries.




-
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] Using Python in GRASS GIS for analysis

2021-02-03 Thread Helmut Kudrnovsky



See
https://github.com/OSGeo/grass/issues/1218

> from win32file import ReadFile, WriteFile
{ImportError: DLL load failed: The specified procedure could not be >found.

This issue should be solved with winGRASS 7.8.5-2 standalone installer. 



-
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] Updated standalone WinGRASS-7.8.5-2 installer published

2021-01-31 Thread Helmut Kudrnovsky

Dear GRASS GIS community,

since the release of GRASS GIS 7.8.5, there have been several complaints
that the standalone winGRASS installer has an startup issue; see [1].

in a shared effort, we've found the reason of the startup issue, fixed it
and published now an updated standalone WinGRASS-7.8.5-2 64bit installer.
[2]

[1] https://github.com/OSGeo/grass/issues/1218
[2] https://github.com/OSGeo/grass-website/pull/249







-
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] r.clump/ Concurent mapset locking is not supported on Windows

2021-01-27 Thread Helmut Kudrnovsky

dag.lit wrote
> I am working only on one user on the computer (I don't have more usuers).
> Everything was normally working and one day it stops. I alredy tried to
> uninstall and install QGIS but it didn't help :(

It could be a region setting issue. 

QGIS shows the used GRASS commands. you could try these commands in GRASS
itself and see if it works. 




-
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] r.clump/ Concurent mapset locking is not supported on Windows

2021-01-25 Thread Helmut Kudrnovsky

dag.lit wrote
> Hello Everyone
> I have a problem with Grass tools in QGIS (QGIS Desktop 3.16.3 with Grass
> 7.8.5). When I try to use r.clump or any other tool from grass I have a
> message 'Warning: Concurent mapset locking is not supported on Windows'.
> Does anyone know how to fix this problem?
> 
> Thanks :)

it's not a bug, it's a feature. ;-)

the concept of mapset locking doesn't work in windows, although in the *nix
world quite well.

though, simultaneously working by different users in the same mapset should
be avoided also in the windows world.

not sure how QGIS handles this; maybe it's more a QGIS questions.



-
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] Error in Compiling GRASS GIS

2021-01-16 Thread Helmut Kudrnovsky

>Now I am getting an error :
>
>--> configure: error: *** Unable to locate lex.
>
>I did some googling and found out that i should download and install FLEX.
>So I did, but still got the same error. Can anyone help on this?

it's part of the msys2 framework
(https://trac.osgeo.org/grass/wiki/CompileOnWindows#InstalltheMSYS2directorystructure)

in the msys2 shell:

$ lex --version
lex 2.6.4


>Also is there any other way to check the working of code changes in GUI
>part without compiling the whole software?

GUI is python, thus no need to compile. drop the updated script into the
corresponding folder.






-
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] Statement Helmut Kudrnovsky

2021-01-14 Thread Helmut Kudrnovsky

Dear GRASS GIS community,

I'm honored to be nominated for the PSC of this wonderful free and open
source GIS project.

For preparing this statement, I've done some archaeology work to find out
since when I'm part of and contribute to the community. :-)

it seems I'm around there in the mailing lists since about 16 years [1].

A few years later, I've got write access to the code base. My first commit
was about fixing some winGRASS standalone installer issues. back then, it
was still in the svn code repository. the cool thing is that the commit
history is still available after the switch to the github [2]. I've
contributed also some addons, e.g. v.fixed.segmentpoints, r.euro.ecosystem,
r.northerness.easterness, r.roughness.vector, r.valley.bottom.

For the OSGeo community, I've served as GSoC admin for a few years.

>From my professional background, as an ecologist I'm working in the field of
applied science and nature conservation. In this field, I'm trying to
promote the use of free and open (GIS) software.

Since the beginning, I'm involved in the windwows side of the GRASS GIS
world. :-) e.g. testing on the windows platform; improving standalone
installer; packaging standalone and OSgeo4W; R-winGRASS bridge; helping on
windows issues in the mailing lists; etc.

I'll continue these activities. As a possibly elected PSC member, a mid term
vision is a completely automated preparing and packaging of winGRASS, e.g.
by github actions. a long term vision is to bring more community members
contributing, maintain and developing on the windwows side of the GRASS GIS
world.

Proud to be part of such a innovative and friendly community !

[1]
http://osgeo-org.1560.x6.nabble.com/GRASSLIST-5704-projection-conversion-td3957936.html#a3957940
[2]
https://github.com/OSGeo/grass/commit/75592c04174547cf1070f941cf794c06ce529d7c

-
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] r.futures not working

2020-12-14 Thread Helmut Kudrnovsky

>is it clear now what were the problems? 

Yes it's clear now what the issue(s) was:

- the winGRASS-R-bridge looks for R installations in windows standard drive
and folders, i.e. C:\Program; R installations in non standard drives,
e.g. D:\Program... are not reckognized => standard R installation location
shouldn't be changed 

- R packages/libraries has to be available system wide, e.g. run R install 
packages as administrator 


another issue is that the current winGRASS-R-bridge version is broken; we
have to reinstate the previous version. 



-
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] r.futures not working

2020-12-13 Thread Helmut Kudrnovsky

>Ok got it, I just had to run R as administrator and download it then. >I
think everything works now. Helmut, I don't know how I can thank >you. I
hope we meet one day so that I can invite you to a coffee or >whatever you
wish

you're welcome. yes you have to install R packages as administrator to be
available system wide. 

feel free donate to the GRASS GIS project
(https://grass.osgeo.org/contribute/donations/)



-
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] r.futures not working

2020-12-13 Thread Helmut Kudrnovsky

It's an R issue, not a GRASS issue. 

Open R in a normal way. 

library("MuMIn")

What does it report?

>The packages can also be found in the directory

That's only the temporary download folder, not the R package folder



-
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] r.futures not working

Looks good so far!  R/RScript is found and work

>Package MuMIn  not found

What I have asked already in a previous mail. A needed R package isn't
installed. 



-
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] r.futures not working

>the R path is: D:\Programme\R-4.0.3

Is it really D:\ and not C:\ ?

The winGRASS-R-bridge looks for R in C:\.



-
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] r.futures not working

What is the content of C:\OSGeo4W64\etc\ini and C:\OSGeo4W64\Apps?

What is the path to your R installation?

Not sure what's going on as tested here on several win 10 boxes, and it
works on all of them. 





-
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] r.futures not working

[a hint to save message size:

- just open a windows command console, 
- change to the relevant folder: e.g.

C:\Users\your user>cd C:\OSGeo4W64\etc\ini
C:\OSGeo4W64\etc\ini>

- do dir /b

C:\OSGeo4W64\etc\ini>dir /b
gdal.bat
libgeotiff.bat
libjpeg.bat
liblas.bat
msvcrt.bat
msys.bat
proj.bat
python-core.bat
qt4.bat
rbatchfiles.bat

- mark the console output with mouse
- copy the text into the mail]

ok, at your computer, there seems to be some incomplete OSGeo4W installation
leftovers here and there. not sure why.

it's recommended to install OSGeo4W 64 bit into C:\OSGeo4W64, not into
c:\Programme

>Does it make sense to transfer this data into the OSGeo64W Folder?

as we don't know, how (in)complete the OSGeo4W installation(s) are, I
suggest to delete both of them and try to re-install a new attempt in
C:\OSGeo4W64.

then try my procedures mentioned before in previous mails.

the content of C:\OSGeo4W64\etc\ini should be something like:

gdal.bat
libgeotiff.bat
libjpeg.bat
liblas.bat
msvcrt.bat
msys.bat
proj.bat
python-core.bat
qt4.bat
rbatchfiles.bat <=

especially rbatchfiles.bat




-
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] r.futures not working

>for a workaround: 

we're working to bring the R-winGRASS-bridge back to OSGeo4W



-
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] r.futures not working

>run o-help for a list of available commands
>C:\>R
>Der Befehl "R" ist entweder falsch geschrieben oder
>konnte nicht gefunden werden.
>
>C:\>Rscript
>Der Befehl "Rscript" ist entweder falsch geschrieben oder
>konnte nicht gefunden werden.
>
>(that means it's been typed wrong or couldn't be found).

no, the GRASS-R-bridge isn't installed.

be aware that if you install the previous rbatch version and then in a next
run of OSGeo4W install of e.g. winGRASS 7.9.daily., then the not working
rbatch version is installed again. it's a drawback of the minimalistic
OSGeo4W package system.

install the previous working rbatch version, then check:

in

- C:\OSGeo4W64\etc\ini\rbatchfiles.bat

and 

- C:\OSGeo4W64\apps\rbatchfiles with 18 files inside are there.

the important file is rbatchfiles.bat in the ini-subfolder.

if it's there, then it should work like here within and outside a winGRASS
session in the OSGeo4W shell.

here:

---

OSGeo4W shell outside a GRASS session:

run o-help for a list of available commands
C:\>R

R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R ist freie Software und kommt OHNE JEGLICHE GARANTIE.
Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten.
Tippen Sie 'license()' or 'licence()' für Details dazu.

R ist ein Gemeinschaftsprojekt mit vielen Beitragenden.
Tippen Sie 'contributors()' für mehr Information und 'citation()',
um zu erfahren, wie R oder R packages in Publikationen zitiert werden
können.

Tippen Sie 'demo()' für einige Demos, 'help()' für on-line Hilfe, oder
'help.start()' für eine HTML Browserschnittstelle zur Hilfe.
Tippen Sie 'q()', um R zu verlassen.

>

and

C:\>RScript
Usage: /path/to/Rscript [--options] [-e expr [-e expr2 ...] | file] [args]

--options accepted are
  --help  Print usage and exit
  --version   Print version and exit
  --verbose   Print information on progress
  --default-packages=list
  Where 'list' is a comma-separated set
of package names, or 'NULL'
or options to R, in addition to --no-echo --no-restore, such as
  --save  Do save workspace at the end of the session
  --no-environDon't read the site and user environment files
  --no-site-file  Don't read the site-wide Rprofile
  --no-init-file  Don't read the user R profile
  --restore   Do restore previously saved objects at startup
  --vanilla   Combine --no-save, --no-restore, --no-site-file
--no-init-file and --no-environ

'file' may contain spaces but not shell metacharacters
Expressions (one or more '-e ') may be used *instead* of 'file'
See also  ?Rscript  from within R

---
and within a winGRASS session:

Starting GRASS GIS...
WARNUNG: Sperren gleichzeitiger Zugriffe auf ein Mapset ist unter Windows
 nicht möglich.
Cleaning up temporary files...

  __  ___   _____
 / / __ \/   | / ___/ ___/   / /  _/ ___/
/ / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
   / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
   \/_/ |_/_/  |_///   \/___///

Welcome to GRASS GIS 7.8.4
GRASS GIS homepage:  https://grass.osgeo.org
This version running through:Command Prompt
(C:\WINDOWS\system32\cmd.exe)
Help is available with the command:  g.manual -i
See the licence terms with:  g.version -c
See citation options with:   g.version -x
If required, restart the GUI with:   g.gui wxpython
When ready to quit enter:exit

Launching  GUI in the background, please wait...
Microsoft Windows [Version 10.0.19042.685]
(c) 2020 Microsoft Corporation. Alle Rechte vorbehalten.

C:\>R

R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R ist freie Software und kommt OHNE JEGLICHE GARANTIE.
Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten.
Tippen Sie 'license()' or 'licence()' f├╝r Details dazu.

R ist ein Gemeinschaftsprojekt mit vielen Beitragenden.
Tippen Sie 'contributors()' f├╝r mehr Information und 'citation()',
um zu erfahren, wie R oder R packages in Publikationen zitiert werden
k├Ânnen.

Tippen Sie 'demo()' f├╝r einige Demos, 'help()' f├╝r on-line Hilfe, oder
'help.start()' f├╝r eine HTML Browserschnittstelle zur Hilfe.
Tippen Sie 'q()', um R zu verlassen.

Beim Start - Warnmeldungen:
1: Setting LC_CTYPE=de_AT.cp1252 failed
2: Setting LC_COLLATE=de_AT.cp1252 failed
3: Setting LC_TIME=de_AT.cp1252 failed
4: Setting LC_MONETARY=de_AT.cp1252 failed
> q()
Workspace sichern? [y/n/c]: n

C:\>RScri

Re: [GRASS-user] r.futures not working

>It is still not working and the error message is still the same. 

install.packages(c("MuMIn", "lme4", "optparse", "rgrass7")) done?

I got a similar error message when MuMIn wasn't installed.

have you tried in OSGeo4W to switch to an earier rbatch version. then R
should be added automatically to %PATH% and r.future.develop works as
expected, see my earlier mail.

if switched, type R and RScript into the OSGeo4W shell and report here.





-
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] r.futures not working

2020-12-11 Thread Helmut Kudrnovsky

>local R version: 4.03 

and tested in

System Info 
GRASS Version: 7.8.4
Code revision: d8fbd49af
Build date: 2020-10-05  
Build platform: x86_64-w64-mingw32  
GDAL: 3.0.4 
PROJ: 6.3.2 
GEOS: 3.8.1 
SQLite: 3.29.0  
Python: 3.7.0   
wxPython: 4.0.7 
Platform: Windows-10-10.0.19041-SP0 (OSGeo4W)   



-
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] r.futures not working

2020-12-11 Thread Helmut Kudrnovsky

>regarding OSGeo4W-winGRASS, unfortunately there was a change in the rbatch
package recently which >breaks adding R to %PATH%
>
>*start OSGeo4W in advanced mode, type rbatch in the search window on the
top left
>* open the tree of "Command_Utilities" and "Libs" and choose version 149-4
instead of 149-5
>* finish installation
>* open OSGeo4W shell and type R
>* then R should start in OSGeo4W shell 

switched back to rbatch 149-4 here in my OSGeo4W environment.

installed all needed R packages mentioned in the workshop [1]

**R (≥ 3.5.0) - needed for r.futures.potential with packages:
**
**   MuMIn, lme4, optparse, rgrass7

local R version: 4.03

trying the workshop example with r.futures.potential (where R is needed):

r.futures.potential -d input=sampling@user1
output=D:\wd\rfutures\futures_Asheville_files\potential.csv
columns=devpressure_0_5_92,slope,road_dens_perc,forest_1992_smooth_perc,dist_to_water_km,dist_to_protected_km,dist_interchanges_km,travel_time
developed_column=urban_change_clip subregions_column=counties
min_variables=4

Running automatic model selection ... <=

addon invoked RScript for model selection correctly; waiting for calculation
be finished:

WARNING: Beim Start - Warnmeldungen:
1: Setting LC_CTYPE=de_AT.cp1252 failed
2: Setting LC_COLLATE=de_AT.cp1252 failed
3: Setting LC_TIME=de_AT.cp1252 failed
4: Setting LC_MONETARY=de_AT.cp1252 failed
Fixed term is "(Intercept)"
Warnmeldung:
In checkConv(attr(opt, "derivs"), opt$par, ctrl = control$checkConv,  :
Model failed to converge with max|grad| = 0.00403567 (tol = 0.002, component
1)
Best model summary:
-
Generalized linear mixed model fit by maximum likelihood (Laplace
Approximation) [glmerMod]
Family: binomial  ( logit )
Formula: urban_change_clip ~ devpressure_0_5_92 + dist_interchanges_km +
dist_to_protected_km + dist_to_water_km + forest_1992_smooth_perc +
road_dens_perc + slope + travel_time + (1 | counties)
Data: input_data

AIC  BIC   logLik deviance df.resid
2641.7   2708.6  -1310.8   2621.7 5916

Scaled residuals:
Min  1Q  Median  3Q Max
-5.5600 -0.2166 -0.0876 -0.0466 21.1719

Random effects:
Groups   NameVariance Std.Dev.
counties (Intercept) 0.04751  0.218
Number of obs: 5926, groups:  counties, 5

Fixed effects:
Estimate Std. Error z value Pr(>|z|)
(Intercept)  0.952166   0.283639   3.357 0.000788 ***
devpressure_0_5_92   0.030397   0.004947   6.144 8.05e-10 ***
dist_interchanges_km-0.054705   0.013647  -4.009 6.11e-05 ***
dist_to_protected_km-0.205176   0.044363  -4.625 3.75e-06 ***
dist_to_water_km-0.157337   0.025512  -6.167 6.95e-10 ***
forest_1992_smooth_perc -0.044996   0.002423 -18.572  < 2e-16 ***
road_dens_perc   0.080876   0.007976  10.140  < 2e-16 ***
slope0.024958   0.009225   2.705 0.006822 **
travel_time -4.057411   0.439160  -9.239  < 2e-16 ***
---
Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1

Correlation of Fixed Effects:
(Intr) d_0_5_ dst_n_ dst_t_p_ dst_t_w_ f_1992 rd_dn_ slope
dvpr_0_5_92 -0.259
dst_ntrchn_ -0.360  0.284
dst_t_prtc_ -0.303  0.099  0.156
dst_t_wtr_k -0.203  0.119 -0.101 -0.100
frst_1992__ -0.256  0.158 -0.077  0.0450.085
rod_dns_prc -0.378 -0.355 -0.008 -0.094   -0.0630.057
slope   -0.151  0.058  0.061 -0.006   -0.093   -0.520 -0.009
travel_time -0.558 -0.116  0.029  0.0360.0140.101  0.167 -0.013
(Fri Dec 11 23:14:30 2020) Befehl ausgeführt (9 Min 3 Sek)  

findings:

- there is some locale issue: Setting LC_CTYPE=de_AT.cp1252 failed - it's a
german windows 10 box here
- In checkConv(attr(opt, "derivs"), opt$par, ctrl = control$checkConv,  : <=
not sure about this one here
- Model failed to converge with max|grad| = 0.00403567 (tol = 0.002,
component 1) <= maybe related to input data (not checked if these make
sense)
- Best model summary:
-
Generalized linear mixed model fit by maximum likelihood (Laplace
Approximation) [glmerMod]

though it seems a best model could be found

to sum up, r.futures.potential invoking some R scripts works here in OSGeo4W
using rbatch 149-4 

[1]
https://grasswiki.osgeo.org/wiki/Workshop_on_urban_growth_modeling_with_FUTURES#Workshop_data





-
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] r.futures not working

2020-12-11 Thread Helmut Kudrnovsky

[keep always the mailing list in the loop that other community members are able 
to help too respectively benefit from the thread]

regarding OSGeo4W-winGRASS, unfortunately there was a change in the rbatch 
package recently which breaks adding R to %PATH%

*start OSGeo4W in advanced mode, type rbatch in the search window on the top 
left
* open the tree of "Command_Utilities" and "Libs" and choose version 149-4 
instead of 149-5
* finish installation
* open OSGeo4W shell and type R
* then R should start in OSGeo4W shell

regarding Mac, others have to answer, no Mac available here.

kind regards
Helmut 
 

Gesendet: Freitag, 11. Dezember 2020 um 10:19 Uhr
Von: "Tom Hackbarth" 
An: "Helmut Kudrnovsky" 
Betreff: Re: [GRASS-user] r.futures not working

Hi Helmut,
 
I tried it now on mac as well. I get to the same point. 
 


Computing model...
Traceback (most recent call last):
  File "/Users//Library/GRASS/7.8/Modules/scripts/r
.futures.potential", line 221, in 
    sys.exit(main())
  File "/Users//Library/GRASS/7.8/Modules/scripts/r
.futures.potential", line 192, in main
    p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
  File "/Applications/GRASS-7.8.app/Contents/Resources/lib/p
ython3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn,
close_fds,
  File "/Applications/GRASS-7.8.app/Contents/Resources/lib/p
ython3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg,
err_filename)
FileNotFoundError: [Errno 2] No such file or directory:
'Rscript'
 
___
 
I got the latest versions of R, python and Grass installed. I get the same 
error message on Windows, mac and Manjaro. 
 
 
Do you know where the problem is?
 
Best regards
 
Tom 

Am Fr., 11. Dez. 2020 um 09:36 Uhr schrieb Tom Hackbarth 
mailto:txhackba...@gmail.com]>:
Hi Helmut,
 
I've been using the OSGeo4W installer for everything, as it was suggested in 
the r.futures workshop.
 
I'm using Python 3.7, but I tried already different versions (2.7, 3.9) in the 
process of trying to fix the problem. 
I do not know whether it is bundled with grass though. How can I figure that 
out?
 
Thanks for your help!
 
Warm regards
 
Tom 

Am Do., 10. Dez. 2020 um 19:31 Uhr schrieb Helmut Kudrnovsky 
mailto:hel...@web.de]>:Tom Hackbarth wrote
> Dear grass users,
>
> I am trying to work my way through the r.futures workshop (
> https://grasswiki.osgeo.org/wiki/Workshop_on_urban_growth_modeling_with_FUTURES#Potential_submodel[https://grasswiki.osgeo.org/wiki/Workshop_on_urban_growth_modeling_with_FUTURES#Potential_submodel]),
> but as soon as I get to the point of using the first r.futures module -
> r.futures-potential I come to a dead end.
>
> This is the message I get:
>
> ___
>
> r.futures.potential input=sampling@practice1 output=potential.csv
> columns=devpressure_0_5_92,road_dens_perc,forest_1992_smooth_perc,dist_to_water_km,dist_to_protected_km
> developed_column=urban_change_clip subregions_column=counties
> Computing model...
> Traceback (most recent call last):
>   File "C:\Users\\AppData\Roaming\GRASS7\addons/scripts
> /r.futures.potential.py[http://r.futures.potential.py]";, line 221, in
> 
>     sys.exit(main())
>   File "C:\Users\\AppData\Roaming\GRASS7\addons/scripts
> /r.futures.potential.py[http://r.futures.potential.py]";, line 192, in main
>     p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
> stderr=subprocess.PIPE)
>   File "D:\Programme\apps\Python37\lib\subprocess.py", line
> 756, in __init__
>     restore_signals, start_new_session)
>   File "D:\Programme\apps\Python37\lib\subprocess.py", line
> 1155, in _execute_child
>     startupinfo)
> FileNotFoundError: [WinError 2] The system cannot find the file specified)
>
>
> _
>
> There seems to be a problem with the Python code. I also tried to work it
> out on linux manjaro, but I get more or less the same error message in the
> End.
>
> Is there anyone who can help me on this? I came not even close to
> repairing the error, so I am happy about any advice one can give me.
>
> Thank you in advance.
>
> Best regards
>
> Tom
>
> ___
> grass-user mailing list

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user[https://lists.osgeo.org/mailman/listinfo/grass-user]


which winGRASS version are you using? standalone winGRASS? OSGeo4W winGRASS?
QGIS bundled winGRASS?

>D:\Programme\apps\Python37\

which python are you using? is it the phyton bundled with winGRASS?



-
best regards
Helmut
--
Sent from: 
http:

Re: [GRASS-user] r.futures not working

2020-12-10 Thread Helmut Kudrnovsky

Tom Hackbarth wrote
> Dear grass users,
> 
> I am trying to work my way through the r.futures workshop (
> https://grasswiki.osgeo.org/wiki/Workshop_on_urban_growth_modeling_with_FUTURES#Potential_submodel),
> but as soon as I get to the point of using the first r.futures module -
> r.futures-potential I come to a dead end.
> 
> This is the message I get:
> 
> ___
> 
> r.futures.potential input=sampling@practice1 output=potential.csv
> columns=devpressure_0_5_92,road_dens_perc,forest_1992_smooth_perc,dist_to_water_km,dist_to_protected_km
> developed_column=urban_change_clip subregions_column=counties
> Computing model...
> Traceback (most recent call last):
>   File "C:\Users\\AppData\Roaming\GRASS7\addons/scripts
> /r.futures.potential.py", line 221, in 
> 
> sys.exit(main())
>   File "C:\Users\\AppData\Roaming\GRASS7\addons/scripts
> /r.futures.potential.py", line 192, in main
> p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
> stderr=subprocess.PIPE)
>   File "D:\Programme\apps\Python37\lib\subprocess.py", line
> 756, in __init__
> restore_signals, start_new_session)
>   File "D:\Programme\apps\Python37\lib\subprocess.py", line
> 1155, in _execute_child
> startupinfo)
> FileNotFoundError: [WinError 2] The system cannot find the file specified)
> 
> 
> _
> 
> There seems to be a problem with the Python code. I also tried to work it
> out on linux manjaro, but I get more or less the same error message in the
> End.
> 
> Is there anyone who can help me on this? I came not even close to
> repairing the error, so I am happy about any advice one can give me.
> 
> Thank you in advance.
> 
> Best regards
> 
> Tom
> 
> ___
> grass-user mailing list

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user


which winGRASS version are you using? standalone winGRASS? OSGeo4W winGRASS?
QGIS bundled winGRASS?

>D:\Programme\apps\Python37\

which python are you using? is it the phyton bundled with winGRASS?



-
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] Can someone help me troubleshoot GRASS on Windows 10

2020-09-30 Thread Helmut Kudrnovsky

do: gdalinfo your-UTM-projected-DEM

>I am trying to use it inside of QGIS 3.12. 

GRASS GIS is bundled with QGIS 3.12. start GRASS GIS itself.

- create location based upon your-UTM-projected-DEM
- g.proj -p
- r.external input=your-UTM-projected-DEM output=linked_dem
- g.region -p -a raster=linked_dem align=linked_dem



-
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] Can someone help me troubleshoot GRASS on Windows 10

2020-09-29 Thread Helmut Kudrnovsky

Eric Eagle wrote
> Hi GRASS users,
> 
> Longtime GIS'er but newbie to GRASS.  I've never been able to get it to
> work properly on my workstation and have always fallen back on Esri or,
> QGIS built-in functions.  Now I am in a situation where I have to get
> GRASS to work because it seems like the fastest way to do some hydro
> things.  I am trying to use it inside of QGIS 3.12.
> 
> Here is my problem.  I have a UTM-projected DEM as input, I just want to
> run r.flow and it fails, reporting:
> 
> "The following layers were not correctly generated. 
> C:/Users/username/AppData/Local/Temp/1/processing_ipancU/89aab5fc64c6999046d99c2e0028b/flowaccumulation.tif
> C:/Users/username/AppData/Local/Temp/1/processing_ipancU/bded4092193446b883446b88344c55272310fa8/flowlength.tif
> C:/Users/username/AppData/Local/Temp/1/processing_ipancU/f4a65331b4ef4fa5a6b2ba826efdd9b4/flowline.gpkg
> 
> You can check the 'Log Messages Panel' in QGIS main window to find more
> information about the execution of the algorithm."
> 
> 
> However, when I check the log messages panel, here is what I see:
> 
> Grass7 tab: only INFO level messages showing the original command payload
> 
> all the other tabs: nothing
> 
> So, not much given to troubleshoot.  This behavior happens with *every*
> GRASS tool I try to run, including even v.buffer.  So something is
> definitely not right.
> 
> *About my setup*
> 
> I do not have admin access rights to my workstation as this is a
> production box in a big enterprise.  However I do have access to write to
> C:/ directories outside of the typical locked down stuff (Program Files,
> Program Files (x86), etc).  I have QGIS currently installed to C:\QGIS_3
> and GRASS sits under that.  The workstation is not connected to the
> internet in case that matters.

some more details are needed:

* which GRASS GIS version used
* g.proj -p output
* g.region -p output
* exact command failing

I guess it has nothing to do with windows 10. works here on several windows
10 boxes.




-
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] Download release sources?

2020-08-14 Thread Helmut Kudrnovsky

SBL wrote
> Hello Hernán,
> 
> Best place to look for the source code of the different releases is
> probably here:
> https://github.com/OSGeo/grass/releases
> 
> @website-devs: I see that Download source code shows up as an option on
> the landing page (https://grass.osgeo.org/download/), but not in the menu.
> Maybe worth adding a subpage for download of source code?


source code of all releases version > 5 are here available:

http://download.osgeo.org/grass/





-
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] Sqlite error when calling GRASS GIS outside of GRASS

2020-08-07 Thread Helmut Kudrnovsky

[in a windows console/osgeo4w console you can mark the content with the mouse, 
then press return on the keybord, then you
can paste the content as normal text into a mail, no screenshot needed}
 
>When I run the where from the windows console I get this: 

there is a sqlite dll hell caused by ArcGIS and anaconda.

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

Re: [GRASS-user] Sqlite error when calling GRASS GIS outside of GRASS

2020-08-07 Thread Helmut Kudrnovsky

>I am getting this error:
>
>Process ended with non-zero return code 3221225785. See errors in the
(error)

it's a dll mixing/mismatch due to more of the same dll  in your %PATH%.

which library errored the message above? (sqlite? gdal?)

>g.run_command(r'C:\OSGeo4W64\apps\grass\grass78\bin\g.proj.exe',
georef=geotiff, location = >locationGeonet)

really an unusual way to invoke g.proj. never saw this working.

>I think this is a conflict with the sqlite3.dll as is suggested the below
wiki but the solutions there have >not worked for me.
>
>https://grasswiki.osgeo.org/wiki/WinGRASS_errors

which solutions did you try?

just open a normal windows console and type:

C:\Users\yourusername>where "$path:sqlite3*"

it's checking sqlite3 in your %PATH%

report back in your case.

when I open the OSGeo4W shell, I get

C:\>where "$path:sqlite3*"
C:\Program Files\QGIS 3.4\bin\sqlite3.dll
C:\Program Files\QGIS 3.4\bin\sqlite3.exe

is there a windows console availabe in the Spyder/ Anaconda framework? if
yes, then type where "$path:sqlite3*" and report back.

have you seen:

https://github.com/OSGeo/grass/issues/679

?

and the mentioned thread:

https://stackoverflow.com/questions/53682315/error-on-libcurl-dll-when-using-gdal-of-osgeo4w-in-django



-
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] v.to.db in GRASS 7.8 requires 'overwrite' if column exists but flag is invalid

2020-07-16 Thread Helmut Kudrnovsky

Mira Kattwinkel wrote
> Dear list,
> 
> 
> in GRASS 7.8 v.to.db creates a new column in contrast to previous 
> versions where it column had to exist before.
> 
> According to the manual "If the /column/ exists, the *--overwrite* flag 
> is required to overwrite it". However, this flag does not exist. Hence, 
> if the column is present, it is not upated, giving:
> 
> ERROR: Column 
> 
>  exists. To overwrite, use the --overwrite flag
> 
> When useing "overwrite", it gives:
> 
> Invalid flag value: overwrite
> 
> 
> Another issue is that even if the flag would work, it would no longer be 
> compatible with previous versions that also do not know the flag but 
> need the column to exist.
> 
> 
> Can anybody please advice me what to do?


yes there was a change in the module behaviour, see

https://github.com/OSGeo/grass/issues/770

I had the same issue.

regarding using this new behaviour in scripts, see e.g.

https://github.com/OSGeo/grass-addons/commit/943d9c72a51716608f6a358a40dd114e38eaa9cf

on the command line, just add --overwrite,

e.g. v.to.db --overwrite map=soils type=centroid option=area
columns=area_size unit=h

but in the v.to.db GUI, there is no overwrite available.

please open an issue about that.



-
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] [R] Need help using GRASS within R - error when running the script for a second time

2020-07-07 Thread Helmut Kudrnovsky

>ERRORS WHEN I RUN THE SCRIPT FOR A SECOND TIME :
>
>  - FROM WINDOWS : g.region.exe : the procedure entry point
> GEOSMakeValid_r could not be located in the dynamic link library
> C:\Program Files\GRASS GIS 7.8\extrabin\gdal300.dll

this looks like a dll mismatch. more than one GDAL seems to be in %PATH%



-
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] r.hants and r.series.lwr in Windows

2020-06-26 Thread Helmut Kudrnovsky

>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

2020-06-26 Thread Helmut Kudrnovsky

>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*

trying here with:

-

r.series.lwr -l -h -i 
input=ETact_SEBAL_2019_03_mm_month@TMPMAP,ETact_SEBAL_2019_04_mm_month@TMPMAP,ETact_SEBAL_2019_05_mm_month@TMPMAP,ETact_SEBAL_2019_06_mm_month@TMPMAP,ETact_SEBAL_2019_07_mm_month@TMPMAP,ETact_SEBAL_2019_08_mm_month@TMPMAP,ETact_SEBAL_2019_09_mm_month@TMPMAP,ETact_SEBAL_2019_10_mm_month@TMPMAP,ETact_SEBAL_2019_11_mm_month@TMPMAP
 order=2 fet=0.5 dod=3 range=0,10 maxgap=3



r.univar map=ETact_SEBAL_2019_03_mm_month_lwr@TMPMAP
total null and non-null cells: 10413
total null cells: 417
Of the non-null cells:
--
n: 9996
minimum: 0
maximum: 78.5551
range: 78.5551
mean: 5.9911
mean of absolute values: 5.9911
standard deviation: 11.3704
variance: 129.287
variation coefficient: 189.789 %
sum: 59887.0226345476



the issue is here in your original command:

range=0,inf

winGRASS doesn't recognize inf or INF as infinity.

there is somewhere an old ticket in trac. please open an issue in github for 
this.

kind regards
Helmut

[p.s. it's not possible anymore to post via nabble.com in the GRASS ML: 
Read-Only Archive. You cannot post here. This is a read-only archive. was there 
any change there in the settings?]
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Estimating import time for large data file

2020-05-31 Thread Helmut Kudrnovsky

Rich Shepard wrote
> On Sun, 31 May 2020, Helmut Kudrnovsky wrote:
> 
>> it seems the projection of your data (+proj=merc) doesn't correpond to
>> the
>> Enterprise Office's projections you mentioned (+proj=lcc, +proj=lcc,
>> +proj=longlat)
> 
> Helmut,
> 
> That's true. So I created a new location for this huge shapefile. The
> issue
> has nothing to do with the projection but the time to import it. And
> Moritz
> and Markus N. both suggested using ogr2ogr with a simplify value. My
> question is how to select that value for a first try.
> 
> Thanks very much,
> 
> Rich
> ___
> grass-user mailing list

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user

I think it is EPSG 3857.

Have you read the wiki entry (from the link I mentioned in a previous mail)?

taken from there:

"While the Web Mercator's formulas are for the spherical form of the
Mercator, geographical coordinates are required to be in the WGS 84
ellipsoidal datum. This discrepancy causes the projection to be slightly
non-conformal. General lack of understanding that the Web Mercator differs
from standard Mercator usage has caused considerable confusion and
misuse.[4]:87 For all these reasons, the United States Department of Defense
through the National Geospatial-Intelligence Agency has declared this map
projection to be unacceptable for any official use.[7]"

thus I suggest, as already before, to use another projection appropriate for
your working area. 

regarding values for ogr2ogr, maybe ask also on the GDAL mailing list .

-
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] Estimating import time for large data file

2020-05-31 Thread Helmut Kudrnovsky

Rich Shepard wrote
> On Sun, 31 May 2020, Helmut Kudrnovsky wrote:
> 
>> is it
>> EPSG:3857 [1] [2]
>> ?
> 
> Helmut,
> 
> I've no idea. This dataset was downloaded from the Oregon Geospatial
> Enterprise Office (clever name, eh?). The introductory page is here:
> <https://www.oregon.gov/geo/Pages/sdlibrary.aspx>;.
> 
> Oregon provides data in three projections:
> 
> # Oregon state standard:
> EPSG 2838  NAD83(HARN)
> <http://www.spatialreference.org/ref/epsg/2838/>;
> proj4: +proj=lcc +lat_1=46 +lat_2=44.34
> +lat_0=43.66 +lon_0=-120.5 +x_0=250 +y_0=0 +ellps=GRS80
> +units=m +no_defs
> 
> # Oregon lon/lat in Lambert Conformal Conic:
> EPSG 2992 +proj=lcc +lat_1=43 +lat_2=45.5 +lat_0=41.75 +lon_0=-120.5
> +x_0=39.984 +y_0=0 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048
> +no_defs
> 
> # Oregon lon/lat in WGS84.
> EPSG 4326: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs
> 
> I keep all Oregon spatial data using the first projection. But, sometimes
> a
> dataset is in another projection. When I started importing it into
> grass-7.9.dev I set the projection based on the .prj file and didn't see
> the
> EPSG code it represented.

>PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",
>GEOGCS["GCS_WGS_1984",
>DATUM["D_WGS_1984",
>SPHEROID["WGS_1984",6378137.0,298.257223563]],
>PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],
>PROJECTION["Mercator_Auxiliary_Sphere"],  <=
>PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],
>PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],
>PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0]]

--

C:\>projinfo EPSG:3857
PROJ.4 string:
+proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1
+units=m +nadgrids=@null +wktext +no_defs +type=crs

WKT2:2019 string:
PROJCRS["WGS 84 / Pseudo-Mercator",
BASEGEOGCRS["WGS 84",
DATUM["World Geodetic System 1984",
ELLIPSOID["WGS 84",6378137,298.257223563,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4326]],
CONVERSION["Popular Visualisation Pseudo-Mercator",
METHOD["Popular Visualisation Pseudo Mercator",
ID["EPSG",1024]],
PARAMETER["Latitude of natural origin",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["False easting",0,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",0,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["easting (X)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing (Y)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["unknown"],
AREA["World - 85┬░S to 85┬░N"],
BBOX[-85.06,-180,85.06,180]],
ID["EPSG",3857]]

--

C:\>projinfo EPSG:2838
PROJ.4 string:
+proj=lcc +lat_0=43.7 +lon_0=-120.5 +lat_1=46
+lat_2=44.3 +x_0=250 +y_0=0 +ellps=GRS80
+towgs84=0,0,0,0,0,0,0 +units=m +no_defs +type=crs

WKT2:2019 string:
PROJCRS["NAD83(HARN) / Oregon North",
BASEGEOGCRS["NAD83(HARN)",
DATUM["NAD83 (High Accuracy Reference Network)",
ELLIPSOID["GRS 1980",6378137,298.257222101,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4152]],
CONVERSION["SPCS83 Oregon North zone (meters)",
METHOD["Lambert Conic Conformal (2SP)",
ID["EPSG",9802]],
PARAMETER["Latitude of false origin",43.7,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8821]],
PARAMETER["Longitude of false origin",-120.5,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8822]],
PARAMETER["Latitude of 1st standard parallel",46,
ANGLEUNIT["degree",0.0174532925199433],
ID

Re: [GRASS-user] Estimating import time for large data file

2020-05-31 Thread Helmut Kudrnovsky

Rich Shepard wrote
> On Sun, 31 May 2020, Markus Neteler wrote:
> 
>> I didn't confirm at all :-) It was just an information or warning.
> 
> Markus,
> 
> Using ogr2ogr was what Moritz suggested.
> 
>> I'd stick to submeter but I don't know what data you are working with
>> nor what their resolution/scale is...
> 
> This is what the *.prj file has to offer:
> 
> PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",GEOGCS["GCS_WGS_1984",
> DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],
> PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],
> PROJECTION["Mercator_Auxiliary_Sphere"],
> PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],
> PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],
> PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0]]
> 
> How sub a submeter would be a good start?

is it 

EPSG:3857 [1] [2]

?

keep in mind the scope of this projection is Web mapping and visualisation
applications, not heavy GIS processing.

from [1]

"Remarks: Uses spherical development of ellipsoidal coordinates. Relative to
WGS 84 / World Mercator (CRS code 3395) errors of 0.7 percent in scale and
differences in northing of up to 43km in the map (equivalent to 21km on the
ground) may arise. "

better to use a projection appropriate to your working area.

[1] http://epsg.io/3857
[2] https://en.wikipedia.org/wiki/Web_Mercator_projection




-
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] Problems with v.what.rast

2020-05-28 Thread Helmut Kudrnovsky

Uwe Fischer wrote
> Hello list,
> 
>  
> 
> I have big trouble with v.what.rast and I dont know why. I have read that
> there are issues with point data sets that have 2 layers, but that is not
> true for my points. They come from shape format using v.in.ogr and have
> normal cat values.
> 
> V.info tells me that there are 22 points. But v.what.rast tells me there
> are
> not points (please see attachments). That is very very confusing, since
> there are 22 points definitely. Maybe there is something wrong with the
> points, but they do exist. It would be a great improvement to update the
> error message in such a case, telling whats wrong with the points.
> 
>  
> 
> However, I tried the steps that are described in the grass help page in
> order to learn whats wrong, but the exact same thing happened (please see
> other attachments): no features of type point found.
> 
>  
> 
> What am I doing wrong?

what does

* g.region -p
* v.info -g
* r.info -g

print?




-
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] python 'NamError' r.landscape.evol

2020-05-01 Thread Helmut Kudrnovsky

Maria Cecilia Zalazar wrote
> Hello. In previous (win)grass versions I was able to work with
> r.landscape.evol addon. Now with 7.8.2 wingrass version appears a python
> NameError:
> 
> 
> 
> *r.landscape.evol elev=DEM_21x21@PERMANENT initbdrk=0 smoothing=no
> prefx=levol_test outdem=elevation_test outsoil=soildepth_test number=1*
> 
> *Traceback (most recent call last):*
> 
> *  File "C:\Users\USUARIO\AppData\Roaming\GRASS7\addons/scrip*
> 
> *ts/r.landscape.evol.py ";, line 665, in
> 
> *
> 
> *f = file(statsout, 'wt')*
> 
> *NameError: name 'file' is not defined*
> 
> 
> 
> It seems that the script was written in Python < 3 and ‘file()’ is not
> supported in Python 3. Is possible that the addon needs to transform into
> valid Python 3.x code?
> 
> Thanks for your help!
> 
> ___
> grass-user mailing list

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user

I opened an issue here:

https://github.com/OSGeo/grass-addons/issues/156

Just comment or if you have a solution, open a PR there





-
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] python 'NamError' r.landscape.evol

2020-05-01 Thread Helmut Kudrnovsky

Maria Cecilia Zalazar wrote
> Hello. In previous (win)grass versions I was able to work with
> r.landscape.evol addon. Now with 7.8.2 wingrass version appears a python
> NameError:
> 
> 
> 
> *r.landscape.evol elev=DEM_21x21@PERMANENT initbdrk=0 smoothing=no
> prefx=levol_test outdem=elevation_test outsoil=soildepth_test number=1*
> 
> *Traceback (most recent call last):*
> 
> *  File "C:\Users\USUARIO\AppData\Roaming\GRASS7\addons/scrip*
> 
> *ts/r.landscape.evol.py ";, line 665, in
> 
> *
> 
> *f = file(statsout, 'wt')*
> 
> *NameError: name 'file' is not defined*
> 
> 
> 
> It seems that the script was written in Python < 3 and ‘file()’ is not
> supported in Python 3. Is possible that the addon needs to transform into
> valid Python 3.x code?
> 
> Thanks for your help!

some hints e.g. here:

https://stackoverflow.com/questions/28121163/python-3-doesnt-have-the-file-function/28121192





-
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] running a simple python script on windows

2020-04-16 Thread Helmut Kudrnovsky

ivan.marchesini wrote
> Dear Grass friends,
> 
> I prepared a simple python3 script that runs correctly using Grass 7.8 
> on GNU/Linux.
> 
> I put the module in the script folder of /usr/lib/grass78.  The parser 
> is able to open the interface and the module runs.
> 
> Someone asked me to run the same script using Grass on Windows (the 
> standalone version 7.8).
> 
> I put the script on the  "C:\Program Files\GRASS GIS 7.8\scripts" folder.
> 
> When I run a the script,  even only with the --help option 
> (mySimpleGrassScript --help) from the Layer Manager Console, i get the 
> error listed at the end of this e-mail.
> 
> May I kindly ask your help to understand what I have to check or to 
> modify in order to run the code on window ?
> 
> thank you very much
> 
> Ivan
> 
> 
> The error I get:
> 
> __
> 
> Traceback (most recent call last):
>    File "C:\Program Files\GRASS GIS
> 7.8\etc\python\grass\script\task.py", line 474, in
> get_interface_description
> 
> stderr=PIPE)
>    File "C:\Program Files\GRASS GIS
> 7.8\etc\python\grass\script\core.py", line 57, in __init__
> 
> .format(args[0]))
> OSError
> :
> Cannot find the executable mySimpleGrassScript
> During handling of the above exception, another exception
> occurred:
> Traceback (most recent call last):
>    File "C:\Program Files\GRASS GIS
> 7.8\gui\wxpython\gui_core\forms.py", line 2866, in
> ParseCommand
> 
> blackList=_blackList)
>    File "C:\Program Files\GRASS GIS
> 7.8\etc\python\grass\script\task.py", line 522, in
> parse_interface
> 
> tree = etree.fromstring(get_interface_description(name))
>    File "C:\Program Files\GRASS GIS
> 7.8\etc\python\grass\script\task.py", line 502, in
> get_interface_description
> 
> "\n\nDetails: <{det}>").format(cmd=cmd, det=e))
> grass.exceptions
> .
> ScriptError
> :
> Unable to fetch interface description for command
> '
> 
> '.
> Details: 
>  mySimpleGrassScript>
> During handling of the above exception, another exception
> occurred:
> Traceback (most recent call last):
>    File "C:\Program Files\GRASS GIS
> 7.8\gui\wxpython\core\gconsole.py", line 493, in RunCmd
> 
> task = GUI(show=None).ParseCommand(command)
>    File "C:\Program Files\GRASS GIS
> 7.8\gui\wxpython\gui_core\forms.py", line 2868, in
> ParseCommand
> 
> raise gcmd.GException(e.value)
> core.gcmd
> .
> GException
> :
> Unable to fetch interface description for command
> '
> 
> '.
> Details: 
>  mySimpleGrassScript>
> During handling of the above exception, another exception
> occurred:
> Traceback (most recent call last):
>    File "C:\Program Files\GRASS GIS
> 7.8\gui\wxpython\gui_core\prompt.py", line 413, in
> OnKeyPressed
> 
> self._runCmd(self.GetCurLine()[0].strip())
>    File "C:\Program Files\GRASS GIS
> 7.8\gui\wxpython\gui_core\prompt.py", line 120, in _runCmd
> 
> self.promptRunCmd.emit(cmd=cmd)
>    File "C:\Program Files\GRASS GIS
> 7.8\etc\python\grass\pydispatch\signal.py", line 229, in
> emit
> 
> dispatcher.send(signal=self, *args, **kwargs)
>    File "C:\Program Files\GRASS GIS
> 7.8\etc\python\grass\pydispatch\dispatcher.py", line 349, in
> send
> 
> **named
>    File "C:\Program Files\GRASS GIS
> 7.8\etc\python\grass\pydispatch\robustapply.py", line 60, in
> robustApply
> 
> return receiver(*arguments, **named)
>    File "C:\Program Files\GRASS GIS
> 7.8\gui\wxpython\gui_core\goutput.py", line 120, in 
> 
> self._gconsole.RunCmd(command=cmd))
>    File "C:\Program Files\GRASS GIS
> 7.8\gui\wxpython\core\gconsole.py", line 496, in RunCmd
> 
> message=unicode(e),
> NameError
> :
> name 'unicode' is not defined

you need a corresponding bat-file in the \bin subfolder, e.g.

grass78\bin\i.tasscap.bat

with this content

@"%GRASS_PYTHON%" "%GISBASE%/scripts/i.tasscap.py" %*

which you have to adapt accordingly.



-
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] Fwd: GRASS GIS problem from OSGeo4W Setup

2020-02-04 Thread Helmut Kudrnovsky

Valter Albino wrote
> Hi Helmut,
> Same problems
> See attached pdf file:
> https://drive.google.com/open?id=1k-Ki6uIOPunHlRuCDQTesWKtM4HsKbB2

in the first error messages:

postinstall/qgis-rel-dev.bat
^^

postinstall/qgis-common.bat
   ^^^

these aren't GRASS GIS issues. these have to be reported in QGIS!

wild guess: are you try to use QGIS dev versions and QGIS release versions
in OSGeo4W at the same time?

that's no good idea as, AFAIK, qgis-dev versions in OSGeo4W are depending on
gdal dev versions; a library mixing may be on the way 

tested here on several 64bit win 10 boxes with this combination of regular
qgis releases (ltr and latest) and grass gis release and grass gis dailys,
all available in OSGeo4W:

qgis ltr 3.4.15-1
qgis 3.10.2-2

grass 7.8.2-1
grass 7.9.dev-b98dc112d-90

no error so far on about 5 different win 10 boxes.

suggestions:

delete the OSGeo4W environment completly and set it up freshly with grass
gis/qgis combinantions mentioned above. no qgis-dev versions should be
activated.

if issues with qgis still pop up again, these should be reported there.





-
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] Fwd: GRASS GIS problem from OSGeo4W Setup

2020-02-04 Thread Helmut Kudrnovsky

>Should post some discussion there?

see

https://lists.osgeo.org/pipermail/osgeo4w-dev/2020-February/003868.html



-
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] r.flow function

2020-02-03 Thread Helmut Kudrnovsky

>Don't understand the presence of 1, he is absent in the formula. >Neither
the choice of number 50.

you're right, the ultimative authority is the source code  :-)

https://github.com/OSGeo/grass/tree/master/raster/r.flow

someone more familiar with these lines of code will probably have a better
answer   :-)



-
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] r.flow function

2020-02-03 Thread Helmut Kudrnovsky

Valter Albino wrote
> Good afternoon
> 
> From the function "r.flow" (
> https://grass.osgeo.org/grass78/manuals/r.flow.html), can some expert
> explain me what is the meaning of: "val-th" and the meaning of: "max(1, 
>  in elevation>
> /50, 
> 
> /50)."

no expert here on my side, though, from the manual:

skip=integer
Number of cells between flowlines

Another option, skip, indicates that only the flowlines from every val-th
cell are to be included in flowline. 

=> it may be something like: val-th value is the threshold value given by
skip

The default skip is max(1, /50, /50)

=> it's the calculation of the default skip value if no skip=integer figure
is given.

see the r.mapcalc manual:
https://grass.osgeo.org/grass78/manuals/r.mapcalc.html

max(x,y[,z...]) largest value of those listed 

contribution for precising the manual welcome.






-
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] Fwd: GRASS GIS problem from OSGeo4W Setup

qgis-common.bat exit code error isn't a GRASS error; this should be reported
in QGIS and OSGeo4W.

OTOH, just tested it here locally on my 64bit OSGeo4W in a win 10 box,
OSGeo4W updating and working with it (GRASS version: 7.8.2 , GRASS version:
7.9.dev, QGIS version 3.10.2-A Coruña) is ok.

though C:\>gdalinfo --version
GDAL 3.0.3, released 2020/01/08

and the OSGeo4W setup says that gdal is on GDAL 3.0.4-1.

no clue so far ...




-
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] Fwd: GRASS GIS problem from OSGeo4W Setup

Valter Albino wrote
> OK, glad to learn.
> Here it is:
> 
> "
> run o-help for a list of available commands
> C:\Users\Particular\Desktop>where gdal300.dll
> C:\OSGeo4W64\bin\gdal300.dll
> 
> C:\Users\Particular\Desktop>gdalinfo --version
> GDAL 3.0.3, released 2020/01/08
> 
> C:\Users\Particular\Desktop>
> "
> 
> Cumprimentos,
> *Valter Albino -* Geógrafo Físico, M.Sc.
> Modelação H&H / Riscos ambientais / OT&U
> www.valteralbino.wixsite.com/hydrodynamics
> 
> 
> Helmut Kudrnovsky <

> hellik@

> > escreveu no dia domingo, 2/02/2020 à(s)
> 20:51:
> 
>> it needs - twice, I.e.
>>
>> gdalinfo --version
>>
>> p.s. you don't need to add screenshots, you can copy/paste from the
>> windows
>> console by marking the windows console with the mouse and and press
>> return
>> on the Keyboard and then paste it in your mail.
>>
>>
>>
>> -
>> best regards
>> Helmut
>> --
>> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
>> ___
>> grass-user mailing list
>> 

> grass-user@.osgeo

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

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user

According to 

https://lists.osgeo.org/pipermail/gdal-dev/2020-January/051582.html

http://download.osgeo.org/osgeo4w/x86_64/release/gdal/

It should be gdal 3.0.4 in OSGeo4W. 

Start your OSGeo4W setup, filter for gdal (filter function on the top) and
see which gdal versions are shown there.



-
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] Fwd: GRASS GIS problem from OSGeo4W Setup

it needs - twice, I.e.

gdalinfo --version 

p.s. you don't need to add screenshots, you can copy/paste from the windows
console by marking the windows console with the mouse and and press return
on the Keyboard and then paste it in your mail.



-
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] Fwd: GRASS GIS problem from OSGeo4W Setup

>And what does gdalinfo --version on the OSGeo4W shell say?

?



-
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] Fwd: GRASS GIS problem from OSGeo4W Setup

try to type into the OSGeo4W shell:

C:\>where gdal300.dll

And what does gdalinfo --version on the OSGeo4W shell say?



-
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] Fwd: GRASS GIS problem from OSGeo4W Setup

Valter Albino wrote
> OK, thanks,
> It opens but i'm not able to enter.
> I will erase all and start to install all over again
> Cumprimentos,
> *Valter Albino -* Geógrafo Físico, M.Sc.
> Modelação H&H / Riscos ambientais / OT&U
> www.valteralbino.wixsite.com/hydrodynamics
> 
> 
> Helmut Kudrnovsky <

> hellik@

> > escreveu no dia domingo, 2/02/2020 à(s)
> 10:16:
> 
>> Valter Albino wrote
>> > Hi Helmut,
>> >
>> > Thanks for reply.
>> > Feel embarrassed, since i can't find the file path you mention.
>> > Tried to install again, but the error remains, starting in the
>> > installation:
>> >
>> > [image: Capturar.GIF]
>> >
>> > In my portable PC i did the same but didn't give error, so can run
>> GRASS
>> > GIS with no problems.
>> > I didn't change the language
>> >
>> >
>> > Cumprimentos,
>> > *Valter Albino -* Geógrafo Físico, M.Sc.
>> > Modelação H&H / Riscos ambientais / OT&U
>> > www.valteralbino.wixsite.com/hydrodynamics
>> >
>> >
>> > Helmut Kudrnovsky <
>>
>> > hellik@
>>
>> > > escreveu no dia domingo, 2/02/2020 à(s)
>> > 08:48:
>> >
>> >> Valter Albino wrote
>> >> > Regarding the issue, this message is also important (during
>> >> instalation):
>> >> >
>> >> > [image: ScreenHunter_31 Feb. 01 20.04.gif]
>> >> >
>> >> >
>> >> > Cumprimentos,
>> >> > *Valter Albino -* Geógrafo Físico, M.Sc.
>> >> > Modelação H&H / Riscos ambientais / OT&U
>> >> > www.valteralbino.wixsite.com/hydrodynamics
>> >> >
>> >> >
>> >> > -- Forwarded message -
>> >> > De: Valter Albino <
>> >>
>> >> > valteralbino@
>> >>
>> >> > >
>> >> > Date: sábado, 1/02/2020 à(s) 19:52
>> >> > Subject: GRASS GIS problem from OSGeo4W Setup
>> >> > To: grass-user <
>> >>
>> >> > grass-user@.osgeo
>> >>
>> >> > >
>> >> >
>> >> >
>> >> > Hi
>> >> >
>> >> > *1)* Trying to install GRASS 7.8.2 or 7.9.dev but have the following
>> >> > message:
>> >> > "
>> >> > OSGeo4W Setup - Running postinstall scripts
>> >> >
>> >> > Postinstall script errors
>> >> > These do not necessarly mean that affectes packages will fail to
>> >> function
>> >> > properly, but please check /var/log/setup.log.full and report any
>> >> > problems.
>> >> > Package: Unknown package
>> >> > qgis-common.bat exit code -1073741511
>> >> >
>> >> > *2)* So, when starting from windows menu, have the follwing message:
>> >> >
>> >> > Starting GRASS GIS...
>> >> > Error: Reading settings from file
>> >> > <C:\Users\Particular\AppData\Roaming\GRASS7\wx> failed.
>> >> > Details: not enough values to unpack (expected 2,
>> got
>> >> 1)
>> >> > Line: ''
>> >> >
>> >> > Using 64bits Windows OS, and having this issue from the 1st time,
>> after
>> >> > update QGIS and GRASS from OSGeo4W Setup.
>> >> >
>> >> > Thanks
>> >> >
>> >> >
>> >> > Cumprimentos,
>> >> > *Valter Albino -* Geógrafo Físico, M.Sc.
>> >> > Modelação H&H / Riscos ambientais / OT&U
>> >> > www.valteralbino.wixsite.com/hydrodynamics
>> >> >
>> >> > ___
>> >> > grass-user mailing list
>> >>
>> >> > grass-user@.osgeo
>> >>
>> >> > https://lists.osgeo.org/mailman/listinfo/grass-user
>> >> >
>> >> > ScreenHunter_31 Feb. 01 20.04.gif (15K)
>> >> > <
>> >>
>> http://osgeo-org.1560.x6.nabble.com/attachment/5428909/0/ScreenHunter_31%20Feb.%2001%2020.04.gif>
>> >> ;
>> >>
>> >> It's part of the OSGeo4W repackaging. Try to reinstall.
>> >>
>> >>
>> >>
>> >> -
&g

Re: [GRASS-user] Fwd: GRASS GIS problem from OSGeo4W Setup

Valter Albino wrote
> Hi Helmut,
> 
> Thanks for reply.
> Feel embarrassed, since i can't find the file path you mention.
> Tried to install again, but the error remains, starting in the
> installation:
> 
> [image: Capturar.GIF]
> 
> In my portable PC i did the same but didn't give error, so can run GRASS
> GIS with no problems.
> I didn't change the language
> 
> 
> Cumprimentos,
> *Valter Albino -* Geógrafo Físico, M.Sc.
> Modelação H&H / Riscos ambientais / OT&U
> www.valteralbino.wixsite.com/hydrodynamics
> 
> 
> Helmut Kudrnovsky <

> hellik@

> > escreveu no dia domingo, 2/02/2020 à(s)
> 08:48:
> 
>> Valter Albino wrote
>> > Regarding the issue, this message is also important (during
>> instalation):
>> >
>> > [image: ScreenHunter_31 Feb. 01 20.04.gif]
>> >
>> >
>> > Cumprimentos,
>> > *Valter Albino -* Geógrafo Físico, M.Sc.
>> > Modelação H&H / Riscos ambientais / OT&U
>> > www.valteralbino.wixsite.com/hydrodynamics
>> >
>> >
>> > -- Forwarded message -
>> > De: Valter Albino <
>>
>> > valteralbino@
>>
>> > >
>> > Date: sábado, 1/02/2020 à(s) 19:52
>> > Subject: GRASS GIS problem from OSGeo4W Setup
>> > To: grass-user <
>>
>> > grass-user@.osgeo
>>
>> > >
>> >
>> >
>> > Hi
>> >
>> > *1)* Trying to install GRASS 7.8.2 or 7.9.dev but have the following
>> > message:
>> > "
>> > OSGeo4W Setup - Running postinstall scripts
>> >
>> > Postinstall script errors
>> > These do not necessarly mean that affectes packages will fail to
>> function
>> > properly, but please check /var/log/setup.log.full and report any
>> > problems.
>> > Package: Unknown package
>> > qgis-common.bat exit code -1073741511
>> >
>> > *2)* So, when starting from windows menu, have the follwing message:
>> >
>> > Starting GRASS GIS...
>> > Error: Reading settings from file
>> > <C:\Users\Particular\AppData\Roaming\GRASS7\wx> failed.
>> > Details: not enough values to unpack (expected 2, got
>> 1)
>> > Line: ''
>> >
>> > Using 64bits Windows OS, and having this issue from the 1st time, after
>> > update QGIS and GRASS from OSGeo4W Setup.
>> >
>> > Thanks
>> >
>> >
>> > Cumprimentos,
>> > *Valter Albino -* Geógrafo Físico, M.Sc.
>> > Modelação H&H / Riscos ambientais / OT&U
>> > www.valteralbino.wixsite.com/hydrodynamics
>> >
>> > ___
>> > grass-user mailing list
>>
>> > grass-user@.osgeo
>>
>> > https://lists.osgeo.org/mailman/listinfo/grass-user
>> >
>> > ScreenHunter_31 Feb. 01 20.04.gif (15K)
>> > <
>> http://osgeo-org.1560.x6.nabble.com/attachment/5428909/0/ScreenHunter_31%20Feb.%2001%2020.04.gif>
>> ;
>>
>> It's part of the OSGeo4W repackaging. Try to reinstall.
>>
>>
>>
>> -
>> best regards
>> Helmut
>> --
>> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
>> ___
>> grass-user mailing list
>> 

> grass-user@.osgeo

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

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user
> 
> Capturar.GIF (140K)
> <http://osgeo-org.1560.x6.nabble.com/attachment/5428927/0/Capturar.GIF>;

The path is something like 

C:\users\yourusername\appdata\...\roaming\grass7 

Do a search for grass7 in the appdata subfolder.

Or copy 

 %APPDATA%

in the Windows file explorer to open directly the appdata folder. 



-
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] Fwd: GRASS GIS problem from OSGeo4W Setup

Valter Albino wrote
> Regarding the issue, this message is also important (during instalation):
> 
> [image: ScreenHunter_31 Feb. 01 20.04.gif]
> 
> 
> Cumprimentos,
> *Valter Albino -* Geógrafo Físico, M.Sc.
> Modelação H&H / Riscos ambientais / OT&U
> www.valteralbino.wixsite.com/hydrodynamics
> 
> 
> -- Forwarded message -
> De: Valter Albino <

> valteralbino@

> >
> Date: sábado, 1/02/2020 à(s) 19:52
> Subject: GRASS GIS problem from OSGeo4W Setup
> To: grass-user <

> grass-user@.osgeo

> >
> 
> 
> Hi
> 
> *1)* Trying to install GRASS 7.8.2 or 7.9.dev but have the following
> message:
> "
> OSGeo4W Setup - Running postinstall scripts
> 
> Postinstall script errors
> These do not necessarly mean that affectes packages will fail to function
> properly, but please check /var/log/setup.log.full and report any
> problems.
> Package: Unknown package
> qgis-common.bat exit code -1073741511
> 
> *2)* So, when starting from windows menu, have the follwing message:
> 
> Starting GRASS GIS...
> Error: Reading settings from file
>  failed.
> Details: not enough values to unpack (expected 2, got 1)
> Line: ''
> 
> Using 64bits Windows OS, and having this issue from the 1st time, after
> update QGIS and GRASS from OSGeo4W Setup.
> 
> Thanks
> 
> 
> Cumprimentos,
> *Valter Albino -* Geógrafo Físico, M.Sc.
> Modelação H&H / Riscos ambientais / OT&U
> www.valteralbino.wixsite.com/hydrodynamics
> 
> ___
> grass-user mailing list

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user
> 
> ScreenHunter_31 Feb. 01 20.04.gif (15K)
> ;

It's part of the OSGeo4W repackaging. Try to reinstall. 



-
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] GRASS GIS problem from OSGeo4W Setup

>Postinstall script errors

try to re-install, it could be there was an qgis repackaging in OSGeo4W with
an updated gdal library. 

>Details: not enough values to unpack (expected 2, got 1)

It's an issue already reported. Did you change the language between english
and yours in the wxgui?

try to delete the wxgui-related files in c:\users\yourusername\grass7 and
then restart grass. 




-
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] problems installing extensions with g.extension

2020-01-25 Thread Helmut Kudrnovsky

>I'm using Grass 7.4.1 on a WIndows

7.4.1 is really old; not sure that winGRASS addons are still built for 7.4.1
anymore.

from GRASS download website:

GRASS GIS 7.6.1 (old stable)
GRASS GIS 7.8.2 (new stable)

any chance to update to 7.8.2? 



-
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] remove vect from gui

2020-01-20 Thread Helmut Kudrnovsky

FrankD wrote
> Hello,
> 
> I cannot remove vector object and attribute data from the right-clic 
> menu on attribute box in the gui (as I was used to do) with grass 7.9 
> (on debian buster)
> 
> But "v.edit tool=delete map=mymap where="mycolum=myvalue" and db.execute 
> "sql=DELETE FROM mymap WHERE mycolomn = myvalue" work fine.
> 
> Is there any trick here ?

please open a bug report, best with an example to reproduce.



-
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] problem installing GRASS

2020-01-20 Thread Helmut Kudrnovsky

>"The program cant start because api-ms-win-crt-runtime-l1-1-0.dll is missing
from your computer.."

which operating system are you using?

during installation by the standalone installer, there is an option to
install Microsoft Visual C/C++ Runtimes.

activate this option, then Microsoft Visual C/C++ Runtimes are downloaded
and installed.

please report back, if it's working then.



-
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] r.proj ERROR

2020-01-13 Thread Helmut Kudrnovsky

nik wrote
>> What does r.proj -g output? With PROJ: 6.2.1,  a proj pipeline has to be
>> given in r.proj. it's not in your cmd
>>
>> Can you report all steps with  g.proj, g.region,, r.proj in source and
>> target locations as I've done?
>>
>>
>>
>> -
>> best regards
>> Helmut
>> --
> 
> g.proj -p
> -PROJ_INFO-
> name   : Lambert Conformal Conic
> proj   : lcc
> datum  : hermannskogel
> ellps  : bessel
> lat_1  : 49
> lat_2  : 46
> lat_0  : 47.5
> lon_0  : 13.33
> x_0    : 40
> y_0    : 40
> no_defs    : defined
> towgs84    : 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
> -PROJ_UNITS
> unit   : metre
> units  : metres
> meters : 1
> 
> --
> 
> g.region -p
> projection: 99 (Lambert Conformal Conic)
> zone:   0
> datum:  hermannskogel
> ellipsoid:  bessel
> north:  576922.51207363
> south:  273692.51207363
> west:   106549.26720377
> east:   694629.26720377
> nsres:  10
> ewres:  10
> rows:   30323
> cols:   58808
> cells:  1783234984
> 
> 
> 
> g.proj -p
> -PROJ_INFO-
> name   : Universal Transverse Mercator
> proj   : utm
> datum  : etrs89
> ellps  : grs80
> zone   : 33
> towgs84    : 0,0,0,0,0,0,0
> no_defs    : defined
> -PROJ_UNITS
> unit   : metre
> units  : metres
> meters : 1
> 
> --
> 
> g.region -p
> projection: 1 (UTM)
> zone:   33
> datum:  etrs89
> ellipsoid:  grs80
> north:  5286581.58847414
> south:  5248335.67358037
> west:   380870.53610518
> east:   429633.13185005
> nsres:  9.998932
> ewres:  10.00053235
> rows:   3825
> cols:   4876
> cells:  18650700
> 
> --
> 
> I downloaded and installed 
> http://www.bev.gv.at/portal/page?_pageid=713,2157075&_dad=portal&_schema=PORTAL
> 
> r.proj -g location=MGI2wgs84_Austria_Lambert mapset=PERMANENT 
> input=dhm_10m_ogd_austria output=dhm_10m_ogd_dachstein_NEU 
> method=bilinear resolution=10 pipeline=+proj=pipeline  +step +inv 
> +proj=lcc +lat_0=47.5 +lon_0=13.3 +lat_1=49 +lat_2=46 
> +x_0=40 +y_0=40 +ellps=bessel +step +proj=hgridshift 
> +grids=AT_GIS_GRID.gsb +step +proj=utm +zone=33 +ellps=GRS80
> n=1.#INF s=5132938.26037436 w=78264.72048991 e=1.#INF rows=30323
> cols=58808
> Eingabekarte  in Location 
> 
> :
> (Mon Jan 13 10:19:18 2020) Befehl ausgeführt (0 Sek)
> 
> But nothing happend!
> 
> And please tell me why do I have to give a pipeline in r.proj? I thought 
> that would defined by the locations resp. regions.
> 
> thx!

for r.proj -g you don't need the pipeline, try just

r.proj -g  location=MGI2wgs84_Austria_Lambert mapset=PERMANENT
input=dhm_10m_ogd_austria

see also example https://grass.osgeo.org/grass78/manuals/r.proj.html 

---
# same calculation, but in a form which can be cut and pasted into a
g.region call
r.proj input=elevation location=ll_wgs84 mapset=user1 -g
---

the pipeline is needed later for the reprojection process.






-
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] r.proj ERROR

2020-01-12 Thread Helmut Kudrnovsky

nik wrote
> Hi
>> which GRASS version and operating system are you using?
> I also use:  
> GRASS Version: 7.8.2  
>   
> Code revision: 3900fb114  
>   
> Build date: 2019-12-11
>   
> Build platform: x86_64-w64-mingw32
>   
> GDAL: 3.0.2   
>   
> PROJ: 6.2.1   
>   
> GEOS: 3.8.0   
>   
> SQLite: 3.29.0
>   
> Python: 3.7.0 
>   
> wxPython: 4.0.7   
>   
> Platform: Windows-10-10.0.18362-SP0 (OSGeo4W)
> 
> I still get this message:
> r.proj location=MGI2wgs84_Austria_Lambert mapset=PERMANENT
> input=dhm_10m_ogd_austria output=dhm_10m_ogd_dachstein_NEU method=bilinear
> resolution=10
> ERROR: Unable to open element file <> for 
> 
> and I tested it from an other location too but its the same problem:
> r.proj location=ASTER_lat-long mapset=PERMANENT
> input=DHM_SRTM30m_Aut-plus-Umgebung output=dhm_30m_ASTER_dachstein
> method=bilinear resolution=30
> ERROR: Unable to open element file <> for 
> 
> What can be wrong?
> Nik
> 
> 
> 
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> grass-user mailing list

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user

What does r.proj -g output? With PROJ: 6.2.1,  a proj pipeline has to be
given in r.proj. it's not in your cmd

Can you report all steps with  g.proj, g.region,, r.proj in source and
target locations as I've done?



-
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] r.proj ERROR

2020-01-11 Thread Helmut Kudrnovsky

nik wrote
> Hi,
> I want to re-project DEM data from a lambert-location into ETRS89/utm zone
> 33N
> I did that many times before but now I get the following message:
>   
> r.proj location=MGI2wgs84_Austria_Lambert mapset=PERMANENT
> input=dhm_10m_ogd_austria output=dhm_10m_ogd_dachstein_NEU method=bilinear
> resolution=10
> ERROR: Unable to open element file <> for 
> (Sat Jan 11 14:24:16 2020) Befehl ausgeführt (0 Sek)
> 
> The WIND file is ok. When I open it there are the correct region settings.
> 
> Whats wrong?
> thx!
> Nik

which GRASS version and operating system are you using?

testing here with:

System Info 
GRASS version: 7.8.2
Code revision: 3900fb114
Build date: 2019-12-11  
Build platform: x86_64-w64-mingw32  
GDAL: 3.0.2 
PROJ: 6.2.1 
GEOS: 3.8.0 
SQLite: 3.29.0  
Python: 3.7.0   
wxPython: 4.0.7 
Platform: Windows-10-10.0.18362-SP0 (OSGeo4W)


and tried here with a raster of the Dachstein region ;-)

g.proj -p   
-PROJ_INFO-
name   : MGI / Austria Lambert
datum  : hermannskogel
ellps  : bessel
proj   : lcc
lat_0  : 47.5
lon_0  : 13.3
lat_1  : 49
lat_2  : 46
x_0: 40
y_0: 40
no_defs: defined
towgs84: 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
-PROJ_EPSG-
epsg   : 31287
-PROJ_UNITS
unit   : meter
units  : meters
meters : 1



g.region -p 
projection: 99 (MGI / Austria Lambert)
zone:   0
datum:  hermannskogel
ellipsoid:  bessel
north:  413800
south:  391100
west:   407600
east:   441400
nsres:  100
ewres:  100
rows:   227
cols:   338
cells:  76726

#

g.proj -p   
-PROJ_INFO-
name   : ETRS89 / UTM zone 33N
datum  : etrs89
ellps  : grs80
proj   : utm
zone   : 33
no_defs: defined
towgs84: 0.000,0.000,0.000
-PROJ_EPSG-
epsg   : 25833
-PROJ_UNITS
unit   : meter
units  : meters
meters : 1



r.proj -g location=dachstein mapset=data input=raster2proj  
WARNING: Found 2 possible transformations

Operation 1:
Description: axis order change (2D) + Inverse of Austria Lambert + MGI to
ETRS89 (1) + UTM zone 33N

Area of use: Austria

Accuracy within area of use: 1.5 m

PROJ string:
+proj=pipeline +step +inv +proj=lcc +lat_0=47.5 +lon_0=13.3
+lat_1=49 +lat_2=46 +x_0=40 +y_0=40 +ellps=bessel +step +proj=push
+v_3 +step +proj=cart +ellps=bessel +step +proj=helmert +x=577.326 +y=90.129
+z=463.919 +rx=5.137 +ry=1.474 +rz=5.297 +s=2.4232
+convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step
+proj=pop +v_3 +step +proj=utm +zone=33 +ellps=GRS80

Operation 2:
Description: axis order change (2D) + Inverse of Austria Lambert + MGI to
ETRS89 (5) + UTM zone 33N

Area of use: Austria

Accuracy within area of use: 0.15 m

PROJ string:
+proj=pipeline +step +inv +proj=lcc +lat_0=47.5 +lon_0=13.3
+lat_1=49 +lat_2=46 +x_0=40 +y_0=40 +ellps=bessel +step
+proj=hgridshift +grids=AT_GIS_GRID.gsb +step +proj=utm +zone=33
+ellps=GRS80

See also output of:
projinfo -o PROJ -s "EPSG:31287" -t "EPSG:25833"
Please provide the appropriate PROJ string with the pipeline option

Selected pipeline:
+proj=pipeline +step +inv +proj=lcc +lat_0=47.5 +lon_0=13.3
+lat_1=49 +lat_2=46 +x_0=40 +y_0=40 +ellps=bessel +step +proj=push
+v_3 +step +proj=cart +ellps=bessel +step +proj=helmert +x=577.326 +y=90.129
+z=463.919 +rx=5.137 +ry=1.474 +rz=5.297 +s=2.4232
+convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step
+proj=pop +v_3 +step +pr

[GRASS-user] question to the community: winGRASS - still a need for 32bit versions?

2019-12-11 Thread Helmut Kudrnovsky

Helmut Kudrnovsky wrote
> Hi GRASS community,
> 
> as stated e.g. in:
> 
> 
> [GRASS-dev] [release planning] GRASS GIS 7.8.2
> https://lists.osgeo.org/pipermail/grass-dev/2019-December/093846.html
> ##
> ne 8. 12. 2019 v 0:33 odesílatel napsal:
>> winGRASS 7.8.2RC2 64bit is available for testing in OSGeo4W 64bit when
>> the
>> experimental/testing tick is activated.
> 
> also 32bit package available for testing and standalone installers [1].
> 
> [1] https://grass.osgeo.org/grass78/binary/mswindows/native/
> 
> 
> we're providing winGRASS in 32bit and 64bit versions (OSGeo4W and
> standalone).
> 
> nowadays 64bit windows operating systems (e.g. win 10) are very common;
> most
> of the personal computer assembled after 2010 are 64bit systems. linux
> distributions start to phase out 32bit support. [1] [2] [3] [4]
> 
> a question to our winGRASS community: is there still a need for 32bit
> versions of winGRASS?
> 
> [1] https://itsfoss.com/end-of-32-bit-linux/
> [2]
> https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Drops-32-bit-x86
> [3]
> https://www.phoronix.com/scan.php?page=news_item&px=OpenMandriva-Dropping-32-Plans
> [4]
> https://www.pcworld.com/article/3089509/end-of-an-era-linux-distributions-will-soon-stop-supporting-32-bit-pcs.html

nobody claims a need for a 32bit winGRASS? really?

do we need winGRASS at all? ;-)

if no objections will pop up in the next days, I'll propose  to the GRASS
PSC (project steering commitee):

* phasing out winGRASS 32bit support by middle next year (2020 July 31)*

reasoning for this proposal:

- 64bit computer architecture and 64bit windows operating systems are very
common
- 32bit computer architecture and 32bit windows operating systems will find
their EOL

and the important reasons:

- reduce the high maintenance burden to keep 2 build environments of
winGRASS (32bit, 64bit) alive
- facilitate to find possible (automatic) alternatives of winGRASS build
environments beside the actual MSYS2/OSGeo4W workflow

comments are welcome :-)




-
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] winGRASS - still a need for 32bit versions?

2019-12-08 Thread Helmut Kudrnovsky

Hi GRASS community,

as stated e.g. in:


[GRASS-dev] [release planning] GRASS GIS 7.8.2
https://lists.osgeo.org/pipermail/grass-dev/2019-December/093846.html
##
ne 8. 12. 2019 v 0:33 odesílatel napsal:
> winGRASS 7.8.2RC2 64bit is available for testing in OSGeo4W 64bit when the
> experimental/testing tick is activated.

also 32bit package available for testing and standalone installers [1].

[1] https://grass.osgeo.org/grass78/binary/mswindows/native/


we're providing winGRASS in 32bit and 64bit versions (OSGeo4W and
standalone).

nowadays 64bit windows operating systems (e.g. win 10) are very common; most
of the personal computer assembled after 2010 are 64bit systems. linux
distributions start to phase out 32bit support. [1] [2] [3] [4]

a question to our winGRASS community: is there still a need for 32bit
versions of winGRASS?

[1] https://itsfoss.com/end-of-32-bit-linux/
[2]
https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Drops-32-bit-x86
[3]
https://www.phoronix.com/scan.php?page=news_item&px=OpenMandriva-Dropping-32-Plans
[4]
https://www.pcworld.com/article/3089509/end-of-an-era-linux-distributions-will-soon-stop-supporting-32-bit-pcs.html



-
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] Datum not recognized by Grass

> ignore the warning and use GRASS with PROJ6, granted that authority name
(e.g. EPSG) and authority code (e.g. 2932) are known for both CRS's in case
of reprojection

this issue is already by GRASS with PROJ6, see


GRASS version: 7.8.1
Code revision: c865432c9
Build date: 2019-11-10  
Build platform: x86_64-w64-mingw32  
GDAL: 3.0.2 
PROJ: 6.2.1  <=  
GEOS: 3.8.0 
SQLite: 3.29.0  
Python: 3.7.0   
wxPython: 4.0.7 
Platform: Windows-10-10.0.18362-SP0 (OSGeo4W)  


and the output from the underlying PROJ: 6.2.1


C:\>projinfo EPSG:2932 -o PROJ,WKT2_2018
PROJ.4 string:
+proj=tmerc +lat_0=24.45 +lon_0=51.21667 +k=0.9 +x_0=20
+y_0=30 +ellps=intl
+towgs84=-119.4248,-303.65872,-11.00061,1.164298,0.174458,1.096259,3.657065
+units=m +no_defs +type=crs

WKT2_2018 string:
PROJCRS["QND95 / Qatar National Grid",
BASEGEOGCRS["QND95",
DATUM["Qatar National Datum 1995",
ELLIPSOID["International 1924",6378388,297,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4614]],
CONVERSION["Qatar National Grid",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",24.45,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",51.21667,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",0.9,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",20,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",30,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["(E)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["(N)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["unknown"],
AREA["Qatar - onshore"],
BBOX[24.55,50.69,26.2,51.68]],
ID["EPSG",2932]]


>The problem is that GRASS still assumes datum transformation from X to
WGS84, whereas with PROJ6, 
>WGS84 is no longer required as pivot datum. Datum transformations from
datum X to datum Y can 
>sometimes (often) be done without going through WGS84. The requirement is
to have EPSG or other 
>authority codes and to use PROJ 6.

this warning is just from a simple v.in.ogr of a EPSG:2932-based shapefile
into a EPSG:2932-created GRASS location.

so, there may be some more adaptions needed for actions like v.in.ogr and
co?



-
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] Datum not recognized by Grass

Markus Neteler wrote
> Hi,
> 
> On Mon, Dec 2, 2019 at 9:49 AM Zoltan Szecsei <

> zoltans@.co

> > wrote:
>>
>> Hi,
>> I'm using EPSG 2932 and QGIS etc all are OK with it.
>>
>> I have installed everything using OSGeo4W64, so how come Grass does not
>> use the same projections database (as QGis etc)?
>> (and please can I have a pointer as to how to introduce EPSG 2932 to
>> Grass 7.8.1)
>>
>> Thanks and regards,
>> Zoltan
>>
>>  Running against:
>> D:\GDBroad_tiles\shp_road_poly_few\23103770_road_poly.shp
>> WARNING: Datum 
> 
>  not recognised by GRASS and
>> no parameters found
> 
> Is it possible that you have a PROJ software version mixup?
> 
> I tried on my Linux box:
> 
> grass78 -c epsg:2932 ~/grassdata/test_2932
> Starting GRASS GIS...
> Creating new GRASS GIS location 
> 
> ...
> Cleaning up temporary files...
> 
>   __  ___   _____
>  / / __ \/   | / ___/ ___/   / /  _/ ___/
> / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
>/ /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
>\/_/ |_/_/  |_///   \/___///
> 
> Welcome to GRASS GIS 7.8.2dev (ad4836c73)
> ...
> 
> GRASS 7.8.2dev (test_2932):~ > g.proj -w
> PROJCS["QND95 / Qatar National Grid",
> GEOGCS["QND95",
> DATUM["Qatar_National_Datum_1995",
> SPHEROID["International 1924",6378388,297,
> AUTHORITY["EPSG","7022"]],
>
> TOWGS84[-119.4248,-303.65872,-11.00061,1.164298,0.174458,1.096259,3.657065],
> AUTHORITY["EPSG","6614"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","4614"]],
> PROJECTION["Transverse_Mercator"],
> PARAMETER["latitude_of_origin",24.45],
> PARAMETER["central_meridian",51.216667],
> PARAMETER["scale_factor",0.9],
> PARAMETER["false_easting",20],
> PARAMETER["false_northing",30],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AXIS["Easting",EAST],
> AXIS["Northing",NORTH],
> AUTHORITY["EPSG","2932"]]

when importing a shapefile with the same epsg projection, I get:

v.in.ogr --verbose input=D:\wd\test_epsg2932.shp
Using OGR driver 'ESRI Shapefile/ESRI Shapefile'
WARNING: Datum  von GRASS nicht erkannt und keine
Parameter gefunden.
Die Projektionsinformationen des Eingabedatensatzes und der aktuellen
Location scheinen übereinzustimmen.

D:\wd>ogrinfo --version
GDAL 3.0.2, released 2019/10/28

D:\wd>ogrinfo test_epsg2932.shp -al -so
INFO: Open of `test_epsg2932.shp'
  using driver `ESRI Shapefile' successful.

Layer name: test_epsg2932
Metadata:
  DBF_DATE_LAST_UPDATE=2019-12-03
Geometry: Point
Feature Count: 1
Extent: (823205.438352, 25769.568359) - (823205.438352, 25769.568359)
Layer SRS WKT:
PROJCS["QND95 / Qatar National Grid",
GEOGCS["QND95",
DATUM["Qatar_National_Datum_1995",
SPHEROID["International 1924",6378388,297,
AUTHORITY["EPSG","7022"]],
AUTHORITY["EPSG","6614"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4614"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",24.45],
PARAMETER["central_meridian",51.21667],
PARAMETER["scale_factor",0.9],
PARAMETER["false_easting",20],
PARAMETER["false_northing",30],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
AUTHORITY["EPSG","2932"]]
Data axis to CRS axis mapping: 1,2
id: Integer64 (10.0)
test: Integer (9.0)

D:\wd>testepsg test_epsg2932.prj
Validate Succeeds.
WKT[test_epsg2932.prj] =
PROJCS["QND95 / Qatar National Grid",
GEOGCS["QND95",
DATUM["Qatar_National_Datum_1995",
SPHEROID["International 1924",6378388,297,
AUTHORITY["EPSG","7022"]],
AUTHORITY["EPSG","6614"]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",24.45],
PARAMETER["central_meridian",51.21667],
PARAMETER["scale_factor",0.9],
PARAMETER["false_easting",20],
PARAMETER["false_northing",30],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH]]

Simplified WKT[test_epsg2932.prj] =
PROJCS["QND95 / Qatar National Grid",
GEOGCS["QND95",
DATUM["Qatar_National_Datum_1995",
SPHEROID["International 1924",6378388,297]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",24.45],
PARAMETER["central_meridian",51.21667],
PARAMETER["scale_

Re: [GRASS-user] Datum not recognized by Grass

Markus Neteler wrote
> Hi,
> 
> On Mon, Dec 2, 2019 at 9:49 AM Zoltan Szecsei <

> zoltans@.co

> > wrote:
>>
>> Hi,
>> I'm using EPSG 2932 and QGIS etc all are OK with it.
>>
>> I have installed everything using OSGeo4W64, so how come Grass does not
>> use the same projections database (as QGis etc)?
>> (and please can I have a pointer as to how to introduce EPSG 2932 to
>> Grass 7.8.1)
>>
>> Thanks and regards,
>> Zoltan
>>
>>  Running against:
>> D:\GDBroad_tiles\shp_road_poly_few\23103770_road_poly.shp
>> WARNING: Datum 
> 
>  not recognised by GRASS and
>> no parameters found
> 
> Is it possible that you have a PROJ software version mixup?
> 
> I tried on my Linux box:
> 
> grass78 -c epsg:2932 ~/grassdata/test_2932
> Starting GRASS GIS...
> Creating new GRASS GIS location 
> 
> ...
> Cleaning up temporary files...
> 
>   __  ___   _____
>  / / __ \/   | / ___/ ___/   / /  _/ ___/
> / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
>/ /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
>\/_/ |_/_/  |_///   \/___///
> 
> Welcome to GRASS GIS 7.8.2dev (ad4836c73)
> ...
> 
> GRASS 7.8.2dev (test_2932):~ > g.proj -w
> PROJCS["QND95 / Qatar National Grid",
> GEOGCS["QND95",
> DATUM["Qatar_National_Datum_1995",
> SPHEROID["International 1924",6378388,297,
> AUTHORITY["EPSG","7022"]],
>
> TOWGS84[-119.4248,-303.65872,-11.00061,1.164298,0.174458,1.096259,3.657065],
> AUTHORITY["EPSG","6614"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","4614"]],
> PROJECTION["Transverse_Mercator"],
> PARAMETER["latitude_of_origin",24.45],
> PARAMETER["central_meridian",51.216667],
> PARAMETER["scale_factor",0.9],
> PARAMETER["false_easting",20],
> PARAMETER["false_northing",30],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AXIS["Easting",EAST],
> AXIS["Northing",NORTH],
> AUTHORITY["EPSG","2932"]]

C:\>g.proj -w
PROJCS["QND95 / Qatar National Grid",
GEOGCS["QND95",
DATUM["Qatar_National_Datum_1995",
SPHEROID["International 1924",6378388,297,
AUTHORITY["EPSG","7022"]],
   
TOWGS84[-119.4248,-303.65872,-11.00061,1.164298,0.174458,1.096259,3.657065],
AUTHORITY["EPSG","6614"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4614"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",24.45],
PARAMETER["central_meridian",51.21667],
PARAMETER["scale_factor",0.9],
PARAMETER["false_easting",20],
PARAMETER["false_northing",30],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
AUTHORITY["EPSG","2932"]]




-
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] Datum not recognized by Grass