Re: [GRASS-user] Fwd: skipping MEM driver with r.out.gdal for large files

[Laura Poggio]

Dear Markus,
Using GTiff (in grass version 8.3.0 and with gdal 3.7.1) solved the
problem. I get a compressed file and the use of RAM is acceptable. I still
get the same errors when using COG.
A quick test with a different file in grass 8.2.1 and gdal 3.6.4 (previous
configuration) indicates that it would be the same there, but I could not
test it with the original file because of some hardware issues.

Thanks a lot!

Laura


On Thu, 22 Jun 2023 at 09:16, Markus Neteler  wrote:

> Hi Laura,
>
> On Thu, Jun 15, 2023 at 5:00 PM Laura Poggio 
> wrote:
> >
> > Dear all,
> > Apologies, sent to the developer mailing list by mistake.
> > I am trying to save a rather large file from GRASS
> >
> > Versions:
> > GRASS GIS 8.2.1
> > GDAL 3.6.3, released 2023/03/07
> > Linux: almalinux:9.1
> >
> > The size of the file is:
> > rows=141120
> > cols=362880
> > cells=51209625600
> >
> > This the command
> > r.out.gdal -c input=out output=output.tif format=COG type=Int16
> createopt=COMPRESS=LZW,PREDICTOR=2,BIGTIFF=YES --overwrite --quiet
> >
> > This the output
> > Warning 6: driver MEM does not support creation option COMPRESS
> > Warning 6: driver MEM does not support creation option PREDICTOR
> > Warning 6: driver MEM does not support creation option BIGTIFF
> > ERROR 2: /usr/gdal-3.6.2/frmts/mem/memdataset.cpp, 1289: cannot allocate
> 1x102419251200 bytes
> > ERROR: Unable to create dataset using memory raster driver
> >
> > Is there any option not to use the MEM driver when writing to disk?
>
> I am not sure, in this code section it doesn't look like this:
>
>
> https://github.com/OSGeo/grass/blob/51e962abbc1176211ad2c4cb7857a61a2b6d1c6f/raster/r.out.gdal/main.c#L377
>
> Maybe someone else in the list has more insights?
>
> Some options:
> - try first the GTiff driver, then convert to COG with gdal_translate
> - enlarge RAM using a swap file (no reboot needed but sudo access
> needed) as disk space is relatively cheap and r.out.gdal will not
> realize then that it gets swapped.
>
> Best,
> Markus
>
> --
> Markus Neteler, PhD
> https://www.mundialis.de - free data with free software
> https://grass.osgeo.org
> https://courses.neteler.org/blog
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Fwd: skipping MEM driver with r.out.gdal for large files

[Laura Poggio]

Dear all,
Apologies, sent to the developer mailing list by mistake.
I am trying to save a rather large file from GRASS

Versions:
GRASS GIS 8.2.1
GDAL 3.6.3, released 2023/03/07
Linux: almalinux:9.1

The size of the file is:
rows=141120
cols=362880
cells=51209625600

This the command
r.out.gdal -c input=out output=output.tif format=COG type=Int16
createopt=COMPRESS=LZW,PREDICTOR=2,BIGTIFF=YES --overwrite --quiet

This the output
Warning 6: driver MEM does not support creation option COMPRESS
Warning 6: driver MEM does not support creation option PREDICTOR
Warning 6: driver MEM does not support creation option BIGTIFF
ERROR 2: /usr/gdal-3.6.2/frmts/mem/memdataset.cpp, 1289: cannot allocate
1x102419251200 bytes
ERROR: Unable to create dataset using memory raster driver

Is there any option not to use the MEM driver when writing to disk?
Thanks
Laura
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] installing grass.jupyter

[Laura Poggio]

Hi Stephan and Veronica,
thanks! I installed grass 8.0.0RC2 and it is there. I will test if this is
enough for the moment. If not I will install the development version from
source.

Thanks a lot
Laura

On Tue, 1 Feb 2022 at 18:52, Veronica Andreo  wrote:

> Hi Laura,
>
> Indeed, it's shipped with GRASS 8.0 already as experimental, but the
> newest stuff will be in the dev branch only.
> This workshop from FOSS4G 2021 is a nice example of usage:
> https://github.com/ncsu-geoforall-lab/grass-gis-workshop-FOSS4G-2021
>
> HTH,
> Vero
>
> El mar, 1 feb 2022 a las 17:58, Stefan Blumentrath (<
> stefan.blumentr...@nina.no>) escribió:
>
>> Hi Laura,
>>
>>
>>
>> You would need a current development version (GRASS GIS 8.1.dev).
>>
>>
>>
>> For MS Windows you can get it here:
>>
>> https://wingrass.fsv.cvut.cz/grass81/
>>
>> On Linux you could clone the code and compile…
>>
>>
>>
>> Cheers
>>
>> Stefan
>>
>>
>>
>> *From:* grass-user  *On Behalf Of *Laura
>> Poggio
>> *Sent:* tirsdag 1. februar 2022 17:45
>> *To:* GRASS user list 
>> *Subject:* [GRASS-user] installing grass.jupyter
>>
>>
>>
>> Dear all,
>>
>> I came across this project:
>> https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.osgeo.org%2Fgrass%2Fwiki%2FGSoC%2F2021%2FJupyterAndGRASS=04%7C01%7CStefan.Blumentrath%40nina.no%7C44ac72ce04c74608667408d9e5a235b5%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637793307708914741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=VBjHGFLPPVJRQXF4afiUpBOJj9P1P50weUhI6C%2F3Y7U%3D=0>.
>> It would be great to use it for some training material that I am working on.
>>
>>
>>
>> I most likely have missed something, but I could not find instructions on
>> how to install grass.jupyter.
>>
>> Any pointers will be really helpful
>>
>>
>>
>> Thanks
>>
>> Laura
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] installing grass.jupyter

[Laura Poggio]

Dear all,
I came across this project:
https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS. It would be
great to use it for some training material that I am working on.

I most likely have missed something, but I could not find instructions on
how to install grass.jupyter.
Any pointers will be really helpful

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

Re: [GRASS-user] error when importing soil grids data into GRASS

[Laura Poggio]

Hi Veronica,
thanks for pointing this out. The projection should be defined in the VRTs
of Soilgrids 2.0 and normally it should be recognised in GRASS-GIS. I have
been using the same files you mentioned. We will look into the issue and
let you know.

Thanks
Laura

On Wed, 8 Dec 2021 at 01:31, Veronica Andreo  wrote:

> Hi Markus,
>
> thanks for your answer :)
>
> El mar., 7 dic. 2021 14:43, Markus Neteler  escribió:
>
>> Hi Vero,
>>
>> On Tue, Dec 7, 2021 at 6:12 PM Veronica Andreo 
>> wrote:
>> >
>> > Dear all,
>> >
>> > I'm trying to import soil grids data for south america into grass gis
>> by means of r.import and the vsicurl driver and I'm facing different errors
>> according to the soilgrid version I use. See below:
>> >
>> > Fist attempt:
>> >
>> > gdalinfo /vsicurl/
>> https://files.isric.org/soilgrids/latest/data/ocd/ocd_0-5cm_mean.vrt
>> > Driver: VRT/Virtual Raster
>> > Files: /vsicurl/
>> https://files.isric.org/soilgrids/latest/data/ocd/ocd_0-5cm_mean.vrt
>> >/vsicurl/
>> https://files.isric.org/soilgrids/latest/data/ocd/ocd_0-5cm_mean.vrt.ovr
>> >/vsicurl/
>> https://files.isric.org/soilgrids/latest/data/ocd/./ocd_0-5cm_mean/tileSG-018-027/tileSG-018-027_2-4.tif
>> >/vsicurl/
>> https://files.isric.org/soilgrids/latest/data/ocd/./ocd_0-5cm_mean/tileSG-018-027/tileSG-018-027_1-1.tif
>> > ...
>> > Size is 159246, 58034
>> > Coordinate System is:
>> > PROJCRS["Interrupted_Goode_Homolosine",
>>
>> This is the problem.
>>
>
> Any idea why it's not recognized? I see it is in PROJ and as you show
> gdalwarp works. Is it something GRASS related?
>
> Here my workaround:
>>
>> ### ocd
>> # PROJCRS["Interrupted_Goode_Homolosine" ... :-(
>> # requires a trick - r.import still fails
>> eval `g.region -g`
>> gdalwarp -t_srs epsg:4326 -te $w $s $e $n ocd/ocd_0-5cm_mean.vrt
>> ocd_0_5cm_mean_epsg4326.tif -co COMPRESS=LZW
>>
>
> Anyway replacing ocd/ocd_0-5cm_mean.vrt by /vsicurl/
> https://files.isric.org/soilgrids/latest/data/ocd/ocd_0-5cm_mean.vrt in
> your workaround does the trick, takes a while, but does it. Thanks a LOT
> for the hint!!
>
> @Luí­s Moreira de Sousa  would it be
> possible to provide the version 2.0 with the projection defined? Or
> additionally in the easy to use epsg 4326 as an alternative for lazy people
> like me? :)
>
> Vero
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] compiling grass-7.8.5 on conda environment

[Laura Poggio]

Hi Vaclav,
thanks a lot. Your patch worked perfectly. The remaining problems were
solved by loading the conda environment path into LD_LIBRARY.
I will look into your repository if there is a better solution. But at
least the environment works and grass can be updated to 7.8 and python3.

Thanks a lot again
Laura

On Tue, 3 Aug 2021 at 17:21, Laura Poggio  wrote:

> Hi Vaclav,
> thanks a lot!
> with the patch for the makefile in the repository I managed to solve the
> previous error. Now I am getting a different error apparently linked to
> some library conflict (same combination of libraries works in a different
> environment):
>
> /home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
> reference to `GEOSFrechetDistance'
> /home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
> reference to `GEOSFrechetDistance_r'
> /home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
> reference to `GEOSFrechetDistanceDensify'
> /home/user/conda3/envs/sg_py3_geo//lib//libgdal.so.27: undefined
> reference to `GEOSMakeValid_r'
> /home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
> reference to `GEOSFrechetDistanceDensify_r'
>
> Tomorrow I will try again with a clean conda environment implementing all
> of your scripts.
> Thanks a lot!
>
> Laura
>
>
>
> On Tue, 3 Aug 2021 at 15:32, Vaclav Petras  wrote:
>
>> Hi Laura,
>>
>> See whether the following is helpful to you. It uses everything from
>> conda and has some local fixes for iconv. I didn't test 7.8.5 specifically,
>> only the 7.8 release branch.
>>
>> GRASS GIS on HPC Henry2
>> https://github.com/ncsu-geoforall-lab/grass-gis-on-hpc-henry2/
>>
>> Some more comments:
>>
>> On Tue, Aug 3, 2021 at 9:12 AM Laura Poggio 
>> wrote:
>>
>>>
>>> I am trying to compile grass 7.8.5 in a conda environment (on centos7,
>>> managed HPC) adapting this instructions here
>>> <https://github.com/GRASS-GIS/grass-gis-experimental-ci/blob/conda-compile/configure.sh>
>>> .
>>>
>>
>> Nobody touched that repo for a while, but development happened elsewhere.
>> We have a CentOS 7 build partially using conda in the main repo's CI.
>> However, my experience was that the CentOS 7 Docker container in CI was
>> very different from the CentOS 7 environment on HPC which has many
>> customizations.
>>
>> https://github.com/OSGeo/grass/blob/master/.github/workflows/centos.yml
>>
>> There is also a conda-based build for macOS, but that would need to be
>> adapted
>>
>>
>>> conda create -y -n $conda_env python=3.8.5
>>> conda activate $conda_env
>>> conda install -c conda-forge geos gdal==3.3.1 -y
>>> conda install -c conda-forge pdal fftw -y
>>> conda install -c biobuilds libxml2
>>> conda install -c conda-forge libiconv
>>>
>>
>> The GRASS GIS on Henry 2 repo has an environment file you can use.
>>
>>
>>>
>>> compile works well. make gives a lot of errors. When I run make again in
>>> one of the folder, I get this errors:
>>> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
>>> libgrass_gis.7.8.so: undefined reference to `libiconv'
>>> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
>>> libgrass_gis.7.8.so: undefined reference to `libiconv_open'
>>> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
>>> libgrass_gis.7.8.so: undefined reference to `libiconv_close'
>>>
>>
>> I was not able to create a proper fix for GRASS GIS configuration, but
>> the repo has a somewhat hacky patch applied locally which injects libiconv
>> into more places.
>>
>> Let me know how this goes. With the scripts in GRASS GIS on Henry 2, I
>> can install new versions easily, but I would like to see it more
>> streamlined with less local customizations.
>>
>> Best,
>> Vaclav
>>
>>
>>>
>>> I found this answer
>>> <http://osgeo-org.1560.x6.nabble.com/Adding-path-iconv-library-to-configure-td5431037.html>,
>>> but I am not sure how to continue from there.
>>> Thanks a lot
>>> Laura
>>>
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] compiling grass-7.8.5 on conda environment

[Laura Poggio]

Hi Vaclav,
thanks a lot!
with the patch for the makefile in the repository I managed to solve the
previous error. Now I am getting a different error apparently linked to
some library conflict (same combination of libraries works in a different
environment):

/home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
reference to `GEOSFrechetDistance'
/home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
reference to `GEOSFrechetDistance_r'
/home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
reference to `GEOSFrechetDistanceDensify'
/home/user/conda3/envs/sg_py3_geo//lib//libgdal.so.27: undefined reference
to `GEOSMakeValid_r'
/home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
reference to `GEOSFrechetDistanceDensify_r'

Tomorrow I will try again with a clean conda environment implementing all
of your scripts.
Thanks a lot!

Laura



On Tue, 3 Aug 2021 at 15:32, Vaclav Petras  wrote:

> Hi Laura,
>
> See whether the following is helpful to you. It uses everything from conda
> and has some local fixes for iconv. I didn't test 7.8.5 specifically, only
> the 7.8 release branch.
>
> GRASS GIS on HPC Henry2
> https://github.com/ncsu-geoforall-lab/grass-gis-on-hpc-henry2/
>
> Some more comments:
>
> On Tue, Aug 3, 2021 at 9:12 AM Laura Poggio 
> wrote:
>
>>
>> I am trying to compile grass 7.8.5 in a conda environment (on centos7,
>> managed HPC) adapting this instructions here
>> <https://github.com/GRASS-GIS/grass-gis-experimental-ci/blob/conda-compile/configure.sh>
>> .
>>
>
> Nobody touched that repo for a while, but development happened elsewhere.
> We have a CentOS 7 build partially using conda in the main repo's CI.
> However, my experience was that the CentOS 7 Docker container in CI was
> very different from the CentOS 7 environment on HPC which has many
> customizations.
>
> https://github.com/OSGeo/grass/blob/master/.github/workflows/centos.yml
>
> There is also a conda-based build for macOS, but that would need to be
> adapted
>
>
>> conda create -y -n $conda_env python=3.8.5
>> conda activate $conda_env
>> conda install -c conda-forge geos gdal==3.3.1 -y
>> conda install -c conda-forge pdal fftw -y
>> conda install -c biobuilds libxml2
>> conda install -c conda-forge libiconv
>>
>
> The GRASS GIS on Henry 2 repo has an environment file you can use.
>
>
>>
>> compile works well. make gives a lot of errors. When I run make again in
>> one of the folder, I get this errors:
>> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
>> libgrass_gis.7.8.so: undefined reference to `libiconv'
>> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
>> libgrass_gis.7.8.so: undefined reference to `libiconv_open'
>> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
>> libgrass_gis.7.8.so: undefined reference to `libiconv_close'
>>
>
> I was not able to create a proper fix for GRASS GIS configuration, but the
> repo has a somewhat hacky patch applied locally which injects libiconv into
> more places.
>
> Let me know how this goes. With the scripts in GRASS GIS on Henry 2, I can
> install new versions easily, but I would like to see it more streamlined
> with less local customizations.
>
> Best,
> Vaclav
>
>
>>
>> I found this answer
>> <http://osgeo-org.1560.x6.nabble.com/Adding-path-iconv-library-to-configure-td5431037.html>,
>> but I am not sure how to continue from there.
>> Thanks a lot
>> Laura
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] compiling grass-7.8.5 on conda environment

[Laura Poggio]

Dear all,
I am trying to compile grass 7.8.5 in a conda environment (on centos7,
managed HPC) adapting this instructions here

.
conda create -y -n $conda_env python=3.8.5
conda activate $conda_env
conda install -c conda-forge geos gdal==3.3.1 -y
conda install -c conda-forge pdal fftw -y
conda install -c biobuilds libxml2
conda install -c conda-forge libiconv

compile works well. make gives a lot of errors. When I run make again in
one of the folder, I get this errors:
/home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
libgrass_gis.7.8.so: undefined reference to `libiconv'
/home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
libgrass_gis.7.8.so: undefined reference to `libiconv_open'
/home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
libgrass_gis.7.8.so: undefined reference to `libiconv_close'

I found this answer
,
but I am not sure how to continue from there.
Thanks a lot
Laura
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] compiling grass-7.8.5 on centos7 with proj from source

[Laura Poggio]

I switched to use conda environments and it seems things are improving.
However I get different errors (see other email)

Thanks
Laura

On Mon, 2 Aug 2021 at 11:07, Laura Poggio  wrote:

> Dear all,
> I am trying to compile grass-7.8.5 on a managed HPC with centos7 and
> rather old libraries for proj. The most recent is 5.0.1. Unfortunately it
> seems not possible to unload completely the oldest (4.8.0) version
> I compile proj 7.2.1 from source and it works.
> This is the compile instructions that I use (it works on containers and
> clean install without this old version of proj loaded).
>
> ```
> ./configure \
> -prefix=/home/user/$grassdir/ \
> --enable-64bit
> --with-fftw-includes=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/include/ \
> --with-fftw-libs=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/lib/ \
> --with-freetype-includes=/home/user/$grassdir/freetypes/freetype-$freetypeVers/include/
> \
> --with-netcdf --with-geos --with-blas --with-lapack --with-postgres \
> --with-zstd-includes=/home/user/$grassdir/zstd/zstd-$zstdVers/lib/ \
> --with-zstd-libs=/home/user/$grassdir/zstd/zstd-$zstdVers/lib/ \
> --with-gdal=/home/user/gdal/bin312/bin/gdal-config \
> --with-geos=/home/user/geo/bin/bin/geos-config \
> --with-proj-include=/home/user/geo/bin/include/ \
> --with-proj-libs=/home/user/geo/bin/lib/ \
> --with-proj-api=yes --with-proj-share=/home/user/geo/bin/share/proj/
> ```
>
> I tried also with --with-proj-api=no and without the --with-proj-share
> option.
>
>
> Then I get these problems:
> [...]
> checking for location of External PROJ includes...
> checking for proj.h... no
> checking External PROJ.4 version... 480
> found PROJ version 480
> using old PROJ version 4 API
> checking for proj_api.h... yes
> checking External PROJ.4 version... 480
> checking for location of External PROJ.4 library... /home/user/geo/bin/lib/
> checking for pj_get_def in -lproj... yes
> checking for location of External PROJ data files...
> /home/user/geo/bin/share/proj/
> checking for /home/user/geo/bin/share/proj//epsg... no
> configure: warning: *** Unable to locate PROJ data files.
> [...]
> using old PROJ 4 API
>
> It compiles but then it gives errors for different modules
> I think the "problem" is that it can not locate proj.h (it exists in
> /home/user/geo/bin/include/proj.h). I tried to add the path to the $PATH
> variable but it does not really improve.
> Any additional/different options that I can try?
>
> Thanks in advance
> Laura
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] compiling grass-7.8.5 on centos7 with proj from source

[Laura Poggio]

Dear all,
I am trying to compile grass-7.8.5 on a managed HPC with centos7 and rather
old libraries for proj. The most recent is 5.0.1. Unfortunately it seems
not possible to unload completely the oldest (4.8.0) version
I compile proj 7.2.1 from source and it works.
This is the compile instructions that I use (it works on containers and
clean install without this old version of proj loaded).

```
./configure \
-prefix=/home/user/$grassdir/ \
--enable-64bit
--with-fftw-includes=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/include/ \
--with-fftw-libs=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/lib/ \
--with-freetype-includes=/home/user/$grassdir/freetypes/freetype-$freetypeVers/include/
\
--with-netcdf --with-geos --with-blas --with-lapack --with-postgres \
--with-zstd-includes=/home/user/$grassdir/zstd/zstd-$zstdVers/lib/ \
--with-zstd-libs=/home/user/$grassdir/zstd/zstd-$zstdVers/lib/ \
--with-gdal=/home/user/gdal/bin312/bin/gdal-config \
--with-geos=/home/user/geo/bin/bin/geos-config \
--with-proj-include=/home/user/geo/bin/include/ \
--with-proj-libs=/home/user/geo/bin/lib/ \
--with-proj-api=yes --with-proj-share=/home/user/geo/bin/share/proj/
```

I tried also with --with-proj-api=no and without the --with-proj-share
option.


Then I get these problems:
[...]
checking for location of External PROJ includes...
checking for proj.h... no
checking External PROJ.4 version... 480
found PROJ version 480
using old PROJ version 4 API
checking for proj_api.h... yes
checking External PROJ.4 version... 480
checking for location of External PROJ.4 library... /home/user/geo/bin/lib/
checking for pj_get_def in -lproj... yes
checking for location of External PROJ data files...
/home/user/geo/bin/share/proj/
checking for /home/user/geo/bin/share/proj//epsg... no
configure: warning: *** Unable to locate PROJ data files.
[...]
using old PROJ 4 API

It compiles but then it gives errors for different modules
I think the "problem" is that it can not locate proj.h (it exists in
/home/user/geo/bin/include/proj.h). I tried to add the path to the $PATH
variable but it does not really improve.
Any additional/different options that I can try?

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

Re: [GRASS-user] r.soils.texture question

[Laura Poggio]

Hi Gianluca,
thanks for the explanation. It was very useful. Thanks to your explanations
I managed to modify the DAT file to reproduce the USDA-NRCS texture triangle
<https://www.nrcs.usda.gov/Internet/FSE_MEDIA/nrcs142p2_050619.jpg>. We are
doing some final checks. After that, if you are interested, I can share the
DAT file.

Thanks a lot!
Laura

On Fri, 12 Jun 2020 at 22:27, Gianluca Massei 
wrote:

> *.dat files are derived from  TALCPP (
> https://www.tandfonline.com/doi/abs/10.1081/CSS-120017410). The values
> describe polygons coordinates for different class inside the texture
> triangle. In r.soils.texture is implemented an algorithm to check if a
> single point is inside or outside a texture polygon. If the point is
> inside it is labeled with the correspondent texture code and used to build
> a texture map.
> By
>
> Il giorno ven 12 giu 2020 alle ore 08:10 Laura Poggio <
> laura.pog...@gmail.com> ha scritto:
>
>> Dear all,
>> I am looking at the DAT file
>> <https://svn.osgeo.org/grass/grass-addons/grass7/raster/r.soils.texture/scheme/USDA.dat>
>> for USDA soil texture classification for the r.soil.texture addon.
>> I have a couple of questions.
>>
>> 1) the class silt-loam appears twice (number 8 and 12). Is this
>> intentional and needed for the calculations?
>>
>> 2) Could you please explain the structure of the DAT file? As example
>> 1
>> 6
>> 0 0 20 45 45 0
>> 100 60 40 40 55 100
>>
>> First line: I think is the class value as written in the pixel.
>> Second line: not sure
>> Following two lines: I think they are somehow the limits of sand, silt
>> and clay. However I can not really understand in which order.
>>
>> Thank you very much in advance
>> Laura
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>
>
> --
> Dott. Gianluca Massei, PhD
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.soils.texture question

[Laura Poggio]

Dear all,
I am looking at the DAT file

for USDA soil texture classification for the r.soil.texture addon.
I have a couple of questions.

1) the class silt-loam appears twice (number 8 and 12). Is this intentional
and needed for the calculations?

2) Could you please explain the structure of the DAT file? As example
1
6
0 0 20 45 45 0
100 60 40 40 55 100

First line: I think is the class value as written in the pixel.
Second line: not sure
Following two lines: I think they are somehow the limits of sand, silt and
clay. However I can not really understand in which order.

Thank you very much in advance
Laura
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error compiling grass 7.8.2 on centos 7

[Laura Poggio]

And this sorted the problem. Compiled with the zstd libraries as well and
no errors.
Thank you very much!
Laura


On Fri, 20 Dec 2019 at 13:14, Markus Metz 
wrote:

>
>
> On Fri, Dec 20, 2019 at 12:03 PM Laura Poggio 
> wrote:
> >
> > Dear all,
> > I managed to remove the error by specifying --without-zstd.
>
> is it possible that your custom path to zstd libs
> /home/user/grass/zstd/zstd-1.4.0/lib
> is not in LD_LIBRARY_PATH?
>
> That would explain it.
>
> Markus M
> >
> > Thanks a lot!
> > Laura
> >
> > On Fri, 20 Dec 2019 at 10:48, Laura Poggio 
> wrote:
> >>
> >> Dear Markus,
> >> the path to the GRASS source (the directory where I compile) is
> >> /home/user/grass/grass-7.8.2/
> >>
> >> I get the same when I try to compile with -prefix=/home/user/local/
> >>
> >> Thanks!
> >> Laura
> >>
> >> On Fri, 20 Dec 2019 at 09:22, Markus Metz <
> markus.metz.gisw...@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Dec 20, 2019 at 7:47 AM Laura Poggio 
> wrote:
> >>> >
> >>> > Dear Markus,
> >>> > thanks
> >>> >
> >>> > Below my configure (grass 7.6.1 compiles fine with a similar
> configure.)
> >>> >
> >>> > ./configure \
> >>> > -prefix=/home/user/grass/ \
> >>>
> >>> is it possible that prefix and path to the GRASS source are identical?
> This will not work and cause errors when running "make install". In this
> case, prefix must be set to another location, e.g. /home/user/local if you
> do not want or can not use the default /usr/local.
> >>>
> >>> Just a guess,
> >>>
> >>> Markus M
> >>>
> >>> > --enable-64bit
> --with-fftw-includes=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/include/ \
> >>> > --with-fftw-libs=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/lib/ \
> >>> >
> --with-freetype-includes=/home/user/grass/freetypes/freetype-2.9.1/include/
> \
> >>> > --with-netcdf --with-geos --with-blas --with-lapack --with-postgres \
> >>> > --with-zstd-libs=/home/user/grass/zstd/zstd-1.4.0/lib/ \
> >>> > --with-zstd-includes=/home/user/grass/zstd/zstd-1.4.0/lib/
> >>> >
> >>> > The freetype and zstd are in my home because they are not available
> on the cluster, so I had to create them locally.
> >>> > If I may, I add an additional question: which is the right option in
> configure to point to a specific version of proj? --with-proj-libs?
> >>> >
> >>> > Thanks a lot
> >>> >
> >>> > Laura
> >>> >
> >>> >
> >>> >
> >>> > On Thu, 19 Dec 2019 at 23:36, Markus Neteler 
> wrote:
> >>> >>
> >>> >> On Thu, Dec 19, 2019 at 8:12 AM Laura Poggio <
> laura.pog...@gmail.com> wrote:
> >>> >> >
> >>> >> > Dear list,
> >>> >> > I am trying to compile grass 7.8.2 on an HPC cluster using centos
> 7 as operative system. I can not install binaries.
> >>> >>
> >>> >> Just to understand: for policy reasons?
> >>> >>
> >>> >> > I need to compile from source.
> >>> >> >
> >>> >> > The python version I am using is Python 3.7.4
> >>> >> >
> >>> >> > The configure and the make are working fine.
> >>> >>
> >>> >> Importantly, pls post your "configure" command to better understand
> >>> >> the error below:
> >>> >>
> >>> >> > However I get the following errors at the make install stage:
> >>> >> >
> >>> >> > rm /home/user/grass//grass78/etc/fontcap
> >>> >> > rm: cannot remove ‘/home/user/grass//grass78/etc/fontcap’: No
> such file or directory
> >>> >> > make[1]: [real-install] Error 1 (ignored)
> >>> >> > make /home/user/grass//grass78/etc/fontcap
> >>> >> > make[2]: Entering directory `/home/user/grass/grass-7.8.2'
> >>> >> > make[2]: *** No rule to make target
> `/home/user/grass/grass-7.8.2/dist.x86_64-pc-linux-gnu/etc/fontcap', needed
> by `/home/user/grass//grass78/etc/fontcap'.  Stop.
> >>> >> > make[2]: Leaving directory `/home/user/grass/grass-7.8.2'
> >>> >> > make[1]: *** [real-install] Error 2
> >>> >> > make[1]: Leaving directory `/home/user/grass/grass-7.8.2'
> >>> >> > make: *** [install] Error 2
> >>> >> >
> >>> >> > Am I missing some dependencies in the fonts?
> >>> >>
> >>> >> ... probably in the configure step.
> >>> >>
> >>> >> > Is the python version ok or should I use a slightly older 3.x one?
> >>> >>
> >>> >> That should be fine.
> >>> >>
> >>> >> > are there any recommendations for the gcc version to use?
> >>> >>
> >>> >> No special recommendations.
> >>> >>
> >>> >> Best wishes
> >>> >> Markus
> >>> >
> >>> > ___
> >>> > grass-user mailing list
> >>> > grass-user@lists.osgeo.org
> >>> > https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error compiling grass 7.8.2 on centos 7

[Laura Poggio]

Dear all,
I managed to remove the error by specifying --without-zstd.

Thanks a lot!
Laura

On Fri, 20 Dec 2019 at 10:48, Laura Poggio  wrote:

> Dear Markus,
> the path to the GRASS source (the directory where I compile) is
> /home/user/grass/grass-7.8.2/
>
> I get the same when I try to compile with -prefix=/home/user/local/
>
> Thanks!
> Laura
>
> On Fri, 20 Dec 2019 at 09:22, Markus Metz 
> wrote:
>
>>
>>
>> On Fri, Dec 20, 2019 at 7:47 AM Laura Poggio 
>> wrote:
>> >
>> > Dear Markus,
>> > thanks
>> >
>> > Below my configure (grass 7.6.1 compiles fine with a similar configure.)
>> >
>> > ./configure \
>> > -prefix=/home/user/grass/ \
>>
>> is it possible that prefix and path to the GRASS source are identical?
>> This will not work and cause errors when running "make install". In this
>> case, prefix must be set to another location, e.g. /home/user/local if you
>> do not want or can not use the default /usr/local.
>>
>> Just a guess,
>>
>> Markus M
>>
>> > --enable-64bit
>> --with-fftw-includes=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/include/ \
>> > --with-fftw-libs=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/lib/ \
>> >
>> --with-freetype-includes=/home/user/grass/freetypes/freetype-2.9.1/include/
>> \
>> > --with-netcdf --with-geos --with-blas --with-lapack --with-postgres \
>> > --with-zstd-libs=/home/user/grass/zstd/zstd-1.4.0/lib/ \
>> > --with-zstd-includes=/home/user/grass/zstd/zstd-1.4.0/lib/
>> >
>> > The freetype and zstd are in my home because they are not available on
>> the cluster, so I had to create them locally.
>> > If I may, I add an additional question: which is the right option in
>> configure to point to a specific version of proj? --with-proj-libs?
>> >
>> > Thanks a lot
>> >
>> > Laura
>> >
>> >
>> >
>> > On Thu, 19 Dec 2019 at 23:36, Markus Neteler  wrote:
>> >>
>> >> On Thu, Dec 19, 2019 at 8:12 AM Laura Poggio 
>> wrote:
>> >> >
>> >> > Dear list,
>> >> > I am trying to compile grass 7.8.2 on an HPC cluster using centos 7
>> as operative system. I can not install binaries.
>> >>
>> >> Just to understand: for policy reasons?
>> >>
>> >> > I need to compile from source.
>> >> >
>> >> > The python version I am using is Python 3.7.4
>> >> >
>> >> > The configure and the make are working fine.
>> >>
>> >> Importantly, pls post your "configure" command to better understand
>> >> the error below:
>> >>
>> >> > However I get the following errors at the make install stage:
>> >> >
>> >> > rm /home/user/grass//grass78/etc/fontcap
>> >> > rm: cannot remove ‘/home/user/grass//grass78/etc/fontcap’: No such
>> file or directory
>> >> > make[1]: [real-install] Error 1 (ignored)
>> >> > make /home/user/grass//grass78/etc/fontcap
>> >> > make[2]: Entering directory `/home/user/grass/grass-7.8.2'
>> >> > make[2]: *** No rule to make target
>> `/home/user/grass/grass-7.8.2/dist.x86_64-pc-linux-gnu/etc/fontcap', needed
>> by `/home/user/grass//grass78/etc/fontcap'.  Stop.
>> >> > make[2]: Leaving directory `/home/user/grass/grass-7.8.2'
>> >> > make[1]: *** [real-install] Error 2
>> >> > make[1]: Leaving directory `/home/user/grass/grass-7.8.2'
>> >> > make: *** [install] Error 2
>> >> >
>> >> > Am I missing some dependencies in the fonts?
>> >>
>> >> ... probably in the configure step.
>> >>
>> >> > Is the python version ok or should I use a slightly older 3.x one?
>> >>
>> >> That should be fine.
>> >>
>> >> > are there any recommendations for the gcc version to use?
>> >>
>> >> No special recommendations.
>> >>
>> >> Best wishes
>> >> Markus
>> >
>> > ___
>> > grass-user mailing list
>> > grass-user@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error compiling grass 7.8.2 on centos 7

[Laura Poggio]

Dear Markus,
the path to the GRASS source (the directory where I compile) is
/home/user/grass/grass-7.8.2/

I get the same when I try to compile with -prefix=/home/user/local/

Thanks!
Laura

On Fri, 20 Dec 2019 at 09:22, Markus Metz 
wrote:

>
>
> On Fri, Dec 20, 2019 at 7:47 AM Laura Poggio 
> wrote:
> >
> > Dear Markus,
> > thanks
> >
> > Below my configure (grass 7.6.1 compiles fine with a similar configure.)
> >
> > ./configure \
> > -prefix=/home/user/grass/ \
>
> is it possible that prefix and path to the GRASS source are identical?
> This will not work and cause errors when running "make install". In this
> case, prefix must be set to another location, e.g. /home/user/local if you
> do not want or can not use the default /usr/local.
>
> Just a guess,
>
> Markus M
>
> > --enable-64bit
> --with-fftw-includes=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/include/ \
> > --with-fftw-libs=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/lib/ \
> >
> --with-freetype-includes=/home/user/grass/freetypes/freetype-2.9.1/include/
> \
> > --with-netcdf --with-geos --with-blas --with-lapack --with-postgres \
> > --with-zstd-libs=/home/user/grass/zstd/zstd-1.4.0/lib/ \
> > --with-zstd-includes=/home/user/grass/zstd/zstd-1.4.0/lib/
> >
> > The freetype and zstd are in my home because they are not available on
> the cluster, so I had to create them locally.
> > If I may, I add an additional question: which is the right option in
> configure to point to a specific version of proj? --with-proj-libs?
> >
> > Thanks a lot
> >
> > Laura
> >
> >
> >
> > On Thu, 19 Dec 2019 at 23:36, Markus Neteler  wrote:
> >>
> >> On Thu, Dec 19, 2019 at 8:12 AM Laura Poggio 
> wrote:
> >> >
> >> > Dear list,
> >> > I am trying to compile grass 7.8.2 on an HPC cluster using centos 7
> as operative system. I can not install binaries.
> >>
> >> Just to understand: for policy reasons?
> >>
> >> > I need to compile from source.
> >> >
> >> > The python version I am using is Python 3.7.4
> >> >
> >> > The configure and the make are working fine.
> >>
> >> Importantly, pls post your "configure" command to better understand
> >> the error below:
> >>
> >> > However I get the following errors at the make install stage:
> >> >
> >> > rm /home/user/grass//grass78/etc/fontcap
> >> > rm: cannot remove ‘/home/user/grass//grass78/etc/fontcap’: No such
> file or directory
> >> > make[1]: [real-install] Error 1 (ignored)
> >> > make /home/user/grass//grass78/etc/fontcap
> >> > make[2]: Entering directory `/home/user/grass/grass-7.8.2'
> >> > make[2]: *** No rule to make target
> `/home/user/grass/grass-7.8.2/dist.x86_64-pc-linux-gnu/etc/fontcap', needed
> by `/home/user/grass//grass78/etc/fontcap'.  Stop.
> >> > make[2]: Leaving directory `/home/user/grass/grass-7.8.2'
> >> > make[1]: *** [real-install] Error 2
> >> > make[1]: Leaving directory `/home/user/grass/grass-7.8.2'
> >> > make: *** [install] Error 2
> >> >
> >> > Am I missing some dependencies in the fonts?
> >>
> >> ... probably in the configure step.
> >>
> >> > Is the python version ok or should I use a slightly older 3.x one?
> >>
> >> That should be fine.
> >>
> >> > are there any recommendations for the gcc version to use?
> >>
> >> No special recommendations.
> >>
> >> Best wishes
> >> Markus
> >
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error compiling grass 7.8.2 on centos 7

[Laura Poggio]

Dear Markus,
thanks

Below my configure (grass 7.6.1 compiles fine with a similar configure.)

./configure \
-prefix=/home/user/grass/ \
--enable-64bit
--with-fftw-includes=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/include/ \
--with-fftw-libs=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/lib/ \
--with-freetype-includes=/home/user/grass/freetypes/freetype-2.9.1/include/
\
--with-netcdf --with-geos --with-blas --with-lapack --with-postgres \
--with-zstd-libs=/home/user/grass/zstd/zstd-1.4.0/lib/ \
--with-zstd-includes=/home/user/grass/zstd/zstd-1.4.0/lib/

The freetype and zstd are in my home because they are not available on the
cluster, so I had to create them locally.
If I may, I add an additional question: which is the right option in
configure to point to a specific version of proj? --with-proj-libs?

Thanks a lot

Laura



On Thu, 19 Dec 2019 at 23:36, Markus Neteler  wrote:

> On Thu, Dec 19, 2019 at 8:12 AM Laura Poggio 
> wrote:
> >
> > Dear list,
> > I am trying to compile grass 7.8.2 on an HPC cluster using centos 7 as
> operative system. I can not install binaries.
>
> Just to understand: for policy reasons?
>
> > I need to compile from source.
> >
> > The python version I am using is Python 3.7.4
> >
> > The configure and the make are working fine.
>
> Importantly, pls post your "configure" command to better understand
> the error below:
>
> > However I get the following errors at the make install stage:
> >
> > rm /home/user/grass//grass78/etc/fontcap
> > rm: cannot remove ‘/home/user/grass//grass78/etc/fontcap’: No such file
> or directory
> > make[1]: [real-install] Error 1 (ignored)
> > make /home/user/grass//grass78/etc/fontcap
> > make[2]: Entering directory `/home/user/grass/grass-7.8.2'
> > make[2]: *** No rule to make target
> `/home/user/grass/grass-7.8.2/dist.x86_64-pc-linux-gnu/etc/fontcap', needed
> by `/home/user/grass//grass78/etc/fontcap'.  Stop.
> > make[2]: Leaving directory `/home/user/grass/grass-7.8.2'
> > make[1]: *** [real-install] Error 2
> > make[1]: Leaving directory `/home/user/grass/grass-7.8.2'
> > make: *** [install] Error 2
> >
> > Am I missing some dependencies in the fonts?
>
> ... probably in the configure step.
>
> > Is the python version ok or should I use a slightly older 3.x one?
>
> That should be fine.
>
> > are there any recommendations for the gcc version to use?
>
> No special recommendations.
>
> Best wishes
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] error compiling grass 7.8.2 on centos 7

[Laura Poggio]

Dear list,
I am trying to compile grass 7.8.2 on an HPC cluster using centos 7 as
operative system. I can not install binaries. I need to compile from source.

The python version I am using is Python 3.7.4

The configure and the make are working fine. However I get the following
errors at the make install stage:

rm /home/user/grass//grass78/etc/fontcap
rm: cannot remove ‘/home/user/grass//grass78/etc/fontcap’: No such file or
directory
make[1]: [real-install] Error 1 (ignored)
make /home/user/grass//grass78/etc/fontcap
make[2]: Entering directory `/home/user/grass/grass-7.8.2'
make[2]: *** No rule to make target
`/home/user/grass/grass-7.8.2/dist.x86_64-pc-linux-gnu/etc/fontcap', needed
by `/home/user/grass//grass78/etc/fontcap'.  Stop.
make[2]: Leaving directory `/home/user/grass/grass-7.8.2'
make[1]: *** [real-install] Error 2
make[1]: Leaving directory `/home/user/grass/grass-7.8.2'
make: *** [install] Error 2

Am I missing some dependencies in the fonts?
Is the python version ok or should I use a slightly older 3.x one?
are there any recommendations for the gcc version to use?

Thank you very much for your help in advance.
Best wishes

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

Re: [GRASS-user] grass78 on centos7 from coprs/neteler/grass78

[Laura Poggio]

Dear Markus,
it works fine with the latest version of grass (7.8.2 from
coprs/neteler/grass78/) on centos 7. I did not test with previous versions.

I will try to test the whole workflow on centos 8 soon(ish).

Thank you very much!
Laura

On Mon, 9 Dec 2019 at 07:46, Laura Poggio  wrote:

> Dear Markus,
> thanks for this!
> I will test as soon as I can this week
>
> Thanks a lot
> Laura
>
>
>
> On Sat, 7 Dec 2019 at 18:11, Markus Neteler  wrote:
>
>> Hi Laura,
>>
>> On Tue, Nov 19, 2019 at 10:11 AM Markus Neteler 
>> wrote:
>> >
>> > Hi Laura,
>> >
>> > Today the EPEL package reached "testing":
>> >
>> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8d020579ef
>> >
>> > You may want to test it and leave "karma" there (positive or negative)
>> > in order to let the packager know that things work (or not).
>>
>> FYI - update:
>>
>> python-wxpython4-4.0.7-4.el7 has been pushed to the Fedora EPEL 7
>> stable repository.
>>
>> (I suppose that it will be available for EPEL 8 either soon or it is
>> already there.)
>>
>> I have now triggered the GRASS GIS compilation on COPR again.
>>
>> Best,
>> Markus
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass78 on centos7 from coprs/neteler/grass78

[Laura Poggio]

Dear Markus,
thanks for this!
I will test as soon as I can this week

Thanks a lot
Laura



On Sat, 7 Dec 2019 at 18:11, Markus Neteler  wrote:

> Hi Laura,
>
> On Tue, Nov 19, 2019 at 10:11 AM Markus Neteler  wrote:
> >
> > Hi Laura,
> >
> > Today the EPEL package reached "testing":
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8d020579ef
> >
> > You may want to test it and leave "karma" there (positive or negative)
> > in order to let the packager know that things work (or not).
>
> FYI - update:
>
> python-wxpython4-4.0.7-4.el7 has been pushed to the Fedora EPEL 7
> stable repository.
>
> (I suppose that it will be available for EPEL 8 either soon or it is
> already there.)
>
> I have now triggered the GRASS GIS compilation on COPR again.
>
> Best,
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass78 on centos7 from coprs/neteler/grass78

[Laura Poggio]

Dear Markus,
I will do it as soon as possible.
Thanks
Laura

On Tue, 19 Nov 2019 at 10:11, Markus Neteler  wrote:

> Hi Laura,
>
> Today the EPEL package reached "testing":
>
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8d020579ef
>
> You may want to test it and leave "karma" there (positive or negative)
> in order to let the packager know that things work (or not).
>
> Best
> Markus
>
> On Fri, Oct 25, 2019 at 3:36 PM Laura Poggio 
> wrote:
> >
> > Hi,
> > thanks a lot!
> > In the meantime I can use the png monitor if really needed (working on a
> cloud machine on a storage type I can not really mount locally).
> >
> > Thanks a lot
> > Laura
> >
> >
> > On Fri, 25 Oct 2019 at 15:02, Markus Neteler  wrote:
> >>
> >> Hi again,
> >>
> >> On Fri, Oct 25, 2019 at 1:52 PM Markus Neteler 
> wrote:
> >> ...
> >> > In GRASS 7.8, we moved to Python 3.
> >> > In Fedora, we use python3-wxpython4 to compile wxGUI:
> >> > - https://koji.fedoraproject.org/koji/packageinfo?packageID=26351
> >> >
> >> > However, I don't know where to find a corresponding EPEL package:
> >> > -
> https://centos.pkgs.org/7/epel-x86_64/wxPython-2.8.12.0-9.el7.x86_64.rpm.html
> >> > -
> https://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/w/
> >> >
> >> > Does anyone have an idea? Maybe I am missing something.
> >>
> >> I now briefly talked to the wxPython EPEL maintainer, and opened a
> >> related ticket:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1765573
> >>
> >> Hope it get's packaged soon.
> >>
> >> Best,
> >> Markus
>
>
>
> --
> Markus Neteler, PhD
> https://www.mundialis.de - free data with free software
> https://grass.osgeo.org
> https://courses.neteler.org/blog
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass78 on centos7 from coprs/neteler/grass78

[Laura Poggio]

Hi,
thanks a lot!
In the meantime I can use the png monitor if really needed (working on a
cloud machine on a storage type I can not really mount locally).

Thanks a lot
Laura


On Fri, 25 Oct 2019 at 15:02, Markus Neteler  wrote:

> Hi again,
>
> On Fri, Oct 25, 2019 at 1:52 PM Markus Neteler  wrote:
> ...
> > In GRASS 7.8, we moved to Python 3.
> > In Fedora, we use python3-wxpython4 to compile wxGUI:
> > - https://koji.fedoraproject.org/koji/packageinfo?packageID=26351
> >
> > However, I don't know where to find a corresponding EPEL package:
> > -
> https://centos.pkgs.org/7/epel-x86_64/wxPython-2.8.12.0-9.el7.x86_64.rpm.html
> > - https://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/w/
> >
> > Does anyone have an idea? Maybe I am missing something.
>
> I now briefly talked to the wxPython EPEL maintainer, and opened a
> related ticket:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1765573
>
> Hope it get's packaged soon.
>
> Best,
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass78 on centos7 from coprs/neteler/grass78

[Laura Poggio]

Dear Markus,
the main installation worked fine. Thanks a lot!

One more question. I installed grass-gui as well withou problems or errors
When I start GRASS I get the message: ERROR: wxGUI requires wxPython. No
module named 'wx'
I installed wxPython (and its devel) with yum but I think it is not the
right version. I tried to installed it within conda environments or using
pip3, but the installation is giving errors.
Before I start to dig into it, I was wondering if there is some quick
solution to get the right wxPython?

Thanks a lot again!

Laura



On Thu, 24 Oct 2019 at 20:26, Markus Neteler  wrote:

> Dear Laura,
>
> I forgot to encapsulate two more statements. It has been compiled again.
> Please give it a new try.
>
> ciao
> Markus
>
> Laura Poggio  schrieb am Do., 24. Okt. 2019,
> 16:27:
>
>> Dear Markus,
>> I tried and I get
>>
>> Error: Package: grass-7.8.0-4.el7.x86_64 (copr:copr.fedorainfracloud.org:
>> neteler:grass78)
>>Requires: python3-numpy
>> Error: Package: grass-7.8.0-4.el7.x86_64 (copr:copr.fedorainfracloud.org:
>> neteler:grass78)
>>Requires: python3-matplotlib
>>
>> yum lists
>> python34-numpy.x86_64 : A fast multidimensional array facility for
>> Python 3.4
>> python36-numpy.x86_64 : A fast multidimensional array facility for
>> Python 3.6
>>
>> but not exactly python3-numpy or python3-matplotlib. I installed 
>> python36-numpy.x86_64
>> and python36-*matplotlib*.x86_64
>> I also tried to install from
>> https://copr.fedorainfracloud.org/coprs/neteler/python-matplotlib/ but I
>> could not get past the error above.
>> Maybe it is something on how it is necessary to refer to python3 in
>> centos?
>> I tried both with conda and with python3 from yum.
>>
>> Thanks a lot!
>>
>> Laura
>>
>>
>> On Thu, 24 Oct 2019 at 15:04, Markus Neteler  wrote:
>>
>>> Hi again,
>>>
>>> On Thu, Oct 24, 2019 at 12:21 PM Markus Neteler 
>>> wrote:
>>> > On Thu, Oct 24, 2019 at 12:12 PM Laura Poggio 
>>> wrote:
>>> >
>>> > Right now we are stuck at this:
>>> ...
>>> > Means I have to update the SPEC file to add more special rules for
>>> > EPEL7... I try asap.
>>>
>>> Seems I got it :)
>>>
>>> https://copr.fedorainfracloud.org/coprs/neteler/grass78/
>>>
>>> Please note that I also fixed a typo in the EPEL7 install step in above
>>> page.
>>> Please let me know if it now works for you,
>>>
>>> Best
>>> Markus
>>>
>>>
>>>
>>> --
>>> Markus Neteler, PhD
>>> https://www.mundialis.de - free data with free software
>>> https://grass.osgeo.org
>>> https://courses.neteler.org/blog
>>>
>>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass78 on centos7 from coprs/neteler/grass78

[Laura Poggio]

Dear Markus,
I tried and I get

Error: Package: grass-7.8.0-4.el7.x86_64 (copr:copr.fedorainfracloud.org:
neteler:grass78)
   Requires: python3-numpy
Error: Package: grass-7.8.0-4.el7.x86_64 (copr:copr.fedorainfracloud.org:
neteler:grass78)
   Requires: python3-matplotlib

yum lists
python34-numpy.x86_64 : A fast multidimensional array facility for Python
3.4
python36-numpy.x86_64 : A fast multidimensional array facility for Python
3.6

but not exactly python3-numpy or python3-matplotlib. I installed
python36-numpy.x86_64
and python36-*matplotlib*.x86_64
I also tried to install from
https://copr.fedorainfracloud.org/coprs/neteler/python-matplotlib/ but I
could not get past the error above.
Maybe it is something on how it is necessary to refer to python3 in centos?
I tried both with conda and with python3 from yum.

Thanks a lot!

Laura


On Thu, 24 Oct 2019 at 15:04, Markus Neteler  wrote:

> Hi again,
>
> On Thu, Oct 24, 2019 at 12:21 PM Markus Neteler  wrote:
> > On Thu, Oct 24, 2019 at 12:12 PM Laura Poggio 
> wrote:
> >
> > Right now we are stuck at this:
> ...
> > Means I have to update the SPEC file to add more special rules for
> > EPEL7... I try asap.
>
> Seems I got it :)
>
> https://copr.fedorainfracloud.org/coprs/neteler/grass78/
>
> Please note that I also fixed a typo in the EPEL7 install step in above
> page.
> Please let me know if it now works for you,
>
> Best
> Markus
>
>
>
> --
> Markus Neteler, PhD
> https://www.mundialis.de - free data with free software
> https://grass.osgeo.org
> https://courses.neteler.org/blog
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass78 on centos7 from coprs/neteler/grass78

[Laura Poggio]

Dear Markus,
thank you very much. Your repositories for fedora and centos are really
very helpful in avoiding the compilation from source.

Thanks a lot
Laura

On Thu, 24 Oct 2019 at 11:56, Markus Neteler  wrote:

> Dear Laura,
>
> On Thu, Oct 24, 2019 at 8:24 AM Laura Poggio 
> wrote:
> >
> > Dear list,
> > I am trying to install grass78 on centos7.
> > I am following the instructions here:
> https://copr.fedorainfracloud.org/coprs/neteler/grass78/
> > However when trying to download the file
> https://copr.fedoraproject.org/coprs/neteler/grass78/repo/epel-7/neteler-grass78-epel-7.repo
> I get "Error 404: Not Found Chroot epel-7 does not exist in neteler/grass78"
> >
> > I am wondering if maybe the file is in some slightly different path or
> if I m doing something wrong
>
> Nothing wrong at your end, but at "my" end. I just see that EPEL7
> compilation was deactivated.
> I have now enabled it and started the compilation [1]. I hope it goes
> through.
>
> Will let you know as soon as I get the result.
>
> [1] https://copr.fedorainfracloud.org/coprs/neteler/grass78/build/1078463/
>
> Best regards
> Markus
>
>
> --
> Markus Neteler, PhD
> https://www.mundialis.de - free data with free software
> https://grass.osgeo.org
> https://courses.neteler.org/blog
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] grass78 on centos7 from coprs/neteler/grass78

[Laura Poggio]

Dear list,
I am trying to install grass78 on centos7.
I am following the instructions here:
https://copr.fedorainfracloud.org/coprs/neteler/grass78/
However when trying to download the file
https://copr.fedoraproject.org/coprs/neteler/grass78/repo/epel-7/neteler-grass78-epel-7.repo
I get "Error 404: Not Found Chroot epel-7 does not exist in neteler/grass78"

I am wondering if maybe the file is in some slightly different path or if I
m doing something wrong

Thank you very much in advance

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

Re: [GRASS-user] turning sqlite journal off

[Laura Poggio]

Dear all,
thanks for the answers and apologies if my question at the beginning was
not so clear.
SQLITE can support multiple readers and only one writer. But it is not the
main problem.
The issue here is the creation of the journal file. Each time a GRASS
session that modified the sqlite.db file is closed, the journal file is
created. This can take quite some time and during this time the database is
locked. This behaviour is expected.
I can turn off the creation of the journal file (being aware of the
potential risks) using sqlite options and thus reducing the time the
database is locked. However these options do not apply when the file is
modified by GRASS.
Is it possible to turn off the creation of the journal file when a GRASS
session is involved?

Thanks!

Laura


On Thu, 16 May 2019 at 00:07, Nikos Alexandris 
wrote:

> * Markus Metz  [2019-05-15 22:55:13 +0200]:
>
> >On Tue, May 14, 2019 at 11:12 AM Panagiotis Mavrogiorgos <
> pma...@gmail.com>
> >wrote:
> >>
> >> Hi Laura,
> >>
> >> This thread seems to be related:
> >
> http://osgeo-org.1560.x6.nabble.com/SQLITE-db-locking-problem-td5182180.html
> >> I also had a somewhat similar problem that was related to the VACUUM
> >command issued when closing a GRASS session (new session started before
> the
> >VACUUM of the previous session was finished)
> >> If I understand this correctly, you are not supposed to concurrently use
> >the same sqlite database.
> >
> >Yes, this is a limitation of sqlite, and the GRASS-internal sqlite driver
> >has been adapted accordingly as much as possible.
>
> Nevertheless, concurrent reading is allowed.  Reading the discussion so
> far, one may think that no concurrent use is possible at all.
>
> See also https://sqlite.org/whentouse.html :
>
>   "SQLite supports an unlimited number of simultaneous readers, but it
>   will only allow one writer at any instant in time."
>
> And in https://sqlite.org/lockingv3.html see 'SHARED'.
> Also, https://stackoverflow.com/a/4060838/1172302.
>
> Nikos
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] turning sqlite journal off

[Laura Poggio]

Dear all,
we need to run a series of operations on a sqlite database. We noticed that
after each grass session close there is a journal file created. This can
take some time to be finished. Therefore it takes some time for the DB to
be ready for the next session.

We tried to turn off the journal mode directly on the sqlite file (being
aware of the potential risks):

sqlite3 $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db
sqlite> PRAGMA journal_mode = OFF;

This worked as any commands run directly from sqlite3 do not create the
journal file anymore. However if the sqlite file is accessed by GRASS the
journal file is created again and we often experience locking problems,
with the following warning is often issued: WARNING: Busy SQLITE db,
already waiting for 10 seconds...

Is there a way to turn off the journal mode in SQLite for GRASS?

Thanks in advance for any suggestions

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

Re: [GRASS-user] sharing GRASS mapsets

[Laura Poggio]

Hi Stefan,
that helps a lot actually. The suggestion to subdivide the mapset is a good
one. But we also need a way to have more than one person (not all users)
able to manage everything. So probably  the GRASS_SKIP_MAPSET_OWNER_CHECK
is a good option if used carefully.

Thanks a lot

Laura

On Wed, 6 Feb 2019 at 14:47, Stefan Blumentrath 
wrote:

> Hi Laura,
>
>
>
> There are several options.
>
>
>
> One option would be to subdivide “ENVIROMENTAL_COVARIATES” into e.g.
> topics.
>
> In my organisation (also environmental research) we organized mapsets with
> prefixes (g_ for mapsets of general interest, gt_ for time series, p_ for
> projects, u_ for users). Different users can take care of different topics
> (but everybody has to clean up his/her own mess).
>
> These mapsets can then easily added to the users search_path with
> g.mapsets (https://grass.osgeo.org/grass74/manuals/g.mapsets.html)…
>
>
>
> An advantage of splitting up ENVIROMENTAL_COVARIATES into smaller mapsets
> is that it is easier to move chunks of data (e.g. from central storage to
> compute units (laptop/server))…
>
>
>
> If your users are allowed to change file ownership, they could in
> principle take over “ENVIROMENTAL_COVARIATES”. However, an important
> point of the ownership check implemented in GRASS is to make sure that
> users do not shoot each others in the foot…
>
> That check can be overwritten with the GRASS_SKIP_MAPSET_OWNER_CHECK
> environment variable (see:
> https://grass.osgeo.org/grass74/manuals/variables.html)
>
>
>
> See also the related issue: https://trac.osgeo.org/grass/ticket/1829
>
>
>
> For both of the latter options there is a significant risk in a multi-user
> environment…
>
>
>
> Hope that helps a bit…
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* grass-user  *On Behalf Of *Laura
> Poggio
> *Sent:* onsdag 6. februar 2019 12:22
> *To:* GRASS user list 
> *Subject:* [GRASS-user] sharing GRASS mapsets
>
>
>
> Dear all,
>
> we need to share a GRASS location and its mapsets across multiple users.
>
> We would like to have a structure similar to this:
>
> LOCATION:
>
>  PERMANENT
>
>  ENVIROMENTAL_COVARIATES
>
>  working_mapset_for_each_user
>
>
>
> It is clear in the documentation that a user can only write in a mapset
> that it owns.
>
> However we would need to have multiple users to be able to
> add/delete/modify files to the ENVIROMENTAL_COVARIATES mapset. Is this
> possible at all? any workaround that can be implemented?
>
>
>
> Thanks in advance
>
>
>
> Laura
>
>
>
>
>
>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] sharing GRASS mapsets

[Laura Poggio]

Dear all,
we need to share a GRASS location and its mapsets across multiple users.
We would like to have a structure similar to this:
LOCATION:
 PERMANENT
 ENVIROMENTAL_COVARIATES
 working_mapset_for_each_user

It is clear in the documentation that a user can only write in a mapset
that it owns.
However we would need to have multiple users to be able to
add/delete/modify files to the ENVIROMENTAL_COVARIATES mapset. Is this
possible at all? any workaround that can be implemented?

Thanks in advance

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

Re: [GRASS-user] installing 7.4.1 on Centos7

[Laura Poggio]

Dear Markus,
The updated package worked without problems.

Thanks a lot

Laura


On Sat, 23 Jun 2018, 19:02 Markus Metz, 
wrote:

>
>
> On Sat, Jun 23, 2018 at 7:31 PM, Markus Neteler  wrote:
> >
> > Dear Laura,
> >
> > On Sat, Jun 23, 2018 at 6:14 PM, Laura Poggio 
> wrote:
> > > Dear Markus,
> > > the packages with wxpython in the name are (centos 7.5.1804):
> > > wxPython-devel.x86_64
> > > wxPython-docs.x86_64
> > > wxPython.x86_64
> > >
> > > yum can not find matches for various combinations of python-wxpython
>
> For the record, on Scientific Linux 7.5, I have only installed
> wxPython.x86_64
> from EPEL, nothing else regarding wxPython, and compiling from source
> works fine.
>
> Markus M
>
> >
> > ok, fine. I have added a condition for EPEL7 which hopefully does the
> > job. All rebuilt there.
> >
> > Please update from the repo:
> >
> > # I think ir is to be done like this:
> > yum clean all
> > yum update
> > ...
> >
> > ... and let me know if that helped.
> >
> > best,
> > Markus
> >
> >
> >
> > --
> > Markus Neteler, PhD
> > http://www.mundialis.de - free data with free software
> > http://grass.osgeo.org
> > http://courses.neteler.org/blog
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] installing 7.4.1 on Centos7

[Laura Poggio]

Dear Markus,
the packages with wxpython in the name are (centos 7.5.1804):
wxPython-devel.x86_64
wxPython-docs.x86_64
wxPython.x86_64

yum can not find matches for various combinations of python-wxpython

Please let me know if you need further information

Thanks a lot

Laura


On Sat, 23 Jun 2018 at 12:42, Markus Neteler  wrote:

> Hi Laura,
>
> On Fri, Jun 22, 2018 at 4:44 PM, Laura Poggio 
> wrote:
> > Dear list,
> > I am trying to install  grass7.4.1 from
> > https://copr.fedorainfracloud.org/coprs/neteler/grass74/ on centos7 :
> >
> > Error: Package: grass-7.4.1-1.el7.x86_64 (neteler-grass74)
> >Requires: python2-wxpython
> >
> > python2-wxpython does not seem to be available on the major repositories.
>
> Would you mind to check the name on centos7? Is it python-wxpython?
> Then I can rebuild the package.
>
> thanks
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] installing 7.4.1 on Centos7

[Laura Poggio]

Dear list,
I am trying to install  grass7.4.1 from
 https://copr.fedorainfracloud.org/coprs/neteler/grass74
/ on centos7 :

Error: Package: grass-7.4.1-1.el7.x86_64 (neteler-grass74)
   Requires: python2-wxpython

python2-wxpython does not seem to be available on the major repositories.

Thanks in advance for any suggestions.

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

Re: [GRASS-user] Global overview of GRASS HPC resources/installations ?

[Laura Poggio]

Hi Massi,
I can see we live in a quite different "computational" world :-)
I will try to further answer your questions below. I do agree completely
that if you have access to a good HPC than cloud providers are probably not
so needed. If you have a good infrastructure that fits (and even goes
beyond) your needs and it is well maintained. I also think that from the
point of view of setting up GRASS the two approaches are not so different.
And it will be interesting to see the development and comparison of the
different set-ups.

Laura

On 24 May 2018 at 12:12, Massi Alvioli <nocha...@gmail.com> wrote:

> even if you can tile-up your problem - which probably covers 95% of
> the parallelization one can do in GRASS - you still have

the problem instantiate the the cloud machines,


Scriptable: once the instance template is ready it takes few seconds to
launch the machines (even hundreds of them)

copying data to the multiple instances, gather back the results and
> patching them into your final results - the order of last two steps is
> your choice - and
>

This is where I am still exploring the most efficient solution. There are
storage options to avoid or reduce the needs to copy the data to/from the
instances


> I expect all of these operations to be much slower going through the cloud
> than in any other
> architecture.

The overall processing time is what matters, from importing initial
> data to having the final result available.


You are right. However I think it depends if the larger data are on own
premises or online (e.g. remote sensing images). For example for me it is
much faster to download an image on a online instance, especially when the
files are already stored on the provider servers.


> Of course, if the cloud is the only viable possibility of having
> multiple cores, there is no way out. It is also true that everybody
> owns a couple of desktop machines with a few tens of computing cores
> overall ..
>
>
To set up a cluster with spare desktops you need to follow IT policies and
sometimes they are not so easy to adapt. In my opinion, it is also not so
easy  to set up a proper cluster, with shared storage, backup, faster net
connections, etc.



> M
>
>
> 2018-05-24 9:11 GMT+02:00 Laura Poggio <laura.pog...@gmail.com>:
> > Hi Massi,
> > using multiple single instances of GRASS had advantages (in our workflow)
> > when tiling: each tile was sent in its own mapset to a different instance
> > for processing.
> > I am aware that this can be done on HPC locally. However, doing this on
> the
> > cloud had the advantage (for us) to be able to use many more instances
> than
> > the cores available locally.
> >
> > I think you are right and I/O operation and concurrent database
> operations
> > will be probably slower, but our workflow focus mainly on raster
> operations
> > and integrated GRASS / R models. If these operations can be tiled, then
> > there are advantages in doing so on different instances, when one does
> not
> > have access to enough local cores.
> >
> > I am trying to tidy up the workflow used to be able to share. And I am
> > looking forward to see other workflows.
> >
> > Thanks
> >
> > Laura
> >
> > On 23 May 2018 at 21:08, Massi Alvioli <nocha...@gmail.com> wrote:
> >>
> >> Hi Laura,
> >>
> >> well, not actually - it does not answer my question. I mean, I am
> >> pretty sure one can have GRASS up and running on some cloud instance,
> >> but the point is: when it comes to performance, is that convenient? I
> >> mean multi-process performance, of course. There is not much point on
> >> running single GRASS instances, if not for very peculiar applications,
> >> right? I bet it is not convenient, on any level, either if we look at
> >> I/O operations, or mapcalc operations, not to talk about concurrent
> >> database operations ... I might be wrong, of course. But my experience
> >> with cloud environments and parallel processing were rather
> >> disappointing. On some un-related problem (I mean, not GRASS-related),
> >> I tried something here https://doi.org/10.30437/ogrs2016_paper_08,
> >> with little success. I can't imagine a reason why it should be
> >> different using GRASS modules, while I found undoubtfully good
> >> performance on HPC machines.
> >>
> >> M
> >>
> >> 2018-05-23 16:35 GMT+02:00 Laura Poggio <laura.pog...@gmail.com>:
> >> > Hi Massi,
> >> > we managed to run GRASS on different single-core instances on a cloud
> >> > provider. It was a bit tricky (initially) to set up the NFS mount
> >> &

Re: [GRASS-user] Global overview of GRASS HPC resources/installations ?

[Laura Poggio]

Hi Massi,
using multiple single instances of GRASS had advantages (in our workflow)
when tiling: each tile was sent in its own mapset to a different instance
for processing.
I am aware that this can be done on HPC locally. However, doing this on the
cloud had the advantage (for us) to be able to use many more instances than
the cores available locally.

I think you are right and I/O operation and concurrent database operations
will be probably slower, but our workflow focus mainly on raster operations
and integrated GRASS / R models. If these operations can be tiled, then
there are advantages in doing so on different instances, when one does not
have access to enough local cores.

I am trying to tidy up the workflow used to be able to share. And I am
looking forward to see other workflows.

Thanks

Laura

On 23 May 2018 at 21:08, Massi Alvioli <nocha...@gmail.com> wrote:

> Hi Laura,
>
> well, not actually - it does not answer my question. I mean, I am
> pretty sure one can have GRASS up and running on some cloud instance,
> but the point is: when it comes to performance, is that convenient? I
> mean multi-process performance, of course. There is not much point on
> running single GRASS instances, if not for very peculiar applications,
> right? I bet it is not convenient, on any level, either if we look at
> I/O operations, or mapcalc operations, not to talk about concurrent
> database operations ... I might be wrong, of course. But my experience
> with cloud environments and parallel processing were rather
> disappointing. On some un-related problem (I mean, not GRASS-related),
> I tried something here https://doi.org/10.30437/ogrs2016_paper_08,
> with little success. I can't imagine a reason why it should be
> different using GRASS modules, while I found undoubtfully good
> performance on HPC machines.
>
> M
>
> 2018-05-23 16:35 GMT+02:00 Laura Poggio <laura.pog...@gmail.com>:
> > Hi Massi,
> > we managed to run GRASS on different single-core instances on a cloud
> > provider. It was a bit tricky (initially) to set up the NFS mount
> points. I
> > am still exploring the different types of storage possible and what
> would be
> > cheaper and more efficient.
> >
> > I hope this answers your question.
> >
> > Once the workflow is more stable I hope I will be able to share it more
> > widely.
> >
> > Thanks
> >
> > Laura
> >
> > On 23 May 2018 at 14:37, Massi Alvioli <nocha...@gmail.com> wrote:
> >>
> >> Hi Laura,
> >>
> >> the effort on cloud providers is probably useless. Was it different in
> >> your case?
> >>
> >>
> >> M
> >>
> >> 2018-05-22 10:12 GMT+02:00 Laura Poggio <laura.pog...@gmail.com>:
> >> > I am really interested in this. I am experimenting with different
> >> > settings
> >> > to use GRASS on HPC, more specifically on multi-core local machines
> and
> >> > on
> >> > single-core multiple instances on a cloud provider. It would be great
> to
> >> > share experiences with other people fighting the same problems.
> >> >
> >> > Thanks
> >> >
> >> > Laura
> >> >
> >> > On 20 May 2018 at 12:32, Moritz Lennert <mlenn...@club.worldonline.be
> >
> >> > wrote:
> >> >>
> >> >> Le Sun, 20 May 2018 09:30:53 +0200,
> >> >> Nikos Alexandris <n...@nikosalexandris.net> a écrit :
> >> >>
> >> >> > * Massi Alvioli <nocha...@gmail.com> [2018-05-17 15:01:39 +0200]:
> >> >> >
> >> >> > >2018-05-17 10:09 GMT+02:00 Moritz Lennert
> >> >> > ><mlenn...@club.worldonline.be>:
> >> >> > >
> >> >> > >Hi,
> >> >> > >
> >> >> > >> [I imagine your mail was supposed to go onto the mailing list
> and
> >> >> > >> not just to me...]
> >> >> > >
> >> >> > >sure my answer was for everyone to read, I believe I tried to send
> >> >> > > it
> >> >> > >again afterwards..
> >> >> > >something must have gone wrong.
> >> >> > >
> >> >> > >> I just presented GRASS and a short overview over GRASS on HPC
> >> >> > >> yesterday at the FOSS4F-FR and there was a lot of interest for
> >> >> > >> this. Several people asked me about specific documentation on
> the
> >> >> > >> subject.
> >> >> >

Re: [GRASS-user] Global overview of GRASS HPC resources/installations ?

[Laura Poggio]

Hi Massi,
we managed to run GRASS on different single-core instances on a cloud
provider. It was a bit tricky (initially) to set up the NFS mount points. I
am still exploring the different types of storage possible and what would
be cheaper and more efficient.

I hope this answers your question.

Once the workflow is more stable I hope I will be able to share it more
widely.

Thanks

Laura

On 23 May 2018 at 14:37, Massi Alvioli <nocha...@gmail.com> wrote:

> Hi Laura,
>
> the effort on cloud providers is probably useless. Was it different in
> your case?
>
>
> M
>
> 2018-05-22 10:12 GMT+02:00 Laura Poggio <laura.pog...@gmail.com>:
> > I am really interested in this. I am experimenting with different
> settings
> > to use GRASS on HPC, more specifically on multi-core local machines and
> on
> > single-core multiple instances on a cloud provider. It would be great to
> > share experiences with other people fighting the same problems.
> >
> > Thanks
> >
> > Laura
> >
> > On 20 May 2018 at 12:32, Moritz Lennert <mlenn...@club.worldonline.be>
> > wrote:
> >>
> >> Le Sun, 20 May 2018 09:30:53 +0200,
> >> Nikos Alexandris <n...@nikosalexandris.net> a écrit :
> >>
> >> > * Massi Alvioli <nocha...@gmail.com> [2018-05-17 15:01:39 +0200]:
> >> >
> >> > >2018-05-17 10:09 GMT+02:00 Moritz Lennert
> >> > ><mlenn...@club.worldonline.be>:
> >> > >
> >> > >Hi,
> >> > >
> >> > >> [I imagine your mail was supposed to go onto the mailing list and
> >> > >> not just to me...]
> >> > >
> >> > >sure my answer was for everyone to read, I believe I tried to send it
> >> > >again afterwards..
> >> > >something must have gone wrong.
> >> > >
> >> > >> I just presented GRASS and a short overview over GRASS on HPC
> >> > >> yesterday at the FOSS4F-FR and there was a lot of interest for
> >> > >> this. Several people asked me about specific documentation on the
> >> > >> subject.
> >> > >
> >> > >What we did about GRASS + HPC was for specific production purposes
> >> > >and no documentation
> >> > >whatsoever wascreated, basically due to lack of time.. so I find it
> >> > >hard to say whether this is going
> >> > >to change in the near future:). Surely the topic is of wide interest
> >> > >and worth being discussed in
> >> > >several contexts.
> >> > >
> >> > >> Currently, I'm aware of the following wiki pages which each
> >> > >> potentially touches on some aspects of HPC:
> >> > >
> >> > >I must admit that existing documentation/papers did not help much.
> >> > >Well, did not help at all, actually.
> >> > >One major problem in my opinion/experience is that
> >> > >multi-core/multi-node machines can be really
> >> > >different from each other, and parallelization strategies very
> >> > >purpose-specific, so that creating
> >> > >general-purpose documents/papers, or even software, *may* be a
> >> > >hopeless effort. Smart ideas
> >> > >are most welcome, of course:)
> >> >
> >> > Dear Massimo and all,
> >> >
> >> > Being a beginner in massively processing Landsat 8 images using JRC's
> >> > JEODPP system (which is designed for High-Throughput,
> >> > https://doi.org/10.1016/j.future.2017.11.007), I found useful notes
> in
> >> > the Wiki (notably Veronica's excellent tutorials) and elsewhere, got
> >> > specific answers through the mailing lists and learned a lot in
> >> > on-site discussions during the last OSGeo sprint, for example.
> >> >
> >> > Nonetheless, I think to have learned quite some things the hard way.
> >> > In this regard, some answers to even "non-sense" questions are worth
> >> > documenting.
> >> >
> >> > My aim is to transfer notes of practical value. Having HPC and HTC
> >> > related notes in a wiki, will help to get started, promote best
> >> > practices, learn through common mistakes and give an overview for the
> >> > points Peter put in this thread's first message.
> >>
> >> +1
> >>
> >> >
> >> > I hope it's fine to name the page "High Performance Computing". Please
> >> > advise or create a page with another name if you think otherwise.
> >>
> >>
> >> +1
> >>
> >> Moritz
> >> ___
> >> grass-user mailing list
> >> grass-user@lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/grass-user
> >
> >
> >
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Global overview of GRASS HPC resources/installations ?

[Laura Poggio]

I am really interested in this. I am experimenting with different settings
to use GRASS on HPC, more specifically on multi-core local machines and on
single-core multiple instances on a cloud provider. It would be great to
share experiences with other people fighting the same problems.

Thanks

Laura

On 20 May 2018 at 12:32, Moritz Lennert 
wrote:

> Le Sun, 20 May 2018 09:30:53 +0200,
> Nikos Alexandris  a écrit :
>
> > * Massi Alvioli  [2018-05-17 15:01:39 +0200]:
> >
> > >2018-05-17 10:09 GMT+02:00 Moritz Lennert
> > >:
> > >
> > >Hi,
> > >
> > >> [I imagine your mail was supposed to go onto the mailing list and
> > >> not just to me...]
> > >
> > >sure my answer was for everyone to read, I believe I tried to send it
> > >again afterwards..
> > >something must have gone wrong.
> > >
> > >> I just presented GRASS and a short overview over GRASS on HPC
> > >> yesterday at the FOSS4F-FR and there was a lot of interest for
> > >> this. Several people asked me about specific documentation on the
> > >> subject.
> > >
> > >What we did about GRASS + HPC was for specific production purposes
> > >and no documentation
> > >whatsoever wascreated, basically due to lack of time.. so I find it
> > >hard to say whether this is going
> > >to change in the near future:). Surely the topic is of wide interest
> > >and worth being discussed in
> > >several contexts.
> > >
> > >> Currently, I'm aware of the following wiki pages which each
> > >> potentially touches on some aspects of HPC:
> > >
> > >I must admit that existing documentation/papers did not help much.
> > >Well, did not help at all, actually.
> > >One major problem in my opinion/experience is that
> > >multi-core/multi-node machines can be really
> > >different from each other, and parallelization strategies very
> > >purpose-specific, so that creating
> > >general-purpose documents/papers, or even software, *may* be a
> > >hopeless effort. Smart ideas
> > >are most welcome, of course:)
> >
> > Dear Massimo and all,
> >
> > Being a beginner in massively processing Landsat 8 images using JRC's
> > JEODPP system (which is designed for High-Throughput,
> > https://doi.org/10.1016/j.future.2017.11.007), I found useful notes in
> > the Wiki (notably Veronica's excellent tutorials) and elsewhere, got
> > specific answers through the mailing lists and learned a lot in
> > on-site discussions during the last OSGeo sprint, for example.
> >
> > Nonetheless, I think to have learned quite some things the hard way.
> > In this regard, some answers to even "non-sense" questions are worth
> > documenting.
> >
> > My aim is to transfer notes of practical value. Having HPC and HTC
> > related notes in a wiki, will help to get started, promote best
> > practices, learn through common mistakes and give an overview for the
> > points Peter put in this thread's first message.
>
> +1
>
> >
> > I hope it's fine to name the page "High Performance Computing". Please
> > advise or create a page with another name if you think otherwise.
>
>
> +1
>
> Moritz
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] installing grass 7.4 and grass-qgis plugin under fedora 27

[Laura Poggio]

Dear Markus,
thank you very much for your help.

In the error message, I used dnf install qgis* and it was trying to install
both versions. But the same error happens with 64 bits.

Regarding QGIS not recognising grass7.4, could it be related with this
other thread?
http://lists.osgeo.org/pipermail/grass-user/2018-February/077854.html


Thanks a lot

Laura

On 18 February 2018 at 22:40, Markus Neteler <nete...@osgeo.org> wrote:

> On Sun, Feb 18, 2018 at 6:24 PM, Markus Neteler <nete...@osgeo.org> wrote:
> > Hi Laura,
> >
> > Am 18.02.2018 6:14 nachm. schrieb "Laura Poggio" <laura.pog...@gmail.com
> >:
> >
> > Dear list,
> > I managed to install grass 74 from the repository
> > https://copr.fedorainfracloud.org/coprs/neteler/grass74/
> > I tried to install the qgis plugin and it seems it requires grass72:
> > package qgis-grass-2.18.12-1.fc27.i686 requires grass(x86-32) = 7.2.1,
> but
> > none of the providers can be installed
> > conflicting requests
> >
> >
> > (I see that you try to install the 32 bit version)
> >
> > [there were few of these lines, but similar in content. I can paste the
> > whole list (long) if necessary]
> >
> > No, it's clear like this.
> >
> > I tried to install the grass-qgis plugin from both the fedora repository
> and
> > https://copr.fedorainfracloud.org/coprs/neteler/QGIS-2.18-Las-Palmas/
> >
> > I still need to update that repo. Will try to do that tonight.
>
> I have tried but QGIS (for today?) refuses to recognize GRASS GIS 7.4
> during compilation [1]
> No idea why...
>
> Markus
>
> [1] https://copr-be.cloud.fedoraproject.org/results/neteler/
> QGIS-2.18-Las-Palmas/fedora-27-x86_64/00717240-qgis/builder-live.log
> (long, 6MB)
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] installing grass 7.4 and grass-qgis plugin under fedora 27

[Laura Poggio]

Dear list,
I managed to install grass 74 from the repository
https://copr.fedorainfracloud.org/coprs/neteler/grass74/
I tried to install the qgis plugin and it seems it requires grass72:
package qgis-grass-2.18.12-1.fc27.i686 requires grass(x86-32) = 7.2.1, but
none of the providers can be installed
conflicting requests
[there were few of these lines, but similar in content. I can paste the
whole list (long) if necessary]

I tried to install the grass-qgis plugin from both the fedora repository
and https://copr.fedorainfracloud.org/coprs/neteler/QGIS-2.18-Las-Palmas/


Thanks

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

Re: [GRASS-user] Unable to install add-ons on fedora23

[Laura Poggio]

Dear all,
I am having the same problem also with the F27 package from
coprs/neteler/grass72/.
But I am not sure it is the same problem or I am doing something wrong.
I removed grass from fedora repository, enabled the copr repository and
then installed grass again from the new repository.

Thanks
Laura

On 29 November 2017 at 20:31, Markus Neteler  wrote:

> On Wed, Nov 29, 2017 at 8:19 PM, Laurent C.  wrote:
> > Hello all,
> >
> > I have a similar problem with Fedora 27:
> >
> > $ grass72 --config path
> > ERROR: Please install the GRASS GIS development package
> > Exiting...
> > $ dnf list installed *grass-devel*
> > Installed Packages
> > grass-devel.x86_64 7.2.1-2.fc27
> @fedora
> >
> > I believe it is a packaging error,
>
> Yes.
>
> > but I don't know what is missing.
> >
> > Any thought?
>
> Missing from the grass-devel RPM is the "include/" directory. This
> contains the information needed by g.extension.
>
> See
> https://bugzilla.redhat.com/show_bug.cgi?id=1489158
>
> I would need some support to get the SPEC file right.
> Anyone?
>
> thanks
> Markus
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS 7.2.1 for centos 7 from copr/neteler repo

[Laura Poggio]

Dear Markus,
I followed the instruction in
https://copr.fedorainfracloud.org/coprs/neteler/grass72/.  I still get the
same errors I posted above. The latest gdal I can install from epel repo is
version 1.11.4. If it help, the centos version I am using is the latest
available image on google cloud compute (CentOS, CentOS, 7, x86_64 built on
2017-07-19).

Thanks a lot

Laura



On 8 August 2017 at 23:43, Markus Neteler <nete...@osgeo.org> wrote:

> Hi Laura,
>
> On Fri, Jul 21, 2017 at 12:51 PM, Laura Poggio <laura.pog...@gmail.com>
> wrote:
> > Dear all,
> > I am trying to install GRASS 7.2.1 using the repository neteler-grass72
> on a
>
> This one:
> https://copr.fedorainfracloud.org/coprs/neteler/grass72/
>
> > machine running centos 7 [Linux version 3.10.0-514.26.2.el7.x86_64
> > (buil...@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat
> > 4.8.5-11) (GCC) )]
> >
> > I get the following errors:
> > Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
> >Requires: libproj.so.12()(64bit)
> > Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
> >Requires: libm.so.6(GLIBC_2.23)(64bit)
> > Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
> >Requires: libgdal.so.20()(64bit)
> > Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
> >Requires: libcrypto.so.1.1()(64bit)
> > Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
> >Requires: libpng16.so.16()(64bit)
> > Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
> >Requires: libpng16.so.16(PNG16_0)(64bit)
> > Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
> >Requires: libgeos-3.6.1.so()(64bit)
> > Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
> >Requires: libssl.so.1.1()(64bit)
> >
> > As far as I can see it requires versions of the libraries that are not
> > readily available from centos 7 repositories (including epel).
>
> I have compiled the version in July on COPR.
> https://copr.fedorainfracloud.org/coprs/neteler/grass72/builds/
>
> Did you install beforehand
>
> yum install epel-release
> yum install gdal gdal-python gdal-devel
> ?
>
>
> > I could compile grass 7.2.1 from source without problems, but I would
> prefer
> > to use the repository if at all possible.
> > What am I missing ? Do I need to compile the dependencies before in
> order to
> > have the right versions? Are there any repositories where the rmps could
> be
> > found?
>
> Those two above should deliver the needed proj and gdal RPMs.
>
> Best
> Markus
>
> --
> Markus Neteler, PhD
> http://www.mundialis.de - free data with free software
> http://grass.osgeo.org
> http://courses.neteler.org/blog
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] GRASS 7.2.1 for centos 7 from copr/neteler repo

[Laura Poggio]

Dear all,
I am trying to install GRASS 7.2.1 using the repository neteler-grass72 on
a machine running centos 7 [Linux version 3.10.0-514.26.2.el7.x86_64 (
buil...@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat
4.8.5-11) (GCC) )]

I get the following errors:
Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
   Requires: libproj.so.12()(64bit)
Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
   Requires: libm.so.6(GLIBC_2.23)(64bit)
Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
   Requires: libgdal.so.20()(64bit)
Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
   Requires: libcrypto.so.1.1()(64bit)
Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
   Requires: libpng16.so.16()(64bit)
Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
   Requires: libpng16.so.16(PNG16_0)(64bit)
Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
   Requires: libgeos-3.6.1.so()(64bit)
Error: Package: grass-libs-7.2.1-6.fc26.x86_64 (neteler-grass72)
   Requires: libssl.so.1.1()(64bit)

As far as I can see it requires versions of the libraries that are not
readily available from centos 7 repositories (including epel).
I could compile grass 7.2.1 from source without problems, but I would
prefer to use the repository if at all possible.
What am I missing ? Do I need to compile the dependencies before in order
to have the right versions? Are there any repositories where the rmps could
be found?

Thanks a lot in advance

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

[GRASS-user] Migrate mcda addons to grass7

[Laura Poggio]

Dear list,
I would be interested in migrating mcda addons, electre (
http://grass.osgeo.org/grass64/manuals/addons/r.mcda.electre.html) and
regime (http://grass.osgeo.org/grass64/manuals/addons/r.mcda.regime.html)
to grass7.
Is there any guidance on how to do this? I think I remember a post about
this a while ago but I could not find it.

Thanks a lot

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

Re: [GRASS-user] Migrate mcda addons to grass7

[Laura Poggio]

Thanks for this Gianluca, I will have a look.

Laura

On 15 June 2015 at 16:18, Gianluca Massei agr.gianluca.mas...@gmail.com
wrote:

 Dear Laura,
 you can use the standard documentation about  new API in grass7 (
 http://grass.osgeo.org/programming7/), furthermore,   I'm available for
 help you or for a collaborative job with you.
 Thanks
 Gianluca

 2015-06-15 16:42 GMT+02:00 Laura Poggio laura.pog...@gmail.com:

 Dear list,
 I would be interested in migrating mcda addons, electre (
 http://grass.osgeo.org/grass64/manuals/addons/r.mcda.electre.html) and
 regime (http://grass.osgeo.org/grass64/manuals/addons/r.mcda.regime.html)
 to grass7.
 Is there any guidance on how to do this? I think I remember a post about
 this a while ago but I could not find it.

 Thanks a lot

 Laura

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




 --
 Dott. Gianluca Massei, PhD

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

Re: [GRASS-user] use of grass 6.4 and 7 on the same location/mapsets

[Laura Poggio]

Thank you very much for the information. As I am not using vectors very
often it should be rather safe.

Thanks

Laura

On 29 October 2012 11:34, Paulo van Breugel p.vanbreu...@gmail.com wrote:

 If you are in 6.4 and want to open a vector layer created in grass 7 (or
 the other way around), you can use v.build.

 Alternatively, you can also open the layer, and in the layer manager,
 right click the layer and select 'rebuild topology'. Rebuilding is very
 quick in my experience and hasn't give me any trouble, whether rebuilding
 from 6.4 to 7 or the other way around.

 Cheers,

 Paulo




 On Mon, Oct 29, 2012 at 12:24 PM, Nick Cahill ndcah...@wisc.edu wrote:

 I found that once I'd converted my vectors to Grass 7, I couldn't go
 back. I ended up going back to 6.4 and having to restore old vectors from a
 backup. It was a pain. Is there an easy way to convert back?

 Thanks,

 Nick Cahill


 On Oct 29, 2012, at 11:59 AM, Maris Nartiss wrote:

  If they are not accessed at a same time, then only problem will be
  with vector data. GRASS 7 uses a bit different vector data storage
  format and thus vector data can be used (displayed) only after a
  v.build run. It's a bit annoying and I don't know if it can introduce
  any problems (I mean when going G7-G6 vectors), still I haven't
  observed any.
 
  In conclusion - for raster - doesn't matter; vectors - better stick to
  one version.
 
  Maris.
 
  2012/10/28 Laura Poggio laura.pog...@gmail.com:
  Dear list,
  are any problems in having mapsets accessed from different version of
 GRASS
  (6.4.2. and 7)?
 
  Thank you
 
  Laura
 
 
  ___
  grass-user mailing list
  grass-user@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-user
 
  ___
  grass-user mailing list
  grass-user@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-user

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



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


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

[GRASS-user] use of grass 6.4 and 7 on the same location/mapsets

[Laura Poggio]

Dear list,
are any problems in having mapsets accessed from different version of GRASS
(6.4.2. and 7)?

Thank you

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

[GRASS-user] missing centroids and link with POSTGRESQL

[Laura Poggio]

Dear all,
I have a vector file created with r.to.vect tool:
r.to.vect my_rast output=my_vect feature=area

The created vector has about 200 areas without centroids. I used
v.centroids to update them:

v.centroids input=my_vect output=my_vect_with_centroids
cat=max_centr_my_vect+1

I then run v.clean on the new vector
v.clean my_vect_with_centroids output=my_vect_clean
tool=break,rmdupl,rmsa,bpol

The my_vect_clean has an updated number of rows.

I need to use the created vector in POSTGRESQL for further analysis and
statistics. However the rows count in the associated attribute table is
still the same as before the centroids and the cleaning.

I think I am missing something rather basic here, but I can not figure what
I should do to convince POSTGRESQL that 200 rows have been added. I am even
not sure this is the proper way to deal with this. Any comments  or
suggestions will be very welcomed.

Thank you very much in advance.

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

Re: [GRASS-user] GIPE modules in GRASS 6.5 and 7.0

[Laura Poggio]

Thank you very much for all suggestions. I now managed to get a working
version of all GIPE modules in grass65 downloading older version from the
svn. By working I mean that they can be loaded and seem to work with test
data I tried. I will test them more seriously. I will also try to test them
on the 6.4.1 version.

In this way I can wait a little bit longer before starting to use GRASS 7.0
for serious work.

Thank you again.

Laura

On 3 November 2011 03:55, Hamish hamis...@yahoo.com wrote:

 Yann Chemin wrote:
  There should be a way to do that by
  going back in time the SVN revisions versions.

 please restrict grass7 development in addons to the grass7/ dir!

 feel free to use the grass6/ dir for archival purposes (svn copy
 the appropriate revision); my unimplemented plan is to move the
 base raster/ imagery/ vector/ dirs into grass6/, then symlink
 them back into the main addons dir. Before doing that I need to
 study up on how well svn deals with symlinks when used from MS
 Windows. The sooner we do this, the better.


 a reminder: while we think it works pretty well, grass7 is still
 pre-alpha. Do not use it for real work, only if you want to help
 program and debug. For production use there is the stable 6.4.x
 line. Although I personally use the development version day-to-
 day as I'm trying things out and building things, with the benefit
 of hindsight sticking with the stable releases for real/final
 work runs has really saved my neck in the past, and it can save
 yours too.


 thanks,
 Hamish


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

[GRASS-user] GIPE modules in GRASS 6.5 and 7.0

[Laura Poggio]

Dear all,
I am trying to install the addons in GIPE. Generally I use GRASS 6.5 and I
managed to download and install some of the modules. However I found out
that some were moved to the main SVN. This would give me a good excuse to
start to use GRASS 7.0. So I downloaded and built it. However I can not
install the extra addons of GIPE
(https://svn.osgeo.org/grass/grass-addons/imagery/gipe%20https://svn.osgeo.org/grass/grass-addons/imagery/gipe).
When I try I get errors such as undefined reference to G_find_cell2
and
other similar Undefined references. I can provide more information if
needed.

Is there a way to have all the GIPE modules in the same version of GRASS? I
would be happy also with old code version of GIPE that can be compiled with
grass 6.5.

Thank you very much

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

Re: [GRASS-user] GIPE modules in GRASS 6.5 and 7.0

[Laura Poggio]

Hi Yann,
I would be more than happy, but unfortunately I do not have the skills.
On the short term, would you have a copy of an old version of all the
modules that I can try to install on 6.5.? I guess it would mainly be the
old version of the modules that are already been migrated.

Thank you very much

Laura


On 2 November 2011 16:54, Chemin, Yann (IWMI) y.che...@cgiar.org wrote:

 Hi Laura,

 I have indeed started the migration to GRASS 7, but could not finalized it
 yet...
 You are welcome to help!

 Yann
 
 From: grass-user-boun...@lists.osgeo.org [
 grass-user-boun...@lists.osgeo.org] on behalf of Laura Poggio [
 laura.pog...@gmail.com]
 Sent: Wednesday, November 02, 2011 9:25 PM
 To: GRASS user list
 Subject: [GRASS-user] GIPE modules in GRASS 6.5 and 7.0

 Dear all,
 I am trying to install the addons in GIPE. Generally I use GRASS 6.5 and I
 managed to download and install some of the modules. However I found out
 that some were moved to the main SVN. This would give me a good excuse to
 start to use GRASS 7.0. So I downloaded and built it. However I can not
 install the extra addons of GIPE (
 https://svn.osgeo.org/grass/grass-addons/imagery/gipe ). When I try I get
 errors such as undefined reference to G_find_cell2 and other similar
 Undefined references. I can provide more information if needed.

 Is there a way to have all the GIPE modules in the same version of GRASS?
 I would be happy also with old code version of GIPE that can be compiled
 with grass 6.5.

 Thank you very much

 Laura


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

Re: [GRASS-user] GIPE modules in GRASS 6.5 and 7.0

[Laura Poggio]

I will keep trying to find a way to access them..

Thank you very much

Laura


On 2 November 2011 19:03, Chemin, Yann (IWMI) y.che...@cgiar.org wrote:

 There should be a way to do that by going back in time the SVN revisions
 versions.
 
 From: Laura Poggio [laura.pog...@gmail.com]
 Sent: Wednesday, November 02, 2011 11:51 PM
 To: Chemin, Yann (IWMI)
 Cc: GRASS user list
 Subject: Re: [GRASS-user] GIPE modules in GRASS 6.5 and 7.0

 Hi Yann,
 I would be more than happy, but unfortunately I do not have the skills.
 On the short term, would you have a copy of an old version of all the
 modules that I can try to install on 6.5.? I guess it would mainly be the
 old version of the modules that are already been migrated.

 Thank you very much

 Laura


 On 2 November 2011 16:54, Chemin, Yann (IWMI) y.che...@cgiar.orgmailto:
 y.che...@cgiar.org wrote:
 Hi Laura,

 I have indeed started the migration to GRASS 7, but could not finalized it
 yet...
 You are welcome to help!

 Yann
 
 From: grass-user-boun...@lists.osgeo.orgmailto:
 grass-user-boun...@lists.osgeo.org [grass-user-boun...@lists.osgeo.org
 mailto:grass-user-boun...@lists.osgeo.org] on behalf of Laura Poggio [
 laura.pog...@gmail.commailto:laura.pog...@gmail.com]
 Sent: Wednesday, November 02, 2011 9:25 PM
 To: GRASS user list
 Subject: [GRASS-user] GIPE modules in GRASS 6.5 and 7.0

 Dear all,
 I am trying to install the addons in GIPE. Generally I use GRASS 6.5 and I
 managed to download and install some of the modules. However I found out
 that some were moved to the main SVN. This would give me a good excuse to
 start to use GRASS 7.0. So I downloaded and built it. However I can not
 install the extra addons of GIPE (
 https://svn.osgeo.org/grass/grass-addons/imagery/gipe ). When I try I get
 errors such as undefined reference to G_find_cell2 and other similar
 Undefined references. I can provide more information if needed.

 Is there a way to have all the GIPE modules in the same version of GRASS?
 I would be happy also with old code version of GIPE that can be compiled
 with grass 6.5.

 Thank you very much

 Laura



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

Re: [GRASS-user] error compiling grass65svn and addons for grass64

[Laura Poggio]

 error You had when compiling 6.5 from source must be a different
 one, as provided error message makes sense only to addons and not
 compilation of whole GRASS.

 Maris.


 2010/10/20, Laura Poggio laura.pog...@gmail.com:
  Yes I have gcc, g++, make.
  The full error message for one extension is pasted below (for one
 extension
  as example).
 
  Thank you very much
 
  Laura
 
  ===
  Checked out revision 43978.
  Compiling r.stream.basins...
  In file included from catchment.c:1:
  global.h:5:23: error: grass/gis.h: No such file or directory
  global.h:6:24: error: grass/Vect.h: No such file or
  directory
  global.h:7:27: error: grass/glocale.h: No such file or
  directory
  In file included from catchment.c:1:
  global.h:64: error: expected ‘=’, ‘,’, ‘;’,
  ‘asm’ or ‘__attribute__’ before ‘*’ token
  catchment.c: In function ‘find_outlets’:
  catchment.c:29: warning: cast to pointer from integer of
  different size
  catchment.c:36: error: ‘streams’ undeclared (first use
  in this function)
  catchment.c:36: error: (Each undeclared identifier is
  reported only once
  catchment.c:36: error: for each function it appears in.)
  catchment.c:45: warning: cast to pointer from integer of
  different size
  catchment.c:48: error: ‘dirs’ undeclared (first use in
  this function)
  catchment.c: In function ‘reset_catchments’:
  catchment.c:115: error: ‘streams’ undeclared (first use
  in this function)
  catchment.c: In function ‘fill_catchments’:
  catchment.c:147: error: ‘streams’ undeclared (first use
  in this function)
  catchment.c:159: error: ‘dirs’ undeclared (first use in
  this function)
  make: *** [OBJ.x86_64-unknown-linux-gnu/catchment.o] Error 1
  ERROR: Compilation failed, sorry. Please check above error messages.
  test -d OBJ.x86_64-unknown-linux-gnu || mkdir -p
  OBJ.x86_64-unknown-linux-gnu
  gcc
 
 -I/usr/src/packages/BUILD/grass-6.4.0/dist.x86_64-unknown-linux-gnu/include
  -O2-I/usr/include/gdal/ -DPACKAGE=\grassmods\
 
 -I/usr/src/packages/BUILD/grass-6.4.0/dist.x86_64-unknown-linux-gnu/include
  -o OBJ.x86_64-unknown-linux-gnu/catchment.o -c catchment.c
  (Wed Oct 20 11:56:21 2010) Command finished (6
  sec)
 
 
  On 20 October 2010 14:38, razmjoo...@faunalia.co.uk wrote:
 
  Have you got the following packges installed?
  gcc
  g++
  make
 
 
  Cheers
  Sab
 
   Hello,
   You have to provide whole error message. Without exact error text,
   it's impossible to tell what kind of problem You have.
  
   WBR,
   Maris.
  
  
   2010/10/20, Laura Poggio laura.pog...@gmail.com:
   Dear all,
   I installed grass6.4 on a machine with Suse11.2 64 bit from the
   official
   repository. Then I tried to install  some addons with g.extension and
   using
   the usual configure/make/make install.
   In both cases I get the following error:
  
   make: *** [OBJ.x86_64-unknown-linux-gnu/[...]] Error 1
   ERROR: Compilation failed, sorry. Please check above error messages.
  
   I also tried to compile grass65 from svn and I am getting the same
   error.
  
   Please let me know and I can provide more details. Sorry but I do not
   know
   what would be useful for better understanding the problem.
  
  
   Thank you very much in advance
  
   Laura
  
   ___
   grass-user mailing list
   grass-user@lists.osgeo.org
   http://lists.osgeo.org/mailman/listinfo/grass-user
  
 
 
 
 

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

[GRASS-user] error compiling grass65svn and addons for grass64

[Laura Poggio]

Dear all,
I installed grass6.4 on a machine with Suse11.2 64 bit from the official
repository. Then I tried to install  some addons with g.extension and using
the usual configure/make/make install.
In both cases I get the following error:

make: *** [OBJ.x86_64-unknown-linux-gnu/[...]] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.

I also tried to compile grass65 from svn and I am getting the same error.

Please let me know and I can provide more details. Sorry but I do not know
what would be useful for better understanding the problem.


Thank you very much in advance

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

Re: [GRASS-user] error compiling grass65svn and addons for grass64

[Laura Poggio]

Yes I have gcc, g++, make.
The full error message for one extension is pasted below (for one extension
as example).

Thank you very much

Laura

===
Checked out revision 43978.
Compiling r.stream.basins...
In file included from catchment.c:1:
global.h:5:23: error: grass/gis.h: No such file or directory
global.h:6:24: error: grass/Vect.h: No such file or
directory
global.h:7:27: error: grass/glocale.h: No such file or
directory
In file included from catchment.c:1:
global.h:64: error: expected ‘=’, ‘,’, ‘;’,
‘asm’ or ‘__attribute__’ before ‘*’ token
catchment.c: In function ‘find_outlets’:
catchment.c:29: warning: cast to pointer from integer of
different size
catchment.c:36: error: ‘streams’ undeclared (first use
in this function)
catchment.c:36: error: (Each undeclared identifier is
reported only once
catchment.c:36: error: for each function it appears in.)
catchment.c:45: warning: cast to pointer from integer of
different size
catchment.c:48: error: ‘dirs’ undeclared (first use in
this function)
catchment.c: In function ‘reset_catchments’:
catchment.c:115: error: ‘streams’ undeclared (first use
in this function)
catchment.c: In function ‘fill_catchments’:
catchment.c:147: error: ‘streams’ undeclared (first use
in this function)
catchment.c:159: error: ‘dirs’ undeclared (first use in
this function)
make: *** [OBJ.x86_64-unknown-linux-gnu/catchment.o] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.
test -d OBJ.x86_64-unknown-linux-gnu || mkdir -p
OBJ.x86_64-unknown-linux-gnu
gcc
-I/usr/src/packages/BUILD/grass-6.4.0/dist.x86_64-unknown-linux-gnu/include
-O2-I/usr/include/gdal/ -DPACKAGE=\grassmods\
-I/usr/src/packages/BUILD/grass-6.4.0/dist.x86_64-unknown-linux-gnu/include
-o OBJ.x86_64-unknown-linux-gnu/catchment.o -c catchment.c
(Wed Oct 20 11:56:21 2010) Command finished (6
sec)


On 20 October 2010 14:38, razmjoo...@faunalia.co.uk wrote:

 Have you got the following packges installed?
 gcc
 g++
 make


 Cheers
 Sab

  Hello,
  You have to provide whole error message. Without exact error text,
  it's impossible to tell what kind of problem You have.
 
  WBR,
  Maris.
 
 
  2010/10/20, Laura Poggio laura.pog...@gmail.com:
  Dear all,
  I installed grass6.4 on a machine with Suse11.2 64 bit from the official
  repository. Then I tried to install  some addons with g.extension and
  using
  the usual configure/make/make install.
  In both cases I get the following error:
 
  make: *** [OBJ.x86_64-unknown-linux-gnu/[...]] Error 1
  ERROR: Compilation failed, sorry. Please check above error messages.
 
  I also tried to compile grass65 from svn and I am getting the same
  error.
 
  Please let me know and I can provide more details. Sorry but I do not
  know
  what would be useful for better understanding the problem.
 
 
  Thank you very much in advance
 
  Laura
 
  ___
  grass-user mailing list
  grass-user@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-user
 



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

Re: [GRASS-user] r.univar.zonal not installing

[Laura Poggio]

Hi Vishal,
I recompiled grass from sources because I also wanted to update it to the
most recent release. I now installed r.univar.zonal on two different
computers and it worked fine. But I recompiled grass each time.

Laura


On 11 October 2010 20:41, Vishal Mehta vishalm1...@gmail.com wrote:

 Hi Laura,

 Did you have to recompile an updated Grass65 from svn?
 I am still unable to install this either from g.extension or compiling it
 from source..

 Vishal

 On Fri, Oct 8, 2010 at 1:43 AM, Laura Poggio laura.pog...@gmail.comwrote:

 Dear all,
 it worked using g.extension on an updated version of GRASS65.
 Sorry for my late answer but in the past days I was unable to try.

 Thank you

 Laura


 On 5 October 2010 20:17, Markus Neteler nete...@osgeo.org wrote:

 On Mon, Aug 9, 2010 at 5:41 PM, Laura Poggio laura.pog...@gmail.com
 wrote:
  Dear all,
  since a while, I am trying to compile the r.univar.zonal addon on a
 Fedora11
  64 bit machine and using GRASS 6.5
 
  I used:
  svn co https://svn.osgeo.org/grass/grass-addons/raster/r.univar2.zonal
  cd r.univar2.zonal/
  make MODULE_TOPDIR=~/bin/grass65/grass6_devel/
 
  No errors were detected, but when I try:
  make MODULE_TOPDIR=/home/myuser/bin/grass65/grass6_devel install
 
  I am getting:
  
  if [  !=  ] ; then \
  for dir in  ; do \
  make -C $dir install ; \
  done ; \
  fi
  ---
 
  Various other addons were installed using these steps, then I think I
 am
  missing something here ... Thank you in advance for any hints!

 Perhaps that comes from the directory name which I find slightly
 confusing:

 GRASS 6.4.1svn (nc_spm_08):~  ls -la
 grass-addons/raster/r.univar2.zonal/
 total 76
 drwxr-xr-x  3 neteler neteler  4096 2010-02-18 21:40 ./
 drwxr-xr-x 53 neteler neteler  4096 2010-09-23 12:04 ../
 -rw-r--r--  1 neteler neteler  1806 2010-02-18 21:36 globals.h
 -rw-r--r--  1 neteler neteler   624 2009-04-09 10:44 Makefile
 -rw-r--r--  1 neteler neteler  8426 2010-02-18 21:36 r3.univar_main.c
 -rw-r--r--  1 neteler neteler  2286 2010-02-18 21:36 r3.univar.zonal.html
 -rw-r--r--  1 neteler neteler  9829 2010-02-18 21:36 r.univar_main.c
 -rw-r--r--  1 neteler neteler  4411 2009-04-09 10:44 r.univar.zonal.html
 -rw-r--r--  1 neteler neteler  3358 2009-02-24 08:27 sort.c
 -rw-r--r--  1 neteler neteler 15223 2010-02-18 21:36 stats.c
 drwxr-xr-x  6 neteler neteler  4096 2010-09-22 09:25 .svn/


 GRASS 6.4.1svn (nc_spm_08):~  grep univ
 grass-addons/raster/r.univar2.zonal/Makefile
 PROGRAMS = r.univar.zonal r3.univar.zonal
 R3UNIVAR = $(BIN)/r3.univar.zonal$(EXE)
 RUNIVAR = $(BIN)/r.univar.zonal$(EXE)
 $(RUNIVAR): $(OBJDIR)/r.univar_main.o $(OBJDIR)/sort.o $(OBJDIR)/stats.o
 $(R3UNIVAR): $(OBJDIR)/r3.univar_main.o $(OBJDIR)/sort.o
 $(OBJDIR)/stats.o

 - PROGRAMS that does not reflect the directory name.

 GRASS 6.4.1svn (nc_spm_08):~  g.extension r.univar.zonal
 WARNING: GRASS_ADDON_PATH is not defined, installing to ~/.grass6/addons/
 Fetching r.univar.zonal from GRASS-Addons SVN (be patient)...
 svn: URL 'https://svn.osgeo.org/grass/grass-addons/raster/r.univar.zonal
 '
 doesn't exist
 ERROR: GRASS Add-on r.univar.zonal not found in repository or no network
   connection or another problem

 But like this it works:

 GRASS 6.4.1svn (nc_spm_08):~  grep univ
 grass-addons/raster/r.univar2.zonal/Makefile
 PROGRAMS = r.univar.zonal r3.univar.zonal
 R3UNIVAR = $(BIN)/r3.univar.zonal$(EXE)
 RUNIVAR = $(BIN)/r.univar.zonal$(EXE)
 $(RUNIVAR): $(OBJDIR)/r.univar_main.o $(OBJDIR)/sort.o $(OBJDIR)/stats.o
 $(R3UNIVAR): $(OBJDIR)/r3.univar_main.o $(OBJDIR)/sort.o
 $(OBJDIR)/stats.o
 GRASS 6.4.1svn (nc_spm_08):~  g.extension r.univar2.zonal
 WARNING: GRASS_ADDON_PATH is not defined, installing to ~/.grass6/addons/
 Fetching r.univar2.zonal from GRASS-Addons SVN (be patient)...
 Ar.univar2.zonal/stats.c
 Ar.univar2.zonal/sort.c
 Ar.univar2.zonal/globals.h
 Ar.univar2.zonal/r.univar.zonal.html
 Ar.univar2.zonal/r.univar_main.c
 Ar.univar2.zonal/r3.univar.zonal.html
 Ar.univar2.zonal/r3.univar_main.c
 Ar.univar2.zonal/Makefile
  U   r.univar2.zonal
 Checked out revision 43799.
 Compiling r.univar2.zonal...
 test -d OBJ.x86_64-unknown-linux-gnu || mkdir -p
 OBJ.x86_64-unknown-linux-gnu
 gcc -I/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/include  -g
 -Wall  -fno-common -fexceptions -mtune=nocona -m64
 -minline-all-stringops   -DPACKAGE=\grassmods\
 -I/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/include -o
 OBJ.x86_64-unknown-linux-gnu/r.univar_main.o -c r.univar_main.c
 ...


 Proposals
 @authors: rename directory to first program name

 @Laura: please try g.extension

 best,
 Markus



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




 --
 Vishal K. Mehta, PhD
 Scientist
 Stockholm

Re: [GRASS-user] r.univar.zonal not installing

[Laura Poggio]

Dear all,
it worked using g.extension on an updated version of GRASS65.
Sorry for my late answer but in the past days I was unable to try.

Thank you

Laura

On 5 October 2010 20:17, Markus Neteler nete...@osgeo.org wrote:

 On Mon, Aug 9, 2010 at 5:41 PM, Laura Poggio laura.pog...@gmail.com
 wrote:
  Dear all,
  since a while, I am trying to compile the r.univar.zonal addon on a
 Fedora11
  64 bit machine and using GRASS 6.5
 
  I used:
  svn co https://svn.osgeo.org/grass/grass-addons/raster/r.univar2.zonal
  cd r.univar2.zonal/
  make MODULE_TOPDIR=~/bin/grass65/grass6_devel/
 
  No errors were detected, but when I try:
  make MODULE_TOPDIR=/home/myuser/bin/grass65/grass6_devel install
 
  I am getting:
  
  if [  !=  ] ; then \
  for dir in  ; do \
  make -C $dir install ; \
  done ; \
  fi
  ---
 
  Various other addons were installed using these steps, then I think I am
  missing something here ... Thank you in advance for any hints!

 Perhaps that comes from the directory name which I find slightly confusing:

 GRASS 6.4.1svn (nc_spm_08):~  ls -la grass-addons/raster/r.univar2.zonal/
 total 76
 drwxr-xr-x  3 neteler neteler  4096 2010-02-18 21:40 ./
 drwxr-xr-x 53 neteler neteler  4096 2010-09-23 12:04 ../
 -rw-r--r--  1 neteler neteler  1806 2010-02-18 21:36 globals.h
 -rw-r--r--  1 neteler neteler   624 2009-04-09 10:44 Makefile
 -rw-r--r--  1 neteler neteler  8426 2010-02-18 21:36 r3.univar_main.c
 -rw-r--r--  1 neteler neteler  2286 2010-02-18 21:36 r3.univar.zonal.html
 -rw-r--r--  1 neteler neteler  9829 2010-02-18 21:36 r.univar_main.c
 -rw-r--r--  1 neteler neteler  4411 2009-04-09 10:44 r.univar.zonal.html
 -rw-r--r--  1 neteler neteler  3358 2009-02-24 08:27 sort.c
 -rw-r--r--  1 neteler neteler 15223 2010-02-18 21:36 stats.c
 drwxr-xr-x  6 neteler neteler  4096 2010-09-22 09:25 .svn/


 GRASS 6.4.1svn (nc_spm_08):~  grep univ
 grass-addons/raster/r.univar2.zonal/Makefile
 PROGRAMS = r.univar.zonal r3.univar.zonal
 R3UNIVAR = $(BIN)/r3.univar.zonal$(EXE)
 RUNIVAR = $(BIN)/r.univar.zonal$(EXE)
 $(RUNIVAR): $(OBJDIR)/r.univar_main.o $(OBJDIR)/sort.o $(OBJDIR)/stats.o
 $(R3UNIVAR): $(OBJDIR)/r3.univar_main.o $(OBJDIR)/sort.o $(OBJDIR)/stats.o

 - PROGRAMS that does not reflect the directory name.

 GRASS 6.4.1svn (nc_spm_08):~  g.extension r.univar.zonal
 WARNING: GRASS_ADDON_PATH is not defined, installing to ~/.grass6/addons/
 Fetching r.univar.zonal from GRASS-Addons SVN (be patient)...
 svn: URL 'https://svn.osgeo.org/grass/grass-addons/raster/r.univar.zonal'
 doesn't exist
 ERROR: GRASS Add-on r.univar.zonal not found in repository or no network
   connection or another problem

 But like this it works:

 GRASS 6.4.1svn (nc_spm_08):~  grep univ
 grass-addons/raster/r.univar2.zonal/Makefile
 PROGRAMS = r.univar.zonal r3.univar.zonal
 R3UNIVAR = $(BIN)/r3.univar.zonal$(EXE)
 RUNIVAR = $(BIN)/r.univar.zonal$(EXE)
 $(RUNIVAR): $(OBJDIR)/r.univar_main.o $(OBJDIR)/sort.o $(OBJDIR)/stats.o
 $(R3UNIVAR): $(OBJDIR)/r3.univar_main.o $(OBJDIR)/sort.o $(OBJDIR)/stats.o
 GRASS 6.4.1svn (nc_spm_08):~  g.extension r.univar2.zonal
 WARNING: GRASS_ADDON_PATH is not defined, installing to ~/.grass6/addons/
 Fetching r.univar2.zonal from GRASS-Addons SVN (be patient)...
 Ar.univar2.zonal/stats.c
 Ar.univar2.zonal/sort.c
 Ar.univar2.zonal/globals.h
 Ar.univar2.zonal/r.univar.zonal.html
 Ar.univar2.zonal/r.univar_main.c
 Ar.univar2.zonal/r3.univar.zonal.html
 Ar.univar2.zonal/r3.univar_main.c
 Ar.univar2.zonal/Makefile
  U   r.univar2.zonal
 Checked out revision 43799.
 Compiling r.univar2.zonal...
 test -d OBJ.x86_64-unknown-linux-gnu || mkdir -p
 OBJ.x86_64-unknown-linux-gnu
 gcc -I/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/include  -g
 -Wall  -fno-common -fexceptions -mtune=nocona -m64
 -minline-all-stringops   -DPACKAGE=\grassmods\
 -I/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/include -o
 OBJ.x86_64-unknown-linux-gnu/r.univar_main.o -c r.univar_main.c
 ...


 Proposals
 @authors: rename directory to first program name

 @Laura: please try g.extension

 best,
 Markus

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

[GRASS-user] r.univar.zonal not installing

[Laura Poggio]

 Dear all,
since a while, I am trying to compile the r.univar.zonal addon on a Fedora11
64 bit machine and using GRASS 6.5

I used:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.univar2.zonal
cd r.univar2.zonal/
make MODULE_TOPDIR=~/bin/grass65/grass6_devel/

No errors were detected, but when I try:
make MODULE_TOPDIR=/home/myuser/bin/grass65/grass6_devel install

I am getting:

if [  !=  ] ; then \
for dir in  ; do \
make -C $dir install ; \
done ; \
fi
---

Various other addons were installed using these steps, then I think I am
missing something here ... Thank you in advance for any hints!

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

[GRASS-user] problems compiling r.univar.zonal

[Laura Poggio]

I am trying to compile the r.univar.zonal addon on a Fedora11 64 bit machine
and using GRASS 6.5 (GRASS 6.5.svn (2010) Revision: 38990, updated last
week).

I used:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.univar2.zonal
cd r.univar2.zonal/
make MODULE_TOPDIR=~/bin/grass65/grass6_devel/

No errors were detected, but when I try:
make MODULE_TOPDIR=/home/myuser/bin/grass65/grass6_devel install

I am getting:

if [  !=  ] ; then \
for dir in  ; do \
make -C $dir install ; \
done ; \
fi
---

Various addons were installed using these steps.

Thank you in advance for any hints!

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

Re: [GRASS-user] quantile/percentile

[Laura Poggio]

Thank you!
 r.series is working fine. I am now trying to solve the problem of the limit
for the number of files within my linux distribution.
It is rather fast, much faster then using R. However my rasters are rather
small (15000 cells), then I do not know how it would behave with a much
larger file.

Thank you again

Laura

2009/9/17 Glynn Clements gl...@gclements.plus.com


 Laura Poggio wrote:

  I would need to calculate the resulting percentile map from a large
 number
  of maps (1), obtaining the values for 5 and 95 percentile for each
  pixel. Is there any function in GRASS?

 Recent versions of r.series can calculate arbitrary quantiles.

 You may have to make some configuration changes in order to allow a
 single process to have 1 open file descriptors (for Linux, check
 /etc/security/limits.conf).

 Memory shouldn't be an issue, as r.series only needs to hold one row
 from each map at a time.

 This won't be particularly fast, as r.series method=quantile sorts all
 of the values then picks out the requested quantile. And if you
 calculate multiple quantiles, it will sort the values once for each
 quantile.

 CC to grass-dev:

 The duplicate sorting can be gotten around in a several ways:

 1. Have the sorting routine first check for an already sorted list.

 2. Add a global variable to lib/stats to indicate that the data is
 already sorted.

 3. Add yet another parameter to the stats functions to indicate that
 the data is sorted.

 4. Use the closure parameter to indicate that the data is sorted (for
 c_quant(), this would mean that it would need to point to a structure
 containing both the quantile and the sorted flag).

 #1 is inefficient, #2 is a bit of a hack, #3 adds another parameter
 which most functions won't use (only diversity, median, mode,
 quantiles need sorted data), #4 is awkward to use.

 The inefficient quantile algorithm can be replaced (or augmented) with
 the more efficient (and more complex) one used by r.quantile and
 r.statistics3. But is it worth the effort and complexity?

 Essentially, it only matters if the number of maps is large enough
 that the qsort() dominates. For a few maps, the setup overhead of the
 more complex algorithm will make it slower. For an intermediate
 number, the speed gain may be small compared to other overheads. It's
 worth it for calculating quantiles over millions of values (although
 the primary motivation was to avoid having to store all values in
 memory), but I don't know if it's worth it for 10,000 values.

 --
 Glynn Clements gl...@gclements.plus.com

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

[GRASS-user] quantile/percentile

[Laura Poggio]

Dear all,
I would need to calculate the resulting percentile map from a large number
of maps (1), obtaining the values for 5 and 95 percentile for each
pixel. Is there any function in GRASS?
I did not find anything in mapcalc. Other functions such r.quantile or
r.univar provide a summarising quantile value for every map, but this is not
very helpful in my case.
I could use R but before I would like to try with GRASS, also because I am
afraid that R would require a huge amount of memory as the raster have about
15 pixels.

Thank you in advance

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

Re: [GRASS-user] some issues of GRASS on Fedora 11

[Laura Poggio]

I had similar issues with fedora 11 64 bit.
I compiled the Grass 6.4 svn snapshot of the 15-08-2009 on a fedora 11 64
bit system. Everything went fine without errors. However when I open GRASS I
get the following error:
-
GRASS 6.4.0svn (DEM):~ 
/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14450:
UserWarning: wxPython/wxWidgets release number mismatch
  warnings.warn(wxPython/wxWidgets release number mismatch)
-
The gui (wx) is starting, but the 3D view and the digitize do not start. For
the 3d view I get a loading data message and nothing is happening.

I tried the same with the svn of 6.5 and I get the same messages. But even
the 2d data are not loading.
I do not have two versions of Python on the machine. However I have the 2.6
installed.
A couple of weeks ago I installed grass on a fedora 10 64 bit with the same
options and everything is working fine. But there the version of Python is
2.5.

I put a message on the fedora forum, but I did not get any answer. And in
the repository the latest official version is still the 6.3. That is why I
went into compiling it.

Thank you

Laura


2009/8/26 Martin Landa landa.mar...@gmail.com

 Hi,

 2009/8/26 ambrish dhaka ambi...@hotmail.com:
  1. Error in digitization tool
 
  Unable to initialize display driver, see README file for more
 information.
 
  Details: 'NoneType' object has no attribute 'OpenMap'
  (/usr/lib/grass-6.3.0/etc/wxpython/vdigit/_grass6_wxvdigit.so: undefined
  symbol: _ZN10wxPseudoDC9AddToListEP5pdcOp)

 First of all I would suggest to you to use more recent version of
 GRASS (note that wxGUI is under development).

  2. Some mismatch issue
 
  GRASS 6.3.0 (projectAfghanistan):~ 
  /usr/lib/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14450:
  UserWarning: wxPython/wxWidgets release number mismatch

 Probably more versions of Python installed on your machine?

 Martin

 --
 Martin Landa landa.martin gmail.com * 
 http://gama.fsv.cvut.cz/~landahttp://gama.fsv.cvut.cz/%7Elanda
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] some issues of GRASS on Fedora 11

[Laura Poggio]

Thank you very much. I was looking at the error filtering with GRASS keyword
and I did not find that page.
I will check what they suggest and in case I will add the example with
GRASS.

I will keep here updated.

Thanks again

Laura

2009/8/26 Martin Landa landa.mar...@gmail.com

 Hi,

 2009/8/26 Laura Poggio laura.pog...@gmail.com:
  I had similar issues with fedora 11 64 bit.
  I compiled the Grass 6.4 svn snapshot of the 15-08-2009 on a fedora 11 64
  bit system. Everything went fine without errors. However when I open
 GRASS I
  get the following error:
  -
  GRASS 6.4.0svn (DEM):~ 
  /usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14450:
  UserWarning: wxPython/wxWidgets release number mismatch
warnings.warn(wxPython/wxWidgets release number mismatch)
  -

 seems to be related

 https://bugzilla.redhat.com/show_bug.cgi?id=502608

 Martin

 --
 Martin Landa landa.martin gmail.com * 
 http://gama.fsv.cvut.cz/~landahttp://gama.fsv.cvut.cz/%7Elanda

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

Re: [GRASS-user] some issues of GRASS on Fedora 11

[Laura Poggio]

In the official repository there is only the 6.3. You can download the
Weekly snapshot for generic linux and install it. It is not difficult, but
some small are missing (3D and digitize).

Laura

2009/8/26 ambrish dhaka ambi...@hotmail.com

  But, I have no control over the versions. As, it is the Fedora which is
 responsible for the maintenance of rpms. ANy further help!

 Ambrish

  Date: Wed, 26 Aug 2009 08:44:50 +0200
  Subject: Re: [GRASS-user] some issues of GRASS on Fedora 11
  From: landa.mar...@gmail.com
  To: ambi...@hotmail.com
  CC: grass-user@lists.osgeo.org
 
  Hi,
 
  2009/8/26 ambrish dhaka ambi...@hotmail.com:
   1. Error in digitization tool
  
   Unable to initialize display driver, see README file for more
 information.
  
   Details: 'NoneType' object has no attribute 'OpenMap'
   (/usr/lib/grass-6.3.0/etc/wxpython/vdigit/_grass6_wxvdigit.so:
 undefined
   symbol: _ZN10wxPseudoDC9AddToListEP5pdcOp)
 
  First of all I would suggest to you to use more recent version of
  GRASS (note that wxGUI is under development).
 
   2. Some mismatch issue
  
   GRASS 6.3.0 (projectAfghanistan):~ 
   /usr/lib/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14450:
   UserWarning: wxPython/wxWidgets release number mismatch
 
  Probably more versions of Python installed on your machine?
 
  Martin
 
  --
  Martin Landa landa.martin gmail.com * 
  http://gama.fsv.cvut.cz/~landahttp://gama.fsv.cvut.cz/%7Elanda

 --
 Match ‘n’ Make new friends with the cool match-meter. Join the Planet with
 you Hotmail ID. Drag n’ drop http://www.WindowsLivePlanet.com

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


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

[GRASS-user] error GRASS 6.4 on fedora 11 64 bit

[Laura Poggio]

Dear all,
I compiled the last svn snapshot (15-08-2009)  of Grass 6.4 on a fedora 11
64 bit system with the following options:
==
-enable-64bit --with-libs=/usr/lib64 \
--with-cxx --with-glw --with-curses --with-freetype --with-postgres
-with-mysql --with-sqlite --with-gdal=/usr/bin/gdal-config
--with-python=/usr/bin/python-config --with-wxwidgets=/usr/bin/wx-config
--with-proj-share=/usr/share/proj --with-mysql-includes=/usr/include/mysql/
--with-mysql-libs=/usr/lib64/mysql
--with-freetype-includes=/usr/include/freetype2
==

Everything went fine without errors. However when I open GRASS I get the
following error:
-
GRASS 6.4.0svn (DEM):~ 
/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14450:
UserWarning: wxPython/wxWidgets release number mismatch
  warnings.warn(wxPython/wxWidgets release number mismatch)
-
The gui (wx) is starting, but the 3D view and the digitize do not start. For
the 3d view I get a loading data message and nothing is happening.

A couple of weeks ago I installed grass on a fedora 10 64 bit with the same
options and everything is working fine.

Thank you very much in advance for any hints!

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

[GRASS-user] error with r.terraflow

[Laura Poggio]

Dear all,
I run r.terraflow and it aborted giving the following output:
-
r.terraflow: sweep.cc:245: AMI_STREAMsweepOutput*
sweep(AMI_STREAMsweepItemBaseTypeint *, flowaccumulation_type, int):
Assertion `crtpoint-getPriority()  prevprio' failed.
Aborted
-

The fill, flow direction and  sink-watershed maps are created, but not the
flow accumulation (the one I am interested in) and the tci.

I managed to have it working on very similar rasters, but not on this one.
I am running grass on 64bit fedora 10 machine.

Thank you in advance for any hints!

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

Re: [GRASS-user] bitpattern analysis

[Laura Poggio]

Thank you for the links that helped to understand more how the things are
working within GRASS.

For the moment I decided to use
r.mapcalc QA_field1=(QAbit_position_field1)% bit_length_field1
for the different fields and then combining the files obtained into a mask.

Thanks

Laura

2009/6/15 Hamish hamis...@yahoo.com


 Laura Poggio wrote:
  I am trying to use the QA information of MODIS products. I
  found that this analysis can be done in GRASS with
  r.bitpattern (from Neteler, 2005 with some examples)
  or with r.mapcalc .
 
  From what I understood, the use of r.mapcal seems to be
  more flexible. I am just wondering if there are some code
  examples using the bitwise operators of mapcalc.

 this doesn't answer your question directly, but maybe it is of
 interest:
  http://grass.osgeo.org/wiki/MODIS

 and quality layer application method here
  http://grass.osgeo.org/wiki/AVHRR



 Hamish

  From what I understood, the use of r.mapcal seems to be more flexible.
  I am just wondering if there are some code examples using the bitwise
  operators of mapcalc. I found the following code:
  lst_filt = (lstmap ~ [XX XX XX 00]) || (lstmap ~ [XX XX 0X 01])
  but to me it is not really clear how this works, especially compared
  to the code provided (and explained) by Glynn Clements:
  r.mapcalc MASK=if((sur_refl_qc_250 / 16) % 16 == 11 , 1, null())
 
  Thank you very much for any help.
 
  Laura


 2009/6/15 Nikos Alexandris nikos.alexand...@felis.uni-freiburg.de

 Hi Laura!

 I am sending you some notes of mine off-list. Also, check...

 In the upcoming release of GRASS (version 7) there is an extra module
 to derive such quality layers called i.modis.qc ;

 Yann Chemin, International Rice Research Institute, The Philippines,
 http://svn.osgeo.org/grass/grass/trunk/imagery/i.modis.qc/i.modis.qc.html

 Regards, Nikos



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

[GRASS-user] bitpattern analysis

[Laura Poggio]

Dear all,
I am trying to use the QA information of MODIS products. I found that this
analysis can be done in GRASS with r.bitpattern (from Neteler, 2005 with
some 
exampleshttp://wald.intevation.org/tracker/index.php?func=detailaid=576group_id=21atid=207)
or with r.mapcalc .

From what I understood, the use of r.mapcal seems to be more flexible. I am
just wondering if there are some code examples using the bitwise operators
of mapcalc. I 
foundhttp://www.mail-archive.com/grassu...@grass.itc.it/msg00127.htmlthe
following code:

lst_filt = (lstmap ~ [XX XX XX 00]) || (lstmap ~ [XX XX 0X 01])

but to me it is not really clear how this works, especially compared to the
code http://www.mail-archive.com/grassu...@grass.itc.it/msg4.htmlprovided
(and explained) by Glynn Clements:

r.mapcalc MASK=if((sur_refl_qc_250 / 16) % 16 == 11 , 1, null())

Thank you very much for any help.

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

Re: [GRASS-user] EPSG 3035

[Laura Poggio]

I will then try to upgrade the version of GRASS, but in the meantime just a
question.

All the files I will work on have the same projection as the location, at
least according to gdal and using EPSG codes.
If I create the location with the problems discussed until now and then
import the files with -o option, would this be source of troubles for
further elaborations such as watershed analysis?

Thank you very much

Laura


2009/3/27 Moritz Lennert mlenn...@club.worldonline.be

 On 26/03/09 11:04, Laura Poggio wrote:

 Sorry I hit reply instead of reply to all.

 The versions of the software are:
 GRASS 6.3.0


 Ok, trying with 6.3 and proj 4.6, I get:

 GRASS 6.3.0 (newLocation):~  g.proj -c location=eee epsg=3035
 WARNING: Datum unknown not recognised by GRASS and no parameters found.
 Location eee created!

 And g.proj -p in that new location gives:

 -PROJ_INFO-
 name   : Lambert Azimuthal Equal Area
 proj   : laea
 ellps  : wgs84
 lat_0  : 52
 lon_0  : 10
 x_0: 4321000
 y_0: 321
 no_defs: defined
 -PROJ_UNITS
 unit   : Meter
 units  : Meters
 meters : 1

 However, trying the same in GRASS 6.5svn and same proj version, I get no
 warning and g.proj -p in the resulting location gives:

  g.proj -p
 -PROJ_INFO-
 name   : Lambert Azimuthal Equal Area
 proj   : laea
 datum  : etrs89
 ellps  : grs80
 lat_0  : 52
 lon_0  : 10
 x_0: 4321000
 y_0: 321
 no_defs: defined
 -PROJ_UNITS
 unit   : metre
 units  : metres
 meters : 1

 So, don't know exactly where the problem lies but it seems to be fixed in
 later versions (can't try 6.4rc right now). Cc'ing Paul in case he knows.

 Moritz

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

Re: [GRASS-user] EPSG 3035

[Laura Poggio]

Ok thanks. Maybe by hand is really the easiest solution.

Thank you

Laura

2009/3/27 Moritz Lennert mlenn...@club.worldonline.be

 On 27/03/09 13:05, Laura Poggio wrote:

 I will then try to upgrade the version of GRASS, but in the meantime just
 a question.

 All the files I will work on have the same projection as the location, at
 least according to gdal and using EPSG codes.
 If I create the location with the problems discussed until now and then
 import the files with -o option, would this be source of troubles for
 further elaborations such as watershed analysis?


 I don't think so. But you might want to try to create a correct location
 with all the parameters, including datum, etc. You might have to do this by
 hand though, i.e. using the option to create the location with projection
 parameters, instead of EPSG code or existing file.

 Moritz

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

Re: [GRASS-user] EPSG 3035

[Laura Poggio]

The output of the g.proj -w command is:

WARNING: Unable to initialise PROJ.4 with the following parameter list:
 +a=6378137 +rf=298.257222101 +no_defs +towgs84=0.000,0.000,0.000
WARNING: The error message: projection not named
WARNING: Can't parse GRASS PROJ_INFO file
WARNING: g.proj: Unable to convert to WKT

Then I think there is some problem

Thank you very much

Laura


2009/3/25 Moritz Lennert mlenn...@club.worldonline.be

 On 25/03/09 18:05, Laura Poggio wrote:

 The output of gdalinfo on the file is

 Driver: GTiff/GeoTIFF   Files:
 data/JRC/map/DTM/ast1.tifSize is 360, 364
  Coordinate System is:
 PROJCS[ETRS89 / ETRS-LAEA,
  GEOGCS[ETRS89,
  DATUM[European_Terrestrial_Reference_System_1989,
SPHEROID[GRS 1980,6378137,298.2572221010042,
AUTHORITY[EPSG,7019]],
  AUTHORITY[EPSG,6258]],
  PRIMEM[Greenwich,0],
  UNIT[degree,0.0174532925199433],
  AUTHORITY[EPSG,4258]],UNIT[metre,1,
AUTHORITY[EPSG,9001]],
  AUTHORITY[EPSG,3035]]


 Mmmh, so coordinate system info is included and GRASS should recognize it.
 Could you send the output of g.proj -w in the location you want to import
 the file into ?

 Moritz



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

[GRASS-user] EPSG 3035

[Laura Poggio]

Dear all,
I am starting to use GRASS and I am trying to set up a location with the
LAEA ETRS89 projection (EPSG 3035).
First I set up the location using the EPSG code and the I tried to import a
geotiff with the same projection (created with gdal_translate). However I
got the error Projection of dataset does not appear to match current
location.
Then I set up the location using the georeferenced file itself, I tried to
import the same file and I got the same error.

I can manage to import the file using the -o option and over-riding
projection check, but I would like to understand and possible solve the
problem.

I am using GRASS63 under linux.

Thank you very much in advance

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

Re: [GRASS-user] EPSG 3035

[Laura Poggio]

The output of gdalinfo on the file is

Driver: GTiff/GeoTIFF
Files: data/JRC/map/DTM/ast1.tif
Size is 360, 364
Coordinate System is:
PROJCS[ETRS89 / ETRS-LAEA,
GEOGCS[ETRS89,
DATUM[European_Terrestrial_Reference_System_1989,
SPHEROID[GRS 1980,6378137,298.2572221010042,
AUTHORITY[EPSG,7019]],
AUTHORITY[EPSG,6258]],
PRIMEM[Greenwich,0],
UNIT[degree,0.0174532925199433],
AUTHORITY[EPSG,4258]],
UNIT[metre,1,
AUTHORITY[EPSG,9001]],
AUTHORITY[EPSG,3035]]
Origin = (4081404.118557849433273,2966229.602829793468118)
Pixel Size = (30.000,-30.000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 4081404.119, 2966229.603)
Lower Left  ( 4081404.119, 2955309.603)
Upper Right ( 4092204.119, 2966229.603)
Lower Right ( 4092204.119, 2955309.603)
Center  ( 4086804.119, 2960769.603)
Band 1 Block=360x5 Type=Float32, ColorInterp=Gray
  NoData Value=-32768
  Metadata:
LAYER_TYPE=athematic

The parameters seems to be correct. I will then use the -o option

Thank you very much

Laura

2009/3/25 Moritz Lennert mlenn...@club.worldonline.be

 On 25/03/09 16:57, Laura Poggio wrote:

 Dear all,
 I am starting to use GRASS and I am trying to set up a location with the
 LAEA ETRS89 projection (EPSG 3035).
 First I set up the location using the EPSG code and the I tried to import
 a geotiff with the same projection (created with gdal_translate). However I
 got the error Projection of dataset does not appear to match current
 location.
 Then I set up the location using the georeferenced file itself, I tried to
 import the same file and I got the same error.

 I can manage to import the file using the -o option and over-riding
 projection check, but I would like to understand and possible solve the
 problem.


 Your file might be georeferenced, but does not contain the information
 about the system it is georeferenced in. In that case, grass will always
 complain that it cannot guarantee a match.

 If you are sure that it is referenced in 3035, then you have to use the -o
 option.

 Moritz

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