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

[Anna Petrášová via grass-user]

There is GRASS_PYTHON variable you can try. Running GRASS in virtual
environment should work too.

On Thu, Mar 21, 2024 at 2:39 AM Hernán De Angelis via grass-user <
grass-user@lists.osgeo.org> wrote:

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

Re: [GRASS-user] [GRASS-dev] Can GRASS import a *.ige file?

[Anna Petrášová via grass-user]

There should be an .img file, try open that instead.

On Fri, Mar 1, 2024 at 4:51 PM Michael Barton via grass-dev <
grass-...@lists.osgeo.org> wrote:

> It doesn't look like r.in.gdal does this. Is there an extension or other
> way to import an ERDAS *.ige file?
>
> Michael
> _
>
> C. Michael Barton
> Associate Director, School of Complex Adaptive Systems (
> https://scas.asu.edu)
> Professor, School of Human Evolution & Social Change (
> https://shesc.asu.edu)
> Director, Center for Social Dynamics & Complexity (
> https://complexity.asu.edu)
> Arizona State University
> Tempe, AZ 85287-2701
> USA
>
> Executive Director, Open Modeling Foundation (
> https://openmodelingfoundation.github.io)
> Director, Network for Computational Modeling in Social & Ecological
> Sciences (https://comses.net)
>
> personal website: http://www.public.asu.edu/~cmbarton
>
>
> ___
> 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

Re: [GRASS-user] GRASS annual report 2023

[Anna Petrášová via grass-user]

Thanks for the input, the news item is now live:

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

On Thu, Dec 21, 2023 at 12:04 AM Anna Petrášová 
wrote:

> Dear all,
>
> We are preparing a report on all GRASS-related achievements in the year
> 2023 and we would like your input! For example, if you presented at a
> conference about GRASS, we would like to hear about this and include it.
> The report will be posted as a news item on grass.osgeo.org. See the
> current state of the report in this PR:
>
> https://github.com/OSGeo/grass-website/pull/405
>
> Feel free to comment on the PR directly and I will incorporate your
> suggestions there.
>
> Thank you for your input!
> Anna
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] re-setting bathymetry data using the raster calculator.

[Anna Petrášová via grass-user]

On Thu, Dec 21, 2023 at 4:45 AM Victor Lundström 
wrote:

> Hi Anna, thank you for responding!
>
> No I haven't tried running r.walk using negative values, I guess I could
> give it a try. But, if I remember correctly, didn't Michael Barton inquired
> about the use of negative values and r.walk previously. I can't remember
> the outcome of that discussion, and I don't seem to have kept the emails
> unfortunately. I'll give the negative values a try, if it works, then that
> will at least be less distorted as opposed to removing negative values by
> addition.
>

He was testing negative values in a friction map, but that's a different
case. Negative values in elevation (that's your case, right?) should not
matter I would hope.

>
> /Victor
>
> Skickat från Outlook för iOS <https://aka.ms/o0ukef>
> --
> *Från:* Anna Petrášová 
> *Skickat:* Thursday, December 21, 2023 5:18:03 AM
> *Till:* Victor Lundström 
> *Kopia:* grass-user@lists.osgeo.org 
> *Ämne:* Re: [GRASS-user] re-setting bathymetry data using the raster
> calculator.
>
> Hi Victor,
>
> I am not sure I understand your concern. Have you tried running r.walk
> with the original raster with negative values? Theoretically, I don't see
> why r.walk couldn't work with negative elevation, although I haven't tried
> it. It should work the same if you add a constant value as you suggest.
> Perhaps you want to e.g. use an absolute value of the elevation?
>
> Anna
>
> On Wed, Dec 20, 2023 at 5:59 PM Victor Lundström via grass-user <
> grass-user@lists.osgeo.org> wrote:
>
> Hi everyone,
>
> I've run in to a problem that I hope to get some help with.
> I'm preparing a set of rasters to perform species distribution modelling.
> For one
> of my predictors, I have chosen to use r.walk in order to record how far
> away my occurrence
> records are to the nearest shoreline. Here's the catch though.. I will be
> generating my walk-distance
> rasters by using the GEBCO bathymetry data set. Here in lies the problem.
> Seeing as it is bathymetry, my raster will have negative values. My initial
> thought was simply to run the bathymetry raster through r.mapcalc in this
> way:
>
> r.mapcalc "expression=prehist_dem = bathymetry + 866"
>
> In this example, "866" references the lowest depth recorded (i.e. -866m).
> Using the expression above, I have
> now removed any negative value in the raster so that min = 0. However,
> while doing this I have now also added
> "866" to every other cell in the raster, and not only will this be
> incorrect for places inland where a cell that originally
> was 5 m.a.s.l. now is 871m, but it will probably affect the cells close to
> the sea in the same way (which in most cases should probalby be close to,
> or slightly above, 0m). More importantly, if I would just stick to this
> approach, I can't help but imagine that it won't produce inaccurate results
> for r.walk further down the line as well.
>
> I can't help but think that there is some clever work-around to this using
> the mapcalculator, but I'm simply stuck
> and don't know how to proceed. Hope any of you can provide some advice!
>
> Best,
> Victor
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>
> [External email] Make sure you recognize the sender's email address
> before you click links, open attachments, or get involved in financial
> transactions. Contact IT-support BRITA if you have any questions.
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] GRASS annual report 2023

[Anna Petrášová via grass-user]

Dear all,

We are preparing a report on all GRASS-related achievements in the year
2023 and we would like your input! For example, if you presented at a
conference about GRASS, we would like to hear about this and include it.
The report will be posted as a news item on grass.osgeo.org. See the
current state of the report in this PR:

https://github.com/OSGeo/grass-website/pull/405

Feel free to comment on the PR directly and I will incorporate your
suggestions there.

Thank you for your input!
Anna
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] re-setting bathymetry data using the raster calculator.

[Anna Petrášová via grass-user]

Hi Victor,

I am not sure I understand your concern. Have you tried running r.walk with
the original raster with negative values? Theoretically, I don't see why
r.walk couldn't work with negative elevation, although I haven't tried it.
It should work the same if you add a constant value as you suggest. Perhaps
you want to e.g. use an absolute value of the elevation?

Anna

On Wed, Dec 20, 2023 at 5:59 PM Victor Lundström via grass-user <
grass-user@lists.osgeo.org> wrote:

> Hi everyone,
>
> I've run in to a problem that I hope to get some help with.
> I'm preparing a set of rasters to perform species distribution modelling.
> For one
> of my predictors, I have chosen to use r.walk in order to record how far
> away my occurrence
> records are to the nearest shoreline. Here's the catch though.. I will be
> generating my walk-distance
> rasters by using the GEBCO bathymetry data set. Here in lies the problem.
> Seeing as it is bathymetry, my raster will have negative values. My initial
> thought was simply to run the bathymetry raster through r.mapcalc in this
> way:
>
> r.mapcalc "expression=prehist_dem = bathymetry + 866"
>
> In this example, "866" references the lowest depth recorded (i.e. -866m).
> Using the expression above, I have
> now removed any negative value in the raster so that min = 0. However,
> while doing this I have now also added
> "866" to every other cell in the raster, and not only will this be
> incorrect for places inland where a cell that originally
> was 5 m.a.s.l. now is 871m, but it will probably affect the cells close to
> the sea in the same way (which in most cases should probalby be close to,
> or slightly above, 0m). More importantly, if I would just stick to this
> approach, I can't help but imagine that it won't produce inaccurate results
> for r.walk further down the line as well.
>
> I can't help but think that there is some clever work-around to this using
> the mapcalculator, but I'm simply stuck
> and don't know how to proceed. Hope any of you can provide some advice!
>
> Best,
> Victor
>
>
> ___
> 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] NSF POSE project progress report

[Anna Petrášová via grass-user]

Dear all,

In September we announced a new grant [1] that was awarded to enhance GRASS
GIS ecosystem. We would like to share a progress report for 1st quarter [2]
with the community to highlight the efforts that span various repositories
and include participation in several events. The report also includes the
project roadmap.

Best,
Anna for the POSE team (Helena, Vaclav, Anna, Huidae, Michael, Giuseppe)

[1] https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/
[2] https://grasswiki.osgeo.org/wiki/NSF_POSE_Project_2023-2025_Timeline
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] cost surface with negative friction odd behavior

[Anna Petrášová via grass-user]

Michael, could you please create a PR for the documentation?

On Wed, Nov 29, 2023 at 3:56 PM Michael Barton via grass-user <
grass-user@lists.osgeo.org> wrote:

> Thanks Anna and Doug,
>
> I did not expect it to work (thought it would be useful if it did). Rather
> I was surprised by the fact that r.walk DID run and that it gave very odd
> results.
>
> Adding to the docs is a good idea. Even better would also to have a
> friction map with a negative value (min<0) raise an error in r.walk, saying
> that all values in a friction map must be ≥ 0
>
> Michael
> _
>
> C. Michael Barton
> Associate Director, School of Complex Adaptive Systems (
> https://scas.asu.edu)
> Professor, School of Human Evolution & Social Change (
> https://shesc.asu.edu)
> Director, Center for Social Dynamics & Complexity (
> https://complexity.asu.edu)
> Arizona State University
> Tempe, AZ 85287-2701
> USA
>
> Executive Director, Open Modeling Foundation (
> https://openmodelingfoundation.github.io)
> Director, Network for Computational Modeling in Social & Ecological
> Sciences (https://comses.net)
>
> personal website: http://www.public.asu.edu/~cmbarton
>
>
> On Nov 29, 2023, at 1:00 PM, grass-user-requ...@lists.osgeo.org wrote:
>
> Date: Wed, 29 Nov 2023 10:17:19 -0500
> From: Anna Petr??ov? 
> To: Michael Barton 
> Cc: GRASS developers , GRASS user list
> 
> Subject: Re: [GRASS-user] cost surface with negative friction odd
> behavior
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> I think r.walk was not written for negative friction and while I imagine
> some small (in absolute sense) negative values may work, your negative
> values are pretty extreme, meaning the resulting travel time through a cell
> would be negative. That can cause all kinds of issues in the algorithm. So
> I would say friction should not be negative. I am not sure I would check
> that in the code, because you would need to check that for each cell and I
> think it's unnecessary overhead. Maybe just adding a note to documentation
> may be enough. I haven't looked into the code itself, so this is just my
> guess.
>
> Anna
>
> On Tue, Nov 28, 2023 at 5:48?PM Michael Barton via grass-user <
> grass-user@lists.osgeo.org> wrote:
>
>
> ___
> 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] cost surface with negative friction odd behavior

[Anna Petrášová via grass-user]

I think r.walk was not written for negative friction and while I imagine
some small (in absolute sense) negative values may work, your negative
values are pretty extreme, meaning the resulting travel time through a cell
would be negative. That can cause all kinds of issues in the algorithm. So
I would say friction should not be negative. I am not sure I would check
that in the code, because you would need to check that for each cell and I
think it's unnecessary overhead. Maybe just adding a note to documentation
may be enough. I haven't looked into the code itself, so this is just my
guess.

Anna

On Tue, Nov 28, 2023 at 5:48 PM Michael Barton via grass-user <
grass-user@lists.osgeo.org> wrote:

> In teaching a class about modeling movement, we talked about how to
> represent a cost surface when some areas of terrain (e.g., water or paved
> roads), could be crossed more rapidly than walking across unmodified
> topography. Since a friction map for r.walk adds cost in seconds/meter to
> the cost of walking across unmodified terrain, I wondered if a friction map
> with **negative costs** would decrease the movement costs across a
> landscape.
>
> Using the SC demo data set, I tried this with a set of maps I prepared for
> class. Previously, I had created a friction map from the landclass96 map
> such that cells with water (class 20) have a value of 90 sec/m, dense
> vegetation (classes 7-19) have a value of 20 sec/m, and the rest of the
> cells have a value of 0 sec/m. I generated a cost surface with r.walk using
> elevation and this friction map with a starting point from the Dorothea Dix
> Hospital.
>
> r.walk --overwrite -k elevation=elevation@PERMANENT
> friction=landclass96_friction output=dd_hospital_seconds_friction
> outdir=dd_hospital_directions_friction start_points=DD_hospital memory=1000
>
> This behaved as expected and created a cost surface that represented
> different degrees of difficulty in crossing vegetated and inundated
> terrain.
>
> To explore what would happen with a friction surface with negative
> numbers, I simply subtracted the previous friction map from 0 so that dense
> vegetation = -20, water = -90, and the rest of the cells = 0. Then I used
> it with r.walk and the elevation DEM.
>
> r.walk -k elevation=elevation@PERMANENT
> friction=landclass96_friction_negative
> output=dd_hospital_seconds_negativefriction
> outdir=dd_hospital_directions_negativefriction start_points=DD_hospital
> memory=2000
>
> There was no error, but the resulting cost surface is very strange.
>
> The data range of the original cost surface with the positive values
> friction map is:
>
> Range of data:min = 0  max = 103883.003593944 (max of 28.8 hours to
> reach the hospital given added costs of walking through dense vegetation or
> avoiding water).
>
> However, the data range of the cost surface made with the friction map
> with negative values is completely weird.
>
> Range of data:min = -166202271.811971  max = -154320.938078961 (-46167
> to -43 hours)
>
> Since a friction map simply adds cost to the cost surface, if a negative
> friction map did not work, I might expect it to raise an error or have no
> impact (values < 0 become 0). But the values in the resulting cost surface
> don't make any sense at all.
>
> Does anyone have any thoughts on this?
>
> I will try to attach attach the original friction map made from the SC
> landclass96 map, the cost surface made with elevation and friction map, and
> cost surface made with elevation and negative friction map.
>
> Michael
>
> _
>
> C. Michael Barton
> Associate Director, School of Complex Adaptive Systems (
> https://scas.asu.edu)
> Professor, School of Human Evolution & Social Change (
> https://shesc.asu.edu)
> Director, Center for Social Dynamics & Complexity (
> https://complexity.asu.edu)
> Arizona State University
> Tempe, AZ 85287-2701
> USA
>
> Executive Director, Open Modeling Foundation (
> https://openmodelingfoundation.github.io)
> Director, Network for Computational Modeling in Social & Ecological
> Sciences (https://comses.net)
>
> personal website: http://www.public.asu.edu/~cmbarton
>
>
> ___
> 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] Student grants

[Anna Petrášová via grass-user]

Dear all,

We would like to announce a paid opportunity for students to contribute to
GRASS GIS! GRASS GIS will offer a number of student grants for projects
that include development of GRASS documentation, tests, new features or
geospatial tools and bug fixing.  Check the wiki for details on how to
apply and suggested topics:

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

Deadline is the end of the year.

Many of you work in research and academia, so please share this opportunity
in your circles!

If you would like to mentor or co-mentor a new topic or one listed on the
wiki, let me know.

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

[GRASS-user] GRASS GIS Mentoring Program

[Anna Petrášová via grass-user]

Dear all,

I would like to bring to your attention a newly started
development-oriented mentoring program focused on students, researchers,
and software developers who want to integrate GRASS GIS into their
projects. See the announcement with details and application form on GRASS
website:

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

Let me know if you have any questions about applying to the program and
please share this announcement in your circles.

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

Re: [GRASS-user] GRASS Working Groups

[Anna Petrášová via grass-user]

Thanks to everyone who responded! I will keep the survey [1] open until the
end of the week. Alternatively, just let me know directly if you want to
join.

Based on the responses I created wiki pages for the different working
groups [2] and added the respondents to the particular group. I assigned a
group coordinator to each group to get us started. For those of you who
already have access to the wiki, please add what kind of issues you are
interested in within the working group. If you don't have a GRASS wiki
account, you can either try to create it or ask me or the other group
coordinators to fill those details for you. There may be some changes in
the wiki authentication now [3], so I am unsure whether signing up at this
point is feasible or not.

The coordinators (me, Vashek, Helena) will reach out to the members of each
group to discuss preferred communication channels. We would like to use the
current development platform as much as possible so it would be helpful for
you to have a GitHub account.

Thanks again,
Anna


[1] https://forms.gle/BXzooNYBjgkjMmYk9
[2] https://grasswiki.osgeo.org/wiki/Working_Groups
[3] https://lists.osgeo.org/pipermail/grass-dev/2023-October/096070.html


On Tue, Oct 3, 2023 at 11:23 PM Anna Petrášová 
wrote:

> Dear all,
>
> We would like to establish working groups to better coordinate the GRASS
> community activities such as software development, documentation, promotion
> and fostering relations with other communities. If you are interested in
> any of these topics or are already involved in these activities, please
> consider joining the particular working group. Joining a working group is
> also a great way for you to provide feedback on various issues, plug into
> the community and contribute your expertise.
>
> See the form for the proposed working groups and consider signing up:
>
> https://forms.gle/BXzooNYBjgkjMmYk9
>
> There is also a place in the form for your feedback. Once we get your
> responses I will be back with more details to get the working groups
> started.
>
> Thank you,
> Anna
>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] GRASS Working Groups

[Anna Petrášová via grass-user]

Dear all,

We would like to establish working groups to better coordinate the GRASS
community activities such as software development, documentation, promotion
and fostering relations with other communities. If you are interested in
any of these topics or are already involved in these activities, please
consider joining the particular working group. Joining a working group is
also a great way for you to provide feedback on various issues, plug into
the community and contribute your expertise.

See the form for the proposed working groups and consider signing up:

https://forms.gle/BXzooNYBjgkjMmYk9

There is also a place in the form for your feedback. Once we get your
responses I will be back with more details to get the working groups
started.

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

Re: [GRASS-user] Learn more about NSF funded project for GRASS ecosystem

[Anna Petrášová via grass-user]

We just successfully finished the first session and the second one is
coming up tomorrow (EST/New York at 10am, CEST/Brussels at 4pm).
We recorded the presentation part, for those who joined late or can't join
tomorrow, I can privately share the recording.

Best,
Anna


On Tue, Sep 19, 2023 at 10:33 AM Anna Petrášová 
wrote:

> For those interested to join us, the first session is coming up this
> Thursday (EST/New York at 2pm, CEST/Brussels at 8pm). You can join with a
> zoom link:
> https://ncsu.zoom.us/j/97419521476?pwd=cmx3TitGYjZiYWxzd241U0J0TzVUdz09
>
> If you can't make it, you can join the second session on Friday (EST/New
> York at 10am, CEST/Brussels at 4pm).
>
> Looking forward to seeing you there!
>
> Anna
>
> On Mon, Sep 11, 2023 at 4:57 PM Anna Petrášová 
> wrote:
>
>> As a follow up on our announcement about the NSF funded project to
>> enhance GRASS ecosystem [1] I would like to invite everybody interested to
>> an info session! We will briefly explain what we hope to achieve in this
>> project and how you can get involved. There will be time for Q as well.
>> To allow as many people to join, we plan two 1-hour info sessions at
>> different days and times:
>>
>> * Thursday, September 21
>> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=9=21=18=0=0=207=51=48=197=3703>
>>  (EST
>> 2pm, Europe 8pm)
>> * Friday, September 22
>> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=9=22=14=0=0=207=51=48=197=3703>
>>  (EST
>> 10am, Europe 4pm)
>>
>> The content of both sessions will be the same. I will send zoom links a
>> day before each event.
>> Hope to see you there!
>>
>> Anna
>>
>>
>> [1] https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Learn more about NSF funded project for GRASS ecosystem

[Anna Petrášová]

For those interested to join us, the first session is coming up this
Thursday (EST/New York at 2pm, CEST/Brussels at 8pm). You can join with a
zoom link:
https://ncsu.zoom.us/j/97419521476?pwd=cmx3TitGYjZiYWxzd241U0J0TzVUdz09

If you can't make it, you can join the second session on Friday (EST/New
York at 10am, CEST/Brussels at 4pm).

Looking forward to seeing you there!

Anna

On Mon, Sep 11, 2023 at 4:57 PM Anna Petrášová 
wrote:

> As a follow up on our announcement about the NSF funded project to enhance
> GRASS ecosystem [1] I would like to invite everybody interested to an info
> session! We will briefly explain what we hope to achieve in this project
> and how you can get involved. There will be time for Q as well.
> To allow as many people to join, we plan two 1-hour info sessions at
> different days and times:
>
> * Thursday, September 21
> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=9=21=18=0=0=207=51=48=197=3703>
>  (EST
> 2pm, Europe 8pm)
> * Friday, September 22
> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=9=22=14=0=0=207=51=48=197=3703>
>  (EST
> 10am, Europe 4pm)
>
> The content of both sessions will be the same. I will send zoom links a
> day before each event.
> Hope to see you there!
>
> Anna
>
>
> [1] https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Anna Petrášová]

Thank you all!

And thank you Aashish, this is exactly what we are looking for and we will
get back to you.

Anna

On Fri, Sep 8, 2023 at 5:17 PM Aashish Chaudhary <
aashish.chaudh...@kitware.com> wrote:

> Congratulations! As the goal of this grant is to facilitate the adoption
> of GRASS GIS in the Industry, I would be glad to discuss how we could
> leverage GRASS GIS for current or future work.
>
> Thanks,
> Aashish
>
> On Fri, Sep 8, 2023 at 5:10 PM massimo di stefano <
> massimodisa...@gmail.com> wrote:
>
>> Bravi tutti!
>>
>> Congratulations <3 !
>>
>> Il giorno ven 8 set 2023 alle 20:38 Anna Petrášová 
>> ha scritto:
>>
>>> 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-dev mailing list
>>> grass-...@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>> ___
>> grass-dev mailing list
>> grass-...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
> --
>
> <https://www.kitware.com/>
>
> *Aashish Chaudhary*
>
> Assistant Director of Business Development, D
>
> Kitware, Inc.
>
> (480) 275-0777
>
> www.kitware.com/aashish-chaudhary/ <http://www.kitware.com/matt-leotta/>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Learn more about NSF funded project for GRASS ecosystem

[Anna Petrášová]

As a follow up on our announcement about the NSF funded project to enhance
GRASS ecosystem [1] I would like to invite everybody interested to an info
session! We will briefly explain what we hope to achieve in this project
and how you can get involved. There will be time for Q as well.
To allow as many people to join, we plan two 1-hour info sessions at
different days and times:

* Thursday, September 21

(EST
2pm, Europe 8pm)
* Friday, September 22

(EST
10am, Europe 4pm)

The content of both sessions will be the same. I will send zoom links a day
before each event.
Hope to see you there!

Anna


[1] https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[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

Re: [GRASS-user] Mouse coordinates in Map Window not following GUI settings projection

[Anna Petrášová]

On Tue, Aug 15, 2023 at 1:39 PM Eric Patton via grass-user <
grass-user@lists.osgeo.org> wrote:

> I am having trouble getting the Grass GUI map window mouse coordinates to
> display Lat-Long WGS84 coordinates in the lower-left corner of the display
> window.
>
> I checked the GUI settings Projection tab, and it is set to EPSG:4326,
> and references /usr/local/share/proj/epsg, but I can't find this file
> anywhere
> on my system.
>

I have there /usr/share/proj/epsg

but even if you can't find it, entering 4326 and proj string
+proj=longlat +datum=WGS84 +no_defs +type=crs

should do it. Then, you have to switch that on in map display settings (see
map display toolbar) -> Status bar -> Display coordinates in different CRS
The idea was to move the epsg panel in GUI settings to the map display
settings, but this part never got finished...


> Here are the closest matches:
>
> cd /usr
>
> find . -name "*epsg*"
> ./include/boost/geometry/srs/epsg.hpp
> ./include/boost/geometry/srs/projections/epsg_params.hpp
> ./include/boost/geometry/srs/projections/epsg.hpp
> ./include/boost/geometry/srs/projections/epsg_traits.hpp
> ./include/geotiff/epsg_datum.inc
> ./include/geotiff/epsg_proj.inc
> ./include/geotiff/epsg_gcs.inc
> ./include/geotiff/epsg_units.inc
> ./include/geotiff/epsg_ellipse.inc
> ./include/geotiff/epsg_vertcs.inc
> ./include/geotiff/epsg_pm.inc
> ./include/geotiff/epsg_pcs.inc
> ./local/gdal-3.7.1/data/epsg.wkt
> ./local/gdal-3.7.1/ogr/ogr_fromepsg.cpp
> ./local/gdal-3.7.1/swig/python/gdal-utils/osgeo_utils/samples/epsg_tr.py
> ./local/gdal-3.7.1/build/ogr/CMakeFiles/ogr.dir/ogr_fromepsg.cpp.o
> ./local/gdal-3.7.1/frmts/gtiff/libgeotiff/epsg_datum.inc
> ./local/gdal-3.7.1/frmts/gtiff/libgeotiff/epsg_proj.inc
> ./local/gdal-3.7.1/frmts/gtiff/libgeotiff/epsg_gcs.inc
> ./local/gdal-3.7.1/frmts/gtiff/libgeotiff/epsg_units.inc
> ./local/gdal-3.7.1/frmts/gtiff/libgeotiff/epsg_ellipse.inc
> ./local/gdal-3.7.1/frmts/gtiff/libgeotiff/epsg_vertcs.inc
> ./local/gdal-3.7.1/frmts/gtiff/libgeotiff/epsg_pm.inc
> ./local/gdal-3.7.1/frmts/gtiff/libgeotiff/epsg_pcs.inc
> ./local/lib/python3/dist-packages/osgeo_utils/samples/epsg_tr.py
>
> ./local/lib/python3/dist-packages/osgeo_utils/samples/__pycache__/epsg_tr.cpython-38.pyc
> ./local/share/gdal/epsg.wkt
>
> Here's my system: (Linux Mint 20.3)
>
> g.version -gre
> version=8.3.dev
> date=2023
> revision=b3ba6c290d
> build_date=2023-08-14
> build_platform=x86_64-pc-linux-gnu
> build_off_t_size=8
> libgis_revision=a82501dc85
> libgis_date=2023-02-27T12:45:25+00:00
> proj=8.2.0
> gdal=3.7.1
> geos=3.12.0
> sqlite=3.31.1
>
>
> My proj installation was installed by Synaptic package manager, in the
> standard
> places, /usr/bin and /usr/share/proj.
>
> Thanks for any helps,
>
> ~ Eric.
>
> ___
> 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] Python Script not working now

[Anna Petrášová]

Hi,

I think the gsetup.init parameters changed, see:
https://grass.osgeo.org/grass83/manuals/libpython/script.html#script.setup.init

Best,
Anna

On Mon, Aug 7, 2023 at 3:03 PM Phillip Allen 
wrote:

> Hi all,
>
> I wrote a python script ~6 years ago to create sample catchment polygons
> for stream sediment samples and all worked well. I created 10,000s of
> catchements successfully!
>
> Today I reconfigured the script for some new data and I am now getting
> this error:
>
> (Mon Aug  7 12:57:09 2023)
>
> D:\DEM_12_5\mcc_area\basin_code04_mcc.py
>
> Traceback (most recent call last):
>   File "D:\DEM_12_5\mcc_area\basin_code04_mcc.py", line 43,
> in 
> gsetup.init(gisbase, gisdb, location, mapset)
>   File "C:\OSGeo4W\apps\grass\grass83\etc\python\grass\scrip
> t\setup.py", line 329, in init
> raise ValueError(
> ValueError: Mapset D:\DEM_12_5\grassdata\dem12_5_a is not
> valid:  is not a valid GRASS Location
> because PERMANENT Mapset is missing
> (Mon Aug  7 12:57:10 2023) Command ended with non-zero return code 1 (0
> sec)
>
> I know the mapset PERMANENT exists and is valid since I just opened it in
> GRASS.
>
> Why is this python code below not running properly now?
> Has something in GRASS changed 'recently' ?
>
> regards,
>
> Phil
> Consulting Geochemist
> (someday I really need to become a better python coder!)
>
> #
> #  basin python code
> #! C:\OSGeo4W64\bin\python.exe
>
> # IMPORT CSV & LOOP THROUGH COORDINATES FOR r.water.outlet
> import os
> import sys
> import psycopg2
>
>
> #set up GRASS environment variables
> sys.path.append(os.path.join(os.environ['GISBASE'], 'etc', 'python'))
> import grass.script as g
> import grass.script.setup as gsetup
> gisbase = os.environ['GISBASE']
>
> gisdb = 'D:/DEM_12_5/grassdata'
> location = 'dem12_5_a'
> mapset = 'PERMANENT'
> rast_draindir = 'mcc_d1_draindir150'
>
>
> # first join the new snap table's cat column to the original attribute
> table
> # v.out.ascii input=th_ss_aem_snap_r5@PERMANENT type=point
> output=D:/DEM_12_5/mcc_area/mcc_ss_aga_pt_temp.csv columns=sample_number
> format=point separator=comma precision=20
> txtfile = 'D:/DEM_12_5/mcc_area/mcc_ss_aga_pt_temp.csv'
> txtfileWKT = 'D:/DEM_12_5/mcc_area/mcc_ss_WKT.txt'
> pgsrid = '32618'
>
> pg_user = 'postgres'
> pg_user_pwd = 'notmyrealpassword'
> pg_schema = 'basin'
> pg_tbl_name = 'mcc_samp_basin'
> pg_host = 'localhost'
> pg_dbname = 'ss_basin_test'
>
> txt_pg_tbl_create = 'CREATE TABLE ' + pg_schema + "." + pg_tbl_name + ' (x
> double precision, y double precision, samp_id character varying(254), geom
> geometry(POLYGON, ' + pgsrid + ') );'
> txt_pg_db =  "host='" + pg_host + "' dbname='" + pg_dbname + "' user='" +
> pg_user + "' password='" + pg_user_pwd + "'"
>
> txt_gpg_db = "PG:dbname=" + pg_dbname + " host='" + pg_host + "' user='" +
> pg_user + "' password='" + pg_user_pwd + "'"
>
>
> #print "Connecting to database\n ->%s" % (txt_pg_db)
> #print "Grass PG Connection String\n ->%s" % (txt_gpg_db)
>
> gsetup.init(gisbase, gisdb, location, mapset)
> g.run_command('g.region', flags='a', rast = rast_draindir)
>
>
> # Create PostGIS Polygon Table
> conn = psycopg2.connect(txt_pg_db)
> cur = conn.cursor()
> cur.execute(txt_pg_tbl_create)
> conn.commit()
>
> #csv file reading and importation
> import csv
> rows = list(open(txtfile))
> totalrows = len(rows) - 1
>
> #loop through the csv(coordinates) file in r.water.outlet module
> f = open(txtfile, 'r')
> element = list(csv.reader(f))
> i = 0
> j = 0
> while True:
> if i <= totalrows:
> g.run_command('r.water.outlet', overwrite = True , input = rast_draindir,
> output = 'b' , coordinates = element[i][j] + ',' + element[i][j + 1] )
> g.run_command('r.null' , map='b', setnull = 0 )
> g.run_command('r.to.vect' , overwrite = True , input='b', output = 'b_rc',
> type = 'area' )
> g.run_command('v.out.ascii', overwrite = True, input='b_rc',
> type='boundary', output=txtfileWKT, format='wkt')
> g.run_command('v.out.postgis', overwrite = True, input='b_rc',
> type='boundary', output=txt_gpg_db , output_layer = pg_schema + ".b_rc" )
> sql_txt = "INSERT INTO " + pg_schema + "." + pg_tbl_name + " SELECT " +
> element[i][j] + " AS x, " + element[i][j + 1] + " AS y, '" + element[i][j +
> 3] + "' AS samp_id, b_rc.geom AS geom FROM " + pg_schema + ".b_rc;"
> cur.execute(sql_txt)
> conn.commit()
> i = i + 1
> else:
> break
>
> cur.close()
> conn.close()
>
>
> ___
> 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] how to calculate volume of water stored in water storage with r.sim.water?

[Anna Petrášová]

On Tue, Aug 1, 2023 at 10:23 AM bonushenricus 
wrote:

> Thank you, Anna.
> r.sim.water finishes the simulation not at the end of the rainfall event,
> in my case at 30 minutes, but at an earlier time. In my case, in the
> smaller reservoir at 16 minutes, in the case of the more extensive
> reservoir at 24 minutes. But the water keeps coming even after that. I
> imagined that the calculation ends when it reaches the steady state of the
> water blade.
> But it's not so. Then I don't understand why it ends at 16 or 24 minutes.
> Doesn't the water continue to arrive after that? Shouldn't it increase?
> I cannot understand it. In the reservoirs, the discharge is very low, as I
> expect. But if the discharge does not increase and the precipitation
> continues, I expect the water depth to rise again.
> And it is not understandable that two reservoirs, one twice the volume of
> the other, contain the same depth of 30 cm at the end of the rainfall.
> To understand how this works, I would apply waterproofing to the
> reservoirs. The ksat, or infil_value, is the only variable that can explain
> this: the larger reservoir loses more water.
> If both reservoirs were waterproof, I would have removed this variable.
> Unfortunately r.sim.water infil=raster where I have marked value 0 in the
> reservoirs does not work. There is perhaps a bug that I have reported. So I
> haven't had a chance to test this.
> I don't know how to do it; I can't trust the 30 cm as a value to calculate
> the water volume in the two reservoirs. I will have to use another model.
> I will try to use a distributed model. Since I have the data in GRASS, I
> will try using the old geomhydas, hoping the modules will work in GRASS8,
> and then use the Mhydas models in OpenFluid. I have no other chance unless
> someone can help me find a solution.
>
>
Unfortunately I haven't had time to look at the reported issue. Perhaps you
could share your data and provide exact commands and pictures, explaining
very clearly what's wrong.


> --
>
> --
> Perito agrario Enrico Gabrielli
> progetto F.A.R.M. www.farm-agroecologia.it
> Tessera n. 633 Collegio Periti agrari prov. Di Modena
> Biblioteca agricoltura: 
> https://www.zotero.org/groups/aplomb/https://www.inaturalist.org/observations/bonushenricus
>
>
> Il giorno mar, 01/08/2023 alle 09.23 -0400, Anna Petrášová ha scritto:
>
>
>
> On Mon, Jul 31, 2023 at 11:42 PM bonushenricus 
> wrote:
>
> Hi Anna
> I too immediately thought it was enough to compute it for the final step
> of the simulation,
> but I noticed that the same slope, same ditches, same rainfall, for two
> reservoirs at the same location, same length along a contour, but different
> width and depth, at the final step of the simulation the water depth was
> always 30 cm, I went to read the article
> Mitasova, Helena, Chris Thaxton, Jaroslav Hofierka, Richard McLaughlin,
> Amber Moore, e Lubos Mitas. «Path Sampling Method for Modeling Overland
> Water Flow, Sediment Transport, and Short Term Terrain Evolution in Open
> Source GIS». In *Developments in Water Science*, 55:1479–90. Elsevier,
> 2004. https://doi.org/10.1016/S0167-5648(04)80159-X
> where I read the Saint-Venant equation. I am an agricultural technician
> and geographer unfortunately ignorant of hydrological calculations and
> serious mathematics, and I understood, looking at the equation, that the
> water depth is the depth of overland flow = rainfall exces - water flow.
> So the final 30 cm should not be understood as accumulated water, but as
> the blade of water that was added at that precise moment.
> Isn't my interpretation right?
>
>
> No, it should be actual water depth.  I didn't understand the discrepancy
> you are describing?
>
> --
>
> --
> Perito agrario Enrico Gabrielli
> progetto F.A.R.M. www.farm-agroecologia.it
> Tessera n. 633 Collegio Periti agrari prov. Di Modena
> Biblioteca agricoltura: 
> https://www.zotero.org/groups/aplomb/https://www.inaturalist.org/observations/bonushenricus
>
>
>
> Il giorno lun, 31/07/2023 alle 14.34 -0400, Anna Petrášová ha scritto:
>
>
>
> On Sun, Jul 30, 2023 at 6:01 AM bonushenricus 
> wrote:
>
> Hi
> From r.sim.water, how can I calculate the volume of water stored in
> small water storages placed along a relief and connected to ditches?
> In this article https://doi.org/10.1016/j.agwat.2023.108398 these
> Italian researchers with r.sim.water manage did this calculation, but I
> do not understand how. With a calculation at different times on
> discharge at the entrance to the water storage?
> I tried to contact them, but they did not reply.
> Thanks!
>
>
> Hi,
>
> volume would be simple depth times cell size squared for a certain
> se

Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?

[Anna Petrášová]

On Mon, Jul 31, 2023 at 11:42 PM bonushenricus 
wrote:

> Hi Anna
> I too immediately thought it was enough to compute it for the final step
> of the simulation,
> but I noticed that the same slope, same ditches, same rainfall, for two
> reservoirs at the same location, same length along a contour, but different
> width and depth, at the final step of the simulation the water depth was
> always 30 cm, I went to read the article
> Mitasova, Helena, Chris Thaxton, Jaroslav Hofierka, Richard McLaughlin,
> Amber Moore, e Lubos Mitas. «Path Sampling Method for Modeling Overland
> Water Flow, Sediment Transport, and Short Term Terrain Evolution in Open
> Source GIS». In *Developments in Water Science*, 55:1479–90. Elsevier,
> 2004. https://doi.org/10.1016/S0167-5648(04)80159-X
> where I read the Saint-Venant equation. I am an agricultural technician
> and geographer unfortunately ignorant of hydrological calculations and
> serious mathematics, and I understood, looking at the equation, that the
> water depth is the depth of overland flow = rainfall exces - water flow.
> So the final 30 cm should not be understood as accumulated water, but as
> the blade of water that was added at that precise moment.
> Isn't my interpretation right?
>

No, it should be actual water depth.  I didn't understand the discrepancy
you are describing?

> --
>
> --
> Perito agrario Enrico Gabrielli
> progetto F.A.R.M. www.farm-agroecologia.it
> Tessera n. 633 Collegio Periti agrari prov. Di Modena
> Biblioteca agricoltura: 
> https://www.zotero.org/groups/aplomb/https://www.inaturalist.org/observations/bonushenricus
>
>
>
> Il giorno lun, 31/07/2023 alle 14.34 -0400, Anna Petrášová ha scritto:
>
>
>
> On Sun, Jul 30, 2023 at 6:01 AM bonushenricus 
> wrote:
>
> Hi
> From r.sim.water, how can I calculate the volume of water stored in
> small water storages placed along a relief and connected to ditches?
> In this article https://doi.org/10.1016/j.agwat.2023.108398 these
> Italian researchers with r.sim.water manage did this calculation, but I
> do not understand how. With a calculation at different times on
> discharge at the entrance to the water storage?
> I tried to contact them, but they did not reply.
> Thanks!
>
>
> Hi,
>
> volume would be simple depth times cell size squared for a certain
> selected area. I would compute it for the final step of the simulation, I
> am not sure what is the purpose of summing it for different time steps.
> Perhaps you could clarify a little bit?
>
> Anna
>
>
> --
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?

[Anna Petrášová]

On Sun, Jul 30, 2023 at 6:01 AM bonushenricus 
wrote:

> Hi
> From r.sim.water, how can I calculate the volume of water stored in
> small water storages placed along a relief and connected to ditches?
> In this article https://doi.org/10.1016/j.agwat.2023.108398 these
> Italian researchers with r.sim.water manage did this calculation, but I
> do not understand how. With a calculation at different times on
> discharge at the entrance to the water storage?
> I tried to contact them, but they did not reply.
> Thanks!
>

Hi,

volume would be simple depth times cell size squared for a certain selected
area. I would compute it for the final step of the simulation, I am not
sure what is the purpose of summing it for different time steps. Perhaps
you could clarify a little bit?

Anna


> --
> --
> Perito agrario Enrico Gabrielli
> progetto F.A.R.M. www.farm-agroecologia.it
> Tessera n. 633 Collegio Periti agrari prov. Di Modena
> Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/
> https://www.inaturalist.org/observations/bonushenricus
> ___
> 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.in.ascii data error

[Anna Petrášová]

How the data is formatted is wrong, see the example. With standard format,
you need to specify coordinates separated by space. Attributes can't be
used.
B 5
  45.654023 -122.980241 393
 

See also https://grass.osgeo.org/grass82/manuals/vectorascii.html

On Tue, May 23, 2023 at 10:05 AM Rich Shepard 
wrote:

> On Tue, 23 May 2023, Anna Petrášová wrote:
>
> > Then yes, just include the boundary and run v.centroids. It was unclear
> > from your first question what it is you actually need.
>
> Anna,
>
> That's what I had done; here are the data file, v.in.ascii command, and
> grass' output:
>
> B 5
>   45.654023|-122.980241|393|Shop
>   45.653931|-122.980315|393|Shop
>   45.653960|-122.979910|393|Shop
>   45.653856|-122.979831|393|Shop
>   45.654023|-122.980241|393|Shop
>
> v.in.ascii -z in=$HOME/projects/oregon/northside-rock/data/shop.txt
> out=maintenance_bldg format=standard sep=pipe cat=0 x=1 y=2 z=3 columns='x
> double precision, y double precision, z integer, label char(4)' --o
>
> > v.in.ascii -z in=$HOME/projects/oregon/northside-rock/data/shop.txt
> out=maintenance_bldg format=standard sep=pipe cat=0 x=1 y=2 z=3 columns='x
> double precision, y double precision, z integer, label char(4)' --o
> WARNING: Unexpected data in vector header:
>   [B 5]
> ERROR: Import failed
>
> 
>
> Looking at the v.in.ascii example 1b I added a 'no header' option to the
> command:
>
> v.in.ascii -zn in=$HOME/projects/oregon/northside-rock/data/shop.txt
> out=maintenance_bldg format=standard sep=pipe cat=0 x=1 y=2 z=3 columns='x
> double precision, y double precision, z integer, label char(4)' --o
>
> > v.in.ascii -zn in=$HOME/projects/oregon/northside-rock/data/shop.txt
> out=maintenance_bldg format=standard sep=pipe cat=0 x=1 y=2 z=3 columns='x
> double precision, y double precision, z integer, label char(4)' --o
> WARNING: Error reading ASCII file: (bad point) [
>   45.654023|-122.980241|393|Shop]
>
> Please tell me what I've done incorrectly.
>
> TIA,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>


-- 
Anna Petrasova
Getting benefits from GRASS GIS? Check new ways to contribute back:
https://opencollective.com/grass/contribute
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.in.ascii data error

[Anna Petrášová]

On Mon, May 22, 2023 at 5:26 PM Rich Shepard 
wrote:

> On Mon, 22 May 2023, Anna Petrášová wrote:
>
> > That's not what I meant. Point format is for points, nothing else. If you
> > need areas, you need standard format. See the first example in the man
> > page for importing areas.
>
> Anna,
>
> That's what I thought, and what I had defined in the data file and command.
> but with a none-rectangular boundary I don't have the coordinates for a
> centroid; although I could just pick a point, I suppose.
>
> Do all standard format boundary data files require me to include a
> centroid?
>

Then yes, just include the boundary and run v.centroids. It was unclear
from your first question what it is you actually need.

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


-- 
Anna Petrasova
Getting benefits from GRASS GIS? Check new ways to contribute back:
https://opencollective.com/grass/contribute
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.in.ascii data error

[Anna Petrášová]

On Mon, May 22, 2023 at 2:47 PM Rich Shepard 
wrote:

> On Mon, 22 May 2023, Anna Petrášová wrote:
>
> >> Data file:
> >> B 5
> >>   45.654023|-122.980241|393|Shop
> >>   45.653931|-122.980315|393|Shop
> >>   45.653960|-122.979910|393|Shop
> >>   45.653856|-122.979831|393|Shop
> >>   45.654023|-122.980241|393|Shop
>
> > you are mixing formats, either use 'standard' or 'point', see the
> > v.in.ascii manual. Likely you need format=point.
>
> Anna,
>
> I know that lines and points use the point format, but boundaries and areas
> use the standard format. Your comment informs me that a boundary or area
> without a specified centroid is imported in point format and becomes an
> area
> after v.centroid is applied.
>

That's not what I meant. Point format is for points, nothing else. If you
need areas, you need standard format. See the first example in the man page
for importing areas.


>
> I didn't think of this.
>
> Many thanks,
>
> 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] v.in.ascii data error

[Anna Petrášová]

Hi Rich,

On Mon, May 22, 2023 at 1:06 PM Rich Shepard 
wrote:

> I've added elevation and a feature name to the standard format v.in.ascii
> file. Grass reports an import error; the same error occurs without those
> two
> added columns. I'm not seeing the error, your fresh eyes will see it.
>
> Data file:
> B 5
>   45.654023|-122.980241|393|Shop
>   45.653931|-122.980315|393|Shop
>   45.653960|-122.979910|393|Shop
>   45.653856|-122.979831|393|Shop
>   45.654023|-122.980241|393|Shop
>
> Command:
> v.in.ascii -z in=$HOME/projects/oregon/northside-rock/data/shop.txt
> out=maintenance_bldg format=standard sep=pipe cat=0 x=1 y=2 z=3 columns='x
> double precision, y double precision, z integer, label char(4)' --o
>

you are mixing formats, either use 'standard' or 'point', see the
v.in.ascii manual. Likely you need format=point.

Best,
Anna


-- 
Anna Petrasova
Getting benefits from GRASS GIS? Check new ways to contribute back:
https://opencollective.com/grass/contribute
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.slope.aspect: rejects DCELL precison for map with DCELL precision

[Anna Petrášová]

On Wed, May 10, 2023 at 9:14 PM Rich Shepard 
wrote:

> I don't understand why a raster elevation map with DCELL precision is
> rejected by r.slope.aspect. The region was set to the vector analysis area.
>
> r.info tells me this about the elevation map:
>
> ++
>   | Map:  dem2014Date: Wed May 10 13:47:46
> 2023|
>   | Mapset:   northside_rock Login of Creator: rshepard
> |
>   | Location: Oregon
>  |
>   | DataBase: /data1/grassdata
>  |
>   | Title:dem_2014
>  |
>   | Timestamp: none
> |
>
> ||
>   |
> |
>   |   Type of Map:  raster   Number of Categories: 0
>  |
>   |   Data Type:DCELLSemantic label: (none)
> |
>   |   Rows: 1037
>  |
>   |   Columns:  1056
>  |
>   |   Total Cells:  1095072
> |
>   |Projection: NAD83(CORS96) / Oregon North
> |
>   |N: 224201S: 223164   Res: 1
>  |
>   |E: 2307121.58W:2306066   Res: 0.99960227
> |
>   |   Range of data:min = 240  max = 820
>  |
>   |
> |
>   |   Data Description:
> |
>   |generated by r.surf.contour
>  |
>   |
> |
>   |   Comments:
> |
>   |r.surf.contour --overwrite input="baseline_dem" output="dem_2014"
>  |
>   |
> |
>
> ++
>
> grass reports (with the module usage redacted):
> r.slope.aspect elev=dem2014 slope=dem2014_slope aspect=dem2014_aspect
> format=degrees precision=DCELLl pcurv=dem2014_pcurve dx=dem2014_ew_slope
> dy=dem2014_ns_slope mem=2000 --o
> Generates raster maps of slope, aspect, curvatures and partial derivatives
> from an elevation raster map.
>   ...
>
> ERROR: Value  out of range for parameter 
> Legal range: CELL,FCELL,DCELL
>
> What exactly is out of range?
>

It's a typo in "DCELL"

>
> 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] v.to.rast questions

[Anna Petrášová]

On Wed, May 10, 2023 at 12:34 PM Rich Shepard 
wrote:

> On Wed, 10 May 2023, Anna Petrášová wrote:
>
> > Sounds like the vector geometry was already 3D, that's the case when you
> > use use=z. If the vector would be 2D (see v.info) you would have to use
> the
> > attribute table.
>
> Anna,
>
> When I used the 2D file, regardless of which parameter I used or both,
> v.to.rast told me the file was not 3D. That's why I converted it. When
> 'use=z' failed I tried 'attribute_column=ContourEle' with the same result.
>
> Now I have the rasterized contour map (image attached) and need to learn
> how
> to use it to create flowlines, flow accumulations, and more. It does not
> have the 1'x1' cells each with a color representing the elevation.
>
> Is there an r.* module to interpolate elevations between the contour lines
> so I have cells?
>

There is r.surf.contour, so that sounds like the tool you need.

>
> This is all new to me so I appreciate all the help I get.
>
> Regards,
>
> 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] v.to.rast questions

[Anna Petrášová]

Sounds like the vector geometry was already 3D, that's the case when you
use use=z. If the vector would be 2D (see v.info) you would have to use the
attribute table.

On Wed, May 10, 2023 at 12:14 PM Rich Shepard 
wrote:

> My current topographic vector data file has a column name for the elevation
> data, ContourEle. Reading the v.to.rast page there is a use parameter (with
> 'z' for elevation) and an attribute_column parmater. Because the vector
> map's database table does not have a column named 'z', but the one named
> 'CountourEle' I put both parameters on the command line.
>
> grass told me that I cannot have both, and that using the named elevation
> column was not allowed. So I put 'use=z' in the command and the conversion
> worked.
>
> How did v.to.rast know that the column named 'ContourEle' was the z value?
>
> Should the manual page explain that the use and attribute_column cannot be
> used together for elevation? And, when the attribute_column would be
> appropriate?
>
> Regards,
>
> 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] Is this a bug in 8.3.dev?

[Anna Petrášová]

Rich, it would be extremely helpful, if you always show the errors you are
getting, otherwise, it's very difficult for us to help you.

On Wed, May 3, 2023 at 3:40 PM Rich Shepard 
wrote:

> On Wed, 3 May 2023, Helmut Kudrnovsky wrote:
>
> > why not, as Anna already suggested in an earlier reply, _fix_ your
> > operating system by removing python 2.x from your linux box and keep only
> > python 3 there.
>
> > for a long time now, GRASS GIS 8.x switched to python 3.
>
> Helmut,
>
> I've no idea whether any other applications still require python2.
> Regardless, I removed python2 from the laptop. Now GRASS_PYTHON=python3.9.
>
> When I restart grass there's still a monitor issue. When I enter `d.mon
> start=wx0` grass tells me it's already running. When I enter `d.mon
> stop=wx0` grass tells me there is no wx0 monitor running.
>
> How do I correct this?
>
> Thanks,
>
> 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] Map not found?

[Anna Petrášová]

Rich, perhaps you want to consider asking these questions on Gitter?
https://gitter.im/grassgis/community

I think it's better suited for these questions.

On Tue, May 2, 2023 at 11:26 AM Anna Petrášová 
wrote:

>
>
> On Tue, May 2, 2023 at 11:22 AM Rich Shepard 
> wrote:
>
>> On Tue, 2 May 2023, Anna Petrášová wrote:
>>
>> > Could you show the exact commands and output? Are you sure it's not a
>> typo?
>>
>> Anna,
>>
>> GRASS NSR_TaxLot/PERMANENT:~ > g.mapsets -p
>> Accessible mapsets:
>> PERMANENT
>> GRASS NSR_TaxLot/PERMANENT:~ > g.list type=vect
>> permit_area
>> GRASS NSR_TaxLot/PERMANENT:~ > g.proj -g georef=permit_area
>>
>
> georef doesn't expect a GRASS map, but a georeferenced file.
>
> ERROR 4: permit_area: No such file or directory
>> ERROR: Unable to read georeferenced file  using GDAL library
>> GRASS NSR_TaxLot/PERMANENT:~ > v.info map=pernit_area
>> ERROR: Vector map  not found
>>
>
> it's a typo
>
>>
>> g.list finds the vector file in the PERMANENT mapset so I expected to
>> learn
>> details using g.proj and v.info.
>>
>> Regards,
>>
>> 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] Map not found?

[Anna Petrášová]

On Tue, May 2, 2023 at 11:22 AM Rich Shepard 
wrote:

> On Tue, 2 May 2023, Anna Petrášová wrote:
>
> > Could you show the exact commands and output? Are you sure it's not a
> typo?
>
> Anna,
>
> GRASS NSR_TaxLot/PERMANENT:~ > g.mapsets -p
> Accessible mapsets:
> PERMANENT
> GRASS NSR_TaxLot/PERMANENT:~ > g.list type=vect
> permit_area
> GRASS NSR_TaxLot/PERMANENT:~ > g.proj -g georef=permit_area
>

georef doesn't expect a GRASS map, but a georeferenced file.

ERROR 4: permit_area: No such file or directory
> ERROR: Unable to read georeferenced file  using GDAL library
> GRASS NSR_TaxLot/PERMANENT:~ > v.info map=pernit_area
> ERROR: Vector map  not found
>

it's a typo

>
> g.list finds the vector file in the PERMANENT mapset so I expected to learn
> details using g.proj and v.info.
>
> Regards,
>
> 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] Map not found?

[Anna Petrášová]

Could you show the exact commands and output? Are you sure it's not a typo?

On Tue, May 2, 2023 at 10:06 AM Rich Shepard 
wrote:

> I'm working on the command line with the development version.
>
> I have a vector area map called 'permit_area' in the PERMANENT mapset.
> When I
> check using 'g.list type=vect' the map name is displayed. But, when I ask
> g.proj or v.info to tell me about that map they tell me 'permit_area not
> found.'
>
> What might cause this behavior?
>
> 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] wxPython cannot find installed module

[Anna Petrášová]

You may want to change the default Python on your system.

On Mon, May 1, 2023 at 2:14 PM Rich Shepard 
wrote:

> On Mon, 1 May 2023, Anna Petrášová wrote:
>
> > There is GRASS_PYTHON:
> > https://grass.osgeo.org/grass82/manuals/variables.html
> >
> > But I have never used it myself. Note that we don't support Python 2
> > anymore.
>
> Anna,
>
> Then I wonder why this clean 15.0 installation on the ThinkPad didn't
> automatically use python3. Guess I'll add the environmenal variable to my
> .bash_profile.
>
> Thanks,
>
> 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] wxPython cannot find installed module

[Anna Petrášová]

There is GRASS_PYTHON:
https://grass.osgeo.org/grass82/manuals/variables.html

But I have never used it myself. Note that we don't support Python 2
anymore.

On Mon, May 1, 2023 at 1:42 PM Rich Shepard 
wrote:

> On Mon, 1 May 2023, Anna Petrášová wrote:
>
> > When you run GRASS, go to terminal, type "python", press Enter and look
> > what the version of Python you use:
>
> Anna,
>
> It's the 2.7.18 version. Is there a configuration file in which I can
> specify python3?
>
> Regards,
>
> 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] wxPython cannot find installed module

[Anna Petrášová]

When you run GRASS, go to terminal, type "python", press Enter and look
what the version of Python you use:

GRASS nc_spm_08_grass7/testpatch:~ > python
Python 3.8.10 (default, Mar 13 2023, 10:26:41)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.version.version
'1.17.4'


or in the GUI, go to Python shell tab, look at the Python version, and try
importing numpy

On Mon, May 1, 2023 at 12:43 PM Rich Shepard 
wrote:

> On Mon, 1 May 2023, Anna Petrášová wrote:
>
> > You are likely using Python 3 already. Why don't you try to see which one
> > you use as I suggested?
>
> >> Apparenly so. My Slackware64-15.0 includes python2-2.7.18,
> >> python3-3.9.10, and python3-numpy-1.22.3. No python2-numpy.
>
> Anna, As I wrote: python3-3.9.10 and python3-numpy-1.22.3 are installed,
> along with python2 and the last python2-numpy.
>
> 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] wxPython cannot find installed module

[Anna Petrášová]

You are likely using Python 3 already. Why don't you try to see which one
you use as I suggested?

On Mon, May 1, 2023 at 11:42 AM Rich Shepard 
wrote:

> On Mon, 1 May 2023, Anna Petrášová wrote:
>
> > The error comes from this:
> > from numpy import matrix
>
> > Is it possible you have different Python installations on your computer?
> > Try running a python shell from an active GRASS session and running the
> > import command and see what it gives you.
>
> Anna,
>
> Apparenly so. My Slackware64-15.0 includes python2-2.7.18, python3-3.9.10,
> and
> python3-numpy-1.22.3. No python2-numpy.
>
> Will GRASS be moving to Python3 some time?
>
> Thanks,
>
> 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] wxPython cannot find installed module

[Anna Petrášová]

The error comes from this:

from numpy import matrix

Is it possible you have different Python installations on your computer?
Try running a python shell from an active GRASS session and running the
import command and see what it gives you.

On Fri, Apr 28, 2023 at 6:14 PM Rich Shepard 
wrote:

> I started grass with the wxGUI. It loaded but the v.t. displayed this
> message:
>
> Launching  GUI in the background, please wait... GRASS
> Oregon_North_State_Plane_ft/PERMANENT:
> ~ > wxnviz.py: This module requires the NumPy module, which could not be
> imported. It probably is not installed (it's not part of the standard
> Python
> distribution). See the Numeric Python site (http://numpy.scipy.org) for
> information on downloading source or binaries.
>
> Installed here: python3-numpy-1.22.3-x86_64-1_SBo
>
> Is there a way to let wxnviz.py know that numpy is installed, or should I
> just ignore it?
>
> 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] GRASS GIS integration with python packages for interactive plotting

[Anna Petrášová]

On Fri, Apr 28, 2023 at 7:50 AM Nunzio Losacco 
wrote:

> Hi all,
>
> I wonder if it is possible to have GRASS GIS interact with some external
> python libraries for interactive plotting, e.g. bokeh.org. Use case:
> click on a point, get a popup window with a pre-defined interactive plot or
> a relevant dashboard.
>

You could run it in Jupyter Notebooks (see e.g. [1]), I have used
matplotlib with GRASS in notebooks before. The use case with clicking is
not there yet, but we intend to implement more interactivity in the future.
Alternatively, the GRASS GIS GUI is implemented in wxPython and wxPython
can be integrated with matplotlib, there are several tools (such as
g.gui.tplot) that already use that.

[1] https://github.com/ncsu-geoforall-lab/grass-gis-workshop-foss4g-2022

>
> Best,
>
> N
>
> ___
> 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] fill in null areas equal to nearest value

[Anna Petrášová]

If I understand correctly, 1) set the computational region to match the
larger map, 2) use r.grow.distance with input=smaller map and option
'value', 3) use r.mapcalc to trim the values based on the larger map.

Best,
Anna

On Mon, Feb 13, 2023 at 11:06 AM Janet Choate  wrote:

> Hello GRASS community,
> I have two maps - where one map is slightly larger than the other - so
> that the smaller map is missing data just around the edges based on the
> outline of the larger map.
> The smaller map is a map of floating point values, the larger map has a
> single value of 1.
> I would like to fill in the missing edge data of the smaller map based on
> the outline of the larger map - setting the null areas to the nearest value
> in the smaller map.
>
> Thank you for any advice!
> Janet
> ___
> 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.sun - beam irradiance issues in mountain area with a high relief energy

[Anna Petrášová]

This could be potentially a problem described in
https://github.com/OSGeo/grass/pull/2534.
Could you try to run this with the changes in the PR?

Anna

On Tue, Jan 31, 2023 at 4:05 PM Helmut Kudrnovsky  wrote:

> hi,
>
> given a a mountain area with a high relief energy based upon an ALS DEM
> with a 1x1m resolution
>
> and system: winGRASS GIS 8.2.1
>
> g.region -p
> projection: 99 (MGI / Austria Lambert)
> zone:   0
> datum:  hermannskogel
> ellipsoid:  bessel
> north:  358599.5
> south:  345055.5
> west:   221323.5
> east:   236275.5
> nsres:  1
> ewres:  1
> rows:   13544
> cols:   14952
> cells:  202509888
>
> DEM range of data: min = 1197.4  max = 3496.68
>
> the horizon rasters are calculated by
>
> r.horizon elevation=als@data step=30 maxdistance=5000 output=horangle
>
> r.sun is calculated for 15 June
>
> r.sun elevation=als@data aspect=als_aspect@data slope=als_slope@data
> horizon_basename=horangle horizon_step=30 beam_rad=beam_rad166 day=166
> nprocs=2 npartitions=2
>
> see the result screenshot in https://pasteboard.co/YShtdFG8C7jk.png
>
> o the high peak has northern, eastern and southern oriented steep slopes
> o the more red, the higher beam irradiance calculated by the r.sun command
> above
> o the southern oriented footslopes show a high beam irradiance (as
> exptected)
> o the southern oriented and very steep slopes around the peak show a
> similar low beam irradiance as the northern slopes (not expected)
>
> I have issues to interpret the results, especially the last pattern:
>
> o Could be the lower beam irradiance in the very southern oriented slopes
> nearby the peak due to the very steep slope?
> o Do slopes with a high inclination (though southern oriented) reduce beam
> irradiance in the implemented model?
>
> Kind regards
> Helmut
> ___
> 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] regex in wxGUI

[Anna Petrášová]

It's using Python regular expressions, so after some googling, something
like this seems to work:
^(?:(?!string).)*$
Seems rather complicated, maybe you can find a simpler solution...

Anna

On Wed, Nov 30, 2022 at 3:25 AM Frank David  wrote:

> Hello,
>
> How can I select layers in the wxGUI when using CTRL+shift+L that does not
> contain a specific string ?
>
> Thank you for your help.
>
> Frank
> ___
> 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.futures.demand

[Anna Petrášová]

Sorry for late reply, is it possible one of the subregions has no developed
cells?

On Thu, Sep 1, 2022, 9:31 PM Mitchell Meads via grass-user <
grass-user@lists.osgeo.org> wrote:

> Hi,
>
> I'm currently attempting to use the futures extension in GRASS 7.8.5 and
> I'm having some issues with the r.futures.demand extension. The error is
> reading as such:
>
>
>
>
>
>
>
>
> *Traceback (most recent call last):  File
> "C:\Users\mitchell.meads\AppData\Roaming\GRASS7\addons/scripts/r.futures.demand.py
> ", line 443, in sys.exit(main())
> File
> "C:\Users\mitchell.meads\AppData\Roaming\GRASS7\addons/scripts/r.futures.demand.py
> ", line 172, in mainsubregionId,
> developed_cells = stats[0], int(stats[12])ValueError: invalid literal for
> int() with base 10: 'nan'*
>
>
> I believe the addon of r.futures.demand is having an issue reading my
> data, however, I have the population trend and projection CSV files
> formatted correctly, according to the manual. If you could please identify
> a potential cause or solution to this error, please let me know.
>
> Additionally, if you need anything else, I'm happy to share whatever I
> have.
>
>
> Thanks,
> Mitchell Meads, PhD Student
> Texas A University at Galveston
> Marine & Coastal Management Sciences; IDRT 
> Contact: mitchell.me...@tamu.edu; (832) 619-0729
>
>
>
> ___
> 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.mapcalc.tiled and mapset

[Anna Petrášová]

That is probably a bug in GridModule, please open an issue,

Thanks, Anna

On Fri, Aug 19, 2022, 12:45 PM Frank David  wrote:

> Hello,
>
> When I use r.mapcalc.tiled, all the mapsets become available from the
> working mapset.
>
> example : r.mapcalc.tiled expression="test=1" process=8
>
> Is there any reason ?
>
> I'm using grass 7.8
>
> Thank you for your help.
>
> Frank
>
>
> ___
> 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] Need help identifying missing wxgtk dependencies

[Anna Petrášová]

On Sat, Aug 13, 2022 at 5:57 PM Eric Patton 
wrote:

> --- Original Message ---
> On Saturday, August 13th, 2022 at 00:23, Anna Petrášová <
> kratocha...@gmail.com> wrote:
>
> I would say ctypes compilation may be a problem, there is a common issue
> related to libproj, see also
> https://github.com/OSGeo/grass/issues/435#issuecomment-688807074
>
> Anna
>
>
> Thanks for the link, Anna. I have the multiple proj installations thing
> resolved now, but I'm not sure what to make of the ctypes issue. I read
> through the bug report, but it's beyond me.
>

Does the ctypes part of compilation go through ok? It seems to me the
problem you describe is not related to Python or wx.

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

Re: [GRASS-user] Need help identifying missing wxgtk dependencies

[Anna Petrášová]

I would say ctypes compilation may be a problem, there is a common issue
related to libproj, see also
https://github.com/OSGeo/grass/issues/435#issuecomment-688807074

Anna

On Fri, Aug 12, 2022 at 11:45 AM Eric Patton via grass-user <
grass-user@lists.osgeo.org> wrote:

> --- Original Message ---
> On Friday, August 12th, 2022 at 12:27, Markus Neteler 
> wrote:
>
> > Pls run this to print the Python and wxPython versions:
> >
> > python3 -c "import sys, wx; print(sys.version); print(wx.version())"
>
> libgrass:
> > locate libgrass_gis.8.3.so
> /usr/local/grass/dist.x86_64-pc-linux-gnu/lib/libgrass_gis.8.3.so
> /usr/local/grass83/lib/libgrass_gis.8.3.so
>
> python3:
> > python3 -c "import sys, wx; print(sys.version); print(wx.version())"
> 3.8.10 (default, Jun 22 2022, 20:18:18)
> [GCC 9.4.0]
> 4.0.7 gtk3 (phoenix) wxWidgets 3.0.4
>
> ~ Eric.
>
>
>
>
> ___
> 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.mapcalc radians vs degrees

[Anna Petrášová]

On Wed, Aug 10, 2022 at 11:20 AM Frank David  wrote:

> Hello,
>
> It seems to me that there is an error on r.mapcalc manual page. The angle
> should be entered in radians and not in degrees in the trigonometric
> functions...
>

Why do you think so? In the past I've used degrees in r.mapcalc without
problems and I don't think there was any change impacting this.

Anna


> Regards,
>
> Frank
> ___
> 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] MacOS - Georectifier unable advance beyond source map type / location selection

[Anna Petrášová]

Hi all,

it would be great to report this as an issue so that we don't forget about
it and it can be fixed:
https://github.com/OSGeo/grass/issues/new/choose

Thank you

Anna

On Tue, Jun 7, 2022 at 2:55 PM Robert Dzur  wrote:

> Dr. Statella,
>
>
> Thanks for the workaround suggestion.  That worked on my Mac OS install.
>
>
>
> Appreciate your kind assistance.
>
>
>
> Rob
>
> --
>
>
>
> *Robert S. Dzur*
>
> Sr. Vice President and Systems Manager Spatial Data
>
> *Bohannan Huston*
>
> *p.* 505.823.1000 *|* *d.* 505.798.7966 *| **c.* 505.235.7786
>
> *Connect*: bhinc.com  | Facebook
>  | LinkedIn
>  | Twitter
> 
>
> *Building great teams to support great communities. Want to be part of the
> team? Visit **bhinc.com/careers* 
>
>
>
> DISCLAIMER: This e-mail, including attachments, may include confidential
> and/or proprietary information and may be used only by the person or entity
> to which it is addressed. Any unauthorized review, use, disclosure, or
> dissemination is strictly prohibited. If you received this e-mail in error,
> please notify the sender by reply e-mail and delete this e-mail immediately.
>
>
>
>
>
> *From: *Thiago Statella 
> *Date: *Tuesday, June 7, 2022 at 12:47 PM
> *To: *Robert Dzur 
> *Cc: *grass-user@lists.osgeo.org 
> *Subject: *Re: [GRASS-user] MacOS - Georectifier unable advance beyond
> source map type / location selection
>
> Hi, Rob
>
>
>
> I had the same issue. In my case, a workaround was directly type the name
> of the mapset and hit next button.
>
>
>
> I hope it helps!
>
>
>
>
>
> Atenciosamente,
>
>
>
> --
> Dr. Thiago Statella, professor Titular
> Instituto Federal de Educação, Ciência e Tecnologia de Mato Grosso - IFMT
> Campus de Cuiabá, Depto. de Infraestrutura
> Rua Prof. Zulmira Canavarros 93, Centro
> CEP: 78605-200, Tel: +55 65 3318-1400
>
> http://lattes.cnpq.br/8559753273123798
> https://sites.google.com/view/statella
>
> http://www.researcherid.com/rid/B-5196-2011
>
>
>
> Em 7 de jun. de 2022, à(s) 14:02, Robert Dzur  escreveu:
>
>
>
> Hello list,
>
>
>
> I’m having some trouble getting past the setup screen with the
> Georectifier on an M1 Max MacBook Pro running the latest 8.2.0 (June 6)
> release.
>
>
>
> I have a fairly rudimentary setup where I have imported a tiff image into
> an XY mapset to perform rough georeferencing of that image against a vector
> dataset in a UTM (EPSG:6341) mapset.  Both mapsets are under a common GRASS
> GIS database path.
>
>
>
> When I attempt to launch the georectifier from the UTM mapset and select
> the source data in the XY database I get the following message:
>
> You must select a valid location and mapset in order to continue
>
>
>
> I cannot seem to get past this setup screen with the Next button pictured
> below:
>
>
>
> 
>
>
>
> Incidentally, I had this issue on prior 8x MacOS versions.  However, if I
> take the same GRASS GIS database (both mapsets) created under MacOS, to a
> Windows machine (running GRASS GIS 8.0.1); I have no issues running the
> Greorectifier.
>
>
>
> Has anyone else come across this issue or might there be a work around on
> the Mac that I’m missing?
>
>
>
> Thank you for any suggestions.
>
>
>
> Best,
>
>
>
> Rob
>
> --
>
> *Robert S. Dzur*
>
> Sr. Vice President and Systems Manager Spatial Data
>
> *Bohannan Huston*
>
> *p.* 505.823.1000 *|* *d.* 505.798.7966 *| **c.* 505.235.7786
>
> *Connect*: bhinc.com
> 
>  | Facebook
> 
>  | LinkedIn
> 
>  | Twitter
> 

Re: [GRASS-user] Error importing 3d csv in grass

[Anna Petrášová]

Hi,

please keep the conversation on the user mailing list.

Have you tried to display it with isosurfaces or slices? See this workshop,
there is a part showing how to create and visualize 3D rasters:
http://ncsu-geoforall-lab.github.io/grass-temporal-workshop/#space-time-cube-representation

Anna

On Fri, May 20, 2022 at 12:36 PM Enrique Torres Moya 
wrote:

> Dear Anna, thanks, with cat =0, the data can be loaded, and I could see
> the data in 2d, but I created the raster 3d, but I cannot see in 3d view,
> ot in voxel.
>
> Please, I will be thanksfull with any indications.
>
> Best regards,
>
> Enrique T
>
> El mié., 18 de mayo de 2022 8:43 a. m., Anna Petrášová <
> kratocha...@gmail.com> escribió:
>
>> Hi,
>>
>> my guess is that the values in column 5 are not unique, which is a
>> problem, because you specified it as cat column, which should be the
>> primary key. So try cat=0 if that helps, that will autogenerate the cat
>> column with unique categories.
>>
>> Anna
>>
>> On Sun, May 8, 2022 at 2:25 AM Helmut Kudrnovsky  wrote:
>>
>>> >v.in.ascii --overwrite
>>> >input=/home/etorresm/Desktop/Vajont_Export_res_integer.csv
>>> >output=voxel_res_int separator=comma skip=1 x=2 y=3 z=4 cat=5
>>> [...]
>>> >UNIQUE constraint failed: voxel_res_int.int_5
>>> >DBMI-SQLite driver error:
>>> >Error in sqlite3_step():
>>> >UNIQUE constraint failed: voxel_res_int.int_5
>>> >ERROR: Unable to insert new record: insert into voxel_res_int values (
>>> 2,
>>> >1015614, 1048407, 2665, 4)
>>> >WARNING: Table  linked to vector map  does
>>> >not exist
>>>
>>> can you share the 10 first lines of the input ascii file?
>>>
>>> kind regards
>>> Helmut
>>>
>>>
>>> ___
>>> 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] Error importing 3d csv in grass

[Anna Petrášová]

Hi,

my guess is that the values in column 5 are not unique, which is a problem,
because you specified it as cat column, which should be the primary key. So
try cat=0 if that helps, that will autogenerate the cat column with unique
categories.

Anna

On Sun, May 8, 2022 at 2:25 AM Helmut Kudrnovsky  wrote:

> >v.in.ascii --overwrite
> >input=/home/etorresm/Desktop/Vajont_Export_res_integer.csv
> >output=voxel_res_int separator=comma skip=1 x=2 y=3 z=4 cat=5
> [...]
> >UNIQUE constraint failed: voxel_res_int.int_5
> >DBMI-SQLite driver error:
> >Error in sqlite3_step():
> >UNIQUE constraint failed: voxel_res_int.int_5
> >ERROR: Unable to insert new record: insert into voxel_res_int values ( 2,
> >1015614, 1048407, 2665, 4)
> >WARNING: Table  linked to vector map  does
> >not exist
>
> can you share the 10 first lines of the input ascii file?
>
> kind regards
> Helmut
>
>
> ___
> 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] problem with g.gui.rlisetup on windows 10

[Anna Petrášová]

Could you please report this weird behavior as an issue?
https://github.com/OSGeo/grass/issues/new/choose

On Mon, May 16, 2022 at 5:34 AM Cyril BERNARD  wrote:

> Hello everyone,
>
> I met a problem with g.gui.rlisetup tool on Windows.
>
> It is impossible to type the name of the configuration file in the
> dialog (the text zone stays blank), thus impossible to click on "Next"
> button, and to create the file.
>
> Meanwhile I tried on Linux, and it works. So I have to create liconf
> file on Linux and then, import it on
> C:\Users\xxx\AppData\Roaming\GRASS7\r.li ...
>
> What's wrong with g.gui.rlisetup tool on Windows ? Is it a bug already
> described ?
>
> And, where can I find a documentation about the syntax, if I want to
> create & edit the config file for r.li in a classic editor such as
> notepad ?
>
> Regards,
> Cyril Bernard
> UMR Espace-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

Re: [GRASS-user] Error compiling Grass 8.0.1: libgrass_interface_generator

[Anna Petrášová]

On Wed, Apr 27, 2022 at 9:22 PM Eric Patton via grass-user <
grass-user@lists.osgeo.org> wrote:

> I am compiling Grass 8.0.1 on a new laptop that is running Linux Mint
> 20.3, and I ran into an error after 'make':
>
> GRASS GIS 8.0.1 exported compilation log
> --
> Started compilation: Wed 27 Apr 2022 12:45:14 PM ADT
> --
> Errors in:
> /usr/local/grass-8.0.1/python/libgrass_interface_generator
>
> I am almost certain I have wrong/missing packages, as I've seen this error
> before, but I can't remember what caused it.
>
> g.version -e
> GRASS 8.0.1 (2022)
> PROJ: 7.2.1
> GDAL/OGR: 3.4.2
> GEOS: 3.10.2
> SQLite: 3.31.1
>

I think this may be relevant:
https://github.com/OSGeo/grass/issues/435#issuecomment-688807074

>
>
> I noticed during 'make' that there were dozens of these errors:
>
> "Cannot parse interface for module d.barscale. Empty strings will be
> placed instead of description and keywords."
>
> and so for seemingly every Grass module. Any ideas?
>

No idea about this one...

Anna

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

Re: [GRASS-user] GRASS GIS 8.0.0 Stand Alone

[Anna Petrášová]

Hi Martin,

please create an issue:
https://github.com/OSGeo/grass/issues/new/choose

Indeed, looks like the URL on the server doesn't match the url g.extension
expects. Note that you are using a daily build, you may want to consider
using released GRASS 8.0.0.

Anna

On Mon, Feb 7, 2022 at 2:57 PM Martin Bittens  wrote:

> Hello GRASS User,
>
> here comes an update concerning the installation of GRASS GIS addons:
>
> In the meantime I could change the addon-download link provided by
> GRASS. Using some of the 'recipes' I found in the internet I manipulated
> the g.extension.py file in line 1442 by adding " patch='dev' " and
> deactivating " patch=version[2] ". As a result, GRASS GIS is now calling
> '/grass80/addons/grass-8.0.dev' for the download of addons. It´s not a
> very professional solution because each time when the addon's web site
> changing its address (what happens as far as I know with each GRASS
> update) I have to made the respective adjustment in g.extension.py. But
> for know it is working.
>
> But...! The addon installation is obviously working only for addons
> which are based on python scripts (e.g., v.centerline.py). Addons which
> come with an exe-file are being installed with error messages and don´t
> work:
>
> g.extension extension=v.centerpoint operation=add
> Downloading precompiled GRASS Addons ...
> Fetching  from
> <
> http://wingrass.fsv.cvut.cz/grass80/addons/grass-8.0.dev/v.centerpoint.zip
> >
> (be patient)...
> Updating extensions metadata file...
> Updating extension modules metadata file...
> WARNING: No metadata available for module 'v.centerpoint': Unable to
> fetch interface description for command ''.
>
> Details:  find '__main__' module in
>
> 'C:\\Users\\Martin\\AppData\\Local\\Temp\\grass8-Martin-25356\\tmpc6exzl8p\\v.centerpoint'
>  >
> Installation of  successfully finished
> (Mon Feb  7 16:49:42 2022) Command finished (19 sec)
>
>
> So, what is the correct way for installing the GRASS GIS addons?
>
>
> Regards
>
>
> Martin
>
>
>
>
>
> Am 2/7/2022 um 11:45 AM schrieb Martin Bittens:
> > Hello GRASS User,
> >
> > I just installed the latest GRASS GIS Stand Alone version (8.0.0). When
> > I tried installing some addons I always received an error message:
> >
> > ERROR: Cannot open URL:
> >
> http://wingrass.fsv.cvut.cz/grass80/addons/grass-8.0.0dev/v.centerpoint.zip
> >
> >
> > I checked the web site and could the that there only exist 2 versions:
> >
> > - /grass80/addons/grass-8.0.dev
> >
> > - /grass80/addons/grass-8.0.0
> >
> >
> > How I can change the web address GRASS GIS is calling to the ones which
> > are providing the addons?
> >
> >
> > Thank you very much for a suggestion.
> >
> >
> > Regards
> >
> >
> > Martin
> >
> >
> > --
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
> > ___
> > 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] 8 Release Candidate

[Anna Petrášová]

On Sun, Jan 23, 2022 at 9:41 AM Randal Hale 
wrote:

> I've been trying to run the 8 release candidate. I'm on a stock Ubuntu
> (21.10) install and I've downloaded the binary 8 release candidate for
> grass. I do have Grass 7.8.5 running.
>
> Anyway - I've installed in a custom location and in the default. I start
> grass and get. The GRASS Splash screen does come up and stays up for about
> 2 secs and then I'm sitting at the prompt. I can't get the GUI up and
> running. Thoughts (I can file a bug report if needed):
>
> ./grass
>
> Starting GRASS GIS...
>
> Cleaning up temporary files...
>
>
>
>   __  ___   _____
>
>  / / __ \/   | / ___/ ___/   / /  _/ ___/
>
> / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
>
>/ /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
>
>\/_/ |_/_/  |_///   \/___///
>
>
>
> Welcome to GRASS GIS 8.0.0dev (4d15e3313)
>
> GRASS GIS homepage:  https://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...
>
> To run a command as administrator (user "root"), use "sudo ".
>
> See "man sudo_root" for details.
>
>
>
> GRASS world_latlong_wgs84/PERMANENT:bin > Traceback (most recent call last):
>
>   File "/usr/lib/python3/dist-packages/wx/core.py", line 3282, in 
>
> lambda event: event.callable(*event.args, **event.kw) )
>
>   File "/home/rjhale/temp/grass/gui/wxpython/wxgui.py", line 86, in 
> show_main_gui
>
> from lmgr.frame import GMFrame
>
>   File "/home/rjhale/temp/grass/gui/wxpython/lmgr/frame.py", line 45, in 
> 
>
> from gui_core.preferences import MapsetAccess, PreferencesDialog
>
>   File "/home/rjhale/temp/grass/gui/wxpython/gui_core/preferences.py", line 
> 52, in 
>
> from gui_core.dialogs import SymbolDialog, DefaultFontDialog
>
>   File "/home/rjhale/temp/grass/gui/wxpython/gui_core/dialogs.py", line 44, 
> in 
>
> from gui_core.gselect import (
>
>   File "/home/rjhale/temp/grass/gui/wxpython/gui_core/gselect.py", line 62, 
> in 
>
> from grass.lib.imagery import (
>
>   File "/home/rjhale/temp/grass/etc/python/grass/lib/imagery.py", line 30, in 
> 
>
> _libs["grass_imagery.8.0"] = load_library("grass_imagery.8.0")
>
>   File "/home/rjhale/temp/grass/etc/python/grass/lib/ctypes_loader.py", line 
> 89, in __call__
>
> raise ImportError("Could not load %s." % libname)
>
> ImportError: Could not load grass_imagery.8.0.
>
>
>
> GRASS world_latlong_wgs84/PERMANENT:bin >
>
>
>

Hi,

I just pushed a fix [1], so the GUI should at least start now, but I don't
know why grass can't load the library. So some functionality still won't
work (e.g. 3D, digitizer).

Anna

[1] https://github.com/OSGeo/grass/pull/2120

> --
> Randal Halerjhale@northrivergeographic.comhttps://www.northrivergeographic.com
>
> ___
> 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] Single GUI window in 8.0.0RC2?

[Anna Petrášová]

On Sat, Jan 22, 2022 at 3:39 PM Helmut Kudrnovsky  wrote:

> Veronica Andreo:
>
> >Oh, sorry that I wasn't explicit enough.
> >
> >I meant the appearance in your operative system. In my fedora box is under
> >Applications or Start  --> settings --> appearance, and there, in the
> Style
> >tab, I see adwaita, adwaita dark and such... Once you pick one of the dark
> >themes among the options, grass will get it too :)
>
> tested here in the MS windows side of the world ;-)  switched the
> windows 10 box into dark mode
>
> many software packages like Word, notepad++ etc are then in dark,
> unfortunately not winGRASS 8 
>

I was not aware of that, but you are right. I tested it and even File
Manager doesn't support it (at least in the version I used), read more here:
https://forums.wxwidgets.org/viewtopic.php?f=23=45869

>
>
> kind regards
> Helmut___
> 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] single window gui in main branch

[Anna Petrášová]

On Fri, Jan 14, 2022 at 8:02 AM Carlos Henrique Grohmann de Carvalho <
carlos.grohm...@gmail.com> wrote:

> Hello all
>
> Just to add my experience. I compiled releasebranch_8 in Linux (Pop!OS
> 21.10). The single window is great! I have been using a lot o GRASS+Jupyer
> lately (running things from Jupyter but with GRASS open for visualization)
> and the ability to do just one alt-tab to GRASS is really nice (instead of
> choosing the window to switch).
>
> I did find it to be a bit slow to start, and also somewhat unresponsive
> when resizing panels.
>
> And while it worked fine on linux, I couldn't get it to work on Windows.
> Is it not available yet? I tried the last executable from
> https://wingrass.fsv.cvut.cz/grass80/x86_64/
>

It's not in 80, it's still in main branch, planned for 8.2.0 release,
unfortunately I don't know if there are right now daily builds of main
branch on windows, there have been a lot of changes...

Anna

>
> Carlos
>
>
>
> On Thu, Jan 13, 2022 at 4:14 PM Micha Silver  wrote:
>
>> Wow, impressive!
>>
>> I especially like the search option in the right panel toolbox. Also the
>> ability to switch the python and command shell to full screen is great.
>>
>>
>> Best regards, and thanks for the nice work!
>>
>> Micha
>>
>>
>> On 11/01/2022 20:16, Veronica Andreo wrote:
>> > Hello everyone,
>> >
>> > Now that single window is merged into main branch I'd like to test :)
>> >
>> > Where's the switch? I just updated and compiled main branch and went
>> > through all tabs and options in the settings?preferences menu from the
>> > GUI, but I could not find anything saying single window something.
>> > What am I doing wrong here?
>> >
>> > Can this be related to
>> >
>> https://github.com/OSGeo/grass/blob/f57940e8a096c593f23b2ce3f9653547f24b8e92/gui/wxpython/core/settings.py#L156
>> > been set to False? Shall I change that to True to make it appear/work?
>> >
>> > Build info
>> > GRASS version: 8.0.dev 
>> > Code revision: 563797cd3
>> > Build date: 2022-01-11
>> >
>> > Thanks much,
>> > Vero
>> > --
>> > Dra. Verónica Andreo
>> > Investigadora Asistente de CONICET
>> > Instituto Gulich (CONAE - UNC)
>> > Centro Espacial Teófilo Tabanera (CETT)
>> > Falda del Cañete - Córdoba, Argentina
>> > +54 3547 40 int. 1153
>> > https://veroandreo.gitlab.io/
>> >
>> > ___
>> > grass-user mailing list
>> > grass-user@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>> --
>> Micha Silver
>> Ben Gurion Univ.
>> Sde Boker, Remote Sensing Lab
>> cell: +972-523-665918
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
>
> --
> Prof. Carlos Henrique Grohmann
> Institute of Energy and Environment - Univ. of São Paulo, Brazil
> Editor-in-Chief - Brazilian Journal of Geology
>
> http://carlosgrohmann.com
> https://spamlab.github.io/
> http://orcid.org/-0001-5073-5572
> 
> Can’t stop the signal.
> ___
> 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] single window gui in main branch

[Anna Petrášová]

Hi Vero,

I added the screenshot to the original PR:
https://github.com/OSGeo/grass/pull/1810

Maybe you overlooked it? The place may not be ideal for it...

On Tue, Jan 11, 2022 at 1:16 PM Veronica Andreo 
wrote:

> Hello everyone,
>
> Now that single window is merged into main branch I'd like to test :)
>
> Where's the switch? I just updated and compiled main branch and went
> through all tabs and options in the settings?preferences menu from the GUI,
> but I could not find anything saying single window something. What am I
> doing wrong here?
>
> Can this be related to
> https://github.com/OSGeo/grass/blob/f57940e8a096c593f23b2ce3f9653547f24b8e92/gui/wxpython/core/settings.py#L156
> been set to False? Shall I change that to True to make it appear/work?
>
> Build info
> GRASS version: 8.0.dev
>
> Code revision: 563797cd3
>
> Build date: 2022-01-11
>
> Thanks much,
> Vero
> --
> Dra. Verónica Andreo
> Investigadora Asistente de CONICET
> Instituto Gulich (CONAE - UNC)
> Centro Espacial Teófilo Tabanera (CETT)
> Falda del Cañete - Córdoba, Argentina
> +54 3547 40 int. 1153
> https://veroandreo.gitlab.io/
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Error in installing r.futures addons in Pop!_OS 20.04

[Anna Petrášová]

You can also download the addons manually from github and then install them
with g.extension, see "Installing when writing a module locally" in
examples section of g.extension manual.

Anna

On Wed, Aug 11, 2021 at 8:16 AM Firman Hadi via grass-user <
grass-user@lists.osgeo.org> wrote:

> Dear Veronica,
>
> Thank you very much for the information.
>
> I use GRASS 7.8.5 provided by QGIS Ubuntu hirsute repository.
> It is Ubuntu 21.04, not 20.04 as I have informed earlier.
> I have upgraded to 7.8.5-1 from QGIS unstable repo, but since it's not
> GRASS 7.8.6.RC2, I can't install any add-ons.
> I will just wait for the stable release.
>
> Thanks.
>
> *Firman Hadi*
> E: firmanh...@me.com
> 
> P: +6281220001994
> W: http://www.sigro.org
> 
> [image: Facebook]
> [image:
> LinkedIn]
> [image:
> Twitter]
> [image:
> Instagram]
> 
> On Aug 11 2021, at 6:50 pm, Veronica Andreo  wrote:
>
> Dear Firman,
>
> What GRASS version are you using? g.extension is currently failing for
> GRASS 7.8.5. See
> https://grass.osgeo.org/news/2021_08_01_g_extension_currently_not_working/
> 
>  for
> an explanation and options.
>
> We released yesterday the second RC for grass 7.8.6 where this problem
> should be fixed: https://github.com/OSGeo/grass/releases/tag/7.8.6RC2
> 
>
> Best regards,
> Vero
>
> [image: Sent from Mailspring]
> El mar, 10 ago 2021 a las 10:20, Firman Hadi via grass-user (<
> grass-user@lists.osgeo.org>) escribió:
>
> Dear all,
>
> I tried to install r.futures addons in Ubuntu-based 20.04 system (Pop!_OS
> 20.04).
> The installation failed with the error message as follows:
> "svn: E17: URL 'https://github.co
> m/OSGeo/grass-addons/trunk/grass7/r.futures'
> doesn't exist"
>
> The modules can be found in this link '
> https://github.com/OSGeo/grass-addons/tree/grass7/src/raster/r.futures'
> 
> So, I used console to install with this command: g.extension
> extension=r.futures url="https://github.co
> m/OSGeo/grass-addons/tree/grass7/src/raster/r.futures"
> Then another error message was shown:
> "ERROR: Extension  not found. Please check 'url' and 'branch'
> options".
>
> Any help regarding the error would be very much appreciated.
>
> Best regards,
>
> *Firman Hadi*
> E: firmanh...@me.com
> 
> P: +6281220001994
> W: http://www.sigro.org
> 
> [image: Facebook]
> [image:
> LinkedIn]
> [image:
> Twitter]
> [image:
> 

Re: [GRASS-user] [GRASS-dev] GRASS 7.8.5 compile errors

[Anna Petrášová]

On Tue, Aug 10, 2021 at 10:06 AM Thomas Adams  wrote:

> Hi all!
>
> I just upgraded from Ubuntu 18.04 to 20.04 and have to re-compile/install
> GRASS 7.8.5. I'm getting these errors:
>
> Errors in:
> /home/teaiii/grass-7.8.5/lib/python/ctypes
> /home/teaiii/grass-7.8.5/vector/v.out.ogr
> /home/teaiii/grass-7.8.5/man
>

What are the actual errors when you go in the directories and run make?

>
> I'm sure I have created some library incompatibilities, so I'm trying to
> identify where the problems are. I know I have python 3.8 installed, but
> when I run python -V I get:
>
> Python 2.7.18
>
> Do I need to compile against python 3.8; if so, how do I do that?
>
> My configure looks like this:
>
> CFLAGS="-O2 -Wall" LDFLAGS="-s" ./configure \
> --enable-64bit \
> --with-cxx \
> --enable-largefile=yes \
> --with-nls \
> --with-readline \
> --with-pthread \
> --with-gdal=/usr/local/bin/gdal-config \
> --with-proj --with-proj-share=/usr/local/share/proj \
> --with-proj-includes=/usr/local/include \
> --with-proj-libs=/usr/local/lib \
> --with-geos=/usr/local/bin/geos-config \
> --with-wxwidgets=/usr/local/bin/wx-config \
> --with-cairo \
> --with-opengl-libs=/usr/include/GL \
> --with-freetype=yes \
> --with-freetype-includes=/usr/include/freetype2/ \
> --with-postgres=yes \
> --with-postgres-includes=/usr/local/include \
> --with-sqlite=yes \
> --with-mysql=yes \
> --with-mysql-includes=/usr/include/mysql \
> --with-odbc=no \
> --with-blas \
> --with-lapack \
> --with-liblas=yes \
> --with-liblas-config=/usr/bin/liblas-config \
> --with-netcdf=/usr/local/bin/nc-config \
> --with-blas-libs=/usr/local/lib \
> --with-lapack-includes=/usr/include \
> --with-lapack-libs=/usr/lib \
> --with-blas-includes=/usr/local/include \
> --with-zstd \
> --with-zstd-includes=/usr/local/include \
> --with-zstd-libs=/usr/local/lib
>
> with no errors.
>
> Any/all suggestions are appreciated...
>
> Regards,
> Tom
>
> --
>
> ___
> 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

Re: [GRASS-user] legend not showing in 3D view

[Anna Petrášová]

This has been reported as a bug:
https://trac.osgeo.org/grass/ticket/3743

On Sun, Apr 25, 2021 at 11:11 AM Veronica Andreo 
wrote:

> Hi Matthew,
>
> I can confirm this in GRASS-dev version and 7.8.5. Is this a bug or the
> raster legend is not supposed to appear while in 3d view?
>
> best,
> Vero
>
> El vie, 23 abr 2021 a las 22:51, Matthew Kratochvil ()
> escribió:
>
>> Hi
>> I am a new user to grass-GIS and I have been using the 3D view to
>> investigate bathymetry data. I have been trying to make legends for the 3D
>> view so I can make figures with them. Everytime I attempt to make a legend
>> for the 3D window for the raster I am investigating it ends up on the 2D
>> raster.
>>
>> I have followed the 3D view instructions that are in the NCSU video
>> series. I think I a missing something like a radio button or a check box.
>>
>> Please advise
>> Matt K
>> ___
>> 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] Problems using v.surf.idw

[Anna Petrášová]

On Mon, Apr 19, 2021 at 10:24 AM Veronica Andreo 
wrote:

> [bringing the issue back to the list for reference]
>
> Dear Luis,
>
> Thanks for your feedback!
>
> If you didn't provide a column name, and the module didn't fall back to
> the cat column as it is supposed to, please report it as a bug (ideally
> with a reproducible example). According to the manual and my very little
> understanding of the c code, it should.
>

Vero is right, I tested it and it does work as the manual describes, using
the values of categories in your case.

Anna

>
> All the best,
> Vero
>
> El lun, 19 abr 2021 a las 16:00, Luí­s Moreira de Sousa (<
> luis.de.so...@protonmail.ch>) escribió:
>
>> Hi Vero,
>>
>> from what I understand the module is seeking neither the value column,
>> not the cat column. This map was created with r.to.vect, these are its
>> attributes:
>>
>> > v.info -c soil_map_rcl_no_water
>> Displaying column types/names for database connection of layer <1>:
>> INTEGER|cat
>> INTEGER|value
>> CHARACTER|label
>>
>> If v.surf.idw was indeed seeking the cat column I would expect the module
>> to succeed with this input, producing a nice Voronoi map.
>>
>> My suggestion would be to explicitly reference the name of the default
>> column/attribute in the manual.
>>
>> Thank you.
>>
>> --
>> Luís
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Monday, April 19, 2021 1:56 PM, Veronica Andreo 
>> wrote:
>>
>> Dear Luis,
>>
>>
>> El lun, 19 abr 2021 a las 8:45, Luí­s Moreira de Sousa via grass-user (<
>> grass-user@lists.osgeo.org>) escribió:
>>
>>> Dear Anna,
>>>
>>> thank you for the reply, indeed once I added the column parameter the
>>> module completed successfully. The manual includes the following on this
>>> parameter:
>>>
>>>column=name
>>>Name of attribute column with values to interpolate
>>>If not given and input is 2D vector map then category values
>>> are used. If input is 3D vector
>>>map then z-coordinates are used.
>>>
>>> If I read that correctly, the module should pick up the "value" column
>>> by defualt. This particular layer was created by GRASS itself and includes
>>> a "value" column:
>>>
>>
>> I might be biased, but the description is clear to me: provide the name
>> of a column that contains the values/quantities that will be used to
>> interpolate. If you do not provide a column name, cat will be used (i.e.,
>> the IDs) in a 2D vector, or the z column in a 3D vector.
>>
>>
>>
>>>
>>> >  v.info -c soil_map_rcl_no_water
>>> Displaying column types/names for database connection of layer <1>:
>>> INTEGER|cat
>>> INTEGER|value
>>> CHARACTER|label
>>>
>>> It is now clear this is not the case, `v.surf.idw` is seeking another
>>> column by default, one that is not created by vector creating modules.
>>>
>>
>> It does not seek for another column, it defaults to cat if you do not
>> provide a column name where the variable you want to interpolate is. It
>> would be annoying, IMO, if I was forced to name a column `value` just
>> because a module only takes that name. Also, there might be many columns
>> with quantities/values in the attr table of a vector. How is the module
>> supposed to know which one to use, if the user does not provide a name?
>>
>> Perhaps this could be made more explicit in the manual page.
>>>
>>
>> Maybe the fact that value appears in the description and your column is
>> called value triggered the confusion?
>> We really appreciate any suggestions on how to improve the wording to
>> make it clearer.
>>
>> Best,
>> Vero
>>
>>
>>
>> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Problems using v.surf.idw

[Anna Petrášová]

Hi Luis,

could be because you haven't provided the attribute column. It should
probably fail with a message in this case...

Anna

On Fri, Apr 16, 2021 at 5:08 AM Luí­s Moreira de Sousa via grass-user <
grass-user@lists.osgeo.org> wrote:

> Hi all,
>
> I have been trying to use v.surf.idw the past few days without success.
>
> The image attached is a screen capture from the Map Display. There is a
> category
> raster (green regions) with a gap (lake Chad) that must be filled with the
> nearest neighbour category. The strategy is to create a points vector from
> the raster
> and then apply v.surf.idw with npoints=1.
>
> If the density of points is too high (> 10 000) the module fails with the
> message "Killed". With fewer points the module fails with the message
> "ERROR: No points found". Below is a log with an example. I have
> tried many different combinations of resolution and number of points, I
> also tried different mapsets, SQLite and Postgres back-ends, but the result
> is always the same.
>
> What can be going wrong?
>
> P.S.: there is previous thread with similar symptoms, but seems to have
> been a different issue:
> http://osgeo-org.1560.x6.nabble.com/v-surf-idw-Not-Working-td5457170.html
>
> Thank you.
>
> Luís
>
> GRASS 7.8.2 (S4AHomolosine):~ > g.region nsres=2 ewres=2 w=1474000
> n=1626000 e=176 s=1383000
> GRASS 7.8.2 (S4AHomolosine):~ > r.to.vect type=point
> input=soil_map_rcl_no_water output=soil_map_rcl_no_water --overwrite
> WARNING: Vector map  already exists and will be
>  overwritten
> Extracting points...
> 100%
> Building topology for vector map ...
> Registering primitives...
> r.to.vect complete.
> GRASS 7.8.2 (S4AHomolosine):~ > v.info soil_map_rcl_no_water
>
> ++
> | Name:
> soil_map_rcl_no_water |
> | Mapset:
> MAL   |
> | Location:
> S4AHomolosine |
> | Database:
> /home/duque004/Work/GRASSDATA |
> |
> Title: |
> | Map scale:
> 1:1   |
> | Name of creator:
> duque004  |
> |
> Organization:  |
> | Source date: Fri Apr 16 10:10:31
> 2021  |
> | Timestamp (first layer):
> none  |
>
> ||
> | Map format:
> native|
>
> ||
> |   Type of map: vector (level:
> 2)   |
> |
> |
> |   Number of points:   114 Number of centroids:
> 0  |
> |   Number of lines:0   Number of boundaries:
> 0  |
> |   Number of areas:0   Number of islands:
> 0  |
> |
> |
> |   Map is 3D:
> No   |
> |   Number of dblinks:
> 1|
> |
> |
> |   Projection:
> unknown  |
> |
> |
> |   N:   1615875S:
> 1393125 |
> |   E:  1749785.71428571W:
> 1484214.28571429 |
> |
> |
> |   Digitization threshold:
> 0|
> |
> Comment: |
> |
> |
>
> ++
>
> GRASS 7.8.2 (S4AHomolosine):~ > g.region nsres=100 ewres=100 w=1474000
> n=1626000 e=176 s=1383000
> GRASS 7.8.2 (S4AHomolosine):~ > v.surf.idw npoints=1
> input=soil_map_rcl_no_water output=soil_map_rcl_water_fill --overwrite
> Input vector map  is 2D - using categories to
> interpolate
> WARNING: No record for point (cat = 1)
> WARNING: No record for point (cat = 2)
> WARNING: No record for point (cat = 3)
> WARNING: No record for point (cat = 4)
> WARNING: No record for point (cat = 5)
> WARNING: No record for point (cat = 6)
> WARNING: No record for point (cat = 7)
> WARNING: No record for point (cat = 8)
> WARNING: No record for point (cat = 9)
> WARNING: No record for point (cat = 10)
> WARNING: No record for point (cat = 11)
> WARNING: No record for point (cat = 12)
> WARNING: No record for point (cat = 13)
> WARNING: No record for point (cat = 14)
> WARNING: No record for point (cat = 15)
> WARNING: No record for point (cat = 16)
> WARNING: No record for point (cat = 17)
> WARNING: No record for point (cat = 18)
> WARNING: No record for point (cat = 19)
> WARNING: No record for point (cat = 20)
> 

Re: [GRASS-user] grass-user Digest, Vol 180, Issue 4

[Anna Petrášová]

Hello,

On Sat, Apr 10, 2021 at 12:51 PM Timothy Glyn Southern via grass-user <
grass-user@lists.osgeo.org> wrote:

> Problem with wxpython guy in Manjaro with grass 7.8.5
>
> Dear colleagues,
>
> Following a period of low use due to health issues I am once again trying
> to use GRASS to visualise and analyse archaeological data.
>
> I am running Manjaro and the latest download of GRASS from AUR.
>
> It starts fine and shows both display windows for the GUI and then the
> windows crash. It is repeatable.
>
> I have tried removing GRASS and reinstalling but that has not fixed the
> issue. As well I have tried changing the flags on the GUI. None make any
> difference, as soon as the mouse is apparently moved the windows crash.
>
> Is this a known problem and is there a work around?
>

based on your description it sounds like a bug in wxPython with Python 3.9:
https://github.com/OSGeo/grass/issues/1123

Hope that helps,
Anna


> Thanks
>
> Tim Southern
> Dr Timothy Glyn Southern
> 0155 941 8432
> 0791 076 6814
>
>
>
>
>
> On 4 Apr 2021, at 20:00, grass-user-requ...@lists.osgeo.org wrote:
>
> Send grass-user mailing list submissions to
> grass-user@lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osgeo.org/mailman/listinfo/grass-user
> or, via email, send a message with subject or body 'help' to
> grass-user-requ...@lists.osgeo.org
>
> You can reach the person managing the list at
> grass-user-ow...@lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-user digest..."
>
>
> Today's Topics:
>
>   1. Re: r.watershed identify inland watershed (ming han)
>
>
> --
>
> Message: 1
> Date: Sat, 3 Apr 2021 16:23:26 -0400
> From: ming han 
> To: Micha Silver 
> Cc: GRASS user list 
> Subject: Re: [GRASS-user] r.watershed identify inland watershed
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Hi Micha
>
>I understand what you mean. But it requires another step to
> manually identify depressions from these pre-conditioned DEM.
>
> Cheers
> Ming
>
>
> Micha Silver  ?2021?4?3??? ??12:43???
>
>
> On 4/2/21 5:37 PM, ming han wrote:
>
> Maybe I am the only one who has this demand. Following is just a
> recommendation to GRASS r.watershed function.
> Maybe it is worth having an option to avoid r.watershed overcome
> depressions.
> The reasons are 1) there are many hydrologically pre condition DEM
> data available globally, such as:HydroSHEDS, MERIT
>2) the depression in these DEM are real
> depressions, overcome these depressions will make the entire drainage
> system
>
>
>
> Regarding Hydrosheds, the documentation[1] in section 3.4 explains how
> they overcame the problem of sinks. They performed a regular "fill
> sinks" operation on areas that were SRTM artifacts. True natural
> depressions were identified manually, then another manual procedure of
> carving rivers was done to force flow thru these depressions and produce
> hydrologically correct streams and basins. So pre-conditioning to
> overcome depressions is not a magic bullet...
>
>
> In my opinion, the best results are obtained when true depressions
> (pits, salt playas or karst regions) are identified, and set to NULL in
> the elevation raster. That will allow r.watershed to stop routing at
> those locations, and produce correct stream and basin layers.
>
>
> [1]https://hydrosheds.org/images/inpages/HydroSHEDS_TechDoc_v1_2.pdf
>
>
> incorrectly.
>
> I understand GRASS has other functions to solve this problem, but just
> a user recommendation. I use GRASS a lot.
>
> Thanks
> Ming
>
> ming han mailto:dustm...@gmail.com>>
> ?2021?3?30??? ??8:06???
>
>Got it, thanks everyone~
>Ming
>
>Micha Silver mailto:tsvi...@gmail.com>>
>?2021?3?29??? ??2:40???
>
>Hello:
>
>You might try `r.param.scale`, or even better `r.geomorphons`
>modules to
>identify geomorphology features, then filter out all pixels
>identified
>as pits.
>
>
>r.watershed is purposely designed to overcome depressions, and
>find flow
>routing thru these spots. So I don't think you can use that
>module to
>identify depressions.
>
>
>On 3/27/21 8:49 PM, ming han wrote:
>
> Hi  Everyone
>
> When I do watershed delineation using r.watershed for
>
>great salt
>
> lake watershed. I found r.watershed always tried to assign
>
>an outlet
>
> for a great salt lake, which does actually not exist because
>
>it is an
>
> inland lake and the great salt lake has no watershed outlet
>
>at all.
>
>
>  I noticed that there is a depression option. But is
>
>there any
>
> way that  r.watershed can automatically identify depressions
>
>while
>
> defining flow accumulation and stream network?
>
> Thanks
> Ming
>
> 

Re: [GRASS-user] r.futures.calib - Error

[Anna Petrášová]

Hi Tom,

I suspect the problem is in the delimiter, try to replace all the spaces in
the potential CSV file with commas. The default delimiter was changed
between FUTURES versions, so perhaps that might be the problem.

On Mon, Mar 1, 2021 at 11:57 AM Tom Hackbarth  wrote:

> Dear Grass-Users,
>
> I have a problem initiating the r.futures.calib module within the FUTURES
> model.
>
> Running the following code, I always get the same error message:
>
> *r.futures.calib --overwrite development_start=urban_2020@IKNmapset
> development_end=urban24CA3@IKNmapset repeat=5 compactness_mean=0.2
> compactness_range=0.05 discount_factor=0.2 patch_threshold=200
> patch_sizes=C:\Users\Student\Documents\TOM GIS\grass new\patcheshard.txt
> calibration_results=C:\Users\Student\Documents\TOM GIS\grass
> new\calibhard.csv nprocs=1 development_pressure=devpres_2020@IKNmapset
> incentive_power=0.2
> predictors=dist_Protec_km@IKNmapset,dist_to_urbancore_km@IKNmapset,dist_waterbodies_km@IKNmapset,Forest_smooth_perc_new@IKNmapset,roads_c_dens_perc@IKNmapset
> n_dev_neighbourhood=10 devpot_params=C:\Users\Student\Documents\TOM
> GIS\grass new\grassdata
> IKN\grassdata\newLocation\IKNmapset\.tmp/unknown\2080.0 num_neighbors=4
> seed_search=probability development_pressure_approach=gravity gamma=0.2
> scaling_factor=0.1 num_steps=3 subregions=Subregions_IKN@IKNmapset
> demand=C:\Users\Student\Documents\TOM GIS\grass new\grassdata
> IKN\Population data\Results rdemand\Demand_DG_lin*
>
> The error message is:
>
> *Analyzing original patches...*
> *Running calibration combination 1/1 of simulation attempt 1/5 with random
> seed 1...*
> *ERROR: Potential: wrong number of columns: ID Intercept devpressure_24_3
> dist_protec_km dist_to_urbancore_km dist_waterbodies_km
> forest_smooth_perc_new roads_c_dens_perc*
> *WARNING: No data base element files found*
> *ERROR: Running r.futures.pga failed. Details: Module run None
> r.futures.pga*
>
> Any idea what the problem might be? The potential input table seems fine
> to me (see picture below). I do not know what it could mean  that the
> number of columns is wrong, as I am not aware of any specifications or
> given requirements in the potential file for *r.futures.calib*.
>
> [image: image.png]
> Thanks in advance. I am happy for any help!
>
> Best regards
>
> Tom
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.futures.demand

[Anna Petrášová]

m,dist_to_pp_km,dist_toh20_
> 2016_km,per_forest_2016,,urban_change_01_16,county_rast
> separator=comma where=devclip_2016 IS NOT NULL AND
> devpress_0_5_2016 IS NOT NULL AND dist_to_evac_km IS NOT
> NULL AND dist_to_pp_km IS NOT NULL AND dist_toh20_2016_km IS
> NOT NULL AND per_forest_2016 IS NOT NULL AND  IS NOT NULL
> AND urban_change_01_16 IS NOT NULL AND county_rast IS NOT
> NULL file=/Volumes/Extreme
> SSD/grassdata/forecast2/PERMANENT/.tmp/Mitchells-MacBook-
> Pro.local/49600.0.csv ended with error
> Process ended with non-zero return code 1. See errors in the
> (error) output.
> (Thu Feb 11 14:09:44 2021) Command finished (0 sec)
>
>
>
>
> Cheers,
> Mitchell Meads, PhD Student
> Texas A University at Galveston
> Marine & Coastal Management Sciences; CTBS <http://www.tamug.edu/ctbs/>
> Email: mitchell.me...@tamu.edu
>
>
>
>
> On Thu, Feb 11, 2021 at 2:01 PM Anna Petrášová 
> wrote:
>
>> Hi Mitchell,
>>
>> looking at your command there are several things to fix. Parameter
>> columns should have only the predictors, so for example remove county_rast
>> and urban_change_01_16. Parameter developed_column should be the response
>> variable, so I suppose urban_change_01_16 is the one to use here. Lastly,
>> without the dredge mode only use combination of predictors that are not
>> correlated and don't represent the same info, for example, do not include
>> dist_toh20_2001_km,dist_toh20_2004_km,dist_toh20_2006,dist_toh20_2008_km,dist_toh20_2011_km,dist_toh20_2013_km,dist_toh20_2016_km,
>> since these all represent the same variable (I suppose). Without the dredge
>> mode, all provided predictors will be used in the model, with the dredge
>> mode, it will try different combinations and return the best model.
>>
>> Note r.futures.potential is basically just a wrapper around R glmer
>> (lme4) function, so if you are familiar with R, you can experiment with
>> finding a model directly in R if you need more flexibility etc.
>>
>> Please keep the conversation on this mailing list which is archived, so
>> that others can add to it or benefit from it later.
>>
>> Best,
>> Anna
>>
>> On Thu, Feb 11, 2021 at 2:12 PM Mitchell Meads 
>> wrote:
>>
>>> Hi Anna,
>>>
>>> I've revisited the r.futures.potential submodel for the futures modeling
>>> and I still can't get the r.futures.potential submodel to run. I've
>>> rescaled my variables so they all should be on a similar scale but the
>>> program is telling me that the variables are still not in appropriate scale
>>> along with some other error messages that I have copied below. Please let
>>> me know what you think I'm doing wrong.
>>>
>>> (Thu Feb 11 13:11:21 2021)
>>>
>>> r.futures.potential --overwrite input=sampling_f_km@PERMANENT
>>> output=potential_f_km.csv
>>> columns=devclip_2016,block_rast,county_rast,devpress_0_5_2016,dist_to_evac_km,dist_to_pp_km,dist_toh20_2001_km,dist_toh20_2004_km,dist_toh20_2006,dist_toh20_2008_km,dist_toh20_2011_km,dist_toh20_2013_km,dist_toh20_2016_km,per_forest_2001,per_forest_2004,per_forest_2006,per_forest_2008,per_forest_2011,per_forest_2013,per_forest_2016,urban_change_01_16
>>> developed_column=devclip_2016 subregions_column=county_rast min_variables=5
>>> max_variables=10
>>> Computing model...
>>> WARNING: fixed-effect model matrix is rank deficient so dropping 2
>>> columns / coefficients
>>> Error in pwrssUpdate(pp, resp, tol = tolPwrss, GQmat = GQmat, compDev =
>>> compDev,  :
>>> pwrssUpdate did not converge in (maxit) iterations
>>> Calls: glmer ...  ->  -> stopifnot -> fn ->
>>> pwrssUpdate
>>> In addition: Warning message:
>>> Some predictor variables are on very different scales: consider rescaling
>>> Execution halted
>>> WARNING: fixed-effect model matrix is rank deficient so dropping 2
>>> columns / coefficients
>>> Error in pwrssUpdate(pp, resp, tol = tolPwrss, GQmat = GQmat, compDev =
>>> compDev,  :
>>> pwrssUpdate did not converge in (maxit) iterations
>>> Calls: glmer ...  ->  -> stopifnot -> fn ->
>>> pwrssUpdate
>>> In addition: Warning message:
>>> Some predictor variables are on very different scales: consider rescaling
>>> Execution halted
>>> ERROR: Running R script failed, check messages above
>>> (Thu Feb 11 13:11:25 2021) Command finished (3 sec)
>>>
>>> Cheers,
>>> Mitchell Meads, PhD Student
>>> Texas A University at Galveston
>>> Marine &am

Re: [GRASS-user] r.futures.demand

[Anna Petrášová]

Hi Mitchell,

looking at your command there are several things to fix. Parameter columns
should have only the predictors, so for example remove county_rast and
urban_change_01_16. Parameter developed_column should be the response
variable, so I suppose urban_change_01_16 is the one to use here. Lastly,
without the dredge mode only use combination of predictors that are not
correlated and don't represent the same info, for example, do not include
dist_toh20_2001_km,dist_toh20_2004_km,dist_toh20_2006,dist_toh20_2008_km,dist_toh20_2011_km,dist_toh20_2013_km,dist_toh20_2016_km,
since these all represent the same variable (I suppose). Without the dredge
mode, all provided predictors will be used in the model, with the dredge
mode, it will try different combinations and return the best model.

Note r.futures.potential is basically just a wrapper around R glmer (lme4)
function, so if you are familiar with R, you can experiment with finding a
model directly in R if you need more flexibility etc.

Please keep the conversation on this mailing list which is archived, so
that others can add to it or benefit from it later.

Best,
Anna

On Thu, Feb 11, 2021 at 2:12 PM Mitchell Meads 
wrote:

> Hi Anna,
>
> I've revisited the r.futures.potential submodel for the futures modeling
> and I still can't get the r.futures.potential submodel to run. I've
> rescaled my variables so they all should be on a similar scale but the
> program is telling me that the variables are still not in appropriate scale
> along with some other error messages that I have copied below. Please let
> me know what you think I'm doing wrong.
>
> (Thu Feb 11 13:11:21 2021)
>
> r.futures.potential --overwrite input=sampling_f_km@PERMANENT
> output=potential_f_km.csv
> columns=devclip_2016,block_rast,county_rast,devpress_0_5_2016,dist_to_evac_km,dist_to_pp_km,dist_toh20_2001_km,dist_toh20_2004_km,dist_toh20_2006,dist_toh20_2008_km,dist_toh20_2011_km,dist_toh20_2013_km,dist_toh20_2016_km,per_forest_2001,per_forest_2004,per_forest_2006,per_forest_2008,per_forest_2011,per_forest_2013,per_forest_2016,urban_change_01_16
> developed_column=devclip_2016 subregions_column=county_rast min_variables=5
> max_variables=10
> Computing model...
> WARNING: fixed-effect model matrix is rank deficient so dropping 2 columns
> / coefficients
> Error in pwrssUpdate(pp, resp, tol = tolPwrss, GQmat = GQmat, compDev =
> compDev,  :
> pwrssUpdate did not converge in (maxit) iterations
> Calls: glmer ...  ->  -> stopifnot -> fn ->
> pwrssUpdate
> In addition: Warning message:
> Some predictor variables are on very different scales: consider rescaling
> Execution halted
> WARNING: fixed-effect model matrix is rank deficient so dropping 2 columns
> / coefficients
> Error in pwrssUpdate(pp, resp, tol = tolPwrss, GQmat = GQmat, compDev =
> compDev,  :
> pwrssUpdate did not converge in (maxit) iterations
> Calls: glmer ...  ->  -> stopifnot -> fn ->
> pwrssUpdate
> In addition: Warning message:
> Some predictor variables are on very different scales: consider rescaling
> Execution halted
> ERROR: Running R script failed, check messages above
> (Thu Feb 11 13:11:25 2021) Command finished (3 sec)
>
> Cheers,
> Mitchell Meads, PhD Student
> Texas A University at Galveston
> Marine & Coastal Management Sciences; CTBS <http://www.tamug.edu/ctbs/>
> Email: mitchell.me...@tamu.edu
>
>
>
>
> On Sat, Jan 23, 2021 at 9:54 PM Anna Petrášová 
> wrote:
>
>> Hi Mitchell,
>>
>> On Fri, Jan 22, 2021 at 3:23 PM Mitchell Meads 
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm getting an error when running r.futures.demand that says "Number of
>>> development raster maps doesn't not correspond to the number of observed
>>> times". I thought that a fix for this would be to make sure my input
>>> population csv had years that matched the input raster maps in the first
>>> column but this didn't change the error. If you could let me know what you
>>> think I'm doing wrong, that would be greatly appreciated!
>>>
>>
>> The error means the number of raster maps in the development parameter
>> does not match the number of years in the observed_population CSV. So for
>> example, if you specify development=urban_2001,urban_2006,urban_2011 (3
>> maps) then the observed_population file should look like this (header + 3
>> lines):
>>
>> year,37037,37063,...
>> 2001,19860,10980,...
>> 2006,20760,12660,...
>> 2011,21070,13090,...
>>
>> If you can't see any obvious mistake with your data, I would have to see
>> the r.futures.demand command you are trying to execute and the input CSV
>> file.
>>
>>
>>>
>>>

Re: [GRASS-user] [GRASS-dev] ASF - OGC - OSGeo code sprint - Feb 17-19, 2021

[Anna Petrášová]

Hi Vero,

we registered for this, we probably won't participate 100% of the time, but
hope to see other GRASS devs there.

Anna & Vaclav

On Thu, Feb 11, 2021 at 9:16 AM Veronica Andreo 
wrote:

> Hello everyone :)
>
> Shall we join the 2021 Joint ASF – OGC – OSGeo Code Sprint [0]?
>
> AFAIU, the focus is on OGC standards implementation. Is anyone in the
> GRASS community currently working on that and wishes to participate? They
> have created a repo with further details [1] in case you are interested.
>
> Best,
> Vero
>
> [0] https://portal.ogc.org/public_ogc/register/20210217_code_sprint.php
> [1] https://github.com/opengeospatial/joint-ogc-osgeo-asf-sprint-2021
> ___
> 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

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

[Anna Petrášová]

On Tue, Feb 9, 2021 at 4:41 PM Chris Bartolomei  wrote:

> Hi Anna - thank you for the suggestion - I tried it but alas, still it
> only outputs a single vector map (layer). I can get either the Country
> vector or the admin_areas vector, but not both overlaid.
> :(
> Chris
>

I realized you are using both environmental variables and d.mon, that might
cause some issues, you use one or the other. So try to remove the lines
starting with d.mon.

Hope that helps,
Anna

>
> On Tuesday, February 9, 2021, 1:20:52 PM EST, Anna Petrášová <
> kratocha...@gmail.com> wrote:
>
>
> Hi,
>
> On Tue, Feb 9, 2021 at 10:25 AM Chris Bartolomei via grass-user <
> grass-user@lists.osgeo.org> wrote:
>
> Good morning :)
> I'm using GRASS 7.4.1 on a Linux cluster so I only have command-line
> capability. I have two vector layers (a country boundary polygon and part
> of an administrative area map - also polygons). I am trying to automate
> creating a PNG file of the admin areas overlaying the country boundary
> therefore all work has to be command-line (in a bash script). I've tried
> this two ways - using the d.mon start=png method and also the ps.map method
> as described below. The d.mon method appears to generate the image with
> only one vector map (not both) and only colors the borders - it won't use
> the fill_color setting. The ps.map method seems to work but assumes the
> image is on a sheet of paper so there's a ton of extra white-space. I'd
> like to use d.mon but I can use ps.map if someone could please let me know
> how to export only the computational region without all the extra 'paper'
> in the image. Here's my code:
>
> g.region vector='Country'
> export GRASS_RENDER_IMMEDIATE=png
> export GRASS_RENDER_WIDTH=640
> export GRASS_RENDER_HEIGHT=480
> export GRASS_RENDER_TRANSPARENT=true
> export GRASS_RENDER_TRUECOLOR=true
> export GRASS_RENDER_FILE=$HOME/country_admin.png
> export GRASS_RENDER_FILE_COMPRESSION=0
> export GRASS_MESSAGE_FORMAT=plain
> d.mon start=png
> d.vect map=Country color=210:210:210 fill_color=153:153:153 display=shape
> type=area
> d.vect map=admin_area color=153:153:153 rgb_column=area_color
> display=shape type=area
> d.mon stop=png
>
> This only produces a png with the last vector listed and only the borders
> are colored with the rgb_column values.
>
>
> I think you are missing  GRASS_RENDER_FILE_READ=TRUE:
> https://grass.osgeo.org/grass78/manuals/pngdriver.html
>
> Regarding rgb_column, I am not sure, didn't have time to test.
>
> Anna
>
>
> If I do this without the d.mon start/stop lines ... i.e. relying on the
> GRASS_RENDER_IMMEDIATE=png only, then only one vector map is converted to
> png however it DOES do the color fill properly. With either above method
> the png is the correct size.
>
> Now using ps.map (same env variable set as above):
>
> g.region vector='Country'
> ps.map input=$HOME/ps_rules.txt out=$HOME/country_admin.ps --overwrite
>   where ps_rules.txt is:
> border y
>   color 81:81:81
>   end
> vareas admin_area
>   layer 1
>   rgbcolumn area_color
>   color 153:153:153
>   end
> vareas Country
>   color 210:210:210
>   fcolor 153:153:153
>   end
>
> We don't have pstopng but we do have ghostscript:
>
> gs-dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dTextAlphaBits=4
> -dGraphicsAlphaBits=4 -r300 -sOutputFile=$HOME/country_admin.png $HOME/
> country_admin.ps
>
> This creates the correct image (color fills, etc) but has white margins
> and a lot of white space below the image like it is printed at the top of
> a piece of paper.
>
> does anyone have any idea how to create a png with multiple vector maps
> overlaying each other (and not have the extra whitespace too)?
>
> v/r
> Chris
>
> ___
> 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] Creating a png file with multiple vector maps

[Anna Petrášová]

Hi,

On Tue, Feb 9, 2021 at 10:25 AM Chris Bartolomei via grass-user <
grass-user@lists.osgeo.org> wrote:

> Good morning :)
> I'm using GRASS 7.4.1 on a Linux cluster so I only have command-line
> capability. I have two vector layers (a country boundary polygon and part
> of an administrative area map - also polygons). I am trying to automate
> creating a PNG file of the admin areas overlaying the country boundary
> therefore all work has to be command-line (in a bash script). I've tried
> this two ways - using the d.mon start=png method and also the ps.map method
> as described below. The d.mon method appears to generate the image with
> only one vector map (not both) and only colors the borders - it won't use
> the fill_color setting. The ps.map method seems to work but assumes the
> image is on a sheet of paper so there's a ton of extra white-space. I'd
> like to use d.mon but I can use ps.map if someone could please let me know
> how to export only the computational region without all the extra 'paper'
> in the image. Here's my code:
>
> g.region vector='Country'
> export GRASS_RENDER_IMMEDIATE=png
> export GRASS_RENDER_WIDTH=640
> export GRASS_RENDER_HEIGHT=480
> export GRASS_RENDER_TRANSPARENT=true
> export GRASS_RENDER_TRUECOLOR=true
> export GRASS_RENDER_FILE=$HOME/country_admin.png
> export GRASS_RENDER_FILE_COMPRESSION=0
> export GRASS_MESSAGE_FORMAT=plain
> d.mon start=png
> d.vect map=Country color=210:210:210 fill_color=153:153:153 display=shape
> type=area
> d.vect map=admin_area color=153:153:153 rgb_column=area_color
> display=shape type=area
> d.mon stop=png
>
> This only produces a png with the last vector listed and only the borders
> are colored with the rgb_column values.
>

I think you are missing  GRASS_RENDER_FILE_READ=TRUE:
https://grass.osgeo.org/grass78/manuals/pngdriver.html

Regarding rgb_column, I am not sure, didn't have time to test.

Anna

>
> If I do this without the d.mon start/stop lines ... i.e. relying on the
> GRASS_RENDER_IMMEDIATE=png only, then only one vector map is converted to
> png however it DOES do the color fill properly. With either above method
> the png is the correct size.
>
> Now using ps.map (same env variable set as above):
>
> g.region vector='Country'
> ps.map input=$HOME/ps_rules.txt out=$HOME/country_admin.ps --overwrite
>   where ps_rules.txt is:
> border y
>   color 81:81:81
>   end
> vareas admin_area
>   layer 1
>   rgbcolumn area_color
>   color 153:153:153
>   end
> vareas Country
>   color 210:210:210
>   fcolor 153:153:153
>   end
>
> We don't have pstopng but we do have ghostscript:
>
> gs-dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dTextAlphaBits=4
> -dGraphicsAlphaBits=4 -r300 -sOutputFile=$HOME/country_admin.png $HOME/
> country_admin.ps
>
> This creates the correct image (color fills, etc) but has white margins
> and a lot of white space below the image like it is printed at the top of
> a piece of paper.
>
> does anyone have any idea how to create a png with multiple vector maps
> overlaying each other (and not have the extra whitespace too)?
>
> v/r
> Chris
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Error launching GUI in latest verison of trunk

[Anna Petrášová]

Could you create an issue for that? Does this happen with other locations
as well?

On Sun, Feb 7, 2021 at 11:29 PM Eric Patton 
wrote:

> On 21/02/07 10:32PM, Anna Petrášová wrote:
> > Before looking more into this, have you tried make distclean?
> >
> > Anna
>
> Yes. It also persists with a fresh checkout of grass/master.
>
> I forgot to mention that just before the GUI crashes, a dialog box pops up
> that
> says "Enable to get the geographic extent. Force quitting wxGUI. Please run
> g.region manually to fix the problem."
>
> Runing g.region -p prints the following:
>
> g.region -p
> projection: 99 (unnamed)
> zone:   0
> datum:  wgs84
> ellipsoid:  wgs84
> north:  -383300
> south:  -918400
> west:   -951200
> east:   764600
> nsres:  100
> ewres:  100
> rows:   5351
> cols:   17158
> cells:  91812458
> free(): invalid pointer
> Aborted (core dumped)
>
>
> $ g.version -er
> GRASS 7.9.dev (2021)
> libgis revision: 2021-02-08T04:01:23+00:00
> libgis date: 2021-02-07T12:00:00-04:00
> PROJ: 7.0.1
> GDAL/OGR: 3.2.1
> GEOS: 3.9.0
> SQLite: 3.31.1
>
> $ wx-config --version
> 3.04
>
> --
> Eric
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Anna Petrášová]

In the r.futures.potential command you have some of the column names
incorrect:
developed_column=urban_change_clip1@IKNmapset
subregions_column=Subregions_IKN@IKNmapset

Remove the @mapset part, that should do it.

Please 'reply to all' to keep the conversation on the mailing list.

On Mon, Feb 8, 2021 at 5:16 AM Tom Hackbarth  wrote:

> Hi Anna,
>
> thank you for the reply!
>
> The results of v.db.select are attached in the .txt file.
>
> v.info gives me the following information:
>
>  
> ++
>  | Name:sampling3
> |
>  | Mapset:  IKNmapset
> |
>  | Location:newLocation
> |
>  | Datenbank:   C:\Users\txhac\Documents\Uni\Master\Master
> Thesis\grassda |
>  | Titel:   Output from v.patch
> |
>  | Maßstab: 1:1
> |
>  | Name des Erzeugers:txhac
> |
>  | Organisation:
>|
>  | Quelldatum:  Sat Feb 06 15:55:09 2021
>|
>  | Timestamp (first layer): none
>|
>
>  
> ||
>  | Kartenformat:native
>|
>
>  
> ||
>  |   Kartenart:: Vektor (level: 2)
>|
>  |
>|
>  |   Anzahl der Punkte:  6000Anzahl der Zentroide: 0
>|
>  |   Anzahl der Linien:  0   Anzahl der Grenzen:   0
>|
>  |   Anzahl der Flächen: 0   Anzahl der Inseln:0
>|
>  |
>|
>  |   Map is 3D:  No
> |
>  |   Anzahl der dblinks: 1
>|
>  |
>|
>  |   Projektion: UTM (Zone 50S)
> |
>  |
>|
>  |   N:   9928525S:   9858735
> |
>  |   E:529655W:447765
> |
>  |
>|
>  |   Digitalisierungs-Schwellwert:: 0
> |
>  |   Kommentar:
> |
>  |
>|
>
>  
> ++
>
>
>
>
> Am Mo., 8. Feb. 2021 um 04:39 Uhr schrieb Anna Petrášová <
> kratocha...@gmail.com>:
>
>> Hi,
>>
>> that would indicate some issue with your sampling3 vector. Could you post
>> here the output of v.info sampling3 and v.db.select sampling3?
>>
>> On Sun, Feb 7, 2021 at 5:06 AM Tom Hackbarth 
>> wrote:
>>
>>> Dear all,
>>>
>>> anyone ever had problems with opening the select-cursor. I do not know
>>> what the problem is and tried to change input parameters several times, but
>>> whenever I want to run r.futures.potential, I get the same error message: 
>>> unable
>>> to open select-cursor.
>>>
>>> If anybody ever had similar problems and knows how to deal with it, I
>>> would be very happy if you would share the solution with me. Or is there
>>> anyone who might have some ideas on how to fix this?
>>>
>>> Thanks already in advance!
>>>
>>> The error message can be seen at the end of this mail.
>>>
>>> Best regards
>>>
>>> Tom
>>>
>>>
>>>
>>> r.futures.potential --overwrite input=sampling3@IKNmapset
>>> output=potential.csv
>>> columns=devpressure_02_24,road_dens_perc,forest_smooth_perc,dist_roads_km,dist_to_forests_km,dist_to_urbancore_km,dist_waterbodies_km
>>> developed_column=urban_change_clip1@IKNmapset
>>> subregions_column=Subregions_IKN@IKNmapset
>>> ERROR: Kann den Select-Cursor nicht öffnen.
>>> Traceback (most recent call last):
>>>   File "C:\Users\txhac\AppData\Roaming\GRASS7\addons/scripts
>>> /r.futures.potential.py", line 221, in 
>>> sys.exit(main())
>>>   File "C:\Users\txhac\AppData\Roaming\GRASS7\addons/scripts
>>> /r.futures.potential.py", line 168, in main
>>> columns="distinct {level}".format(level=level)).strip()
>>>   File "D:\Programme\apps\grass\grass78\etc\python\grass\scr
>>> ipt\core.py", line 503, in read_command
>>> return handle_errors(returncode, stdout, args, kwargs)
>>>   File "D:\Programme\apps\grass\grass78\etc\python\grass\scr
>>> ipt\core.py", line 343, in handle_errors
>>> returncode=returncode)
>>> grass.exceptions.CalledModuleError: Module run None
>>> v.db.select -c map=sampling3@IKNmapset columns=distinct
>>> Subregions_IKN@IKNmapset ended with error
>>> Process ended with non-zero return code 1. See errors in the
>>> (error) output.
>>> (Sun Feb  7 11:00:09 2021) Befehl ausgeführt (0 Sek)
>>> ___
>>> 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.futures.potential - unable to open select-cursor

[Anna Petrášová]

Hi,

that would indicate some issue with your sampling3 vector. Could you post
here the output of v.info sampling3 and v.db.select sampling3?

On Sun, Feb 7, 2021 at 5:06 AM Tom Hackbarth  wrote:

> Dear all,
>
> anyone ever had problems with opening the select-cursor. I do not know
> what the problem is and tried to change input parameters several times, but
> whenever I want to run r.futures.potential, I get the same error message: 
> unable
> to open select-cursor.
>
> If anybody ever had similar problems and knows how to deal with it, I
> would be very happy if you would share the solution with me. Or is there
> anyone who might have some ideas on how to fix this?
>
> Thanks already in advance!
>
> The error message can be seen at the end of this mail.
>
> Best regards
>
> Tom
>
>
>
> r.futures.potential --overwrite input=sampling3@IKNmapset
> output=potential.csv
> columns=devpressure_02_24,road_dens_perc,forest_smooth_perc,dist_roads_km,dist_to_forests_km,dist_to_urbancore_km,dist_waterbodies_km
> developed_column=urban_change_clip1@IKNmapset
> subregions_column=Subregions_IKN@IKNmapset
> ERROR: Kann den Select-Cursor nicht öffnen.
> Traceback (most recent call last):
>   File "C:\Users\txhac\AppData\Roaming\GRASS7\addons/scripts
> /r.futures.potential.py", line 221, in 
> sys.exit(main())
>   File "C:\Users\txhac\AppData\Roaming\GRASS7\addons/scripts
> /r.futures.potential.py", line 168, in main
> columns="distinct {level}".format(level=level)).strip()
>   File "D:\Programme\apps\grass\grass78\etc\python\grass\scr
> ipt\core.py", line 503, in read_command
> return handle_errors(returncode, stdout, args, kwargs)
>   File "D:\Programme\apps\grass\grass78\etc\python\grass\scr
> ipt\core.py", line 343, in handle_errors
> returncode=returncode)
> grass.exceptions.CalledModuleError: Module run None
> v.db.select -c map=sampling3@IKNmapset columns=distinct
> Subregions_IKN@IKNmapset ended with error
> Process ended with non-zero return code 1. See errors in the
> (error) output.
> (Sun Feb  7 11:00:09 2021) Befehl ausgeführt (0 Sek)
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Error launching GUI in latest verison of trunk

[Anna Petrášová]

Before looking more into this, have you tried make distclean?

Anna

On Sun, Feb 7, 2021 at 5:20 PM Eric Patton via grass-user <
grass-user@lists.osgeo.org> wrote:

> Hi,
>
> I forget if these kind of errors should go to the dev list or the user's
> list, it's been so long since I've been on dev.
>
> Anyway, I get the following error launching the GUI after updating my git
> repo to Feb. 7th:
>
> Details:  Traceback (most recent call last):
>   File "/home/epatton/.grass7/addons/scripts/r.mblend", line 281, in
> 
> gscript.use_temp_region()
>   File "/usr/local/grass79/etc/python/grass/script/core.py", line 1285, in
> use_temp_region
> run_command("g.region", flags="u", save=name, overwrite=True)
>   File "/usr/local/grass79/etc/python/grass/script/core.py", line 501, in
> run_command
> return handle_errors(returncode, result=None, args=args, kwargs=kwargs)
>   File "/usr/local/grass79/etc/python/grass/script/core.py", line 393, in
> handle_errors
> raise CalledModuleError(module=module, code=code,
> grass.exceptions.CalledModuleError: Module run g.region g.region --o -u
> save=tmp.r.mblend.265507 ended with error
> Process ended with non-zero return code -6. See errors in the (error)
> output.
>
> This is Grass 7.9 on Linux Mint 20.1.
>
> --
> Eric Patton
>
>
> ___
> 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.futures.demand

[Anna Petrášová]

Hi Mitchell,

On Fri, Jan 22, 2021 at 3:23 PM Mitchell Meads 
wrote:

> Hi all,
>
> I'm getting an error when running r.futures.demand that says "Number of
> development raster maps doesn't not correspond to the number of observed
> times". I thought that a fix for this would be to make sure my input
> population csv had years that matched the input raster maps in the first
> column but this didn't change the error. If you could let me know what you
> think I'm doing wrong, that would be greatly appreciated!
>

The error means the number of raster maps in the development parameter does
not match the number of years in the observed_population CSV. So for
example, if you specify development=urban_2001,urban_2006,urban_2011 (3
maps) then the observed_population file should look like this (header + 3
lines):

year,37037,37063,...
2001,19860,10980,...
2006,20760,12660,...
2011,21070,13090,...

If you can't see any obvious mistake with your data, I would have to see
the r.futures.demand command you are trying to execute and the input CSV
file.


>
>
> Cheers,
> Mitchell
>
>
> ___
> 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] Statement Anna Petrasova

[Anna Petrášová]

Dear GRASS community,

Thank you for the PSC nomination! I have been involved in GRASS GIS
development for ten years now, being a PSC member since 2016. I have been
mostly focusing on GUI development, but I am familiar with most parts of
the codebase. As a PhD student and now working in academia I have been
teaching geospatial modeling in GRASS, leading numerous workshops, and
helping students individually as well as supporting the broader scientific
community on mailing lists. After participating in Google Summer of Code as
a student, I mentored and co-mentored several GSoC students with projects
focusing e.g. on Python 3 support and new start-up.

I am really excited from the many changes GRASS underwent recently
including transitioning to GitHub, which increased the outside
contributions, attracted more developers, and increased code quality. I
would like to continue that trend by making sure current and new devs are
supported with high quality code reviews and more readable and documented
code in general. Also I hope to participate in programs attracting new
developers such as GSoC.

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

Re: [GRASS-user] Contribution to GRASS GIS

[Anna Petrášová]

On Sat, Jan 9, 2021 at 1:27 PM ASHUTOSH MITRA 
wrote:

> Dear community members,
>
> I am Ashutosh Mitra from India. I am pursuing a masters in Geoinformatics
> from CSRE, IIT Bombay. I have had exposure to ArcGIS, GRASS GIS, spatial
> database, QGIS, etc. in the past. Also, I have done projects in GIS for
> making an AR app for COVID19 to detect the number of cases in a particular
> direction. And another project for detecting straight lines in an image
> using Hough Transform. Currently, I am studying courses like GIS and Remote
> sensing applications to hydrocarbon and mineral exploration.
>
> I am very much interested in contributing to the open-source community as
> it will help to improve my skills, build connections and learn new things.
>
> Thus, I would like to contribute to OSGEO in Google Summer of Code 2021
> for the project
>
> · *GRASS GUI: Single window layout*
>
> Link to my projects:
>
> https://github.com/Ashutoshmitra/Hough_Transform
>
> https://github.com/Ashutoshmitra/AR-app-for-COVID19
>
> I would be grateful if I could get direction to proceed from your side.
>
> Regards
>
> Ashutosh Mitra
>


Hello Ashutosh,

thank you for contacting us! You are a little bit ahead of us, we will
create the 2021 GSoC page shortly, perhaps adding other topics. If you are
interested in Single window layout, please go ahead with the test of skills
as listed on the 2020 GSoC page [1]. Additionally, check GRASS GitHub page
for GUI bugs and enhancements, since this topic requires you to be quite
familiar with the existing GUI code base. To start, try e.g. issue 1189 [2].

Best,
Anna

[1] https://trac.osgeo.org/grass/wiki/GSoC/2020
[2] https://github.com/OSGeo/grass/issues/1189
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to find elevation drop for all cells in a basin

[Anna Petrášová]

On Tue, Dec 15, 2020 at 1:10 PM Ken Mankoff  wrote:

>
> Specifically, I have outlets and basins. I can find the (x,y) location of
> the outlet for every cell in each basin using the following code. Note that
> I'm doing this for all cells in the basin, not just stream cells. The
> r.stream.order does provide elev_drop. I'd like this for non-stream cells
> too, for each basin.
>
> Assuming that I have a outlets with unique IDs, I can create basins for
> each outlet with:
>
> # dir comes from r.stream.extract
> r.stream.basins -m direction=dir points=outlets basins=basins
>
> g.copy basins,cat_x
> g.copy basins,cat_y
>
> I can then export the x and y location of each outlet to a file:
>
> r.out.xyz input=outlets | awk -F'|' '{print $3, $1}' > ./tmp/outlets_x
> r.out.xyz input=outlets | awk -F'|' '{print $3, $2}' > ./tmp/outlets_y
>
> I can then copy my basins (same categories as outlets) and change the
> category to x and y.
>
> r.category map=cat_x rules=./tmp/outlets_x separator=space
> r.category map=cat_y rules=./tmp/outlets_y separator=space
>
> Note: There is probably a way to combine the above r.out.xyz and
> r.category commands so that I don't need to use a temporary disk file.
>
> Finally, convert x and y from category to value
>
> r.mapcalc "outlet_x = @cat_x"
> r.mapcalc "outlet_y = @cat_y"
>
>
> I can then use outlet_x and outlet_y, for example in r.mapcalc to find the
> direct distance between each inland cell and the outlet:
>
> r.mapcalc "dist = (outlet_x^2 + outlet_y^2)^(0.5)"
>
> Rather than finding the distance from each inland cell to its outlet, I'd
> like to find the elevation change from each inland cell to its outlet. Is
> this possible to do efficiently in the Bash interface to GRASS? I can do it
> with some loops in Python but prefer to stay in Bash if possible.
>
>
I admit I haven't read the entire email, but isn't r.stream.distance what
you need?

Anna


> Thanks,
>
>   -k.
> ___
> 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.futures not working

[Anna Petrášová]

Thanks Helmut for figuring it out! I was wondering is it clear now what
were the problems? I thought a summary might be useful if we encounter this
again...

Anna

On Sun, Dec 13, 2020 at 7:05 AM Helmut Kudrnovsky  wrote:

> >Ok got it, I just had to run R as administrator and download it then. >I
> think everything works now. Helmut, I don't know how I can thank >you. I
> hope we meet one day so that I can invite you to a coffee or >whatever you
> wish
>
> you're welcome. yes you have to install R packages as administrator to be
> available system wide.
>
> feel free donate to the GRASS GIS project
> (https://grass.osgeo.org/contribute/donations/)
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Anna Petrášová]

Hi Tom,

On Thu, Dec 10, 2020 at 4:24 AM Tom Hackbarth  wrote:

> Hi Anna,
>
> thanks for your answer.
>
> I reinstalled it already multiple times. I get the same error message
> every time though. I will try it on a mac tomorrow, but that is the last
> idea I have. Has there ever been a problem like this using r.futures? It's
> such a shame because I really want to use it for my Master's Thesis as it
> is capable of all the things that I need to do for it, but I cannot get
> it to work.
>

I am not sure why reinstalling doesn't work and I am myself on Linux
so can't test now. You can try to paste a line like this:

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

in the GRASS terminal (the black one), you need to change the path to R
based on your R installation. Then try to run Rscript in the terminal, just
to see if the binary can now be found. If yes, try to run
r.futures.potential. This temporarily changes the PATH variable so that
your system can find R, once you close GRASS, you need to repeat this next
you need to run it. Let us know if at least this works.

Anna


>
> Best regards
>
> Tom
>
> Am Mi., 9. Dez. 2020 um 15:01 Uhr schrieb Anna Petrášová <
> kratocha...@gmail.com>:
>
>>
>>
>> On Wed, Dec 9, 2020 at 8:37 AM Tom Hackbarth 
>> wrote:
>>
>>> Dear grass users,
>>>
>>> I am trying to work my way through the r.futures workshop (
>>> https://grasswiki.osgeo.org/wiki/Workshop_on_urban_growth_modeling_with_FUTURES#Potential_submodel),
>>> but as soon as I get to the point of using the first r.futures module -
>>> r.futures-potential I come to a dead end.
>>>
>>> This is the message I get:
>>>
>>> ___
>>>
>>> r.futures.potential input=sampling@practice1 output=potential.csv
>>> columns=devpressure_0_5_92,road_dens_perc,forest_1992_smooth_perc,dist_to_water_km,dist_to_protected_km
>>> developed_column=urban_change_clip subregions_column=counties
>>> Computing model...
>>> Traceback (most recent call last):
>>>   File "C:\Users\\AppData\Roaming\GRASS7\addons/scripts
>>> /r.futures.potential.py", line 221, in 
>>> sys.exit(main())
>>>   File "C:\Users\\AppData\Roaming\GRASS7\addons/scripts
>>> /r.futures.potential.py", line 192, in main
>>> p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
>>> stderr=subprocess.PIPE)
>>>   File "D:\Programme\apps\Python37\lib\subprocess.py", line
>>> 756, in __init__
>>> restore_signals, start_new_session)
>>>   File "D:\Programme\apps\Python37\lib\subprocess.py", line
>>> 1155, in _execute_child
>>> startupinfo)
>>> FileNotFoundError: [WinError 2] The system cannot find the file
>>> specified)
>>>
>>> _
>>>
>>> There seems to be a problem with the Python code. I also tried to work
>>> it out on linux manjaro, but I get more or less the same error message in
>>> the End.
>>>
>>> Is there anyone who can help me on this? I came not even close to
>>> repairing the error, so I am happy about any advice one can give me.
>>>
>>> Thank you in advance.
>>>
>>> Copying response from grass-web:
>>
>> r.futures.potential calls Rscript, so the error means it can't find the
>> Rscript binary. If R is installed, I would recommend reinstalling GRASS,
>> during installation it tries to automatically look for it, so there is a
>> chance it will work then. I would recommend subscribing to grass-user
>> mailing list and ask more questions there.
>>
>> Anna
>>
>>
>>> Best regards
>>>
>>> Tom
>>> ___
>>> 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] unstable results with r.param.scale ?

[Anna Petrášová]

Don't have time right now, but running it with valgrind might show the
problem.

Anna

On Wed, Dec 9, 2020 at 8:27 AM Vincent Bain  wrote:

> Hello Vincent,
>
> in case it could be related to my recent issue with r.param.scale:
>
> https://lists.osgeo.org/pipermail/grass-user/2020-October/081788.html
>
> In my case there was most probably something wrong with my OpenMP
> configuration.
>
> HTH,
> Vincent.
>
> Le mercredi 09 décembre 2020 à 13:59 +0100, Vincent Godard a écrit :
> > Dear Grass users,
> >
> > I've been using r.param.scale to compute various type of curvatures
> > over
> > a 1 m LiDAR DEM (FCELL) (from opentopography.org) :
> >
> > r.param.scale --o -c input=dem output=curvature size=15 method=profc
> > r.info -r curvature
> >
> > I usually get reasonable results like (checked with independent
> > calculations) :
> >
> > min=-0.203124601340989
> > max=0.0685868278408049
> >
> > But when running this command repeatedly, I randomly (usually every
> > 3rd
> > or 4th time) get very different results like :
> >
> > min=-127112309.998249
> > max=131128979.492382
> >
> > I am running GRASS 7.8.4 on Ubuntu 20.04. The problem is also
> > present
> > when running r.param.scale from QGIS or rgrass7 (in a R session).
> >
> > I have replicated the problem with another high resolution DEM of
> > different source (still FCELL), and also with a 30 m SRTM DEM
> > (CELL),
> > but in this case the occurrence of these odd results is less
> > frequent
> > and they are not contrasting as much with the expected outcome
> > ("only"
> > by a 1 or 2 order of magnitude). The problem is present with or
> > without
> > the -c option, and seems only to affect the computation of
> > curvatures
> > (profc,planc,longc,crosc,minic,maxic).
> >
> > Has anyone encountered something like that, or have any idea about
> > what
> > might be going on?
> >
> > Thanks in advance,
> >
> > Vincent
> >
>
> ___
> 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.futures not working

[Anna Petrášová]

On Wed, Dec 9, 2020 at 8:37 AM Tom Hackbarth  wrote:

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

r.futures.potential calls Rscript, so the error means it can't find the
Rscript binary. If R is installed, I would recommend reinstalling GRASS,
during installation it tries to automatically look for it, so there is a
chance it will work then. I would recommend subscribing to grass-user
mailing list and ask more questions there.

Anna


> Best regards
>
> Tom
> ___
> 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] Recommendations for v.surf.rst parameters for huge region

[Anna Petrášová]

On Mon, Oct 26, 2020 at 12:38 PM Eric Patton 
wrote:

> On 20/10/20 10:12PM, Anna Petrášová wrote:
> > Hi,
> >
> > I don't have an answer but couple notes I can now think of:
> >
> > - Variable density of points may be a problem, I sometimes had that
> issue with
> > gaps in lidar when it creates visible segments. In that case you need to
> > increase npmin, but that substantially increases processing time. The
> default
> > npmin is 300, but that is typically unnecessary, npmin 150 is usually ok
> and
> > runs faster. The segments can be mitigated as well by higher tension. I
> usually
> > use tension between 20-40. I haven't used smooth value larger than 5 I
> think.
> > But again, your data are probably quite different.
> >
>
> Hi Anna, thanks for your comments. My experimentation agrees with the
> range of
> values you mention here.
>
> > - v.surf.rst is parallelized, you need to compile GRASS with openMP to
> take
> > advantage of that
>
> Yep, done.
>
> > - Have you looked at r.fill.stats? I used it for lidar, first r.in.lidar
> and
> > then fill the rest with r.fill.stats, possibly multiple passes to fill
> larger
> > holes. It uses IDW, and it will be *significantly* faster, although
> v.surf.rst
> > would probably give you better results in the end.
>
> I have not tried this module yet, but I will. I am somewhat confused about
> which
> raster fill/interpolation module to use in which circumstance, as there
> are so
> many (there are 6 r.resamp.* modules, 2 r.fill* modules...plus
> r.neighbours,
> r.mapcalc, r.surf.{nnbathy,rst,idw}, r.mblend, etc.)
>

Unfortunately, you need to read the manual, I agree it can be confusing. I
have been mostly using v.surf.rst for interpolation and r.fill.stats for
gap filling.

>
> I have been running r.mblend for 10 days now, with no sign or ending in
> sight.
> It is stuck on 'Buffering areas' for the last two days with no progress
> percentage
> written to the terminal, so I am going to have to kill it.
>

I think r.mblend is for seamless combining higher and lower-resolution
data, to e.g. update lidar with UAS, but your surfaces need to be already
interpolated.  Addon r.patch.smooth does something similar, but it's raster
based, so it might run faster, not sure if it is relevant for your use case
though.

Anna

>
> Cheers,
>
> ~ Eric.
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Recommendations for v.surf.rst parameters for huge region

[Anna Petrášová]

Hi,

I don't have an answer but couple notes I can now think of:

- Variable density of points may be a problem, I sometimes had that issue
with gaps in lidar when it creates visible segments. In that case you need
to increase npmin, but that substantially increases processing time. The
default npmin is 300, but that is typically unnecessary, npmin 150 is
usually ok and runs faster. The segments can be mitigated as well by higher
tension. I usually use tension between 20-40. I haven't used smooth value
larger than 5 I think. But again, your data are probably quite different.

- v.surf.rst is parallelized, you need to compile GRASS with openMP to take
advantage of that

- Have you looked at r.fill.stats? I used it for lidar, first r.in.lidar
and then fill the rest with r.fill.stats, possibly multiple passes to fill
larger holes. It uses IDW, and it will be *significantly* faster, although
v.surf.rst would probably give you better results in the end.

Best,
Anna

On Fri, Oct 16, 2020 at 3:05 PM Eric Patton 
wrote:

> Hello list,
>
> I am trying to interpolate raster values for a single massive dataset that
> represents dozens of multibeam bathymetry surveys over a few decades.
>
> The region is pretty big: all of Eastern Canada; at 100m resolution there
> are
> ~ 464M cells.
>
> The raster data has a wide range of completeness; in some areas, there is
> near 100% coverage - these areas were surveyed with modern sonars and 100%
> overlap between survey lines. In other areas, the data is very sparse, with
> ~1km or more between tracklines. These areas would represent surveys from
> the
> 70's to 90's using singlebeam echosounders.
>
> Firstly, would v.surf.rst be the best module for a massive interpolation
> job
> like this?  If not, could you recommend what would be the optimal method?
>
> If v.surf.rst is the right module to use, I was wondering if anyone could
> help
> with what parameters to use for an area this size, at least as a starting
> point. I have read the manual several times, but I still don't have a good
> intuition for how parameters like npmin, segmax, dmin, dmax, smooth all
> work
> together.
>
> At the moment, I have a script written that accepts a user-supplied number
> of
> random positions all over the input raster. For each random point, I obtain
> the east and north coordinates with v.to.db, feed these to g.region, and
> grow
> the region around the point in all four cardinal directions by some value
> like
> 10,000m to create an analysis window around each point. I create a polygon
> vector of this region with v.in.region, and use this polygon to clip my
> vectorized raster bathymetry with v.clip, and then do v.surf.rst on this
> clipped vector.
>
> I have no other way of knowing what v.surf.rst parameters to use other than
> trial and error, so I have a 4-level nested 'for' loop written to basically
> traverse through all permutations of the parameters within the ranges I
> chosen. So for example, I am exploring all combinations of parameters
> within
> these ranges:
>
> Tension: 10, 20, 40, 80, 160
> npmin: 100, 200, 400, 800, 1000
> smooth: 1, 2, 4, 8, 16, 32
>
> With 7 random points selected around the full region, this script will
> produce
> a few hundred maps per point, and quite a long time to run. And even more
> time
> to look at the results.  I know this isn't the best approach.
>
> I am looking for help to find some workable set of parameters to use for
> the
> entire dataset from other users who have more experience using this module.
>
> Thanks,
>
> --
> Eric Patton
> Marine Geoscience Technologist
> Geological Survey of Canada (Atlantic)
> Natural Resources Canada
> Bedford Institute of Oceanography
> 1 Challenger Drive, Dartmouth NS, Canada
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Compiling GRASS 7.9 using zstandard source

[Anna Petrášová]

Hi,

perhaps you don't have to use zstd, just configure grass with
--without-zstd, GRASS will then use different compression.
Alternatively you would have to build it locally, not sure how difficult
that is.

Anna

On Sun, Sep 20, 2020 at 10:56 AM Massimiliano Alvioli 
wrote:

> Hi all,
>
> I have a question about installing 7.9 on a remote machine, in which I
> do not have superuser privileges (galileo@CINECA) - thus I can't
> install zstd packages. I downloaded zstd v1.45 from github, unpacked
> it, and realized this library is not so "standard", meaning that users
> are not supposed to compile it and place it in some location (in an
> easy way, at least: there is no configure script in there). This means
> that configuring GRASS with the following flags:
>
> --with-zstd \
>
> --with-zstd-includes=/galileo/home/userexternal/malvioli/local/zstd/lib \
> --with-zstd-libs=/galileo/home/userexternal/malvioli/local/zstd/lib
>
> does not work. Note that I used zstd/lib as "include" folder because
> zstd.h happens to be there; there is no include folder in the source
> tree whatsoever. By "does not work" I mean that compiling GRASS would
> give zillions of:
>
>
> /galileo/home/userexternal/malvioli/local/grass-7.9.0/dist.x86_64-pc-linux-gnu/lib/
> libgrass_gis.7.9.so:
> undefined reference to `ZSTD_isError'
>
> /galileo/home/userexternal/malvioli/local/grass-7.9.0/dist.x86_64-pc-linux-gnu/lib/
> libgrass_gis.7.9.so:
> undefined reference to `ZSTD_decompress'
>
> /galileo/home/userexternal/malvioli/local/grass-7.9.0/dist.x86_64-pc-linux-gnu/lib/
> libgrass_gis.7.9.so:
> undefined reference to `ZSTD_compress'
>
> /galileo/home/userexternal/malvioli/local/grass-7.9.0/dist.x86_64-pc-linux-gnu/lib/
> libgrass_gis.7.9.so:
> undefined reference to `ZSTD_getErrorName'
>
> /galileo/home/userexternal/malvioli/local/grass-7.9.0/dist.x86_64-pc-linux-gnu/lib/
> libgrass_gis.7.9.so:
> undefined reference to `ZSTD_compressBound'
>
> errors. Instructions on zstandard's github page say:
>
> "Presuming a project needs to integrate libzstd's source code (as
> opposed to linking a pre-compiled library), the /lib source directory
> can be copy/pasted into target project. Then the local build system
> must setup a few include directories. Some setups are automatically
> provided in prepared build scripts, such as Makefile, but any other
> 3rd party build system must do it on its own.
> This integration is now simplified, thanks to @felixhandte, by making
> all dependencies within /lib relative, meaning it’s only necessary to
> setup include directories for the *.h header files that are directly
> included into target project (typically zstd.h). Even that task can be
> circumvented by copy/pasting the *.h into already established include
> directories."
>
> I do not understand anything of that - any help is really appreciated.
>
>
> M
> ___
> 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] Troubles using t.create

[Anna Petrášová]

Hi, the second mentioned problem was in master only, but should be fixed
now. Not sure about the first one.
Anna

On Tue, May 5, 2020 at 6:44 PM Veronica Andreo  wrote:

> Hello
>
> I can't reproduce the error with GRASS 7.8.2. No idea what can be the
> problem at your end... The parameter `semantictype` is required and not set
> in your example... It has a default value though... but maybe worth a try
>
> best,
> Vero
>
> El mar., 5 may. 2020 a las 16:01, Worme Florian (SIRS) (<
> florian.wo...@sirs-fr.com>) escribió:
>
>> Hi,
>>
>> As I need to work with space time raster data serie, I am trying to use
>> the t.create function (the first step to build a strds as indicated in
>> tutorials) but unlike other functions that seem to work (I am new to
>> GRASS), this one keeps returning errors that my more advanced users
>> co-workers and I can't explain.
>>
>> *-> Here is an exemple of the error i get when I try it on a local
>> computer *
>>
>>
>> *(base) fworme@SW-031:~> t.create type=strds temporaltype=absolute \ *
>>
>> *>  output=precipitation_monthly \ *
>>
>> *>  title="Monthly precipitation" \ *
>> *>  description="Dataset with monthly precipitation"*
>>
>>
>> *Traceback (most recent call last): *
>>
>> *  File "/usr/lib64/grass78/scripts/t.create", line 92, in  *
>>
>> *main() *
>>
>> *  File "/usr/lib64/grass78/scripts/t.create", line 74, in main *
>>
>> *import grass.temporal as tgis *
>>
>> *  File "/usr/lib64/grass78/etc/python/grass/temporal/__init__.py", line
>> 3, in  *
>>
>> *from .core import * *
>>
>> *  File "/usr/lib64/grass78/etc/python/grass/temporal/core.py", line 39,
>> in  *
>>
>> *from .c_libraries_interface import * *
>>
>> *  File
>> "/usr/lib64/grass78/etc/python/grass/temporal/c_libraries_interface.py",
>> line 20, in  *
>>
>> *import grass.lib.gis as libgis *
>>
>> *  File "/usr/lib64/grass78/etc/python/grass/lib/gis.py", line 23, in
>>  *
>>
>> *_libs["grass_gis.7.8"] = load_library("grass_gis.7.8") *
>>
>> *  File "/usr/lib64/grass78/etc/python/grass/lib/ctypes_loader.py", line
>> 64, in load_library *
>>
>> *raise ImportError("%s not found." % libname) *
>>
>> *ImportError: grass_gis.7.8 not found. *
>>
>> *The thing is: finding grass_gis 7.8 shouldn't be a problem, and other
>> grass functions are working *
>>
>>
>> *-> And here is what I get when I try to run it on
>> mundialis/grass-py3-pdal:latest grass - Docker*
>>
>>
>> *Starting GRASS GIS... *
>>
>> *Creating new GRASS GIS location ... *
>>
>> *Cleaning up temporary files... *
>>
>> *Executing  ... (grass.sh containting the same
>> exemple I tryed on a local computer) *
>>
>>
>> *Default TGIS driver / database set to: *
>>
>> *driver: sqlite *
>>
>> *database: $GISDBASE/$LOCATION_NAME/$MAPSET/tgis/sqlite.db *
>>
>> *WARNING: Temporal database connection defined as: *
>>
>> * /tmp/grass7-root-1/tmploc/PERMANENT/tgis/sqlite.db *
>>
>> * But database file does not exist. *
>>
>> *Creating temporal database: *
>>
>> */tmp/grass7-root-1/tmploc/PERMANENT/tgis/sqlite.db *
>>
>> *Traceback (most recent call last): *
>>
>> *  File "/usr/local/grass/scripts/t.create", line 92, in  *
>>
>> *main() *
>>
>> *  File "/usr/local/grass/scripts/t.create", line 85, in main *
>>
>> *tgis.init() *
>>
>> *  File "/usr/local/grass/etc/python/grass/temporal/core.py", line 707,
>> in init *
>>
>> *create_temporal_database(dbif) *
>>
>> *  File "/usr/local/grass/etc/python/grass/temporal/core.py", line 843,
>> in create_temporal_database *
>>
>> *self._create_temporal_database_views(dbif) *
>>
>> *NameError: name 'self' is not defined *
>>
>> *Execution of  finished. *
>>
>> *Cleaning up temporary files... *
>>
>>
>> If anyone has any idea about where does the problem come from...
>> Thank you for your help / your time.
>> --
>>
>> *Ce message et toutes les pièces jointes (ci-après le "message") sont
>> établis à l'intention exclusive de ses destinataires et sont confidentiels.
>> Si vous recevez ce message par erreur ou s'il ne vous est pas destiné,
>> merci de le détruire ainsi que toute copie de votre système et d'en avertir
>> immédiatement l'expéditeur. Toute lecture non autorisée, toute utilisation
>> de ce message qui n'est pas conforme à sa destination, toute diffusion ou
>> toute publication, totale ou partielle, est interdite. L'Internet ne
>> permettant pas d'assurer l'intégrité de ce message électronique susceptible
>> d'altération, l’expéditeur (et ses filiales) décline(nt) toute
>> responsabilité au titre de ce message dans l'hypothèse où il aurait été
>> modifié ou falsifié.*
>>
>> *This message and any attachments (the "message") is intended solely for
>> the intended recipient(s) and is confidential. If you receive this message
>> in error, or are not the intended recipient(s), please delete it and any
>> copies from your systems and immediately notify the sender. Any
>> unauthorized view, use that does not comply 

Re: [GRASS-user] Error in installing r.in.nasadem

[Anna Petrášová]

The wingrass addons should be now updated, I can see r.in.nasadem there.

On Mon, Feb 24, 2020 at 7:13 PM Firman Hadi  wrote:

> Hi Markus,
>
> Thanks for sending me the information.
>
> I have tried it again but still no r.in.nasadem binary in the repo.
> Now, I am using GRASS GIS 7.6dev on a Mac. I could install the add-on
> after creating symbolic link of Pyhton3.
>
> But there is another problem. It failed to download the data with the
> error message KeyError = 'version' as attached. Any suggestion on how to
> solve the problem?
>
> Thanks.
>
> Best regards,
>
> Firman Hadi.
>
>
>
>
> On Feb 24 2020, at 12:16 am, Markus Neteler  wrote:
>
> On Sun, Feb 23, 2020 at 4:39 PM Markus Metz
>  wrote:
>
> On Sun, Feb 23, 2020 at 12:12 PM Firman Hadi  wrote:
>
>
> Dear all,
>
> I am trying to install GRASS Addons (r.in.nasadem) from GRASS GIS 7.8.2 in
> MS Windows.
> I use GRASS GIS from QGIS 3.10 installer. I couldn't install it due to
> file not found as attached image.
>
>
> it seems like the wingrass build server has not updated yet the addons
> from github.
>
>
> According to the timestamps in
> http://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.2/
>
> the job will run in 2 hs from now.
>
> Please try then again.
>
> best,
>
> markusN
>
> ___
> 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.sim.water simulation considering dams

[Anna Petrášová]

Hi,

I don't have any experience with that parameter, but I think if you don't
need permeable structures, you don't need that parameter. I would try to
represent the structures in the elevation, that should work. But keep in
mind that it's a shallow water flow model, so it's not ideal for filling
large and deep depressions. In that case you can also consider Itzi model.

Anna

On Thu, Jan 23, 2020 at 5:16 AM Johannes Radinger <
johannesradin...@gmail.com> wrote:

> Dear GRASS users,
>
> maybe someone of you has already worked with r.sim.water while considering
> dams as impermeable structures that retain water, i.e. create
> impoundments/reservoirs.
>
> I am wondering how to best specify dams within r.sim.water: There is the
> parameter flow_control which is a raster map that indicates the
> permeability of the landscape. The manual mentions here a permeability
> ratio (0-1) and I guess this should be 0 for all cells that represent a dam
> and 1 for all other cells of the computational region?!
> But what about the elevation data then; Do I need to provide an
> elevation raster that includes the dam height or should this be the
> elevation as without dams?
> I'd like to know whether I need to provide a flow_control map or an
> elevation map that includes dams or both? I couldn't find any example of
> r.sim.water that uses the flow_control parameter so far... any
> ideas/experiences from your side?
>
> cheers,
> Johannes
>
> ___
> 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] Question on the installation of Grass in Mac Catalina OS

[Anna Petrášová]

I would use GRASS 7.6.2 from http://grassmac.wikidot.com/downloads.

Anna

On Mon, Nov 25, 2019 at 11:06 AM Gabriel Cotlier 
wrote:

> Dear Grass users,
>
> I’m trying to install Grass on Mac OS latest version Catalina; please I
> would appreciate if I can receive guidance and orientations for a correct
> installation of Grass.
> Thanks in advance.
> Kind regards,
> Gabriel
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error in g.extension, add-ons not written in GUI

[Anna Petrášová]

Could you create a ticket for this with info on Python version, locale
etc.? This happens with any addon? (at least couple randomly tried ones)

On Thu, Jul 18, 2019 at 9:49 AM Veronica Andreo 
wrote:

> Hi all,
>
> I just compiled grass77 in a Linux Mint 19.1 Cinamon laptop following the
> instructions here:
> https://grasswiki.osgeo.org/wiki/Compile_and_Install#Linux_Mint
>
> All is fine, but when we install any add-on, we get:.
> g.extension r.seasons
> Fetching  from GRASS GIS Addons repository (be patient)...
> Compiling...
> Installing...
> Updating addons metadata file...
> Updating private addons metadata file...
> Traceback (most recent call last):
>   File
> "/home/carla/software/grass-7.7.git/dist.x86_64-pc-linux-gnu/scripts/g.extension",
> line 1933, in 
> sys.exit(main())
>   File
> "/home/carla/software/grass-7.7.git/dist.x86_64-pc-linux-gnu/scripts/g.extension",
> line 1913, in main
> install_extension(source=source, url=url, xmlurl=xmlurl)
>   File
> "/home/carla/software/grass-7.7.git/dist.x86_64-pc-linux-gnu/scripts/g.extension",
> line 704, in install_extension
> blist = install_private_extension_xml(tmp_dir, mlist)
>   File
> "/home/carla/software/grass-7.7.git/dist.x86_64-pc-linux-gnu/scripts/g.extension",
> line 1006, in install_private_extension_xml
> write_xml_modules(xml_file, tree)
>   File
> "/home/carla/software/grass-7.7.git/dist.x86_64-pc-linux-gnu/scripts/g.extension",
> line 603, in write_xml_modules
> (' ' * indent, tnode.find('keywords').text))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in
> position 19: ordinal not in range(128)
>
> GRASS 7.7.dev (nc_basic_spm_grass7):~ > g.extension extension=v.class.mlR
> Fetching  from GRASS GIS Addons repository (be patient)...
> Compiling...
> Installing...
> Updating addons metadata file...
> Updating private addons metadata file...
> Traceback (most recent call last):
>   File
> "/home/carla/software/grass-7.7.git/dist.x86_64-pc-linux-gnu/scripts/g.extension",
> line 1933, in 
> sys.exit(main())
>   File
> "/home/carla/software/grass-7.7.git/dist.x86_64-pc-linux-gnu/scripts/g.extension",
> line 1913, in main
> install_extension(source=source, url=url, xmlurl=xmlurl)
>   File
> "/home/carla/software/grass-7.7.git/dist.x86_64-pc-linux-gnu/scripts/g.extension",
> line 704, in install_extension
> blist = install_private_extension_xml(tmp_dir, mlist)
>   File
> "/home/carla/software/grass-7.7.git/dist.x86_64-pc-linux-gnu/scripts/g.extension",
> line 1006, in install_private_extension_xml
> write_xml_modules(xml_file, tree)
>   File
> "/home/carla/software/grass-7.7.git/dist.x86_64-pc-linux-gnu/scripts/g.extension",
> line 603, in write_xml_modules
> (' ' * indent, tnode.find('keywords').text))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in
> position 29: ordinal not in range(128)
>
> The add-on is indeed installed, but it is not added to the list of
> extensions in the GUI. Is there something we are missing here or in the
> instructions for Mint?? I cannot reproduce in my Fedora box with freshly
> re-compiled grass77
>
> Any hint is wellcome :)
> Cheers,
> Vero
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.mon displays box on startup

[Anna Petrášová]

On Wed, Sep 26, 2018 at 1:50 PM Huidae Cho  wrote:

> This is a great feature, but I was wondering why it turns red on zoom
> in/out.
>
>
I think it changes color depending if you are zoomed inside or outside of
the region. I find this behavior little bit confusing, perhaps just having
one color would be enough, and maybe don't show it when you are zoomed
inside?

Anna

On Tue, Sep 25, 2018 at 4:32 PM Markus Neteler  wrote:
>
>> On Tue, Sep 25, 2018 at 10:28 PM Veronica Andreo 
>> wrote:
>> >
>> > That's the computational region limits which are now visible by default
>> in Map display and wx monitors.
>> > However, I agree that an option to make it invisible as before would
>> make sense.
>>
>> Just disable it at left bottom of the display window -> the trick is that
>> you need to *first* switch to "Show comp. extent" which isn't obvious:
>>
>> [image: image.png]
>>
>> > You can open a ticket for this
>>
>> Not needed :)
>>
>> But I think that the "Show computational extent" should always be there.
>> Maybe a ticket for that wish?
>>
>
>
> +1
>
>
>
>> Markus
>>
>> PS: sorry for HTML email
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>
>
> --
> Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
> Open Source GIS Developer, GRASS GIS Development Team
> ___
> 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

[Anna Petrášová]

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

Re: [GRASS-user] experimental Python 3 support in trunk

[Anna Petrášová]

On Mon, Sep 3, 2018 at 2:28 AM Markus Neteler  wrote:

> On Mon, Sep 3, 2018 at 4:21 AM Anna Petrášová 
> wrote:
> >
> > Hi,
> >
> > I committed the experimental support of Python 3 to trunk (grass77) by
> Sanjeet (GSoC 2018).
>
> This is excellent, thanks for much for your hard work, Sanjeet, Anna
> and all involved!
>
> > In the first stage of testing, we need to make sure GRASS can compile
> and run with Python 2 without problems. Python 3 support is highly
> experimental, we are still having problems with ctypes and libraries using
> them. However, you should be able to compile GRASS, launch GUI and run
> modules. I tested it on Ubuntu 16.04 with Python 2.7 and Python 3.5
> (virtualenv), utf8 English locale, other platforms were not tested.
>
> Could you please post a few lines how to properly do the testing with
> virtualenv?
>

https://trac.osgeo.org/grass/wiki/Python3Support#Howtotest

also, we have now new small dependency - Python 'six' package


> > For reporting bugs related to this, please create tickets and put
> 'Python3' as keyword (even for problems running GRASS on Python2 related to
> this commit).
> >
> > Anna
>
> thanks again,
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] experimental Python 3 support in trunk

[Anna Petrášová]

Hi,

I committed the experimental support of Python 3 to trunk (grass77) by
Sanjeet (GSoC 2018). In the first stage of testing, we need to make sure
GRASS can compile and run with Python 2 without problems. Python 3 support
is highly experimental, we are still having problems with ctypes and
libraries using them. However, you should be able to compile GRASS, launch
GUI and run modules. I tested it on Ubuntu 16.04 with Python 2.7 and Python
3.5 (virtualenv), utf8 English locale, other platforms were not tested.

For reporting bugs related to this, please create tickets and put 'Python3'
as keyword (even for problems running GRASS on Python2 related to this
commit).

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

Re: [GRASS-user] g.gui.psmap: set region

[Anna Petrášová]

On Tue, Aug 14, 2018 at 9:36 PM Rich Shepard 
wrote:

> On Tue, 14 Aug 2018, Anna Petrášová wrote:
>
> > no, you should be able to add maps from any accessible mapset, use
> > g.mapsets -s to check your mapsets are accessible.
>
> Anna,
>
>In the ps.map manual I read setting the region using g.mapsets, but
> within
> the cartographic composer the region setting dropdown choice box did not
> let
> me select a map in a different mapset.


It works for me, are we talking about "Map frame settings"?


> Using g.mapsets -s is still on the
> command line, not within the GUI as far as I can tell.
>

not sure what you mean, g.mapsets -s sets the visibility of mapsets globally

>
> Best regards,
>
> 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] g.gui.psmap: set region

[Anna Petrášová]

On Tue, Aug 14, 2018 at 6:50 PM Rich Shepard 
wrote:

>It appears that the only maps available for setting a ps.map region in
> the
> cartographic composer are those of the current mapset. When looking at the
> choices, no other mapset can be opened to view the contained maps. Is this
> correct?
>

no, you should be able to add maps from any accessible mapset, use
g.mapsets -s to check your mapsets are accessible.


>If so, I'll be sure to change the current mapset to the one with the
> region I want to use for the cartographic layout.
>
> 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] Creating presentation maps: g.gui.psmap, ps.map, wx.psmap

[Anna Petrášová]

On Mon, Aug 13, 2018 at 6:58 PM Rich Shepard 
wrote:

>The g.gui.psmap manual page's description for the module includes the
> statement, "It works better with files created by wx.psmap (more tested)."
> I
> cannot find wx.psmap.
>

wx.psmap is the same as cartographic composer, I reformulated it little so
that it makes more sense.

>
>Backing up to the parent page (the Cartography box in the lower left
> corner) and navigating to the postscript commands manual produces the
> heading of the parent page:
>

hm, not sure what you mean here

>
> "GRASS GIS 7.5.svn Reference Manual
>
> Geographic Resources Analysis Support System, commonly referred to as
> GRASS,
> is a Geographic Information System (GIS) used for geospatial data
> management
> and analysis, image processing, graphics/maps production, spatial modeling,
> and visualization. GRASS is currently used in academic and commercial
> settings around the world, as well as by many governmental agencies and
> environmental consulting companies.
>
> This reference manual details the use of modules distributed with
> Geographic
> Resources Analysis Support System (GRASS), an open source (GNU GPLed),
> image
> processing and geographic information system (GIS).
>
> Go back to help overview"
>
>Tucked away under that is the link,
>   "Postscript commands:
> ps.map  Produces hardcopy PostScript map output."
>
>I suggest that the page be eliminated and the link from the main module
> directory's 'Cartography' link go directly to
> .
>
>At the bottom of the psmap page is a section, "CHANGES BETWEEN VERSION
> 5.0.x/5.4.x and
> 6.0" that probably be safely removed.
>

I removed it

>
>It has been many years since I've used ps.map. If I'm correctly reading
> the manual for g.gui.psmap I need to create the ps.map input *.txt file,
> then use g.gui.psmap to tweak it. Is this correct?
>

no, you can work with cartographic composer (which is basically GUI for
ps.map) directly. You can then export a file which can then be used with
ps.map, or reloaded into cartographic composer.

Best,
Anna


>
> Regards,
>
> 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] tmp file

[Anna Petrášová]

On Sat, Jul 21, 2018 at 9:10 AM Micha Silver  wrote:

>
>
> On 07/20/2018 06:05 PM, Frank David wrote:
>
> Hello dear grass users,
>
> I'm writing python scripts and I wonder if is there a better way to handle
> tmp file between several mapcalc, For the moment I create a tmp raster file
> and once I don't need anymore I remove with g.remove. If the script crash,
> the tmp raster still exists. If another script run and use the same tmp
> name, that could make conflict.
>
> Is there a specific way the handle tmp raster (or vector) file ?
>
> I guess the proper way to deal with this is to first prepare a cleanup
> function. Then wrap your grass functions in a try...except structure, and
> whenever you catch an error, fire off the cleanup routine.
>

Use atexit package, see for example cleanup routine in r.sun.daily module:
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.sun.daily/r.sun.daily.py#L612

and example on wiki:

https://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library#Sophisticated_cleanup_procedure


Anna

>
> Thank you
> Frank
>
>
> ___
> grass-user mailing 
> listgrass-user@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/grass-user
>
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
>
> ___
> 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] 3D raster color coding

[Anna Petrášová]

I sent you some time ago a video how to view 3D rasters using isosurfaces
or slices:
https://youtu.be/CmK-fEyf2SY

If you haven't added any isosurface or slice, you won't see anything beside
the 3D box.

Also, I recommend setting higher z-exaggeration.
Anna

On Mon, Jun 11, 2018 at 10:29 PM Francois Chartier 
wrote:

>  I have pasted below the colors files for the 3d raster.  The data is
> there as i am viewing the wireframe around the data.  the r3.color is set
> to bgyr.  therefore, i do not see how come the interpolated data does not
> show up in the display.  any ideas?
>
> r3.colors map=BHALL_May24v2@Toronto color=bgyr
>
> Color table for raster3d map  set to 'bgyr'
>
>
> color table - the data is associated with a color as per below.
> % -8.9909944534301758 33.892620086669922
> -8.9909944534301758:0:191:191 -0.41427154541015626:0:255:0
> -0.41427154541015626:0:255:0 8.1624513626098629:255:255:0
> 16.739174270629881:255:127:0 25.315897178649902:191:127:63
> 25.315897178649902:191:127:63 33.892620086669922:200
> 8.1624513626098629:255:255:0 16.739174270629881:255:127:0
>
> Metadata of 3d raster. - same range of data as color table.
>
>
> Le dim. 10 juin 2018 à 15:57, Francois Chartier 
> a écrit :
>
>> the vector is visible in 3d as per attached screen shot.  could this be a
>> problem due to computer instead of Grass.  there may be too many data
>> points to show?
>>
>> Le dim. 10 juin 2018 à 15:46, Francois Chartier 
>> a écrit :
>>
>>>  I have pasted below the colors files for the 3d raster.  the screen
>>> capture shows that the data is there as i am showing the wireframe around
>>> the data.  the r3.color is set to bgyr.  therefore, i do not see how come
>>> the interpolated data does not show up in the display.
>>>
>>> r3.colors map=BHALL_May24v2@Toronto color=bgyr
>>>
>>> Color table for raster3d map  set to 'bgyr'
>>>
>>>
>>> color table - the data is associated with a color as per below.
>>> % -8.9909944534301758 33.892620086669922
>>> -8.9909944534301758:0:191:191 -0.41427154541015626:0:255:0
>>> -0.41427154541015626:0:255:0 8.1624513626098629:255:255:0
>>> 16.739174270629881:255:127:0 25.315897178649902:191:127:63
>>> 25.315897178649902:191:127:63 33.892620086669922:200
>>> 8.1624513626098629:255:255:0 16.739174270629881:255:127:0
>>>
>>> Metadata of 3d raster. - same range of data as color table.
>>> ype of Map:  raster_3dNumber of Categories: 0   |
>>>  |   Data Type:FCELL
>>>   |
>>>  |   Rows: 90
>>>  |
>>>  |   Columns:  85
>>>  |
>>>  |   Depths:   307
>>>   |
>>>  |   Total Cells:  2348550
>>>   |
>>>  |   Total size:   3180868 Bytes
>>>   |
>>>  |   Number of tiles:  336
>>>   |
>>>  |   Mean tile size:   9466 Bytes
>>>  |
>>>  |   Tile size in memory:  30420 Bytes
>>>   |
>>>  |   Number of tiles in x, y and  z:   6, 7, 8
>>>   |
>>>  |   Dimension of a tile in x, y, z:   15, 13, 39
>>>  |
>>>  |
>>>   |
>>>  |Projection: UTM (zone 17)
>>>  |
>>>  |N:4870795S:4825715   Res: 500.8889
>>>   |
>>>  |E: 651669W: 609204   Res: 499.58823529
>>>   |
>>>  |T:352B: 45   Res: 1
>>>  |
>>>  |   Range of data:   min = -8.99099445 max = 33.89262009
>>>  |
>>>  |
>>>   |
>>>  |   Data Source:
>>>  |
>>>  |
>>>   |
>>>  |
>>>   |
>>>  |
>>>   |
>>>  |   Data Description:
>>>   |
>>>  |generated by v.vol.rst
>>>   |
>>>  |
>>>   |
>>>  |   Comments:
>>>   |
>>>  |v.vol.rst input="BHMat1All_May12@Toronto" wcolumn="cat"
>>> tension=40. \   |
>>>  |smooth=0.1 segmax=50 npmin=200 npmax=700 dmin=2 wscale=1.0
>>> zscale=1.\   |
>>>  |0 elevation="BHALL_May24v2"
>>>
>>>
>>>
>>> Le sam. 2 juin 2018 à 15:37, Helmut Kudrnovsky  a écrit :
>>>
 >Unfortunately in the Display window nothing shows up, whether in 2D or
 in 3D
 view.  I do not know what i >am doing incorrectly.

 see https://trac.osgeo.org/grass/ticket/3571

 please add your findings there.



 -
 best regards
 Helmut
 --
 Sent from:
 http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 https://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>> ___
> 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 vol rst super slow

[Anna Petrášová]

On Wed, May 23, 2018 at 10:05 PM, Francois Chartier
<fra.chart...@gmail.com> wrote:
> Thank you,
>
> v.vol.rst input=BHMat1All_May12@Toronto wcolumn=cat dmin=5
> elevation=may23trial
>
> it would appear to have worked.  I changed the resolution to 200 m
> horizontally and 5 m for z using g.region as  a trial.
> now the big question is how do you see the data.  I am able to view a 2D
> raster by changing the color scale but 3d raster is blank,

You can view it in 3D view, see https://youtu.be/CmK-fEyf2SY or use
r3.to.rast (https://grass.osgeo.org/grass74/manuals/r3.to.rast.html)
to slice it into a series of 2D rasters and view them.

>
>
> +
>  | Layer:may23trial@Toronto Date: Wed May 23 21:46:30 2018
> |
>  | Mapset:   TorontoLogin of Creator: Francois
> Charti |
>  | Location: Toronto
> |
>  | DataBase: C:\Users\Francois Chartier\Documents\grassdata
> |
>  | Title:may23trial
> |
>  | Units:none
> |
>  | Vertical unit: units
> |
>  | Timestamp: none
> |
>
> ||
>  |
> |
>  |   Type of Map:  raster_3dNumber of Categories: 0
> |
>  |   Data Type:FCELL
> |
>  |   Rows: 90
> |
>  |   Columns:  85
> |
>  |   Depths:   61
> |
>  |   Total Cells:  466650
> |
>  |   Total size:   853368 Bytes
> |
>  |   Number of tiles:  64
> |
>  |   Mean tile size:   1 Bytes
> |
>  |   Tile size in memory:  32384 Bytes
> |
>  |   Number of tiles in x, y and  z:   4, 4, 4
> |
>  |   Dimension of a tile in x, y, z:   22, 23, 16
> |
>  |
> |
>  |Projection: UTM (zone 17)
> |
>  |N:4870795S:4825715   Res: 500.8889
> |
>  |E: 651669W: 609204   Res: 499.58823529
> |
>  |T:352B: 45   Res: 5.03278689
> |
>  |   Range of data:   min = -0.18226054 max = 32.72385025
> |
>  |
> |
>  |   Data Source:
> |
>  |
> |
>  |
> |
>  |
> |
>  |   Data Description:
> |
>  |generated by v.vol.rst
> |
>  |
> |
>  |   Comments:
> |
>  |v.vol.rst input="BHMat1All_May12@Toronto" wcolumn="cat" tension=40. \
> |
>  |    smooth=0.1 segmax=50 npmin=200 npmax=700 dmin=5 wscale=1.0 zscale=1.\
> |
>  |0 elevation="may23trial"
> |
>  |
> |
>
> ++
> (Wed May 23 21:54:13 2018) Command finished (0 sec)
>
>
> 2018-05-23 21:42 GMT-04:00 Anna Petrášová <kratocha...@gmail.com>:
>>
>> On Wed, May 23, 2018 at 9:02 PM, Francois Chartier
>> <fra.chart...@gmail.com> wrote:
>> > How do you change the resolution to something coarser?
>>
>> With g.region, res= is horizontal and tbres= is vertical resolution, e.g:
>>
>> g.region res=200 tbres=200 -p3
>>
>> >
>> > 2018-05-23 15:30 GMT-04:00 Markus Metz <markus.metz.gisw...@gmail.com>:
>> >>
>> >>
>> >>
>> >> On Wed, May 23, 2018 at 1:09 PM, Francois Chartier
>> >> <fra.chart...@gmail.com> wrote:
>> >> >
>> >> > see below
>> >> > g.region -3p
>> >> >
>> >> > projection: 1 (UTM)
>> >> > zone:   17
>> >> > datum:  nad83
>> >> > ellipsoid:  grs80
>> >> > north:  4870795
>> >> > south:  4825715
>> >> > west:   609204
>> >> > east:   651669
>> >> > top:352.
>> >> > bottom: 45.
>> >> > nsres:  5
>> >> > nsres3: 5
>> >> > ewres:  5
>> >> > ewres3: 5
>> >> > tbres:  1
>> >> > rows:   9016
>> >> > rows3:  9016
>> >> > cols:   8493
>> >> > cols3:  8493
>> >> > depths: 307
>> >> > cells:  76572888
>> >> > cells3: 23507876616
>> >> >
>> >> > for v.vol.rst command line - i am not sure where you get this so i
>> >> > just
>> >> > restarted the simulation.
>> >> > Wed May 23 07:07:59 2018)
>> >> > v.vol.rst input=BHMat1All_May12@Toronto wcolumn=cat dmin=0.1
>> >> > 25 records selected from table
>> >> > Processing all selected output fil