Re: [GRASS-user] How to avoid Grass84 compiling against the system Python3.6?

[Hernán De Angelis via grass-user]

I understand you are using openSUSE Leap. At the moment I cannot check
which Python version is offered there as base. Are you sure you cant
install a newer version? If that is not possible you could perhaps install
a newer version using your own separate local environment, using miniforge,
for example.

I use openSUSE Tumbleweed and always build from source. Python 3.11 is the
base version now, with 3.12 starting to be rolled in. Perhaps it is not too
crazy to try TW?

Good luck!

Hernán

Den tors 21 mars 2024 01:23Barry Keeling via grass-user <
grass-user@lists.osgeo.org> skrev:

> Hi @grass-users,
>
> I posted the following on libera.chat#grass but it seemed like there
> isn't much activity on there (pls. excuse if I'm wrong on that).
>
> I spent the day learning how to compile the grass8.4dev source, and
> managed to get the app to compile, and fire up
> but there's a glitch, it compiled against the system python which is
> only v3.6 (not compatible based on REQUIREMENTS file)
> and I don't know how to point it at python v3.11.
>
> This is on OpenSuse 15.5 Linux, btw, and though the Grass application
> windows work well, I get errors in the console related mostly to python,
> when trying to use the various modules, for example using r.in.png.
>
> I've tried per-user setting python3 aliased to v3.11 in my .bashrc, but
> no luck Grass still shows v3.6 in Help/about/system ..
>
> I'm wondering whether I should use update-alternatives approach, and
> also wondering whether the problem might be related to wxpython3 being
> linked to the system python and not v3.11.
>
> I haven't compiled wxpython separately.
>
> I'm just hoping someone might be able to point me in the right direction
> :-)
>
> Barry
>
>
> ___
> 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] v.rast.stats skipping polygons. Why?

[Hernán De Angelis via grass-user]

Hola Vero,

Thank you. There were a few repeated or shared categories but not as 
many as skipped polygons. The problem was with the data like many 
extremely small lakes and a too coarse raster resolution to capture all 
of them them. This is solved now.


All well, thanks again

/Hernán


Den 2023-10-31 kl. 23:47, skrev Veronica Andreo:

Hola Hernán,

Do your polygons have repeated/shared cat values? That might be one 
potential cause according to the Notes in the manual: 
https://grass.osgeo.org/grass83/manuals/v.rast.stats.html


just my 2 cents
Vero

El mar, 31 oct 2023 a las 6:35, Hernán De Angelis via grass-user 
() escribió:


Hi all,

I have a vector layer with 97015 polygons (lakes in real life)
many of
which are complicated, with islands. The layer has been cleaned using
v.clean (during import, and after as well). I then run
v.stats.rast to
pick statistics from a raster. This works well for about 3/4 of the
categories while about 1/4 are skipped. Why?

 From v.stats.rast:
WARNING: Not all vector categories converted to raster. Converted
73078 of
  97837.
Processing input data (73078 categories)...

I see that v.to.rast has no problems converting polygons to raster
(only
visually checked). A test running v.rast.stats using the rasterized
vector reports:
WARNING: Not all vector categories converted to raster. Converted
97015 of
  97837.
Processing input data (97015 categories)...
That is, it converts all polygons.

I have cleaned, and rebuilt topology to no avail. Also calling
v.rast.stats using layer (1) and type (centroid) did not change
the results.

Am I missing something here? Why is this happening and what can be
done
to calculate raster statistics for all polygons?

Thanks in advance!

Hernán


v.category report is:
 > v.category input=lakes option=report
Layer/table: 1/lakes
type   count    min    max
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid   97837  1  97015
area   0  0  0
face   0  0  0
kernel 0  0  0
all    97837  1  97015
Layer: 2
type   count    min    max
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid  21  2  2
area   0  0  0
face   0  0  0
kernel 0  0  0
all   21  2  2


___
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] v.rast.stats skipping polygons. Why?

[Hernán De Angelis via grass-user]

Hi all,

I have a vector layer with 97015 polygons (lakes in real life) many of 
which are complicated, with islands. The layer has been cleaned using 
v.clean (during import, and after as well). I then run v.stats.rast to 
pick statistics from a raster. This works well for about 3/4 of the 
categories while about 1/4 are skipped. Why?


From v.stats.rast:
WARNING: Not all vector categories converted to raster. Converted 73078 of
 97837.
Processing input data (73078 categories)...

I see that v.to.rast has no problems converting polygons to raster (only 
visually checked). A test running v.rast.stats using the rasterized 
vector reports:

WARNING: Not all vector categories converted to raster. Converted 97015 of
 97837.
Processing input data (97015 categories)...
That is, it converts all polygons.

I have cleaned, and rebuilt topology to no avail. Also calling 
v.rast.stats using layer (1) and type (centroid) did not change the results.


Am I missing something here? Why is this happening and what can be done 
to calculate raster statistics for all polygons?


Thanks in advance!

Hernán


v.category report is:
> v.category input=lakes option=report
Layer/table: 1/lakes
type   count    min    max
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid   97837  1  97015
area   0  0  0
face   0  0  0
kernel 0  0  0
all    97837  1  97015
Layer: 2
type   count    min    max
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid  21  2  2
area   0  0  0
face   0  0  0
kernel 0  0  0
all   21  2  2


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

Re: [GRASS-user] NSF Grant Awarded to Enhance GRASS GIS Ecosystem

[Hernán De Angelis]

Congratulations! This is great news !

Best

Hernán

Den 2023-09-08 kl. 20:37, skrev Anna Petrášová:

Dear all,

On behalf of a team of researchers from four U.S. universities, I am 
excited to announce a new NSF funded project to support and expand the 
global GRASS GIS community. See the announcement below:


https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/

Best,
Anna

___
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] ps.map logscale colortable?

[Hernán De Angelis]

Hi all

I wonder if it is possible to produce a logaritmic colortable for a 
raster in a map created with ps.map. I have rasters using a logaritmic 
scale but their colortables appear linear in the output. In the Map 
display it is possible to make a legend logaritmic (d.legend with option 
-l) but I cannot figure out how to easily do it in ps.map. Any suggestions?


Thanks

Hernán

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

Re: [GRASS-user] Map production recommendations

[Hernán De Angelis]

Den 2023-05-13 kl. 19:41, skrev Rich Shepard:

Since we are listing options here, GMT experienced quite some revamp. I
would curious if anyone here has tried it lately.


What's GMT other than the deprecated Greenwich Mean Time? 



Generic Mapping Tools

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

[GRASS-user] New single-window GUI

[Hernán De Angelis]

Hi grassers

Just to share that I am very pleased with the new single-window GUI too. 
Everything is elegantly organized. And the tool panel to the right is a 
charm. Warm congratulations to everyone that worked to make this a reality!


I compiled the main branch on openSUSE Tumbleweed today. For once 
though, I experienced many compilation problems that were solved by 
running make in each of the different location with errors. This is 
unusual for me but it does not necessarily mean that there are problems 
with GRASS. openSUSE Tumbleweed is a rolling distribution that is being 
constantly upgraded so maybe this is caused by small differences in the 
packages used, or perhaps by running make in parallel. Nothing to be 
overly concerned with IMO.


Best

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

[GRASS-user] Startup menu small. Why?

[Hernán De Angelis]

Dear grassers

I compiled and installed 7.8.6 yesterday. Everything seemed to go well 
and GRASS works as good as ever. However, a small nuisance that I am 
experiencing is that the startup menu window shows up sort of 
"minimized", instead of the classical larger size showing the locations 
and mapsets from which to choose:


I have to manually increase its size to what formally was a normal size 
in order to see which location and mapset to choose:



This is not a problem, just a minor nuisance. And perhaps GRASS is not 
even involved in this but rather something else related with wxPython etc.


Has anyone experienced this before? Does someone has any idea on how to 
overcome this?


Thanks in advance

Hernán



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

Re: [GRASS-user] GUI/Addons

[Hernán De Angelis]

Cyril,


I also use openSUSE (Tumbleweed, not Leap). I believe you are 
experiencing problems that have different causes.



In first place you seem to use Python modules installed using both the 
package manager (zypper) and pip. My experience is that this is often 
cause for conflicts that are hard to diagnose and solve. My suggestion 
is to uninstall everything and install again using one or the other 
approach exclusively.



One reason I use Tumbleweed instead of Leap is that packages in the 
latter may be outdated and pose problems. In tumbleweed everything is 
bleeding edge. This is most often and advantage although of course it 
sometimes poses a different sort of problem.



Then I see you also have problems with openJPEG but I cannot help with 
that.



Good luck!


Hernán




On 2021-05-06 15:20, Cyril Gainon wrote:

Oh yeah sorry abour that.

you're right i totally forgot about it, i mainly used apt-get (in my 
studies i was mostly on mint) so i guess we go back to your theory 
conflit with unbuntu library.


Here are all the wx i got with zypper pa | grep wx

   | openSUSE-Leap-15.2-1                                     | 
plplotwxwidgets-devel                                         | 
5.15.0-lp152.2.4                                           | x86_64
   | Dépôt principal                                                  
| plplotwxwidgets-devel     | 5.15.0-lp152.2.4         | x86_64
i+ | openSUSE-Leap-15.2-1                                         | 
python-wxWidgets-3_0                                              | 
3.0.2.0-lp152.4.8    | x86_64
i+ | Dépôt principal                                                 | 
python-wxWidgets-3_0    | 3.0.2.0-lp152.4.8        | x86_64
   | openSUSE-Leap-15.2-1                                         | 
python-wxWidgets-3_0-devel    | 3.0.2.0-lp152.4.8        | x86_64
   | Dépôt principal                                                  
| python-wxWidgets-3_0-devel    | 3.0.2.0-lp152.4.8        | x86_64
i+ | openSUSE-Leap-15.2-1                                       | 
python-wxWidgets-3_0-lang     | 3.0.2.0-lp152.4.8          | x86_64
i+ | Dépôt principal                                          | 
python-wxWidgets-3_0-lang   | 3.0.2.0-lp152.4.8


btw does any package from pip influence on the behavior of grass ?

Here is the full error message

GRASS 7.8.4 (nc_spm_08_grass7):~ > g.extension 
extension=r.neighborhoodmatrix

Fetching  from GRASS GIS Addons repository (be
patient)...
Compiling...
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld : 
/usr/lib64/libgdal.so.28 : référence indéfinie vers 
« opj_encoder_set_extra_options »

collect2: error: ld returned 1 exit status
make: *** [/usr/lib64/grass78/include/Make/Module.make:18: 
/tmp/grass7-cyril.gainon-13653/tmpsqayrj_1/r.neighborhoodmatrix/bin/r.neighborhoodmatrix] 
Error 1

ERREUR : Compilation failed, sorry. Please check above error messages.
GRASS 7.8.4 (nc_spm_08_grass7):~ >


(please keep the list in CC so that all can contribute/benefit)

On Thu, May 6, 2021 at 11:27 AM Cyril Gainon  
wrote:

>
> Hello Markus,
>
> First thanks for your reactivity.
>
> I thought i mentioned it at the end of my mail. I'm currently using 
OpenSuse Leap 15.2, both error are on the same computer.


I see. I was just confused about

> And when i try to install it via sudo apt-get install wxPython

Isn't it zypper on OpenSuse?

> I checked the wiki page you linked, and it seems that i already have 
the package, maybe as you said lower i have some conflict.


Please send the list of wxpython related packages which are installed.

Now to your separate g.extension problem:

> GDAL work fines, i just used gdalwarp 2 min ago.

OK, good.

> So now, how can i see there is a conflict and how can i fix it ?

No idea. I just tried here:

GRASS nc_spm_08_grass7/user1:~ > g.extension 
extension=r.neighborhoodmatrix

Fetching  from GRASS GIS Addons repository (be
patient)...
Compiling...
main.c: In function ‘main’:
main.c:83:28: warning: unused variable ‘nbp_search’ [-Wunused-variable]
   83 | struct nbp *nbp_found, nbp_search, *nbp_new;
  |    ^~
main.c:66:9: warning: unused variable ‘i’ [-Wunused-variable]
   66 | int i;
  | ^
At top level:
main.c:47:13: warning: ‘free_pavl_item’ defined but not used 
[-Wunused-function]

   47 | static void free_pavl_item(void *p)
  | ^~
Installing...
Updating extensions metadata file...
Updating extension modules metadata file...
Installation of  successfully finished

The compile warnings are not dramatic and unrelated. Perhaps you can
send the entire error message to better understand.

Markus

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

Re: [GRASS-user] Building grass version grass-7.8.5

[Hernán De Angelis]

Stephen,

Let's see if I can help you. I always compile GRASS from source and in 
my experience whenever there is a problem the most probable reason is 
that a library is lacking. Seldom is GRASS itself the problem.


The instructions Vero linked work of course but these are general and 
you need to change them to adapt to your system or preferred setup. So 
that depends on you.


I do not see what exactly you are doing or in which OS you are. It seems 
that you may need to ensure that python 3 is installed with its relevant 
modules. How that is done depends on your exact system. Pay attention 
that the GRASS GUI needs python wxWidgets bindings.


Assuming you are in Linux and that you have all the required libraries 
(including dev packages) installed, this should work:



- open a terminal and log in as root user


- change dir to /usr/local/src


- get the package file

wget https://github.com/OSGeo/grass/archive/refs/tags/7.8.5.tar.gz


- untar and uncompress the package file

tar -xvf 7.8.5.tar.gz


- change dir to grass-7.8.5

cd grass-7.8.5 (or whatever is called)


- configure, this depends on what exactly you have and what you want to 
do. The following is the line I use often. You need to edit this to suit 
your system and needs:


|./configure --enable-shared --with-odbc --with-fftw --with-readline 
--with-curses --with-proj-share=/usr/local/share/proj --enable-largefile 
--with-motif --with-freetype 
--with-freetype-includes=/usr/include/freetype2 --with-sqlite 
--enable-64bit --with-geos --with-python --with-netcdf --with-blas|

||


|-make (use the N = number of cores in your processor to parallelize and 
make it complete in less time)

|

|make -j N|
|
|

|- install (this will put a script called grass78 in /usr/local/bin):|

|make install|


- as normal user, type in a terminal:

grass78


GRASS should then start.


Good luck


Hernán



On 2021-03-26 23:13, Stephen Kirby wrote:
Thanks Veronica for that good information.  I've made some progress by 
ensuring I had the libs it needs ready (GDAL, etc.).  Now it is giving 
me a Python error :


 File 
"/home/me/grass/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py", 
line 305,

**options,
SyntaxError: invalid syntax

I am not a Python user so this is throwing me.  I assume I need to 
install a Python (Python3?) module, via "pip install ..." I suppose.  
Can someone tell me which module can fix this?


For reference, the whole Python block of code containing the offending 
line, from core.py is:

def make_command(
 prog,
 flags="",
 overwrite=False,
 quiet=False,
 verbose=False,
 superquiet=False,
 errors=None,
 **options,
);

Thanks for any ideas.

Best,
Steve

On Fri, Mar 26, 2021 at 12:25 PM Veronica Andreo > wrote:


Hi Steve,

I'm no expert in compiling at all, but I always run configure in
the source code directory. Have you tried?
Once configure runs without errors, just run make, if no errors at
the end, you are good to go

Here's a wiki with instructions for diverse linux platforms:
https://grasswiki.osgeo.org/wiki/Compile_and_Install


hth,
Vero

El vie, 26 mar 2021 a las 18:07, Stephen Kirby
(mailto:thinjog...@gmail.com>>) escribió:

Hi,

I am trying to build the version of GRASS listed in the
subject line.  However, when I run configure, it does not
produce a "Makefile" even though configure appears to complete
without error.  The closest thing I see to a Makefile is this
file:  include/Make/Platform.make.  I am not running configure
in the source code directory as one is always told this is a
bad idea (for ex., when building gcc).  I am running configure
in a separate directory ("/build-grass").  Let me know what I
should try next as I am excited to get GRASS running!

Best regards,
Steve
___
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] Elections results and new GRASS GIS PSC

[Hernán De Angelis]

On 2021-02-09 21:09, Helmut Kudrnovsky wrote:

Moritz Lennert wrote

[Online version of this announcement:
https://grass.osgeo.org/news/2021_02_05_new_grass_psc/
https://grass.osgeo.org/news/2021_02_05_new_grass_psc/;]


   New GRASS GIS Project Steering Committee

By the end of last year, the GRASS GIS project called for PSC members
election. A total of/13 GRASS GIS contributors/were nominated by the
community to cover the nine PSC positions.

After the election itself, the new GRASS GIS PSC is composed of the
following nine members ranked by number of votes:

   * Markus Neteler (95)
   * Anna Petrášová (88)
   * Helena Mitášová (86)
   * Martin Landa (83)
   * Verónica Andreo (76)
   * Moritz Lennert (74)
   * Václav Petráš (68)
   * Michael Barton (58)
   * Huidae Cho (56)

For completeness, all relevant candidacy communications, as well as
details about the voting process, have been published
at:https://trac.osgeo.org/grass/wiki/PSC/Election2020
https://trac.osgeo.org/grass/wiki/PSC/Election2020;

On behalf of the GRASS GIS project, we would like to thank/Hernán De
Angelis/who agreed to serve as Chief Returning Officer (CRO) and all
community members for their participation. Furthermore, we want to
acknowledge the contributions of former PSC members and all nominees.
The development of GRASS GIS is a collective effort and we are all part
of it regardless of our role. So,*CONGRATS to everyone!*


   New PSC chair person

There’s yet one more change to report. GRASS GIS PSC has a new chair
person:*Veronica Andreo* https://veroandreo.gitlab.io/;. She works
as a
researcher in Argentina focusing on environmental drivers of
vector-borne disease outbreaks and works primarily with satellite
imagery and GIS-based time series analysis. For years, Vero has been
very active in the GRASS GIS project, especially with documenting
complex topics in a user friendly way, testing, development of the new
website, coding of addons, outreach, social media and more. She
regularly introduces GRASS GIS to new users and teaches introductory and
advanced courses and workshops. We thank Vero for accepting this
challenge!

We want to acknowledge and thank*Markus Neteler*
https://www.mundialis.de/neteler/for his enormous efforts and
passionate work on pushing the GRASS GIS development for more than 20
years. While Markus was re-elected as PSC member, he preferred to pass
on the position of chairperson to a new PSC member. Markus is one of the
long runners in the project, as he already started to discover the
software in 1993 as a student. In 1998, he set up a “European GRASS
site” at the University of Hannover, which evolved into an international
development team. From manual source code management, he was part of the
journey to a modern, GitHub-based development system including code
quality testing. Markus is known to be active in conferences, code
sprints, bug fixing, user support, infrastructure management, project
and release management, etc. He will continue to do so!


   PSC roles & tasks

In addition to the chair role, in the firstPSC
https://trac.osgeo.org/grass/wiki/PSCmeeting, we have defined some
basic areas/tasks and PSC members responsible for them:

   * Treasurer - Moritz
   * Release manager - Markus, Martin
   * Infrastructure manager - Markus
   * Translation manager - Huidae
   * Website & Marketing manager - Michael, Vero
   * Github manager - Vaclav

Of course, *everyone is invited to join and contribute*in these and
other areas:https://trac.osgeo.org/grass/wiki/PSC/Roles
https://trac.osgeo.org/grass/wiki/PSC/Roles;.

/The GRASS Development Team, Feb 2021/

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


Yes!  Congratulations to the new PSC!

/H.

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

Re: [GRASS-user] [GRASS-dev] Call for candidates for Chief Return Officer(s) to oversee election of new Project Steering Committee

[Hernán De Angelis]

Looking forward to do my best as CRO and give back to this community :-)

/H.

On 2020-12-11 10:58, Moritz Lennert wrote:

Dear all,

Many thanks to Hernán De Angelis who has agreed to serve as CRO !

We will put things in place with him to launch the entire process as soon as 
possible.

Moritz

Am 10. Dezember 2020 09:14:55 MEZ schrieb Moritz Lennert 
:

Dear all,

As part of the effort to guarantee a solid and sustainable governance of
GRASS GIS development, and in accordance with OSGeo guidelines, we have
a Project Steering Committee (PSC) [1]. Although most decisions are
taken by consensus via the mailing lists or via discussions in github
issues, some decisions go through this committee: annual budget,
admission of new developers into the core development team, and some
fundamental decisions (recent example: phasing out of a 32-bit version
for MS Windows).

The last election for this committee was in 2016 and at the time we
decided that the PSC should be renewed approximately every 3 years. We
are already beyond this time frame and so a new election should happen,
soon. The general outline of the procedure has been drafted [2].

The first step in that procedure is the nomination of one (or several)
Chief Return Officer(s) (CRO) who will oversee the election process and
who should not be a member of the current PSC, nor aim at becoming a
member of the new PSC.

Is anyone willing to play this role ? You can just respond directly here
on the list to display your interest.

In a second step, we will be looking for candidates for the new PSC. For
an overview of the (fairly low-noise) activity of the PSC, you can
browse through the archives of its public mailing list [3]. You will see
that it is not a job that requires a lot of work, but it is an essential
job nevertheless. Also: no need to be a developer to be part of the PSC,
users should also be represented.

On behalf of the current PSC,
Moritz

[1] https://trac.osgeo.org/grass/wiki/PSC
<https://trac.osgeo.org/grass/wiki/PSC>

[2] https://trac.osgeo.org/grass/wiki/PSC/Election2020

[3] https://lists.osgeo.org/pipermail/grass-psc/
___
grass-dev mailing list
grass-...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

___
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] The new GRASS start menu

[Hernán De Angelis]

Hi everyone

I just got and installed the latest master and was positively surprised 
by the new GRASS start menu.


This is for me a step forward in making live easier for newcommers to 
GRASS GIS.


Kudos to all who have worked with this.

/Hernán


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

Re: [GRASS-user] Download release sources?

[Hernán De Angelis]

Thanks for your answer, Vero.

The links in the page you refer to point to the binaries and my question 
was rather where the source code for different releases is going to be 
found. The answer seems to be trac (which one reaches when clicking in 
announcements: https://grass.osgeo.org/grassNN/source/grass-*) or github 
for the latest.


Perhaps it could be nice to have a link to the source directly in the 
link list for every release. This is not critical of course.


Best

Hernán


On 2020-08-13 21:46, Veronica Andreo wrote:

Hello Hernan,

You can go to any of those marked links in the attached image (or 
directly to https://grass.osgeo.org/download/) and they will lead to 
other links/pages for the different operating systems with options to 
download. Please let us know if you find that we could make it more 
explicit.



best,
Vero

El jue., 13 ago. 2020 a las 21:02, Hernán De Angelis 
(mailto:dhdeange...@comhem.se>>) escribió:


Since the migration to the new web it is not obvious to me where will
one go to get the source code for different releases. Those were
previously found at
https://grass.osgeo.org/download/software/sources/.
Perhaps it is the trac page that will be used from now on for
downloads?
Or just the latest code from github? Perhaps I missed something.
Thanks
for clarification.

/H.


___
grass-user mailing list
grass-user@lists.osgeo.org <mailto: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] Download release sources?

[Hernán De Angelis]

Since the migration to the new web it is not obvious to me where will 
one go to get the source code for different releases. Those were 
previously found at https://grass.osgeo.org/download/software/sources/. 
Perhaps it is the trac page that will be used from now on for downloads? 
Or just the latest code from github? Perhaps I missed something. Thanks 
for clarification.


/H.


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

Re: [GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Hernán De Angelis]

On 2020-02-02 10:40, Nikos Alexandris wrote:

Markus Metz:


Hi Nikos,

PROJ is moving fast, please use the latest PROJ 6 release 6.3.0

On Sat, Feb 1, 2020 at 8:36 PM Nikos Alexandris 


wrote:


Dears,

I cannot get GRASS GIS 7.8 to compile with
proj
Rel. 6.0.0, March 1st, 2019


if possible, never use a x.0.0 release of any software, these new major
releases are usually full of bugs.

Markus M


Thank you Markus!
I got it working, more or less. Recompiling only PROJ did away most of
the errors but a few. I guess I need to recompile PROJ (+GEOS), then
GDAL, then the rest.


Yes, IME the compile sequence to satisfy dependencies is (with optional 
in parentheses):


geos, proj, (netcdf), libgeotiff, (spatialite), GDAL, GRASS


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

Re: [GRASS-user] no more gui after upgrade to buster

[Hernán De Angelis]

On 2020-01-11 17:22, Markus Neteler wrote:

On Sat, Jan 11, 2020 at 12:08 PM Hernán De Angelis
 wrote:

I had (and still have) a similar problem that I began experiencing when I 
updated to 7.8. I may be mistaken but as far as I understand it is not GRASS 
but something related to wxPython for python 3 in the platform in question. I 
am using openSUSE 15.1 and already spent a too much time trying in vain to 
solve this. For the time being I will use GRASS in command line or via QGIS.

Did you report the error? I don't see any related trac bug report or
email (maybe I am overlooking it).


No, I did not report this to the GRASS list. I probably tweaked too many 
things, many more that I can remember to make a useful account of what 
happened. But as I wrote I have reasons to believe the problem is 
related to the local wxPython implementation, not GRASS.


H.

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

Re: [GRASS-user] no more gui after upgrade to buster

[Hernán De Angelis]

Hi

I had (and still have) a similar problem that I began experiencing when 
I updated to 7.8. I may be mistaken but as far as I understand it is not 
GRASS but something related to wxPython for python 3 in the platform in 
question. I am using openSUSE 15.1 and already spent a too much time 
trying in vain to solve this. For the time being I will use GRASS in 
command line or via QGIS.


/H.


On 2020-01-11 10:52, Frank David wrote:


Hi,

Yes why not. Is the installation procedure is same than stretch ? Is 
Python3 support will not make problems with my Python2 scripts ? and 
what to do to avoid in that case ?


Do I follow this ? > 
https://grasswiki.osgeo.org/wiki/Compile_and_Install#GRASS_7_on_Debian_Stretch


Thank you

Le 10/01/2020 à 21:01, Markus Neteler a écrit :

Hi,

any chance that you update to the much more modern GRASS GIS 7.8?

Best
Markus

On Thu, Jan 9, 2020 at 6:05 PM Frank David  wrote:

Hello all,

I have no more gui on grass 7.6 after upgrade from debian strech to buster.

Thank you for your help !

Regards

Frank

See below last errors :

Traceback (most recent call last):
   File "/usr/local/grass-7.6.0/gui/wxpython/wxgui.py", line 169, in 
 sys.exit(main())
   File "/usr/local/grass-7.6.0/gui/wxpython/wxgui.py", line 156, in main
 app = GMApp(workspaceFile)
   File "/usr/local/grass-7.6.0/gui/wxpython/wxgui.py", line 50, in __init__
 wx.App.__init__(self, False)
   File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk3/wx/_core.py", line 8628, 
in __init__
 self._BootstrapApp()
   File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk3/wx/_core.py", line 8196, 
in _BootstrapApp
 return _core_.PyApp__BootstrapApp(*args, **kwargs)
   File "/usr/local/grass-7.6.0/gui/wxpython/wxgui.py", line 103, in OnInit
 workspace=self.workspaceFile)
   File "/usr/local/grass-7.6.0/gui/wxpython/lmgr/frame.py", line 142, in 
__init__
 self.notebook = self._createNoteBook()
   File "/usr/local/grass-7.6.0/gui/wxpython/lmgr/frame.py", line 337, in 
_createNoteBook
 gcstyle=GC_PROMPT)
   File "/usr/local/grass-7.6.0/gui/wxpython/gui_core/goutput.py", line 118, in 
__init__
 self.cmdPrompt = GPromptSTC(parent=self, menuModel=self._menuModel)
   File "/usr/local/grass-7.6.0/gui/wxpython/gui_core/prompt.py", line 139, in 
__init__
 GPrompt.__init__(self, parent=parent, menuModel=menuModel)
   File "/usr/local/grass-7.6.0/gui/wxpython/gui_core/prompt.py", line 57, in 
__init__
 self.mapList = self._getListOfMaps()
   File "/usr/local/grass-7.6.0/gui/wxpython/gui_core/prompt.py", line 101, in 
_getListOfMaps
 result['raster'] = grass.list_strings('raster')
   File "/usr/local/grass-7.6.0/etc/python/grass/script/core.py", line 1252, in 
list_strings
 mapset=mapset).splitlines():
   File "/usr/local/grass-7.6.0/etc/python/grass/script/core.py", line 478, in 
read_command
 return handle_errors(returncode, stdout, args, kwargs)
   File "/usr/local/grass-7.6.0/etc/python/grass/script/core.py", line 334, in 
handle_errors
 returncode=returncode)
grass.exceptions.CalledModuleError: Module run None ['g.list', '--q', '-m', 
'type=raster'] ended with error
Process ended with non-zero return code 127. See errors in the (error) output.
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
   File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
 func(*targs, **kargs)
PyAssertionError: C++ assertion "GetEventHandler() == this" failed at 
../src/common/wincmn.cpp(478) in ~wxWindowBase(): any pushed event handlers must have 
been removed
Error in sys.exitfunc:
Traceback (most recent call last):
   File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
 func(*targs, **kargs)
wx._core.PyAssertionError: C++ assertion "GetEventHandler() == this" failed at 
../src/common/wincmn.cpp(478) in ~wxWindowBase(): any pushed event handlers must have 
been removed

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

--
*Geophom*
327 rue de Vieille Cour 44521 OUDON
Tel +33(0)2 85 52 02 59 - Port +33(0)6 04 47 91 06
www.geophom.fr

___
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] SQL: generating numeric class numbers from class text labels?

[Hernán De Angelis]

The variable to increment should be of course as corrected below:


# get the unique classes

SELECT distinct(label) FROM table;

-> fetch results in an array "txt_label"

# iterate over array and insert new integer labels in table

*int_label = 0 *

foreach txt_label {

    INSERT INTO table.label_int VALUES int_label WHERE label = 
'txt_label'


*int_label++*

}


/H.





On 2019-12-04 18:11, Markus Neteler wrote:

Hi,

I have a landuse map with text labels (forest, street, ...). For
r.learn.ml I need to have them as numeric classes.
It is not important for me which number is assigned but I search for
an automated solution, i.e. SQL statement unless there is a different
way.

So:

cat|label|label_int
1|forest|1
2|forest|1
3|street|2
4|forest|1
5|street|2
6|urban|3
...

I guess I have done that already some years ago but I can't remember
the trick :-)

thanks for a hint,
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
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] SQL: generating numeric class numbers from class text labels?

[Hernán De Angelis]

Hi

I cannot think of a short and simple SQL "one liner" statement but can 
think of a short script that will do that using SQL statements.


In pseudo-code, translate to your favorite language:


# get the unique classes

SELECT distinct(label) FROM table;

-> fetch results in an array "txt_label"

# iterate over array and insert new integer labels in table

int_label = 0

foreach txt_label {

    INSERT INTO table.label_int VALUES int_label WHERE label = 'txt_label'

    n++

}


This may seem obvious to you, but since you asked :-)

Cheers and good luck


Hernán





On 2019-12-04 18:11, Markus Neteler wrote:

Hi,

I have a landuse map with text labels (forest, street, ...). For
r.learn.ml I need to have them as numeric classes.
It is not important for me which number is assigned but I search for
an automated solution, i.e. SQL statement unless there is a different
way.

So:

cat|label|label_int
1|forest|1
2|forest|1
3|street|2
4|forest|1
5|street|2
6|urban|3
...

I guess I have done that already some years ago but I can't remember
the trick :-)

thanks for a hint,
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] Updated trunk to grass77, GUI crashes at start: wxPython/wxWidgets release number mismatch

[Hernán De Angelis]

No worries, thanks for that, Anna.

One question: how do I tell GRASS to use python 3, given that both 
Python 2 and 3 are present in the system? I tried using the configure 
option "--with-python=/usr/bin/python3" but cannot tell if it worked.


H.

On 9/23/18 1:42 PM, Anna Petrášová wrote:

Hi,

trunk is now less 'stable' than usually since it contains experimental 
support for Python 3, but it means there can be new bugs even with 
Python 2 (it was announced on mailing lists). If you want more stable 
environment, please use grass 76, but I will also appreciate you 
testing trunk.


Anna

On Sat, Sep 22, 2018, 9:22 AM Hernán De Angelis <mailto:dhdeange...@comhem.se>> wrote:


Please forget the previous email. I solved the problem by building
wxwidgets from source and then reinstalling grass. All works as
expected
now.

/H.


On 9/22/18 2:50 PM, Hernán De Angelis wrote:
> Hi
>
> I have just updated trunk to grass77 (r73379) via SVN. After the
build
> the location selection window opens normally, then, after the
location
> is selected, the greeting window flashes normally but the GUI never
> starts. There are a lot of warning/errors (see below).
>
> I understand that wxwidgets and python may be the culprit. This
wasn't
> the case with my previous installation (grass75) although there
where
> lots of warnings with this. I have not touched wxwidgets or python
> since my previous grass install.
>
> Any hint on a solution will be appreciated.
>
> Thanks in advance.
>
> /H.
>
>
>
--

>
>
> GRASS 7.7.svn (NVtest):~/NV/grassdb > grass77
> Starting GRASS GIS...
> /usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py:16629:
> UserWarning: wxPython/wxWidgets release number mismatch
>   warnings.warn("wxPython/wxWidgets release number mismatch")
> Cleaning up temporary files...
>
>
>   __  ___   __ ___
>  / / __ \/   | / ___/ ___/   / /  _/ ___/
>     / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
>    / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
>    \/_/ |_/_/  |_/// \/___///
>
> Welcome to GRASS GIS 7.7.svn (r72914)
> GRASS GIS homepage: http://grass.osgeo.org
> This version running through:    Bash Shell (/bin/bash)
> Help is available with the command:  g.manual -i
> See the licence terms with:  g.version -c
> See citation options with:   g.version -x
> If required, restart the GUI with:   g.gui wxpython
> When ready to quit enter:    exit
>
> Launching  GUI in the background, please wait...
> GRASS 7.7.svn (NVtest):~/NV/grassdb >
> /usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py:16629:
> UserWarning: wxPython/wxWidgets release number mismatch
>   warnings.warn("wxPython/wxWidgets release number mismatch")
> Traceback (most recent call last):
>   File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line
169, in
> 
>     sys.exit(main())
>   File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line
156, in
> main
>     app = GMApp(workspaceFile)
>   File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line
50, in
> __init__
>     wx.App.__init__(self, False)
>   File
"/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py",
> line 8628, in __init__
>     self._BootstrapApp()
>   File
"/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py",
> line 8196, in _BootstrapApp
>     return _core_.PyApp__BootstrapApp(*args, **kwargs)
>   File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line
101, in
> OnInit
>     from lmgr.frame import GMFrame
>   File "/usr/local/grass-7.7.svn/gui/wxpython/lmgr/frame.py",
line 51,
> in 
>     from lmgr.layertree import LayerTree, LMIcons
>   File
"/usr/local/grass-7.7.svn/gui/wxpython/lmgr/layertree.py", line
> 38, in 
>     from mapdisp.frame import MapFrame
>   File "/usr/local/grass-7.7.svn/gui/wxpython/mapdisp/frame.py",
line
> 33, in 
>     from mapdisp.toolbars import MapToolbar, NvizIcons
>   File "/usr/local/grass-7.7.svn/gui/wxpython/mapdisp/toolbars.py",
> line 22, in 
>     from nviz.main import haveNviz
>   File "/usr/local/grass-7.7.

Re: [GRASS-user] Versions question

[Hernán De Angelis]

Rich,

In my system the executables for the different grass versions look like 
this:


grass74

grass75

grass77

There was no confusion when updating the svn trunk (grass7_trunk).

I guess that the problem will disappear if you delete the installed 
executable, the installed grass folder, and then make a new fresh install.


/H.

On 9/22/18 7:01 PM, Rich Shepard wrote:

Looking at the web site's source download page I see that the svn trunk
was changed last month to 7.7svn. Removing the ~/gis/grass/grass7_trunk/
directory and running "svn checkout 
https://svn.osgeo.org/grass/grass/trunk
grass7_trunk" then building from scratch and installing the latest 
release

(73393?) I expected to see the new 7.7 version when I started grass.
However, I still see:

$ grass --version
GRASS GIS 7.5.svn

  And starting grass shows:

Welcome to GRASS GIS 7.5.svn (exported)
and
GRASS 7.5.svn :~/data/grassdata >

  When I run 'find / -name grass-7.5' nothing is found.

  What changes these version displays with the new build?

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

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

Re: [GRASS-user] r.in.wms problems in grass7.7.svn (73379)

[Hernán De Angelis]

It worked!!

Gracias!

/H.

On 9/22/18 5:07 PM, Veronica Andreo wrote:

Hi,

Check this thread:

https://lists.osgeo.org/pipermail/grass-dev/2018-September/089798.html

Anna provided a patch, but I could not yet test. If you do, please 
report back ;)


Cheers,
Vero

El sáb., 22 sep. 2018 11:58, Hernán De Angelis <mailto:dhdeange...@comhem.se>> escribió:


Dear users,

I am consistently experiencing an error in grass 7.7.svn (73379) when
trying to read a WMS (see below).

This error was not present in my previous grass 7.5.svn
installation and
is not present in my currently installed grass 7.4.1 in the same
machine. It seems to affect every WMS server I have tried, while
those
same servers are accessed without problems from grass 7.4.1, QGIS and
could be accesed with grass 7.5.svn up to yesterday.

Both 7.4.1 and 7.7.svn were compiled today against the same gdal
(2.3.1), geos (3.6.3) and python (2.7.14).

Is anyone else experiencing issues like this?

/H.


Traceback (most recent call last):
   File "/usr/local/grass-7.7.svn/gui/scripts/d.wms", line 214, in

 sys.exit(main())
   File "/usr/local/grass-7.7.svn/gui/scripts/d.wms", line 207, in
main
 temp_map = wms.GetMap(options, flags)
   File "/usr/local/grass-7.7.svn/etc/r.in.wms/wms_base.py", line
215,
in GetMap
 self.temp_map = self._download()
   File "/usr/local/grass-7.7.svn/etc/r.in.wms/wms_drv.py", line
232, in
_download
 temp_map_dataset.SetProjection(projection)
   File "/usr/local/lib64/python2.7/site-packages/osgeo/gdal.py",
line
1902, in SetProjection
 return _gdal.Dataset_SetProjection(self, *args)
TypeError: in method 'Dataset_SetProjection', argument 2 of type
'char
const *'



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

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

[GRASS-user] r.in.wms problems in grass7.7.svn (73379)

[Hernán De Angelis]

Dear users,

I am consistently experiencing an error in grass 7.7.svn (73379) when 
trying to read a WMS (see below).


This error was not present in my previous grass 7.5.svn installation and 
is not present in my currently installed grass 7.4.1 in the same 
machine. It seems to affect every WMS server I have tried, while those 
same servers are accessed without problems from grass 7.4.1, QGIS and 
could be accesed with grass 7.5.svn up to yesterday.


Both 7.4.1 and 7.7.svn were compiled today against the same gdal 
(2.3.1), geos (3.6.3) and python (2.7.14).


Is anyone else experiencing issues like this?

/H.


Traceback (most recent call last):
  File "/usr/local/grass-7.7.svn/gui/scripts/d.wms", line 214, in 
    sys.exit(main())
  File "/usr/local/grass-7.7.svn/gui/scripts/d.wms", line 207, in main
    temp_map = wms.GetMap(options, flags)
  File "/usr/local/grass-7.7.svn/etc/r.in.wms/wms_base.py", line 215, 
in GetMap

    self.temp_map = self._download()
  File "/usr/local/grass-7.7.svn/etc/r.in.wms/wms_drv.py", line 232, in 
_download

    temp_map_dataset.SetProjection(projection)
  File "/usr/local/lib64/python2.7/site-packages/osgeo/gdal.py", line 
1902, in SetProjection

    return _gdal.Dataset_SetProjection(self, *args)
TypeError: in method 'Dataset_SetProjection', argument 2 of type 'char 
const *'




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

Re: [GRASS-user] Updated trunk to grass77, GUI crashes at start: wxPython/wxWidgets release number mismatch

[Hernán De Angelis]

Please forget the previous email. I solved the problem by building 
wxwidgets from source and then reinstalling grass. All works as expected 
now.


/H.


On 9/22/18 2:50 PM, Hernán De Angelis wrote:

Hi

I have just updated trunk to grass77 (r73379) via SVN. After the build 
the location selection window opens normally, then, after the location 
is selected, the greeting window flashes normally but the GUI never 
starts. There are a lot of warning/errors (see below).


I understand that wxwidgets and python may be the culprit. This wasn't 
the case with my previous installation (grass75) although there where 
lots of warnings with this. I have not touched wxwidgets or python 
since my previous grass install.


Any hint on a solution will be appreciated.

Thanks in advance.

/H.


-- 



GRASS 7.7.svn (NVtest):~/NV/grassdb > grass77
Starting GRASS GIS...
/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py:16629: 
UserWarning: wxPython/wxWidgets release number mismatch

  warnings.warn("wxPython/wxWidgets release number mismatch")
Cleaning up temporary files...


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

Welcome to GRASS GIS 7.7.svn (r72914)
GRASS GIS homepage:  http://grass.osgeo.org
This version running through:    Bash Shell (/bin/bash)
Help is available with the command:  g.manual -i
See the licence terms with:  g.version -c
See citation options with:   g.version -x
If required, restart the GUI with:   g.gui wxpython
When ready to quit enter:    exit

Launching  GUI in the background, please wait...
GRASS 7.7.svn (NVtest):~/NV/grassdb > 
/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py:16629: 
UserWarning: wxPython/wxWidgets release number mismatch

  warnings.warn("wxPython/wxWidgets release number mismatch")
Traceback (most recent call last):
  File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line 169, in 


    sys.exit(main())
  File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line 156, in 
main

    app = GMApp(workspaceFile)
  File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line 50, in 
__init__

    wx.App.__init__(self, False)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py", 
line 8628, in __init__

    self._BootstrapApp()
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py", 
line 8196, in _BootstrapApp

    return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line 101, in 
OnInit

    from lmgr.frame import GMFrame
  File "/usr/local/grass-7.7.svn/gui/wxpython/lmgr/frame.py", line 51, 
in 

    from lmgr.layertree import LayerTree, LMIcons
  File "/usr/local/grass-7.7.svn/gui/wxpython/lmgr/layertree.py", line 
38, in 

    from mapdisp.frame import MapFrame
  File "/usr/local/grass-7.7.svn/gui/wxpython/mapdisp/frame.py", line 
33, in 

    from mapdisp.toolbars import MapToolbar, NvizIcons
  File "/usr/local/grass-7.7.svn/gui/wxpython/mapdisp/toolbars.py", 
line 22, in 

    from nviz.main import haveNviz
  File "/usr/local/grass-7.7.svn/gui/wxpython/nviz/main.py", line 24, 
in 

    from nviz import mapwindow
  File "/usr/local/grass-7.7.svn/gui/wxpython/nviz/mapwindow.py", line 
42, in 

    from nviz.workspace import NvizSettings
  File "/usr/local/grass-7.7.svn/gui/wxpython/nviz/workspace.py", line 
24, in 

    from nviz import wxnviz
  File "/usr/local/grass-7.7.svn/gui/wxpython/nviz/wxnviz.py", line 
51, in 

    from grass.lib.gis import *
  File "/usr/local/grass-7.7.svn/etc/python/grass/lib/gis.py", line 
988, in 

    G_asprintf = _variadic_function(_func,_restype,_argtypes)
TypeError: __init__() takes exactly 5 arguments (4 given)

___
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] Updated trunk to grass77, GUI crashes at start: wxPython/wxWidgets release number mismatch

[Hernán De Angelis]

Hi

I have just updated trunk to grass77 (r73379) via SVN. After the build 
the location selection window opens normally, then, after the location 
is selected, the greeting window flashes normally but the GUI never 
starts. There are a lot of warning/errors (see below).


I understand that wxwidgets and python may be the culprit. This wasn't 
the case with my previous installation (grass75) although there where 
lots of warnings with this. I have not touched wxwidgets or python since 
my previous grass install.


Any hint on a solution will be appreciated.

Thanks in advance.

/H.


--

GRASS 7.7.svn (NVtest):~/NV/grassdb > grass77
Starting GRASS GIS...
/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py:16629: 
UserWarning: wxPython/wxWidgets release number mismatch

  warnings.warn("wxPython/wxWidgets release number mismatch")
Cleaning up temporary files...


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

Welcome to GRASS GIS 7.7.svn (r72914)
GRASS GIS homepage:  http://grass.osgeo.org
This version running through:    Bash Shell (/bin/bash)
Help is available with the command:  g.manual -i
See the licence terms with:  g.version -c
See citation options with:   g.version -x
If required, restart the GUI with:   g.gui wxpython
When ready to quit enter:    exit

Launching  GUI in the background, please wait...
GRASS 7.7.svn (NVtest):~/NV/grassdb > 
/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py:16629: 
UserWarning: wxPython/wxWidgets release number mismatch

  warnings.warn("wxPython/wxWidgets release number mismatch")
Traceback (most recent call last):
  File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line 169, in 


    sys.exit(main())
  File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line 156, in main
    app = GMApp(workspaceFile)
  File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line 50, in 
__init__

    wx.App.__init__(self, False)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py", 
line 8628, in __init__

    self._BootstrapApp()
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py", 
line 8196, in _BootstrapApp

    return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "/usr/local/grass-7.7.svn/gui/wxpython/wxgui.py", line 101, in 
OnInit

    from lmgr.frame import GMFrame
  File "/usr/local/grass-7.7.svn/gui/wxpython/lmgr/frame.py", line 51, 
in 

    from lmgr.layertree import LayerTree, LMIcons
  File "/usr/local/grass-7.7.svn/gui/wxpython/lmgr/layertree.py", line 
38, in 

    from mapdisp.frame import MapFrame
  File "/usr/local/grass-7.7.svn/gui/wxpython/mapdisp/frame.py", line 
33, in 

    from mapdisp.toolbars import MapToolbar, NvizIcons
  File "/usr/local/grass-7.7.svn/gui/wxpython/mapdisp/toolbars.py", 
line 22, in 

    from nviz.main import haveNviz
  File "/usr/local/grass-7.7.svn/gui/wxpython/nviz/main.py", line 24, 
in 

    from nviz import mapwindow
  File "/usr/local/grass-7.7.svn/gui/wxpython/nviz/mapwindow.py", line 
42, in 

    from nviz.workspace import NvizSettings
  File "/usr/local/grass-7.7.svn/gui/wxpython/nviz/workspace.py", line 
24, in 

    from nviz import wxnviz
  File "/usr/local/grass-7.7.svn/gui/wxpython/nviz/wxnviz.py", line 51, 
in 

    from grass.lib.gis import *
  File "/usr/local/grass-7.7.svn/etc/python/grass/lib/gis.py", line 
988, in 

    G_asprintf = _variadic_function(_func,_restype,_argtypes)
TypeError: __init__() takes exactly 5 arguments (4 given)

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

Re: [GRASS-user] GRASS GIS installation error in ubuntu 16.04

[Hernán De Angelis]

Hi

Somehow the installation script does not "see" the libraries. Is your 
library path standard in your system? If not you could add it to your 
ld.so.conf


Good luck!


On 9/11/18 2:11 AM, yacob sen wrote:

Dear users,

I am trying to install the latest version of GRASS GIS from source 
code in my linux ubuntu 16.04 OS but having difficulty. The error 
message is as follows:


"error while loading shared libraries: *libproj.so.13*: cannot open 
shared object file: No such file or directory"


I have also manually installed  the latest version of proj (5.1.0) and 
provided the library link during configuration of the installation of 
GRASS GIS


clearly both *libproj.so * and *libproj.so.13* do exist in the lib 
directory of the proj software package and permission is fine. Besides 
I have soft linked the /usr/lib/*libproj.so* to *libproj.so*

The *libproj.so* is resides at  my installation directory at
/opt/source/proj-5.1.0/build/lib/*libproj.so *and further soft linked 
to *libproj.so.13*

*
*
*Any comments please ?*
*
*
*Regards*
*Yacob
*

___
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] Importing .img file

[Hernán De Angelis]

Hi

As far as I know, .img is ERDAS Imagine raster format.

You should be able to open it with r.in.gdal, as GDAL can both read and 
write it:


http://www.gdal.org/frmt_hfa.html

/H.


On 06/27/2018 05:10 PM, Rich Shepard wrote:

I have a set of files that appear to be ESRI raster image files:

Metro_Highres_value_definitions.xlsx
metro_highres.img.xml
metro_highres.img
metro_highres.lpk

and I've not before seen this type of data.

  Looking at the image commands I don't see one appropriate for importing
these data; perhaps r.in.gdal would be appropriate? The provided .xml 
file

is attached.

  Please provide advice on importing these data.

TIA,

Rich


___
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] Redefining computational region for vector overlay

[Hernán De Angelis]

On 2018-05-13 21:29, Markus Metz wrote:

ou could try to replace

3. v.clip

with

3.1. v.select to select only those areas overlapping with the current 
buffer
3.2 v.overlay of the selected areas with the current buffer which 
should now take only seconds


Markus M


That made a *very* serious improvement in performance!

Now processing ~2.5 points per minute (30 in 12 minutes). From the 
previous 1 every 8 minutes with v.clip this change makes a ~20x 
improvement in performance!


Thanks Markus for the suggestion and thanks Moritz for your kind help!

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

Re: [GRASS-user] Redefining computational region for vector overlay

[Hernán De Angelis]

Hi again Moritz, and thanks for your detailed answer.

Thank you for explaining what the -r switch does in v.clip. Yes, it is 
step 3 that takes long time to complete.


I suspect that the polygon maps may be problematic themselves. When I 
imported them from shapefiles it also took a long time with all the 
cleaning and topology checks.


Unfortunately I do not have much time to explore this in detail now. I 
will try converting to these polygon maps to a raster with small enough 
cell size. That will be fine.


Thanks again for the help!

Cheers!

H.


On 2018-05-13 19:06, Moritz Lennert wrote:

Le Sun, 13 May 2018 17:48:41 +0200,
Hernán De Angelis <dhdeange...@comhem.se> a écrit :


Thanks for your answer and link, Moritz.

Of course, slow or fast are relative terms. May be I wasn't clear
enough. Let's me explain better:

The core of my processing is simple:

1. extract point from point map (v.extract)

2. create buffer (v.buffer)

3. clip polygon map with buffered point (v.clip)

4. calculate areas (v.to.db)

This takes only 8 minutes. So we can agree to call it "fast".

8 minutes for 1 buffer and the 2 million polygons ? And it is step 3
which takes a long time ? I agree that this should be faster. It would
be interesting to understand which part of v.clip takes the longest.

AFAICT, if you clip areas by areas it uses v.overlay so that is
identical with my script. However, by default there is a dissolve step,
unless you use the -d flag. Maybe try with this ?

I imagine that your buffers overlap ? Another option would be to run
v.buffer only once on all points with the -t flag, then v.overlay, then
calculate the areas of overlap between the buffers and the small
polygons and with some SQL magic group the areas by original point cats.





The problem is: I have to do this for 60 points, in 5 different
buffer sizes, for 14 sets of polygon maps, that is 4200 times.

At this rate, this process will take 4200 x 8 minutes = 33600
minutes, or about 23 days and 8 hours.

If this approach ends up being the only one, you might be able to
significantly shorten this by parallelizing it.


That's why my question was if there was setting I might activate to
reduce computation time like, for example, limiting the computational
region to the area under the buffer. In the meantime since I posted
my question I read more carefully the v.clip manual and see that
there is a switch (-r) to use in a defined region. This is what I am
using now.

Watch out, the -r flag in v.clip means that instead of clipping using
the buffers, you clip your polygons by the rectangle
representing your current computational region. This means you will not
have the area of polygons overlaid by the buffers, but the area that
falls in the current computational region.


I will have a look at your script, but for what I see it does not
seem critically different from my working routine. I believe I may
explore another path, namely converting the polygons to a raster of
suitably small pixel size and calculating the areas using r.stats
instead. may be that's significantly faster.

r.stats, or r.stats.zonal, or r.univar with the zones parameter, but
for all these the issue is how to handle overlapping buffer areas.

GRASS GIS normally uses a spatial index. This means that overlay
operations of vector features should not have to test in detail all
features, but only those that fall into the relevant bounding boxes.
Maybe there is some issue with this index not being
used ? CC'ing MarkusM who wrote the index code.

Moritz



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

Re: [GRASS-user] Redefining computational region for vector overlay

[Hernán De Angelis]

Thanks for your answer and link, Moritz.

Of course, slow or fast are relative terms. May be I wasn't clear 
enough. Let's me explain better:


The core of my processing is simple:

1. extract point from point map (v.extract)

2. create buffer (v.buffer)

3. clip polygon map with buffered point (v.clip)

4. calculate areas (v.to.db)

This takes only 8 minutes. So we can agree to call it "fast".

The problem is: I have to do this for 60 points, in 5 different buffer 
sizes, for 14 sets of polygon maps, that is 4200 times.


At this rate, this process will take 4200 x 8 minutes = 33600 minutes, 
or about 23 days and 8 hours.


That's why my question was if there was setting I might activate to 
reduce computation time like, for example, limiting the computational 
region to the area under the buffer. In the meantime since I posted my 
question I read more carefully the v.clip manual and see that there is a 
switch (-r) to use in a defined region. This is what I am using now.


I will have a look at your script, but for what I see it does not seem 
critically different from my working routine. I believe I may explore 
another path, namely converting the polygons to a raster of suitably 
small pixel size and calculating the areas using r.stats instead. may be 
that's significantly faster.


Regards and thanks for the help!

/H.




On 2018-05-13 17:05, Moritz Lennert wrote:

Le Sun, 13 May 2018 13:21:51 +0200,
Hernán De Angelis <dhdeange...@comhem.se> a écrit :


Hello GRASS users!

I am working to make a certain vector process faster and more
effective and would like to ask you for some advice on how to proceed.

I have a vector map containing points and a collection of vector maps
containing polygons. My task is to calculate the area covered by
these polygons en each polygon map but only under buffers of certain
sizes around each of the points. I understand how to do this. My
problem is how to do it faster and more effectively.

Each polygon map contains around 2 million of them. The point map has
only ~60 points. Both cover the entire country (Sweden). The buffer
zones extend only a relatively small area around each point (up to
some tens of km). Selecting points and generating buffers around them
is easy and fast. The problem appears in the overlay operation. The
vast majority of polygons are not involved in the computations but
both v.clip and v.overlay seem to need to process them all. This
takes a long time.

I wish there could be a way of limiting the number of features
involved in the computation to the size of each buffer zone in order
to cut down the processing time. I understand (and confirmed
empirically!) that setting the computational region does not work for
vector operations in GRASS (except for v.in.region). I therefore
wonder what can be done in this respect.

I am not new to GRASS but have not used it for heavy duty tasks in a
long time, my skills have become rusty! Any hint will be greatly
appreciated!

I'm a bit surprised that v.overlay is so slow for you. In the the
little alternative (faster) script in [1] I got quite fast results
using v.overlay with other modules. Maybe it can help you identify a
faster way.

Moritz

[1] https://trac.osgeo.org/grass/ticket/3361.



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

[GRASS-user] Redefining computational region for vector overlay

[Hernán De Angelis]

Hello GRASS users!

I am working to make a certain vector process faster and more effective 
and would like to ask you for some advice on how to proceed.


I have a vector map containing points and a collection of vector maps 
containing polygons. My task is to calculate the area covered by these 
polygons en each polygon map but only under buffers of certain sizes 
around each of the points. I understand how to do this. My problem is 
how to do it faster and more effectively.


Each polygon map contains around 2 million of them. The point map has 
only ~60 points. Both cover the entire country (Sweden). The buffer 
zones extend only a relatively small area around each point (up to some 
tens of km). Selecting points and generating buffers around them is easy 
and fast. The problem appears in the overlay operation. The vast 
majority of polygons are not involved in the computations but both 
v.clip and v.overlay seem to need to process them all. This takes a long 
time.


I wish there could be a way of limiting the number of features involved 
in the computation to the size of each buffer zone in order to cut down 
the processing time. I understand (and confirmed empirically!) that 
setting the computational region does not work for vector operations in 
GRASS (except for v.in.region). I therefore wonder what can be done in 
this respect.


I am not new to GRASS but have not used it for heavy duty tasks in a 
long time, my skills have become rusty! Any hint will be greatly 
appreciated!


Thanks in advance!

Hernán


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

[GRASS-user] Anything new about the i.class problem?

[Hernán De Angelis]

Hi all,

About one month ago there has been a discussion about a problem with i.class:
http://lists.osgeo.org/pipermail/grass-user/2008-March/043736.html

I am experiencing exactly the same problems:

- created group and subgroup (with more than 3 images)
- run i.class interactively: i.class can't locate subgroup
- run i.class from command line: generated a signature file that
cannot be read by i.maxlik

in the latter case the resulting signature file seems to be very poor,
for example:

#
#water
14343

#snow
485

#forest
5684


which seems odd, and signature files created by i.cluster are much
more complex than this.

Tried several times, with different locations. Always the same problem.
Is there any solution to this?


Thanks


Hernán


-- 

Hernán De Angelis
Linux user # 397217
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] OT: Data Source

[Hernán De Angelis]

Martin,

If you mean the thickness of the ice sheet, you can find information here:
http://www.antarctica.ac.uk/bas_research/data/access/bedmap/


Other publicly available info can be found here:

Modis Mosaic of Antarctica:
http://nsidc.org/data/moa/

Radarsat Antarctic Mapping Project (images and DEM)
http://nsidc.org/data/ramp/

and the recently released Landsat Image Mosaic of Antarctica:
http://lima.usgs.gov/


Hope this helps

Hernán



2008/1/12, Martin Bley [EMAIL PROTECTED]:
 Hi List,
 sorry for the off topic posting, but I get stucked finding map data of
 Greenland and Antarctica including information about the thickness of
 the ice layer. Any hints?

 Thanks,
 Martin

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



-- 

Hernán De Angelis
Linux user # 397217
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass 6.2.3 cannot find BLAS

[Hernán De Angelis]

Thanks for that!  Here are the last lines of config.log. Configure
complains about undefined refernces to things. I guess it might be
something related to gcc/gfortran but I can't understand the cause of
the failure.


configure:12134: checking whether to use BLAS
configure:12156: checking for location of BLAS library
configure:12183: checking for dnrm2_ in -lblas
configure:12200: gcc -o conftest -g -O2 -Wl,--export-dynamic
conftest.c -lblas -lm   15
/usr/lib/gcc/i586-suse-linux/4.1.2/../../../libblas.so: undefined
reference to `_gfortran_st_write_done'
/usr/lib/gcc/i586-suse-linux/4.1.2/../../../libblas.so: undefined
reference to `_gfortran_transfer_integer'
/usr/lib/gcc/i586-suse-linux/4.1.2/../../../libblas.so: undefined
reference to `_gfortran_stop_numeric'
/usr/lib/gcc/i586-suse-linux/4.1.2/../../../libblas.so: undefined
reference to `_gfortran_st_write'
/usr/lib/gcc/i586-suse-linux/4.1.2/../../../libblas.so: undefined
reference to `_gfortran_transfer_character'
collect2: ld returned 1 exit status
configure: failed program was:
#line 12189 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char dnrm2_();

int main() {
dnrm2_()
; return 0; }
configure:12219: checking for dnrm2_ in -lblas
configure:12236: gcc -o conftest -g -O2 -Wl,--export-dynamic
conftest.c -lblas -lm -lg2c  15
/usr/lib/gcc/i586-suse-linux/4.1.2/../../../libblas.so: undefined
reference to `_gfortran_st_write_done'
/usr/lib/gcc/i586-suse-linux/4.1.2/../../../libblas.so: undefined
reference to `_gfortran_transfer_integer'
/usr/lib/gcc/i586-suse-linux/4.1.2/../../../libblas.so: undefined
reference to `_gfortran_stop_numeric'
/usr/lib/gcc/i586-suse-linux/4.1.2/../../../libblas.so: undefined
reference to `_gfortran_st_write'
/usr/lib/gcc/i586-suse-linux/4.1.2/../../../libblas.so: undefined
reference to `_gfortran_transfer_character'
collect2: ld returned 1 exit status
configure: failed program was:
#line 12225 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char dnrm2_();

int main() {
dnrm2_()
; return 0; }









2007/11/30, Glynn Clements [EMAIL PROTECTED]:

 Hernán De Angelis wrote:

  Thanks for your clarification. But, why does the configure script not
  find the blas libraries?

 There should be some clues (i.e. error messages) in the config.log
 file.

 --
 Glynn Clements [EMAIL PROTECTED]



-- 

Hernán De Angelis
Linux user # 397217
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user