[GRASS-dev] SOLVED: Re: function to get mouse position - too vague

2021-07-22 Thread Zoltan

Apologies for the bandwidth taken - I should have though of this earlier:

grep -i -R --include "*.py" "mouse"
and
grep -i -R --include "*.c" "mouse"

Regards,
Zoltan


On 2021/07/22 13:37, Zoltan wrote:

Hi again,
OK, I was far to vague...
What I am looking for is where in the digitising functions the 
mouse-clicks are collected to add/edit/etc the geometry elements.


I'm scratching through the 'C' progs and .py folders ..but 
some guidance would shorten my quest.


Thanks and keep well,
Zoltan


On 2021/07/21 17:07, Zoltan wrote:

Hi Devs,

Is there a function that will return the coordinates of the mouse 
pointer, if it is inside a graphics window?

This on mouse-click.

Ideally the return value would be:   button,x,y(,z)

Even more ideally, if mouse hovers inside a graphics window, and a 
keyboard key is press (say the letter 'k'), then the return value 
would be "k,x,y(,z)"


If any of you are old enough to have used Genamap, then I am looking 
to emulate its 'gloc' command.


TIA,
Zoltan





--

=
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028 (Signal, not WhatsApp)
www.geograph.co.za
=

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


Re: [GRASS-dev] function to get mouse position - too vague

2021-07-22 Thread Zoltan

Hi again,
OK, I was far to vague...
What I am looking for is where in the digitising functions the 
mouse-clicks are collected to add/edit/etc the geometry elements.


I'm scratching through the 'C' progs and .py folders ..but some 
guidance would shorten my quest.


Thanks and keep well,
Zoltan


On 2021/07/21 17:07, Zoltan wrote:

Hi Devs,

Is there a function that will return the coordinates of the mouse 
pointer, if it is inside a graphics window?

This on mouse-click.

Ideally the return value would be:   button,x,y(,z)

Even more ideally, if mouse hovers inside a graphics window, and a 
keyboard key is press (say the letter 'k'), then the return value 
would be "k,x,y(,z)"


If any of you are old enough to have used Genamap, then I am looking 
to emulate its 'gloc' command.


TIA,
Zoltan



--

=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028 (Signal, not WhatsApp)
www.geograph.co.za
=

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


[GRASS-dev] function to get mouse position

2021-07-21 Thread Zoltan

Hi Devs,

Is there a function that will return the coordinates of the mouse 
pointer, if it is inside a graphics window?

This on mouse-click.

Ideally the return value would be:   button,x,y(,z)

Even more ideally, if mouse hovers inside a graphics window, and a 
keyboard key is press (say the letter 'k'), then the return value would 
be "k,x,y(,z)"


If any of you are old enough to have used Genamap, then I am looking to 
emulate its 'gloc' command.


TIA,
Zoltan

--

=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028 (Signal, not WhatsApp)
www.geograph.co.za
=

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


Re: [GRASS-dev] FIXED: Re: compiling GRASS-latest - configure fails with Unable to locate PostgreSQL includes

2021-06-22 Thread Zoltan
Perhaps all that is required is that, if config does an error-exit, then 
print a message: "Have you read grasswiki...blah...blah"


Regards,
Z

On 2021-06-22 07:49, Maris Nartiss wrote:

2021-06-22 0:24 GMT+03:00, Markus Neteler :

Maybe others here have suggestions how to improve the current
(message) situation?

We are free to change messages in configure.in file, still it would be
hard to customize for all potential failure scenarios. One option
would be to create a longer version of message like: "FOO not found.
Consult configure.log for exact reason of failure and seek in GRASS
WIKI for potential solutions."


Best,
Markus

Māris


--

=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028 (Signal, not WhatsApp)
www.geograph.co.za
=

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


Re: [GRASS-dev] FIXED: Re: compiling GRASS-latest - configure fails with Unable to locate PostgreSQL includes

2021-06-21 Thread Zoltan

Hi Markus,
OK, I am now logged into the Ubuntu system I used, and can better trace 
what I did.


I started my research at 
https://github.com/OSGeo/grass/blob/previewbranch_8_0/INSTALL
Under "Prerequisite/Installation order" I installed/compiled gdal with 
ecw, and installed postgres.


I then did a ./configure (without extra parameters) and tried to bumble 
my way through the errors I was getting.

I fired off my initial email to grass-dev as I was not finding the solution.

I then found the grass-wiki recipe and corrected the problems by 
copy/paste the ./configure for Ubuntu 20.04


So, a few thoughts from my side.

 * In the github install (all versions of grass), add a pointer to the
   grasswiki page, especially at the ./configure paragraph. (I would
   find it more reliable and easy to manage a link to one source of
   info, than to copy the source into contents of other documents)
 * Amend the configure script error message to suggest the that the
   with-XXX-includes= parameter should be used, instead of just:
   configure: error: *** Unable to locate FreeType includes.
 * As most apt installed products go to specific directories, is it
   possible to let the configure script not first try a few obvious
   places before crashing with the error message? If they are not 'apt
   installed', then they likely go to /usr/*local/*XXX

HTH, and thanks again for your persistence.
Regards,
Zoltan






On 2021/06/21 13:32, Markus Neteler wrote:

Hi Zoltan,

Where would you expect this info, i.e. a link to the wiki?
Maybe we can improve things :)

Best
Markus



Zoltan mailto:zolt...@geograph.co.za>> 
schrieb am Mo., 21. Juni 2021, 12:11:


Hi Markus/Māris,
Thanks for your interest.
@Māris:  I did provide the log tail-end on my first post.

@Markus: I started off the process using Google/Duck-Duck-Go to
piece together what info I needed, as I wanted ECW support and one
or two other add-ons.
Far too many websites offering help, come up.
I read through a couple but only later the Grasswiki you referred
to below - and then only noticing the with-XXX-includes folder
directives.

my bad :-(

Regards and keep well,
Zoltan


*On 2021-06-21 07:20, Maris Nartiss wrote:*

Please include relevant part of configure.log where exact reasons of
failure will be seen.

Māris.





*On 2021-06-20 18:42, Markus Neteler wrote:*

Hi Zoltan,

On Sat, Jun 19, 2021 at 12:36 PM Zoltan  
<mailto:zolt...@geograph.co.za>  wrote:

Hi Devs,
Sorted!

The correct folder(s) were:  
-with-postgres-includes=/usr/include/postgresql 
--with-freetype-includes=/usr/include/freetype2
(Had to add the freetype include folder as well)

Glad you solved it.
BTW, there is a wiki page with hints:
https://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu#Quick_instructions  
<https://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu#Quick_instructions>

Please feel free to improve it as needed.

Best
Markus


-- 


=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028 (Signal, not WhatsApp)
www.geograph.co.za  <http://www.geograph.co.za>
=



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


Re: [GRASS-dev] FIXED: Re: compiling GRASS-latest - configure fails with Unable to locate PostgreSQL includes

2021-06-21 Thread Zoltan

Hi Markus/Māris,
Thanks for your interest.
@Māris:  I did provide the log tail-end on my first post.

@Markus: I started off the process using Google/Duck-Duck-Go to piece 
together what info I needed, as I wanted ECW support and one or two 
other add-ons.

Far too many websites offering help, come up.
I read through a couple but only later the Grasswiki you referred to 
below - and then only noticing the with-XXX-includes folder directives.


my bad :-(

Regards and keep well,
Zoltan


*On 2021-06-21 07:20, Maris Nartiss wrote:*

Please include relevant part of configure.log where exact reasons of
failure will be seen.

Māris.





*On 2021-06-20 18:42, Markus Neteler wrote:*

Hi Zoltan,

On Sat, Jun 19, 2021 at 12:36 PM Zoltan  wrote:

Hi Devs,
Sorted!

The correct folder(s) were:  -with-postgres-includes=/usr/include/postgresql 
--with-freetype-includes=/usr/include/freetype2
(Had to add the freetype include folder as well)

Glad you solved it.
BTW, there is a wiki page with hints:
https://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu#Quick_instructions

Please feel free to improve it as needed.

Best
Markus


--

=
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028 (Signal, not WhatsApp)
www.geograph.co.za
=

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


[GRASS-dev] compiling GRASS-latest - configure fails with Unable to locate PostgreSQL includes

2021-06-19 Thread Zoltan

Hi,
I'm having trouble with:
./configure --enable-64bit --enable-largefile --with-libs=/usr/lib64 
--with-postgres=yes --with-odbc=yes --with-opencl=yes 
--with-gdal=/usr/local/bin/gdal-config -with-pdal=/usr/bin/pdal-config 
--with-postgres-includes=/home/zls/dev/postgresql-13.3/src/interfaces/libpq/

.
.
.
checking for png_read_image in -lpng... yes
checking whether to use PostgreSQL... yes
checking for location of PostgreSQL includes... 
/home/zls/dev/postgresql-13.3/src/interfaces/libpq/

checking for libpq-fe.h... no
*configure: error: *** Unable to locate PostgreSQL includes.*

I tried various folders and then downloaded/unzipped 
https://www.postgresql.org/ftp/source/v13.3/ *postgresql-13.3.tar.bz2*

into my dev folder - but still get the above 'includes' error.

I'm working on Ubuntu 20.04 and downloaded GRASS src as follows:

zls@ZolAW17ubuntu:~/dev$ git clone https://github.com/OSGeo/grass.git 
grass-latest_20210619.git

then cd grass-latest_20210619.git and ./configure (as above)

Thanks in advance,
Zoltan



--

=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028 (Signal, not WhatsApp)
www.geograph.co.za
=

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


[GRASS-dev] FIXED: Re: compiling GRASS-latest - configure fails with Unable to locate PostgreSQL includes

2021-06-19 Thread Zoltan

Hi Devs,
Sorted!

The correct folder(s) were:  
-with-postgres-includes=*/usr/include/postgresql* 
--with-freetype-includes=*/usr/include/freetype2*

(Had to add the freetype include folder as well)

Apologies for the 'noise'.

Regards,
Zoltan



On 2021/06/19 11:32, Zoltan wrote:

Hi,
I'm having trouble with:
./configure --enable-64bit --enable-largefile --with-libs=/usr/lib64 
--with-postgres=yes --with-odbc=yes --with-opencl=yes 
--with-gdal=/usr/local/bin/gdal-config -with-pdal=/usr/bin/pdal-config 
--with-postgres-includes=/home/zls/dev/postgresql-13.3/src/interfaces/libpq/

.
.
.
checking for png_read_image in -lpng... yes
checking whether to use PostgreSQL... yes
checking for location of PostgreSQL includes... 
/home/zls/dev/postgresql-13.3/src/interfaces/libpq/

checking for libpq-fe.h... no
*configure: error: *** Unable to locate PostgreSQL includes.*

I tried various folders and then downloaded/unzipped 
https://www.postgresql.org/ftp/source/v13.3/ *postgresql-13.3.tar.bz2*

into my dev folder - but still get the above 'includes' error.

I'm working on Ubuntu 20.04 and downloaded GRASS src as follows:

zls@ZolAW17ubuntu:~/dev$ git clone https://github.com/OSGeo/grass.git 
grass-latest_20210619.git

then cd grass-latest_20210619.git and ./configure (as above)

Thanks in advance,
Zoltan



--

=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028 (Signal, not WhatsApp)
www.geograph.co.za
=


--

=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028 (Signal, not WhatsApp)
www.geograph.co.za
=

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


Re: [GRASS-dev] [GRASS-user] compare a DCELL and FCELL question

2021-01-24 Thread Zoltan
No inconvenience - general list etiquette usually says start with 'user' 
and then move to 'dev' if it looks like a SW issue.

But I am NOT lecturing you, so please do not take offense.

Keep well,
Zoltan

On 2021-01-24 18:28, ming han wrote:
sorry for the inconvenience. I was just not sure if it is problem that 
needs developers to answer.

Best regards
Ming

Zoltan mailto:zolt...@geograph.co.za>> 
于2021年1月24日周日 上午11:13写道:


Hi,
Is it important to cross-post this discussion on both dev and user
    lists?

Regards,
Zoltan


On 2021-01-24 17:56, Markus Metz wrote:

Trying to answer the original question: with a DCELL map
"cat1_acc_riv" and a FCELL map "cat1_minacc", why is
"float(cat1_acc_riv) == float(cat1_minacc)" not equal to
"int(cat1_acc_riv) == int(cat1_minacc)" ?

int truncates to integer while float converts to single precision
floating point. E.g. with cat1_acc_riv = 1.1 and cat1_minacc =
1.9, "float(cat1_acc_riv) == float(cat1_minacc)" becomes "1.1 ==
1.9" whereas "int(cat1_acc_riv) == int(cat1_minacc)" becomes "1
== 1", thus the results are different.

Another reason for possible differences is that float can only
represent max 7 decimal digits. E.g. float(194320567) becomes
194320560 but int(194320567) preserves the value 194320567.

Thus the safest is to cast everything to the type with the
highest precision. In this case with FCELL and DCELL, use
"double(cat1_acc_riv) == double(cat1_minacc)" or even better the
suggestion of Markus N.

Markus M


On Sun, Jan 24, 2021 at 3:51 PM ming han mailto:dustm...@gmail.com>> wrote:
>
> Hi Markus and Micha
>
>      I am just trying to find grids have the same values in
these two rasters, I will try the threshold approach.
>
> Thanks
> Ming
>
> Markus Neteler mailto:nete...@osgeo.org>>
于2021年1月24日周日 上午6:58写道:
>>
>> Hi Ming,
>>
>> On Sun, Jan 24, 2021 at 10:49 AM ming han mailto:dustm...@gmail.com>> wrote:
>> >
>> > Hi Micha
>> >
>> >      Many thanks for your reply.
>> >      Here is the command I am using:
>> >
>> >      if(float(cat1_acc_riv) == float(cat1_minacc), str_r,
null())
>> >
>> >       The str_r is a CELL raster. the result is different
when I change it to:
>> >        if(int(cat1_acc_riv) == int(cat1_minacc), str_r, null())
>>
>> Note that numerical "equality" is better tested with a
threshold test
>> against the map pixel difference.
>> As the threshold, we use GRASS_EPSILON which is defined as
1.0e-15.
>>
>> Hence the test needs to be implemented in a different way, i.e. by
>> using an epsilon.
>> Essentially something like this:
>>
>> if(fabs(map_A - map_B) <= 1.0e-15, ... )
>>
>> In your case (untested):
>> r.mapcalc diffepsilon = if( abs( map_A - map_B) <= 1.0e-15,
str_r , null())
>>
>> See related discussions here: [1], [2] and elsewhere.
>>
>> [1] Comment by Glynn:
https://trac.osgeo.org/grass/ticket/2854#comment:9
<https://trac.osgeo.org/grass/ticket/2854#comment:9>
>> [2] Comment by Glynn:
>>
https://lists.osgeo.org/pipermail/grass-user/2015-October/073200.html
<https://lists.osgeo.org/pipermail/grass-user/2015-October/073200.html>
>>
>> Best,
>> Markus
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/grass-dev
<https://lists.osgeo.org/mailman/listinfo/grass-dev>

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


-- 


=
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

    Cape Town, South Africa.

Mobile: +27-83-6004028
www.geograph.co.za  <http://www.geograph.co.za>
=

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



--

=
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028
www.geograph.co.za
=

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


Re: [GRASS-dev] [GRASS-user] compare a DCELL and FCELL question

2021-01-24 Thread Zoltan

Hi,
Is it important to cross-post this discussion on both dev and user lists?

Regards,
Zoltan


On 2021-01-24 17:56, Markus Metz wrote:
Trying to answer the original question: with a DCELL map 
"cat1_acc_riv" and a FCELL map "cat1_minacc", why is 
"float(cat1_acc_riv) == float(cat1_minacc)" not equal to 
"int(cat1_acc_riv) == int(cat1_minacc)" ?


int truncates to integer while float converts to single precision 
floating point. E.g. with cat1_acc_riv = 1.1 and cat1_minacc = 1.9, 
"float(cat1_acc_riv) == float(cat1_minacc)" becomes "1.1 == 1.9" 
whereas "int(cat1_acc_riv) == int(cat1_minacc)" becomes "1 == 1", thus 
the results are different.


Another reason for possible differences is that float can only 
represent max 7 decimal digits. E.g. float(194320567) becomes 
194320560 but int(194320567) preserves the value 194320567.


Thus the safest is to cast everything to the type with the highest 
precision. In this case with FCELL and DCELL, use 
"double(cat1_acc_riv) == double(cat1_minacc)" or even better the 
suggestion of Markus N.


Markus M


On Sun, Jan 24, 2021 at 3:51 PM ming han <mailto:dustm...@gmail.com>> wrote:

>
> Hi Markus and Micha
>
>      I am just trying to find grids have the same values in these 
two rasters, I will try the threshold approach.

>
> Thanks
> Ming
>
> Markus Neteler mailto:nete...@osgeo.org>> 
于2021年1月24日周日 上午6:58写道:

>>
>> Hi Ming,
>>
>> On Sun, Jan 24, 2021 at 10:49 AM ming han <mailto:dustm...@gmail.com>> wrote:

>> >
>> > Hi Micha
>> >
>> >      Many thanks for your reply.
>> >      Here is the command I am using:
>> >
>> >      if(float(cat1_acc_riv) == float(cat1_minacc), str_r, null())
>> >
>> >       The str_r is a CELL raster. the result is different when I 
change it to:

>> >        if(int(cat1_acc_riv) == int(cat1_minacc), str_r, null())
>>
>> Note that numerical "equality" is better tested with a threshold test
>> against the map pixel difference.
>> As the threshold, we use GRASS_EPSILON which is defined as 1.0e-15.
>>
>> Hence the test needs to be implemented in a different way, i.e. by
>> using an epsilon.
>> Essentially something like this:
>>
>> if(fabs(map_A - map_B) <= 1.0e-15, ... )
>>
>> In your case (untested):
>> r.mapcalc diffepsilon = if( abs( map_A - map_B) <= 1.0e-15, str_r , 
null())

>>
>> See related discussions here: [1], [2] and elsewhere.
>>
>> [1] Comment by Glynn: 
https://trac.osgeo.org/grass/ticket/2854#comment:9 
<https://trac.osgeo.org/grass/ticket/2854#comment:9>

>> [2] Comment by Glynn:
>> 
https://lists.osgeo.org/pipermail/grass-user/2015-October/073200.html 
<https://lists.osgeo.org/pipermail/grass-user/2015-October/073200.html>

>>
>> Best,
>> Markus
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/grass-dev 
<https://lists.osgeo.org/mailman/listinfo/grass-dev>


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


--

=
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

Cape Town, South Africa.

Mobile: +27-83-6004028
www.geograph.co.za
=

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


Re: [GRASS-dev] Should we use GitHub Discussions?

2021-01-21 Thread Zoltan

Hi,
Whatever platform we keep or migrate to, please just remember the 
unknown number of GRASS-interested people out there, like myself, who 
will not make the time to regularly login to a website to see if there 
happens to be anything interesting.
Likewise as bad as having to login "to see" , is to have to click a link 
from a push email, get redirected and maybe still have to login,  and 
then only see that the message was uninteresting to the person (me).


Weekly (periodic) digests that are 'pushed' lack the "now" factor so 
minimise one's ability to get involved.


I hope you all find and agree a solution that also caters for 
mailing-list style correspondence.


Regards and thanks for discussing this before "just changing things".
Zoltan

On 2021-01-21 09:48, massimo di stefano wrote:

‘’’
 I think emails (and mailing lists) are awesome, but mailing lists are 
increasingly seen as archaic and not accessible

‘’’

What about migrating our mailing list to mailman3?
The postorius interface looks modern and when integrated with hyper 
kitty, allows an easy access to the list archives (including search 
and post statistics).



My 2cents.


Il giorno gio 21 gen 2021 alle 4:32 AM Vaclav Petras 
mailto:wenzesl...@gmail.com>> ha scritto:


Let me finally write some arguments for GitHub Discussions.

First of all, I think it is a tradeoff, so I agree that the issues
here are valid, at least to a point. My question now is if it is
worth enabling GitHub Discussions anyway.

As I mentioned earlier, people are asking for a web-based solution
(see e.g. post from November on grass-user [1]). I think emails
(and mailing lists) are awesome, but mailing lists are
increasingly seen as archaic and not accessible. Nabble does not
seem to cut it and it was even demoted on the mailing list for its
link instability (which I think is a concern). It seems that if
the Nabble situation would be fixable, it would be fixed already.
Signup to receive all emails for a specific mailing list before
posting a question is a big commitment, especially when people are
using multiple software packages or are just trying out GRASS GIS.
Is it clear to everybody they need to sign up before posting
anyway? When you are already committed to GRASS GIS, they might
not show stoppers, but when you are not, they certainly can be.
Conclusion: If we want even the uncommitted users to ask
questions, we need something which feels light, you already have
an account there, and it does not require you to manage email
filtering.

There are already web-based forums, namely GIS StackExchange and
StackOverflow proper where GRASS-related questions are being
asked. This demonstrates the interest in the web-based Q&A
platform, however when you look at the posts there, you see that
it does not work that great. First, many of the original posts and
consequently answers are actually not a good fit for that kind of
platform - often a back and forth discussion is required. And
perhaps more importantly, there are only a few GRASS power users
answering there compared to mailing lists and comparing to how
many people from the GRASS community have an account on GitHub.
Conclusion: Even if we don't direct users to a platform and
support that platform, people will use it anyway resulting in harm
as questions are not properly answered.

GitHub Discussions is a good web-based forum for three reasons, 1)
GitHub is a platform we are already committed to, 2) devs,
core+addon contributors, and bug-reporting users all have an
account there, 3) a lot of potential users already have account
there. The last point is especially interesting because not only
that a lot of code-aware GIS users or scientists have an account
there, but a lot of developers have an account there and we are
very very interested in attracting developers.
Developers/programmers need to combine multiple projects to create
whatever they are creating. Asking them to subscribe to a mailing
list in order to ask a question is exactly the reason why they
will try their luck with another project. Conclusion: To attract
more users, especially those who are developers, a GitHub-related
service, such as GitHub Discussions, is needed and we are already
on GitHub.

As I mentioned in the initial post, I don't think enabling GitHub
Discussions means closing mailing lists. I think it is important
we have there is an option to ask a question, or even report a
problem, without signing up for a proprietary third party service
(it is bad enough we more or less require that for contributions).
However, as there are people who see GitHub Terms and Conditions
or a web interface as a barrier to post a question, there are
people who see mailing

Re: [GRASS-dev] Should we use GitHub Discussions?

2021-01-17 Thread Zoltan

Hi List,
My 2 cents would be to stay with mailing list only.
GRASS is not my focus, but I keep a keen interest on what is happening 
because I do use it when I have project.


For me the benefit is that a ML keeps me _reactive_ - I can quickly 
parse the email and decide whether to file it or delete it.

Discussion/Bulletin boards and forums force the user to be _proactive_.
I for one would not log into the forum until I need something - that 
means that for many months I would loose track of GRASS progress and 
direction.


Forums are also a pain to search. I am (right now) on the zoneminder 
forum trying to find a solution to 2 problems I have.
I have spent over an hour trying to find a discussion close enough to 
match my problem (so as not to do a lazy new post), and I have just now 
created a new post on zoneminder.


The traffic on grass-dev and grass -user is fairly low - I would even 
merge the two - especially as you, the devs, answer on the grass-user ML 
anyway!


But I am happy watching 2 GRASS MLs.

Please consider _not_ moving to a forum style platform.

Thanks and regards,
Zoltan

On 2021-01-17 16:27, Stefan Blumentrath wrote:

Dear all,

In general, I do agree with Moritz on this.

In addition to the risk of more fragmented communication, I do appreciate the 
fact that ML-discussion is archived. Furthermore, GitHub discussion seems to be 
a feature that locks us more into GitHub and would it make more complicated if 
we should be forced to move to another platform (given the proprietary nature 
of GitHub).

I do also see that some discussion has moved to github issues/PRs, but that is 
probably only natural, esp. when point of the discussion is specifics of an 
implementation / change.

However, to address both valid issues (demand for web-based forum and a 
coherent communication), we could probably to three things:
1. Encourage all contributors to discuss/mention more significant changes on 
the ML.
2. Promote nabble [http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html] 
on our github repository
3. Check whether it would be feasible to sign up to nabble / ML with 
OAuth/github to make integration more seamless. I have no idea though if this 
would be feasible at all. Maybe OSGeo admins know?...

Cheers
Stefan



-Original Message-
From: grass-dev  On Behalf Of Moritz Lennert
Sent: søndag 17. januar 2021 13:51
To: grass-dev@lists.osgeo.org; Vaclav Petras ; 
grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] Should we use GitHub Discussions?



Am 17. Januar 2021 06:31:22 MEZ schrieb Vaclav Petras :

Dear all,

What about enabling GitHub Discussions [1] on grass repo? Enabling is
easy [2], so the question really is, do we want them? They are for open
ended discussions, questions, etc. Right, like mailing list, but on
GitHub. We do get asked periodically for a web-based (as opposed to
email-based) forum which is what GitHub Discussions can fulfill. I'm
not saying we should abandon the mailing list, but GitHub Discussions
may be easier for some users, so it would open another avenue for
people to ask or get engaged on a platform we are already using anyway.

I have never used GitHub discussions, so I have no opinion as such on its 
usefulness for us.

I do have a more fundamental issue, however: ever since we've moved to GitHub, 
discussions about important feature decisions seem to me to be more and more dispersed 
across PRs and less centrally visible. Currently, there are discussions about starting 
GRASS GIS by default without a terminal window [1], how to handle GUI startup when the 
last used mapset is not available, whether GRASS GIS can be considered as an 
"app" and if yes, whether this should be reflected in the name of the startup 
script [3], and probably others I forgot or that I am not aware of.

All of these are interesting discussions with solid points made, but I have the 
feeling that they are really confidential, involving only a very limited number 
of developers because others do not think that they the PR as such is relevant 
to them, and so they miss the fact that there are discussions going on that 
will have an impact on how GRASS GIS runs and/or is perceived.

If we create yet another forum I'm afraid that things will get even worse.

Maybe this is just a sign that our community is growing so rapidly and activity 
has increased so much that no one can follow every important discussion, but I 
do think this is also linked to the multiplication of tools used. Maybe it's 
also due to my bad personal organization if the information flows.

I would be happy to hear other opinions about this (and possibly some best 
practices on how others handle this problem). Depending on the answers to this, 
I think we might have to have a fundamental discussion on development decision 
making that ensures a somewhat larger group, while not stifling the enthousiasm 
behind the different initiatives and proposal

Re: [GRASS-dev] minor tweak to new website

2021-01-15 Thread Zoltan
Agreed, 'preview' is better.
Regards,
Zoltan

⁣Sent from BlueMail ​

On 16 Jan 2021, 02:17, at 02:17, Markus Neteler  wrote:
>On Fri, Jan 15, 2021 at 10:12 PM Michael Barton
> wrote:
>>
>> You are correct about the redundancy. I was trying to make the change
>as minor as possible. A somewhat better listing would be
>>
>> GRASS GIS 7.8.5 (current stable)
>>
>> GRASS GIS 7.6.1 (legacy) [change from “old”]
>>
>> GRASS GIS 7.9 (preview) [“development” is OK, but “preview” sounds
>more inviting for use]
>
>I like the new wording.
>
>Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] minor tweak to new website

2021-01-15 Thread Zoltan
Hi,
If I may:

Devel (development)  has wording redundancy.
What about7.9 snapshot (under development)

Regards from a lurker that admires the effort you guys put in.
Zoltan

⁣Sent from BlueMail ​

On 15 Jan 2021, 21:21, at 21:21, Helena Mitasova  wrote:
>I agree with Michael’s suggestion too, Helena
>
>> On Jan 15, 2021, at 2:10 PM, Paulo van Breugel
> wrote:
>>
>>
>>
>> On Fri, Jan 15, 2021 at 5:49 PM Michael Barton
> wrote:
>> On the new download pages, I just noticed that the dev versions are
>referenced like this:
>>
>>
>>
>> GRASS GIS 7.9 devel (unstable)
>>
>>
>>
>> This implies that GRASS 7.9 is risky and perhaps minimally useable.
>The reality is that it works very well but has some new features that
>might be buggy or might change. While we want to indicate these
>differences from the current stable version, we don’t want to
>discourage people from trying it (and reporting any issues).
>>
>>
>>
>> I suggest that we reference it as
>>
>>
>>
>> GRASS GIS 7.9 devel (development)
>>
>>
>>
>> Or
>>
>>
>>
>> GRASS GIS 7.9 devel (preview)
>>
>>
>>
>>
>> +1 good point, it indeed works well, and is in my experience more
>stable than many other software tools I use(d).
>>
>>
>>
>>
>> Michael
>>
>> __
>>
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Director, Network for Computational Modeling in Social & Ecological
>Sciences
>> Associate Director, School of Complex Adaptive Systems
>> Professor, School of Human Evolution & Social Change
>> Arizona State University
>> Tempe, AZ  85287-2402
>> USA
>>
>> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>> fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
>> www: http://shesc.asu.edu,
>>
>> https://complexity.asu.edu,
>>
>> http://www.public.asu.edu/~cmbarton
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>Helena Mitasova
>Professor at the Department of Marine,
>Earth, and Atmospheric Sciences
>Associate director and faculty fellow at the Center for Geospatial
>Analytics
>North Carolina State University
>Raleigh, NC 27695-8208
>hmit...@ncsu.edu
>
>"All electronic mail messages in connection with State business which
>are sent to or received by this account are subject to the NC Public
>Records Law and may be disclosed to third parties.”
>
>___
>grass-dev mailing list
>grass-dev@lists.osgeo.org
>https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


[GRASS-dev] No module named grass.script

2020-02-09 Thread Zoltan Szecsei

Hi,
I've just installed OSGEO4W64
Grass 7.8.2 works (alone), as does Grass functionality through QGIS 
3.10.2 (with Grass 7.8.2).


I am now trying to put together a python 3.7 script using PyCharm 
2019.3.3 Community edition.

I start PyCharm using the cmd script below.

My python script fails (in the Pycharm IDE) on import grass.script as 
gscript.


I have set GISBASE, GRASSBIN and PATH in the windows env setup.
Please can someone point me in the correct direction to be able to write 
python scripts using grass modules, in pycharm.


Thanks and regards,
Zoltan.



My pycharm startup script is:
@echo off
SET OSGEO4W_ROOT=C:\OSGeo4W64
call "%OSGEO4W_ROOT%"\bin\o4w_env.bat
call "%OSGEO4W_ROOT%"\apps\grass\grass78\etc\env.bat
@echo off
path %PATH%;%OSGEO4W_ROOT%\apps\qgis\bin
path %PATH%;%OSGEO4W_ROOT%\apps\grass\grass78\lib
path %PATH%;%OSGEO4W_ROOT%\apps\Qt5\bin
path %PATH%;%OSGEO4W_ROOT%\apps\Python37\Scripts

set PYTHONPATH=%PYTHONPATH%;%OSGEO4W_ROOT%\apps\qgis\python
set 
PYTHONPATH=%PYTHONPATH%;%OSGEO4W_ROOT%\apps\grass\grass78\etc\python\grass

SET PYTHONHOME=%OSGEO4W_ROOT%\apps\Python37
SET PYTHONPATH=%PYTHONHOME%;%PYTHONHOME%\Scripts
PATH %PYTHONPATH%;%PATH%

set PATH=C:\Program Files\Git\bin;%PATH%

start "PyCharm aware of Quantum GIS" /B "C:\Program 
Files\JetBrains\PyCharm Community Edition 2019.2\bin\pycharm64.exe"



--

=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

P.O. Box 7, Muizenberg 7950, South Africa.

Mobile: +27-83-6004028 (WhatsApp only)
Qatar:  +974 5083 2722 www.geograph.co.za
=

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

Re: [GRASS-dev] [GRASS GIS] #3981: winGRASS: defining a new location by EPSG code: TypeError: invalid result from TransList.OnMeasureItem(), an integer is required (got type NoneType)

2019-12-03 Thread Zoltan Szecsei

Hi,
I think I am banging my head on this error #3981
I posted my problem to grass-user, but no response.
Is there a possible workaround for me?

Thanks,
Zoltan.

On 2019/12/02 11:49, Zoltan Szecsei wrote:

Hi,
I'm using EPSG 2932 and QGIS etc all are OK with it.

I have installed everything using OSGeo4W64, so how come Grass does 
not use the same projections database (as QGis etc)?
(and please can I have a pointer as to how to introduce EPSG 2932 to 
Grass 7.8.1)


Thanks and regards,
Zoltan

 Running against: 
D:\GDBroad_tiles\shp_road_poly_few\23103770_road_poly.shp
WARNING: Datum  not recognised by GRASS and 
no parameters found

Check if OGR layer <23103770_road_poly> contains polygons...
Creating attribute table for layer <23103770_road_poly>...
WARNING: Name <23103770_road_poly> is not SQL compliant. Must start 
with a letter.

Importing 28 features (OGR layer <23103770_road_poly>)...



On 2019/12/03 17:31, GRASS GIS wrote:

#3981: winGRASS: defining a new location by EPSG code: TypeError: invalid result
from TransList.OnMeasureItem(), an integer is required (got type NoneType)
-+---
   Reporter:  hellik  |  Owner:  grass-dev@…
   Type:  defect  | Status:  new
   Priority:  normal  |  Milestone:  7.8.2
  Component:  wxGUI   |Version:  git-releasebranch78
Resolution:  |   Keywords:  wingrass, py3, python3, proj6
CPU:  x86-64  |   Platform:  MSWindows
-+---

Comment (by annakrat):

  https://github.com/OSGeo/grass/pull/233


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


--

=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

P.O. Box 7, Muizenberg 7950, South Africa.

Mobile: +27-83-6004028 (WhatsApp only)
Qatar:  +974 5083 2722 www.geograph.co.za
=

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

Re: [GRASS-dev] PyCharm 2019 with Grass 7.8.1

2019-11-27 Thread Zoltan Szecsei

HI,
Thanks for this.
On a point of "note", don't you also wonder why people buy PCs with 
slower CPU's _but more processing cores_, and then run everything 
single-threaded :-)


I do spatial data capture projects so am always scripting in different 
environments and languages - so I write in a way that I can run many 
(10+) scripts on 1 PC, and them still spread that across sometimes even 
10 PCs.


(Nice to see that you are also 'production aware')

Cheers for now,
Zoltan

On 2019/11/27 12:32, Maris Nartiss wrote:

I have been dealing with similar large file count issue by splitting
processing into two parts — processing script for a single file
launched with "grass --exec python my_processing_script
params_for_script" — no need for setting up session in advance etc.;
launcher script starting multiple processing scripts in parallel (one
file = one mapset).
Afterwards it is easy to modify launcher script to be started by srun
or sbatch and migrate to more than one PC, when your tasks outgrows
single system resources.

Good luck,
Māris.

otrd., 2019. g. 26. nov., plkst. 15:04 — lietotājs Stefan Blumentrath
() rakstīja:

Hi Zoltan,

did you try https://github.com/zarch/grass-session
That should simplify running GRASS algorithms using GRASS more as a library.

Cheers
Stefan
____
Fra: grass-dev  på vegne av Zoltan Szecsei 

Sendt: tirsdag 26. november 2019 13:34
Til: grass-dev@lists.osgeo.org 
Emne: [GRASS-dev] PyCharm 2019 with Grass 7.8.1

Hi,
I've just installed QGIS/GRASS etc with Osgeo4w64, but am struggling to
find out how to set up PyCharm to do some grasspy scripting with.
(import grass.scripting as gscript fails - I have set GISBASE, GRASSBIN
and PATH to various C:\OSGeo4W64\apps\grass\grass78 folders)

I need to run r.thin over 2800 tif images, so figured a python loop
should do it.

Any pointers would be welcome.

Thanks and regards,
Zoltan

--

=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

P.O. Box 7, Muizenberg 7950, South Africa.

Mobile: +27-83-6004028 (WhatsApp only)
Qatar:  +974 5083 2722 www.geograph.co.za
=

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


--

=====
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

P.O. Box 7, Muizenberg 7950, South Africa.

Mobile: +27-83-6004028 (WhatsApp only)
Qatar:  +974 5083 2722 www.geograph.co.za
=

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

[GRASS-dev] PyCharm 2019 with Grass 7.8.1

2019-11-26 Thread Zoltan Szecsei

Hi,
I've just installed QGIS/GRASS etc with Osgeo4w64, but am struggling to 
find out how to set up PyCharm to do some grasspy scripting with.
(import grass.scripting as gscript fails - I have set GISBASE, GRASSBIN 
and PATH to various C:\OSGeo4W64\apps\grass\grass78 folders)


I need to run r.thin over 2800 tif images, so figured a python loop 
should do it.


Any pointers would be welcome.

Thanks and regards,
Zoltan

--

=
Zoltan Szecsei GPrGISc 0031
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

P.O. Box 7, Muizenberg 7950, South Africa.

Mobile: +27-83-6004028 (WhatsApp only)
Qatar:  +974 5083 2722 www.geograph.co.za
=

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