[GRASS-dev] GSoC 2024: Week 11 Report: Improve GRASS user experience in Jupyter Notebook

[Riya Saxena via grass-dev]

Hello everyone,

I wanted to provide an update on the progress made during the eleventh week
of my coding period.
Summary of Week Seven:

   1.

   *Achievements:*
   -

  *Managing Multiple Toggle Buttons*:
  - Introduced InteractiveDrawController [1] and
 InteractiveQueryController [2] to better handle individual events.
  -

  *Added Tutorials* [3]
  -

  *Updated Descriptions* [4]:
  - I’ve revised the descriptions for the modified files and updated
 the docstrings accordingly.
  2.

   *Plans for Next Week:*
   - Writing the documentation.
  3.

   *Current Challenges:*
   - None at present.

References:

   - [1] grass.jupyter: Allow Users to Draw Computational Regio
   
   - [2] grass.jupyter: Add Query Button to InteractiveMap
   
   - [3] grass.jupyter: Modify jupyter_tutorial.ipynb
   
   - [4] grass.jupyter: Modify Descriptions
   

For further details, please visit:

   - My profile 
   - My wiki page
   

   - My Forked Repository 

Best regards,

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

[GRASS-dev] GSoC 2024: Week 7 Report: Improve GRASS user experience in Jupyter Notebook

[Riya Saxena via grass-dev]

Hello everyone,

I hope this message finds you well. I wanted to provide an update on the
progress made during the seventh week of my coding period.
Summary of Week Seven:

   1.

   *Achievements:*
   - Implemented the Query Button in InteractiveMap [1]:
 - Finalized the appearance of the popup button.
  - Enhanced Computational Region Drawing [2]:
 - Added functionality for zooming into the computational region.
  - Developed Drawing and Saving of Simple Geometries [3]:
 - Users can now draw simple geometries in InteractiveMap and save
 them as GRASS native vector maps.
 - Transitioned from DrawControl (deprecated) to GeomanDrawControl
 in ipyleaflet.
  2.

   *Plans for Next Week:*
   - Finalize Query Button Integration [1]:
 - Prepare code for merging into the main branch.
  - Optimize Drawing and Saving of Simple Geometries [3]:
 - Implement GeomanDrawControl for improved functionality.
  - Initiate Parallelization for TimeseriesMap and SeriesMap.
   3.

   *Current Challenges:*
   - None at present.

References:

   - [1] Add Query Button to InteractiveMap
   
   - [2] Allow Users to Draw Computational Region
   
   - [3] Allow Users to Draw and Save Simple Geometries
   

For further details, please visit:

   - My profile 
   - My wiki page
   

   - My Forked Repository 

Best regards,

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

[GRASS-dev] GSoC 2024: Week 3 Report: Improve GRASS user experience in Jupyter Notebook

[Riya Saxena via grass-dev]

Hello everyone,

I would like to update you on the work completed during the third week of
my coding period.

*Progress Report for the Third Week:*

   1. *Accomplishments:*
  - Query Button in InteractiveMap [1]:
- Added a Popup button to display the queried point.
- Enabled support for multiple raster and vector layers.
  - Computational Region Drawing [2]:
- Began work on allowing users to draw a computational region.

   2. *Plans for the Next Week:*
   - Continue developing the feature to allow users to draw computational
  regions.
  - Improve the Query Mode functionality.

   3. *Blockers:*
  - None.

*References:*
[1] Add Query Button to InteractiveMap

[2] Allow Users to draw computational region


For more information, you can check the following links:

   - My profile 
   - My wiki page
   

   - My Forked Repository 

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

[GRASS-dev] GSoC 2024: Week 2 Report: Improve GRASS user experience in Jupyter Notebook

[Riya Saxena via grass-dev]

Hello everyone,

I would like to provide an update on the work completed during the second
week of my coding period.

*Progress Report for the Second Week:*

   1. *Accomplishments:*
  - Implemented an “Activate Query” button in InteractiveMap. This new
  feature allows users to query both raster and vector data. [1]

   2. *Plans for the Next Week:*
   - Enhance the visual presentation of the Activate Query Button.
  - Enable users to draw a box to define the computational region.

   3. *Blockers:*
  - None.

*References:*
[1] Add button to Activate Query Mode


For more information, you can check the following links:

   - My profile 
   - My wiki page
   

   - My Forked Repository 

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

[GRASS-dev] GSoC 2024: Week 1 Report: Improve GRASS user experience in Jupyter Notebook

[Riya Saxena via grass-dev]

Hello everyone,

I would like to provide an update on the work completed during the first
week of my coding period.

*Progress Report for the First Week:*

   1. *Accomplishments:*
   - Created the *BaseSeriesMap* class to eliminate redundancy between
  *SeriesMap* and *TimeSeriesMap*. [1]
  - Added an “Activate Query” button to *InteractiveMap*, allowing
  users to retrieve points in terms of Latitude and Longitude when
activated.
  [2]

   2. *Plans for the Next Week:*
   - Enable users to retrieve raster/vector data information associated
  with queried points when the Query Mode is enabled.

   3. *Blockers:*
  - None, except that I am down with a heatstroke due to the ongoing
  heatwave in North India. I am in the process of recovering.

*References:*
[1] Create BaseSeriesMap to remove redundancies in SeriesMap and
TimeSeriesMap 
[2] Add button to Activate Query Mode


For more information, you can check the following links:

   - My profile 
   - My wiki page
   

   - My Forked Repository 

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

[GRASS-dev] GSoC 2024: Community Bonding Period (Week 0) Report

[Riya Saxena via grass-dev]

Hello everyone,

Here's an overview:

1) What did I accomplish this week?

   - Familiarized myself with the contribution guidelines.
   - Set up my profile WikiPage [1] and my project WikiPage [2].
   - Configured the development environment.
   - Read more about GRASS GIS.
   - Worked on a pull request to remove redundancies in SeriesMap and
   TimeSeriesMap [3].


2) What are my plans for next week?

   - Implement a button in grass.jupyter.interactivemap.py [4] that allows
   users to perform queries when activated.
   - Work on the PR. [3]

3) Am I blocked on anything?

   - No

References:
[1] User:29riyasaxena 
[2] GRASS GSoC 2024 Improve user experience in Jupyter Notebooks


[3] Create BaseSeriesMap to remove redundancies in SeriesMap and
TimeSeriesMap 
[4] grass.jupyter.interactivemap

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

Re: [GRASS-dev] GSoC 2024

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

Just a reminder, we are meeting today to kick off the Google Summer of Code
community bonding period:

Time: May 8, 2024 01:00 PM Eastern Time (US and Canada)
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024&month=5&day=8&hour=17&min=0&sec=0&p1=207&p2=48&p3=51&p4=671

Join Zoom Meeting
https://ncsu.zoom.us/j/91478802764?pwd=NzlNc3ZvN3FMMzZxcVNzUEFsYWV3dz09

On Thu, May 2, 2024 at 3:48 PM Markus Neteler  wrote:

> On Thu, May 2, 2024 at 5:29 PM Anna Petrášová via grass-dev
>  wrote:
> >
> > Hi devs,
> >
> > We plan to have a call with the new Google Summer of Code students. If
> you want to learn more about the projects and meet the students, please
> join the call:
> >
> > Topic: GRASS GIS GSoC 2024
> > Time: May 8, 2024 01:00 PM Eastern Time (US and Canada)
> >
> > Join Zoom Meeting
> > https://ncsu.zoom.us/j/91478802764?pwd=NzlNc3ZvN3FMMzZxcVNzUEFsYWV3dz09
> >
> > Meeting ID: 914 7880 2764
> > Passcode: 868437
> >
> > Best,
> > Anna
>
> Here in some other timezones:
>
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024&month=5&day=8&hour=17&min=0&sec=0&p1=207&p2=48&p3=51&p4=671
>
> (hope I got it right)
>
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2024

[Markus Neteler via grass-dev]

On Thu, May 2, 2024 at 5:29 PM Anna Petrášová via grass-dev
 wrote:
>
> Hi devs,
>
> We plan to have a call with the new Google Summer of Code students. If you 
> want to learn more about the projects and meet the students, please join the 
> call:
>
> Topic: GRASS GIS GSoC 2024
> Time: May 8, 2024 01:00 PM Eastern Time (US and Canada)
>
> Join Zoom Meeting
> https://ncsu.zoom.us/j/91478802764?pwd=NzlNc3ZvN3FMMzZxcVNzUEFsYWV3dz09
>
> Meeting ID: 914 7880 2764
> Passcode: 868437
>
> Best,
> Anna

Here in some other timezones:
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024&month=5&day=8&hour=17&min=0&sec=0&p1=207&p2=48&p3=51&p4=671

(hope I got it right)

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

[GRASS-dev] GSoC 2024

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

Hi devs,

We plan to have a call with the new Google Summer of Code students. If you
want to learn more about the projects and meet the students, please join
the call:

Topic: GRASS GIS GSoC 2024
Time: May 8, 2024 01:00 PM Eastern Time (US and Canada)

Join Zoom Meeting
https://ncsu.zoom.us/j/91478802764?pwd=NzlNc3ZvN3FMMzZxcVNzUEFsYWV3dz09

Meeting ID: 914 7880 2764
Passcode: 868437

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

Re: [GRASS-dev] GSoC 2024 - Add EODAG support to GRASS GIS

[Stefan Blumentrath via grass-dev]

Thanks, Hamed for sharing. This looks very interesting. I added some comments and suggestions.

Fingers crossed that the project gets accepted!

 

Kind regards,

Stefan

 

 

 
 

Gesendet: Sonntag, 31. März 2024 um 21:56 Uhr
Von: "Hamed A. Elgizery via grass-dev" 
An: grass-dev@lists.osgeo.org
Betreff: Re: [GRASS-dev] GSoC 2024 - Add EODAG support to GRASS GIS


Hello everyone,

 

I am interested on working on Adding EODAG support to GRASS for Google Summer of Code 2024.

 

I have been working on my proposal, and I would like to share my proposal draft with you: 

https://docs.google.com/document/d/1PlUhGX_OWAOkdkHmH5smiYEgAl0yvqPh8tAa14WbE2E/edit?usp=sharing


 

I would be grateful if you could provide me with feedback and suggestions for the proposal :D

 

Kind regards,

Hamed

 


On Tue, 19 Mar 2024 at 16:19, Hamed A. Elgizery <hamedashraf2...@gmail.com> wrote:


Okay, sounds good. I will work on that.
 

Thank you!

 

Best,

Hamed

 


On Tue, 19 Mar 2024 at 05:25, Vaclav Petras <wenzesl...@gmail.com> wrote:



 


Hi and welcome Hamed,
 


On Mon, 18 Mar 2024 at 20:10, Hamed A. Elgizery via grass-dev <grass-dev@lists.osgeo.org> wrote:




Can you please guide me with any materials — if available — regarding the datasets? And if there is an issue “test of skills” available that is related to EODAG, since there are no issues associated with this task here: https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#:~:text=i.landsat.download-,Test%20of%20skills%3A,-GUI%3A%20Add%20space



 

This was suggested in the past by Luca as a test of skills for this topic:

 

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

 

Best,

Vaclav







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



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

Re: [GRASS-dev] [GSoC 2024] OSGeo Grass: Add JSON output to different tools in C

[Kriti Birda via grass-dev]

Hi Anna,

Thanks again for the feedback. I have submitted my proposal on the GSoC
portal.

Regards.

On Mon, Apr 1, 2024 at 6:59 PM Anna Petrášová  wrote:

> Hi Kriti,
>
> I think you can go ahead and submit it!
>
> Anna
>
> On Wed, Mar 27, 2024 at 3:22 PM Kriti Birda 
> wrote:
>
>> Hi Anna,
>>
>> Thanks for the feedback and the insights. I had put 1 per week as a
>> conservative estimate but yes I think more should be doable too. Please let
>> me know if I should make any other changes to the proposal.
>>
>> Regards.
>>
>> On Thu, Mar 28, 2024 at 12:38 AM Anna Petrášová 
>> wrote:
>>
>>> Hi Kriti,
>>>
>>> Welcome and thank you for your interest! I provided some suggestions in
>>> terms of which tools to prioritize. I put two tools per week, I think it's
>>> feasible, but please understand this is flexible and one tool a week would
>>> be a success as well. The priority of the tools may change as well based on
>>> the community input and other factors.
>>>
>>> Best,
>>> Anna
>>>
>>>
>>> On Wed, Mar 27, 2024 at 9:44 AM Kriti Birda via grass-dev <
>>> grass-dev@lists.osgeo.org> wrote:
>>>
 Hello Grass devs,

 I am Kriti Birda, an undergraduate student of Bachelor of Science at
 Indian Institute of Technology, Madras. I would like to apply to your
 organisation for Google Summer of Code this year. I find the idea to add
 JSON output to various tools in Grass particularly interesting. I have also
 worked closely with Grass devs over the past few days to add JSON output
 support to one module (https://github.com/OSGeo/grass/pull/3528). Here
 is a draft project proposal I wrote for my application:
 https://docs.google.com/document/d/1CQOAkjKINPeWt7pW561Jp1WEWV90ws-m_ybOQLIWvOM/edit?usp=sharing.
 It would be awesome if you could review and provide feedback on how I can
 improve it.

 Looking forward to hearing from you. Warm Regards.
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 https://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] [GSoC 2024] OSGeo Grass: Add JSON output to different tools in C

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

Hi Kriti,

I think you can go ahead and submit it!

Anna

On Wed, Mar 27, 2024 at 3:22 PM Kriti Birda 
wrote:

> Hi Anna,
>
> Thanks for the feedback and the insights. I had put 1 per week as a
> conservative estimate but yes I think more should be doable too. Please let
> me know if I should make any other changes to the proposal.
>
> Regards.
>
> On Thu, Mar 28, 2024 at 12:38 AM Anna Petrášová 
> wrote:
>
>> Hi Kriti,
>>
>> Welcome and thank you for your interest! I provided some suggestions in
>> terms of which tools to prioritize. I put two tools per week, I think it's
>> feasible, but please understand this is flexible and one tool a week would
>> be a success as well. The priority of the tools may change as well based on
>> the community input and other factors.
>>
>> Best,
>> Anna
>>
>>
>> On Wed, Mar 27, 2024 at 9:44 AM Kriti Birda via grass-dev <
>> grass-dev@lists.osgeo.org> wrote:
>>
>>> Hello Grass devs,
>>>
>>> I am Kriti Birda, an undergraduate student of Bachelor of Science at
>>> Indian Institute of Technology, Madras. I would like to apply to your
>>> organisation for Google Summer of Code this year. I find the idea to add
>>> JSON output to various tools in Grass particularly interesting. I have also
>>> worked closely with Grass devs over the past few days to add JSON output
>>> support to one module (https://github.com/OSGeo/grass/pull/3528). Here
>>> is a draft project proposal I wrote for my application:
>>> https://docs.google.com/document/d/1CQOAkjKINPeWt7pW561Jp1WEWV90ws-m_ybOQLIWvOM/edit?usp=sharing.
>>> It would be awesome if you could review and provide feedback on how I can
>>> improve it.
>>>
>>> Looking forward to hearing from you. Warm Regards.
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Proposal [Improve GRASS user experience in Jupyter Notebook]

[Riya Saxena via grass-dev]

{
  "emoji": "💖",
  "version": 1
}___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2024 - Add EODAG support to GRASS GIS

[Hamed A. Elgizery via grass-dev]

Hello everyone,

I am interested on working on Adding EODAG support to GRASS for Google
Summer of Code 2024.

I have been working on my proposal, and I would like to share my proposal
draft with you:
https://docs.google.com/document/d/1PlUhGX_OWAOkdkHmH5smiYEgAl0yvqPh8tAa14WbE2E/edit?usp=sharing

I would be grateful if you could provide me with feedback and suggestions
for the proposal :D

Kind regards,
Hamed

On Tue, 19 Mar 2024 at 16:19, Hamed A. Elgizery 
wrote:

> Okay, sounds good. I will work on that.
>
> Thank you!
>
> Best,
> Hamed
>
> On Tue, 19 Mar 2024 at 05:25, Vaclav Petras  wrote:
>
>>
>> Hi and welcome Hamed,
>>
>> On Mon, 18 Mar 2024 at 20:10, Hamed A. Elgizery via grass-dev <
>> grass-dev@lists.osgeo.org> wrote:
>>
>>>
>>> Can you please guide me with any materials — if available — regarding
>>> the datasets? And if there is an issue “test of skills” available that is
>>> related to EODAG, since there are no issues associated with this task here:
>>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#:~:text=i.landsat.download-,Test%20of%20skills%3A,-GUI%3A%20Add%20space
>>>
>>
>> This was suggested in the past by Luca as a test of skills for this topic:
>>
>> https://github.com/OSGeo/grass-addons/issues/1033
>>
>> Best,
>> Vaclav
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Proposal [Improve GRASS user experience in Jupyter Notebook]

[Veronica Andreo via grass-dev]

Hello Riya,

Welcome to GRASS GIS and thanks for sharing the proposal draft! I went
through it earlier this morning, and it looks really good :)
I'm looking forward to testing and using those planned new features!

Happy coding!
Vero

El mar, 26 mar 2024 a las 11:55, Riya Saxena via grass-dev (<
grass-dev@lists.osgeo.org>) escribió:

> Hello everyone,
>
> I am Riya, a pre-final year undergrad at the Department of Earth Sciences,
> IIT Roorkee. My interest in GIS stems from an Introduction to GIS course
> taught by Arun K. Saraf in my last semester.
>
> I started exploring GIS, which led me to GRASS GIS and ultimately to GSoC,
> which combined my interest in open-source and GIS. It is a perfect
> opportunity to spend my summers on (or even continue my M.Tech
> dissertation).
>
> Over the last few weeks, Anna guided me in writing my draft proposal.
> Please find it linked here: GSoC Draft
> . I would love to receive
> reviews from the dev community on my proposal.
>
> Looking forward to receiving your reviews.
>
> Regards,
> Riya
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>


-- 
Dra. Verónica Andreo
Investigadora Adjunta 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-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GSoC 2024] OSGeo Grass: Add JSON output to different tools in C

[Kriti Birda via grass-dev]

Hi Anna,

Thanks for the feedback and the insights. I had put 1 per week as a
conservative estimate but yes I think more should be doable too. Please let
me know if I should make any other changes to the proposal.

Regards.

On Thu, Mar 28, 2024 at 12:38 AM Anna Petrášová 
wrote:

> Hi Kriti,
>
> Welcome and thank you for your interest! I provided some suggestions in
> terms of which tools to prioritize. I put two tools per week, I think it's
> feasible, but please understand this is flexible and one tool a week would
> be a success as well. The priority of the tools may change as well based on
> the community input and other factors.
>
> Best,
> Anna
>
>
> On Wed, Mar 27, 2024 at 9:44 AM Kriti Birda via grass-dev <
> grass-dev@lists.osgeo.org> wrote:
>
>> Hello Grass devs,
>>
>> I am Kriti Birda, an undergraduate student of Bachelor of Science at
>> Indian Institute of Technology, Madras. I would like to apply to your
>> organisation for Google Summer of Code this year. I find the idea to add
>> JSON output to various tools in Grass particularly interesting. I have also
>> worked closely with Grass devs over the past few days to add JSON output
>> support to one module (https://github.com/OSGeo/grass/pull/3528). Here
>> is a draft project proposal I wrote for my application:
>> https://docs.google.com/document/d/1CQOAkjKINPeWt7pW561Jp1WEWV90ws-m_ybOQLIWvOM/edit?usp=sharing.
>> It would be awesome if you could review and provide feedback on how I can
>> improve it.
>>
>> Looking forward to hearing from you. Warm Regards.
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GSoC 2024] OSGeo Grass: Add JSON output to different tools in C

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

Hi Kriti,

Welcome and thank you for your interest! I provided some suggestions in
terms of which tools to prioritize. I put two tools per week, I think it's
feasible, but please understand this is flexible and one tool a week would
be a success as well. The priority of the tools may change as well based on
the community input and other factors.

Best,
Anna


On Wed, Mar 27, 2024 at 9:44 AM Kriti Birda via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Hello Grass devs,
>
> I am Kriti Birda, an undergraduate student of Bachelor of Science at
> Indian Institute of Technology, Madras. I would like to apply to your
> organisation for Google Summer of Code this year. I find the idea to add
> JSON output to various tools in Grass particularly interesting. I have also
> worked closely with Grass devs over the past few days to add JSON output
> support to one module (https://github.com/OSGeo/grass/pull/3528). Here is
> a draft project proposal I wrote for my application:
> https://docs.google.com/document/d/1CQOAkjKINPeWt7pW561Jp1WEWV90ws-m_ybOQLIWvOM/edit?usp=sharing.
> It would be awesome if you could review and provide feedback on how I can
> improve it.
>
> Looking forward to hearing from you. Warm Regards.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GSoC 2024] OSGeo Grass: Add JSON output to different tools in C

[Kriti Birda via grass-dev]

Hello Grass devs,

I am Kriti Birda, an undergraduate student of Bachelor of Science at Indian
Institute of Technology, Madras. I would like to apply to your organisation
for Google Summer of Code this year. I find the idea to add JSON output to
various tools in Grass particularly interesting. I have also worked closely
with Grass devs over the past few days to add JSON output support to one
module (https://github.com/OSGeo/grass/pull/3528). Here is a draft project
proposal I wrote for my application:
https://docs.google.com/document/d/1CQOAkjKINPeWt7pW561Jp1WEWV90ws-m_ybOQLIWvOM/edit?usp=sharing.
It would be awesome if you could review and provide feedback on how I can
improve it.

Looking forward to hearing from you. Warm Regards.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Proposal [Improve GRASS user experience in Jupyter Notebook]

[Riya Saxena via grass-dev]

Hello everyone,

I am Riya, a pre-final year undergrad at the Department of Earth Sciences,
IIT Roorkee. My interest in GIS stems from an Introduction to GIS course
taught by Arun K. Saraf in my last semester.

I started exploring GIS, which led me to GRASS GIS and ultimately to GSoC,
which combined my interest in open-source and GIS. It is a perfect
opportunity to spend my summers on (or even continue my M.Tech
dissertation).

Over the last few weeks, Anna guided me in writing my draft proposal.
Please find it linked here: GSoC Draft
. I would love to receive reviews
from the dev community on my proposal.

Looking forward to receiving your reviews.

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

Re: [GRASS-dev] GSoC 2024 - Add EODAG support to GRASS GIS

[Hamed A. Elgizery via grass-dev]

Okay, sounds good. I will work on that.

Thank you!

Best,
Hamed

On Tue, 19 Mar 2024 at 05:25, Vaclav Petras  wrote:

>
> Hi and welcome Hamed,
>
> On Mon, 18 Mar 2024 at 20:10, Hamed A. Elgizery via grass-dev <
> grass-dev@lists.osgeo.org> wrote:
>
>>
>> Can you please guide me with any materials — if available — regarding the
>> datasets? And if there is an issue “test of skills” available that is
>> related to EODAG, since there are no issues associated with this task here:
>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#:~:text=i.landsat.download-,Test%20of%20skills%3A,-GUI%3A%20Add%20space
>>
>
> This was suggested in the past by Luca as a test of skills for this topic:
>
> https://github.com/OSGeo/grass-addons/issues/1033
>
> Best,
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2024 - Add EODAG support to GRASS GIS

[Vaclav Petras via grass-dev]

Hi and welcome Hamed,

On Mon, 18 Mar 2024 at 20:10, Hamed A. Elgizery via grass-dev <
grass-dev@lists.osgeo.org> wrote:

>
> Can you please guide me with any materials — if available — regarding the
> datasets? And if there is an issue “test of skills” available that is
> related to EODAG, since there are no issues associated with this task here:
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#:~:text=i.landsat.download-,Test%20of%20skills%3A,-GUI%3A%20Add%20space
>

This was suggested in the past by Luca as a test of skills for this topic:

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

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

[GRASS-dev] GSoC 2024 - Add EODAG support to GRASS GIS

[Hamed A. Elgizery via grass-dev]

Hello everyone,

My name is Hamed. I have developed an interest in working on adding EDOAG
support to GRASS GIS during GSoC.

About me:
I am a sophomore CS student at the Arab Academy for Science & Technology. I
have solid problem-solving skills due to my involvement in Competitive
Programming competitions for 5+ years.

I have thoroughly gone through the EODAG website, and I have got a
reasonable overview of what are the expected outcomes.
I am going to fulfill the expectations of the task by implementing a module
that will utilize the EDOAG library to download the required datasets from
the different providers without having to worry about the different methods
for dealing with each provider. I am currently working on compiling GRASS
locally and setting up my coding environment.
Can you please guide me with any materials — if available — regarding the
datasets? And if there is an issue “test of skills” available that is
related to EODAG, since there are no issues associated with this task here:
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#:~:text=i.landsat.download-,Test%20of%20skills%3A,-GUI%3A%20Add%20space

I am looking forward to contributing to this task, as it will speed up the
future development of GRASS GIS and open new possibilities.

Kind regards,
Hamed A. Elgizery
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

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

On Sun, Mar 3, 2024 at 4:07 PM Luca Delucchi  wrote:

> Hi Anna,
>
> On Fri, 1 Mar 2024 at 17:30, Anna Petrášová  wrote:
> >
> > We have already students wanting to work on github issues linked as test
> of skills. Martin and Luca, your ideas don't have a test of skills, please
> add it there as soon as possible, otherwise we can't really use the idea,
> test of skills is required by OSGeo.
> >
>
> Thanks for the reminder, I created this issue
> https://github.com/OSGeo/grass-addons/issues/1033, is it doable or too
> complicated?
>
> Sure, that works!


> > Thank you
> >
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Luca Delucchi via grass-dev]

Hi Anna,

On Fri, 1 Mar 2024 at 17:30, Anna Petrášová  wrote:
>
> We have already students wanting to work on github issues linked as test of 
> skills. Martin and Luca, your ideas don't have a test of skills, please add 
> it there as soon as possible, otherwise we can't really use the idea, test of 
> skills is required by OSGeo.
>

Thanks for the reminder, I created this issue
https://github.com/OSGeo/grass-addons/issues/1033, is it doable or too
complicated?

> Thank you
>

-- 
ciao
Luca

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

Re: [GRASS-dev] GSoC Ideas

[Martin Landa via grass-dev]

Hi Anna,

pá 1. 3. 2024 v 17:35 odesílatel Anna Petrášová 
napsal:

> Martin, how about using https://github.com/OSGeo/grass/issues/2599 as a
> test?
>

good idea, thanks for pointing this out. Martin

-- 
Martin Landa
https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

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

Martin, how about using https://github.com/OSGeo/grass/issues/2599 as a
test?

On Fri, Mar 1, 2024 at 11:29 AM Anna Petrášová 
wrote:

> We have already students wanting to work on github issues linked as test
> of skills. Martin and Luca, your ideas don't have a test of skills, please
> add it there as soon as possible, otherwise we can't really use the idea,
> test of skills is required by OSGeo.
>
> Thank you
>
> On Mon, Feb 26, 2024 at 1:32 PM Anna Petrášová 
> wrote:
>
>> Good news, OSGeo was accepted [1]. We need to do some advertising now.
>>
>> [1] https://lists.osgeo.org/pipermail/discuss/2024-February/040113.html
>>
>> On Sat, Feb 24, 2024 at 9:04 AM Anna Petrášová 
>> wrote:
>>
>>>
>>>
>>> On Fri, Feb 23, 2024, 6:11 PM Martin Landa 
>>> wrote:
>>>
 Hi,

 so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <
 grass-dev@lists.osgeo.org> napsal:

> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac
> wiki, which I think we should be moving away from):
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>
> It's not updated yet, I plan to add more topics. If you want to mentor
> a topic, we can discuss it here.
>

 I add a new topic related to space-time datasets and Data Catalog [1].
 Martin

>>>
>>> Thanks for adding the topic, please also include a test of skills and at
>>> least for now assign yourself as a mentor, I can be a co-mentor.
>>>
>>> Anna
>>>

 [1]
 https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#GUI%3A_Add_space-time_datasets_support_in_Data_Catalog

 --
 Martin Landa
 https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
 http://gismentors.cz/mentors/landa

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

Re: [GRASS-dev] GSoC Ideas

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

We have already students wanting to work on github issues linked as test of
skills. Martin and Luca, your ideas don't have a test of skills, please add
it there as soon as possible, otherwise we can't really use the idea, test
of skills is required by OSGeo.

Thank you

On Mon, Feb 26, 2024 at 1:32 PM Anna Petrášová 
wrote:

> Good news, OSGeo was accepted [1]. We need to do some advertising now.
>
> [1] https://lists.osgeo.org/pipermail/discuss/2024-February/040113.html
>
> On Sat, Feb 24, 2024 at 9:04 AM Anna Petrášová 
> wrote:
>
>>
>>
>> On Fri, Feb 23, 2024, 6:11 PM Martin Landa 
>> wrote:
>>
>>> Hi,
>>>
>>> so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <
>>> grass-dev@lists.osgeo.org> napsal:
>>>
 I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
 which I think we should be moving away from):
 https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024

 It's not updated yet, I plan to add more topics. If you want to mentor
 a topic, we can discuss it here.

>>>
>>> I add a new topic related to space-time datasets and Data Catalog [1].
>>> Martin
>>>
>>
>> Thanks for adding the topic, please also include a test of skills and at
>> least for now assign yourself as a mentor, I can be a co-mentor.
>>
>> Anna
>>
>>>
>>> [1]
>>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#GUI%3A_Add_space-time_datasets_support_in_Data_Catalog
>>>
>>> --
>>> Martin Landa
>>> https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
>>> http://gismentors.cz/mentors/landa
>>>
>>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

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

Good news, OSGeo was accepted [1]. We need to do some advertising now.

[1] https://lists.osgeo.org/pipermail/discuss/2024-February/040113.html

On Sat, Feb 24, 2024 at 9:04 AM Anna Petrášová 
wrote:

>
>
> On Fri, Feb 23, 2024, 6:11 PM Martin Landa  wrote:
>
>> Hi,
>>
>> so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <
>> grass-dev@lists.osgeo.org> napsal:
>>
>>> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
>>> which I think we should be moving away from):
>>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>>>
>>> It's not updated yet, I plan to add more topics. If you want to mentor a
>>> topic, we can discuss it here.
>>>
>>
>> I add a new topic related to space-time datasets and Data Catalog [1].
>> Martin
>>
>
> Thanks for adding the topic, please also include a test of skills and at
> least for now assign yourself as a mentor, I can be a co-mentor.
>
> Anna
>
>>
>> [1]
>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#GUI%3A_Add_space-time_datasets_support_in_Data_Catalog
>>
>> --
>> Martin Landa
>> https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
>> http://gismentors.cz/mentors/landa
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

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

On Fri, Feb 23, 2024, 6:11 PM Martin Landa  wrote:

> Hi,
>
> so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <
> grass-dev@lists.osgeo.org> napsal:
>
>> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
>> which I think we should be moving away from):
>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>>
>> It's not updated yet, I plan to add more topics. If you want to mentor a
>> topic, we can discuss it here.
>>
>
> I add a new topic related to space-time datasets and Data Catalog [1].
> Martin
>

Thanks for adding the topic, please also include a test of skills and at
least for now assign yourself as a mentor, I can be a co-mentor.

Anna

>
> [1]
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#GUI%3A_Add_space-time_datasets_support_in_Data_Catalog
>
> --
> Martin Landa
> https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Martin Landa via grass-dev]

Hi,

so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <
grass-dev@lists.osgeo.org> napsal:

> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
> which I think we should be moving away from):
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>
> It's not updated yet, I plan to add more topics. If you want to mentor a
> topic, we can discuss it here.
>

I add a new topic related to space-time datasets and Data Catalog [1].
Martin

[1]
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#GUI%3A_Add_space-time_datasets_support_in_Data_Catalog

-- 
Martin Landa
https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

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

of black
> magick (e.g. three clicks or less to have everything ready for any of
> our intro tutorials, including opening a web browser with the chosen
> tutorial and adding some layers to the map view; two clicks (+ file
> browsing) to have users raster or vector data displayed).
>

 I think Vashek's point was to gently remind you there has been a lot of
discussion going on in the past, not to resurrect one of those ideas:)

>
> Linda, in your paper you wrote: „Since both options were favorably
> rated (85% responded positively to the first-run wizard and 74% to
> info bars), we decided to implement an info bar as a technically
> simpler and more flexible solution.“ The idea of this GSOC proposal
> was to implement in some form the second option that would allow to
> perform A/B testing with real users. As you (et al.) have done a huge
> work with the codebase, now it would be much easier to implement than
> some years a go.
> I also understand that users want to start working with the software
> right away. But here is a catch – most likely nobody will start GRASS
> to work with data provided by the demo project. Either they will start
> GRASS to do some exercises in a training course / to follow a tutorial
> (= download one of sample datasets, add some layer to the map view),
> or to work with data they have to solve the analysis problem they are
> facing (= create a new project from supplied data, import file, add it
> to the map view, display warning about computational region in your
> info bar, if imported data were vectors and not raster). If user
> cancels the wizard, just fine. Let him enjoy the demo project and
> display first time screen also on the next startup iff there is no
> project with data in the GISDBASE. This would not interfere with a
> big, fat warning if someone tries to import external data into sample
> projects (NC, Spearfish, ...) or any other enhancements that could be
> done.
>

 I agree with a lot of points you are making but I guess I still don't
understand exactly what your suggestion is and how it would make things
better and for whom...


> Huh, I think I answered most of points from previous emails (except
> going into details of potential architecture (thus Anna for wxPython
> expertise) or user friendliness (thus Vero)). Thank you to everyone
> who read this far and sorry for all unintentional fuss I caused.
> Probably Linda you are right – it is too ambitious for an experimental
> project that might get tossed away at the end. I see that Anna has
> already removed the idea from the wiki, most likely for good. Do not
> restore it, let it be so. We can return to this idea at any point
> later if we feel need for it. I have plenty to do to fix pointer
> juggling bugs in the new module I have almost finished (anisotropic
> smoothing).
> Māris.
>
> piektd., 2024. g. 16. febr., plkst. 10:41 — lietotājs Linda Kladivová
> () rakstīja:
> >
> > Hello Māris,
> >
> > just to add some other info, we did several surveys among GRASS users
> about first-time user experience with Anna, Martin and Vashek and we also
> tested old and new startup mechanisms in a real environment within the
> usability testing - you can have a look at our article:
> https://www.mdpi.com/2220-9964/12/9/376.
> >
> > As Anna has already written, the results of usability testing were
> indeed mixed but I would like to emphasize one thing - most of the
> usability participants (first-time users) said to me that they simply
> expect they will be directly redirected to the main software window where
> they can start working without knowing anything about the software. The
> current "info bar" solution goes in that direction and although I have to
> admit that it has flaws there are ways how to make it better and Anna has
> already written some points.
> >
> > I think it would be nice to focus on how to make the current solution
> better (it is definitely doable and even desirable) and not go back to some
> alternatives to the old solution.
> > Above that, it would be extremely time-consuming to implement any dialog
> wizards and at the same time the impact of that "dialog" solution is very
> uncertain - one important thing we also learned from surveys and
> discussions inside/outside the community is that the one good generally
> acceptable solution simply does not exist here - it will always be a
> compromise.
> >
> > Just my two cents. :-)
> > Linda
> >
> > -- Původní e-mail --
> > Od: Maris Nartiss via grass-dev 
> > Komu: Anna Petrášová , Veronica Andreo <
> veroand...@gmail.com>
> > Kopie: GRASS-dev 
> > Datum: 15. 2. 2024 13:04:24
> > Předmět: Re: 

Re: [GRASS-dev] GSoC Ideas

[Luí­s Moreira de Sousa via grass-dev]

Hi all, Johnny Come Lately here. Like and subscribe.
 
This thread pretty much reenacted the long discussion in Prague last June. The 
only conclusion at the time was for this proposal to not jeopardise the work 
done on the new GUI. It seems that Maris is sticking to that. I hope this 
proposal can still take shape at some point, if nothing else to understand its 
implications.

On a broader perspective, there is an obvious tension here between ease-of-use 
and correctness-of-use. A ready-to-use GUI will always be the preferred choice 
of users, both novice or seasoned (just give me the damn CLI!). But the 
educational aspect of GRASS should not be disregarded either. As an (other) 
example of how this tension has concrete implications, I leave below a link to 
the document by the Australia/New Zealand authority trying to dissuade 
communities like this one from using the WGS84 datum ensemble.

Best.

https://www.icsm.gov.au/sites/default/files/GMIWG%20Advisory%20on%20WGS%2084%20and%20Web%20Mapping%20%E2%80%93%2015%20June%202020.pdf


--
Luís


Sent with Proton Mail secure email.

On Friday, 16 February 2024 at 19:42, Maris Nartiss via grass-dev 
 wrote:

> Hello all,
> although I expected some discussion, I didn't expect a kind of Spanish
> Inquisition. To make things easier for me (I still have to type single
> handed), I'll try to address all issues in a single email.
> 
> At first we all must agree that coordinate systems, geospatial data
> and thus also GIS is hard. We will never have a perfect (the final)
> solution or a solution we all can agree on, but it shouldn't stop us
> from trying out new things.
> 
> Second – from the GSOC web site: „Google Summer of Code is a global,
> online program focused on bringing new contributors into open source
> software development.“ It is not „get some code to merge into next
> release“ and thus developing an experimental feature still is a good
> way how to get familiar with the code base, contributing to os, issues
> and features of GRASS.
> 
> Third – we should improve GRASS with a goal of making easy to do „the
> right thing“ and to make hard to do „wrong“. We have (and should
> keep!) plenty of „shortcuts“ for experienced users who understand what
> they do.
> 
> And now let's dive into specifics (in chronological order).
> Vero, I meant a first-run wizard, but choose a bad name. Sorry, my
> fault. Although I had no fundamental objections against the old
> startup screen, there is no need to resurrect it. He's dead, Jim.
> 
> Anna, there were many ideas floating around in Prague caused by the
> „location“->„project“ proposal. And you are right, we couldn't agree
> 
> on a single solution (see the first point of this email). At the same
> time there were concerns from me and others (IIRC Martin, Luís,
> Helmut?) that it is still too easy to continue with a sub-optimal or
> outright wrong CRS (location/project structure). Later on (after a few
> too many beers) I tried to convince everyone (sorry Linda!) that we
> should focus on that “easy to do right“ mantra. At the end we all
> agreed (or everyone agreed just to silence me ;-) that we should
> continue exploring alternatives and thus was the GSOC proposal.
> 
> Brendan, there's more than one way to skin a cat.
> 
> Anna, the current info bar is just bad for at least two reasons (sorry
> Linda, I'm just opinionated). Although you state that most users just
> dismiss it, I'll call it a lie – it is not possible to dismiss it at
> all! Yeah, I'm just kidding, there is a bug in the code. I rm'ed my
> .grass8 to see first start-up experience. See attachment with a cutout
> from a full screen window I was presented with – one can not read
> whole message or see any buttons as the widget is too small to fit all
> of its content. And that's even before the text is translated to
> Latvian, German or Finnish that will make the text even longer
> (Äteritsiputeritsipuolilautatsijänkä is an actual name of region in
> Lapland and makes a good word to test UI).
> The info bar has fallen into the old startup window trap – try to
> explain GRASS specifics (an important thing!) instead of providing
> easy actionable options that all lead to „doing it right“. It is a
> TL;DR, and why I should „create new project“ if I already have one
> open? Keep in mind attention span of a goldfish (a.k.a. length of a
> Tiktok video) we are dealing with. (Has anyone read this far? Let me
> know in the comments and don't forget to like and subscribe.)
> My idea did not interfere with implementing an offer to create a new
> project in import tools if a reprojection from projected to ll project
> is detected (I <3 how this sentence rolls-off my tongue) or any other
> enhancements that also can (and should) be implemented.
> 
> Vaclav, thanks. I was thinking of something like A1 proposal, but even
> simpler (three + 1 buttons) and the same time with a lot of black
> magick (e.g. three clicks or less to have everything ready for any of
> our in

Re: [GRASS-dev] GSoC Ideas

[Maris Nartiss via grass-dev]

n your
info bar, if imported data were vectors and not raster). If user
cancels the wizard, just fine. Let him enjoy the demo project and
display first time screen also on the next startup iff there is no
project with data in the GISDBASE. This would not interfere with a
big, fat warning if someone tries to import external data into sample
projects (NC, Spearfish, ...) or any other enhancements that could be
done.

Huh, I think I answered most of points from previous emails (except
going into details of potential architecture (thus Anna for wxPython
expertise) or user friendliness (thus Vero)). Thank you to everyone
who read this far and sorry for all unintentional fuss I caused.
Probably Linda you are right – it is too ambitious for an experimental
project that might get tossed away at the end. I see that Anna has
already removed the idea from the wiki, most likely for good. Do not
restore it, let it be so. We can return to this idea at any point
later if we feel need for it. I have plenty to do to fix pointer
juggling bugs in the new module I have almost finished (anisotropic
smoothing).
Māris.

piektd., 2024. g. 16. febr., plkst. 10:41 — lietotājs Linda Kladivová
() rakstīja:
>
> Hello Māris,
>
> just to add some other info, we did several surveys among GRASS users about 
> first-time user experience with Anna, Martin and Vashek and we also tested 
> old and new startup mechanisms in a real environment within the usability 
> testing - you can have a look at our article: 
> https://www.mdpi.com/2220-9964/12/9/376.
>
> As Anna has already written, the results of usability testing were indeed 
> mixed but I would like to emphasize one thing - most of the usability 
> participants (first-time users) said to me that they simply expect they will 
> be directly redirected to the main software window where they can start 
> working without knowing anything about the software. The current "info bar" 
> solution goes in that direction and although I have to admit that it has 
> flaws there are ways how to make it better and Anna has already written some 
> points.
>
> I think it would be nice to focus on how to make the current solution better 
> (it is definitely doable and even desirable) and not go back to some 
> alternatives to the old solution.
> Above that, it would be extremely time-consuming to implement any dialog 
> wizards and at the same time the impact of that "dialog" solution is very 
> uncertain - one important thing we also learned from surveys and discussions 
> inside/outside the community is that the one good generally acceptable 
> solution simply does not exist here - it will always be a compromise.
>
> Just my two cents. :-)
> Linda
>
> ------ Původní e-mail --
> Od: Maris Nartiss via grass-dev 
> Komu: Anna Petrášová , Veronica Andreo 
> 
> Kopie: GRASS-dev 
> Datum: 15. 2. 2024 13:04:24
> Předmět: Re: [GRASS-dev] GSoC Ideas
>
> Hello Anna, Vero.
> I added the welcome screen idea we discussed during our Prague
> meeting. I think it would be a good GSOC project as it is quite easy
> and at the same time will allow to understand if it is the way to go.
> Anna, would you be able to be a co-mentor as it is a GUI project? Or
> who else could be?
> Vero, your user-centric view also would be valuable.
> Please edit the wiki accordingly.
>
> Thanks,
> Māris.
>
> sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
> grass-dev () rakstīja:
> >
> > Hi,
> >
> > I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, 
> > which I think we should be moving away from):
> > https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
> >
> > It's not updated yet, I plan to add more topics. If you want to mentor a 
> > topic, we can discuss it here.
> >
> > Anna
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Linda Kladivová via grass-dev]

Hello Māris,




just to add some other info, we did several surveys among GRASS users about
first-time user experience with Anna, Martin and Vashek and we also tested
old and new startup mechanisms in a real environment within the usability 
testing - you can have a look at our article: https://www.mdpi.com/2220-
9964/12/9/376.




As Anna has already written, the results of usability testing were indeed 
mixed but I would like to emphasize one thing - most of the usability
participants (first-time users) said to me that they simply expect they will
be directly redirected to the main software window where they can start 
working without knowing anything about the software. The current "info bar"
solution goes in that direction and although I have to admit that it has 
flaws there are ways how to make it better and Anna has already written some
points.


I think it would be nice to focus on how to make the current solution better
(it is definitely doable and even desirable) and not go back to some
alternatives to the old solution.

Above that, it would be extremely time-consuming to implement any dialog 
wizards and at the same time the impact of that "dialog" solution is very 
uncertain - one important thing we also learned from surveys and discussions
inside/outside the community is that the one good generally acceptable
solution simply does not exist here - it will always be a compromise.



Just my two cents. :-)


Linda




-- Původní e-mail --
Od: Maris Nartiss via grass-dev 
Komu: Anna Petrášová , Veronica Andreo 
Kopie: GRASS-dev 
Datum: 15. 2. 2024 13:04:24
Předmět: Re: [GRASS-dev] GSoC Ideas
"Hello Anna, Vero.
I added the welcome screen idea we discussed during our Prague
meeting. I think it would be a good GSOC project as it is quite easy
and at the same time will allow to understand if it is the way to go.
Anna, would you be able to be a co-mentor as it is a GUI project? Or
who else could be?
Vero, your user-centric view also would be valuable.
Please edit the wiki accordingly.

Thanks,
Māris.

sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
grass-dev () rakstīja:
>
> Hi,
>
> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, 
which I think we should be moving away from):
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>
> It's not updated yet, I plan to add more topics. If you want to mentor a
topic, we can discuss it here.
>
> Anna
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
"___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Vaclav Petras via grass-dev]

Seeing the new startup screen idea description, the "Proposals for a new
GRASS GIS startup mechanism" wiki page on Trac wiki might be a good read:

https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup

On Thu, 15 Feb 2024 at 14:11, Anna Petrášová via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> I believe the welcome screen would most likely be dismissed. The other
> possible solutions Brendan brings up may be difficult to implement with
> wxpython. But we tried to do something similar with Linda using the info
> bar, which shows info/buttons for first-time users. She tested that with
> mixed results, people often just dismissed it. But I think it could be
> further refined. For example, maybe we could move it to map display to make
> it more prominent. The other direction is to better detect when users are
> doing something likely wrong (import projected data to default project) and
> then suggest alternatives.
>
> On Thu, Feb 15, 2024 at 12:05 PM Brendan  wrote:
>
>> Personally I like the new interface, but Maris' proposal for wizards to
>> create new projects sounds helpful. Rather than a startup screen that
>> stalls users, there could be temporary icons floating on the map canvas
>> that prompt users to create a new project in different ways. Would
>> disappear as soon as data is added to the map. A helpful guide/shortcut
>> that users could choose to ignore. Still, any startup hints might be
>> annoying like Clippy the infamous paperclip. I can find an example from
>> other software if the idea is of interest. Or the logo that pops up when
>> you start GRASS could have buttons for creating new projects; if a user
>> doesn't click on them while GRASS is starting, then it will open in the
>> default / previous project.
>> Best, Brendan
>>
>> On Thu, Feb 15, 2024 at 8:35 AM Anna Petrášová via grass-dev <
>> grass-dev@lists.osgeo.org> wrote:
>>
>>> I agree with Vero. I am not sure we had enough time to evaluate the
>>> current state yet. I don't remember the details of our discussions, so if
>>> you provide a description of what exactly you mean, that would be helpful.
>>> In terms of a GSoC project, the main issue I see is that the mentors need
>>> to provide clear instructions on what the student should do, especially for
>>> this case, and we apparently don't have a consensus here. So I would be
>>> willing to mentor it only as long as we develop a plan ahead of time we can
>>> all agree on. Given the past experience, I am somewhat skeptical we can all
>>> agree on something:) But I'll try to be open to ideas!
>>>
>>> On Thu, Feb 15, 2024 at 8:12 AM Veronica Andreo 
>>> wrote:
>>>
 Hi Maris,

 Would you mind sharing more details on this idea? I'm afraid I was not
 able to attend/hear the discussion about this welcome screen in Prague. I
 hope though we do not end up with a new startup screen. It took so much
 time to reach an agreement and finally remove it.

 Vero

 El jue, 15 feb 2024 a las 9:00, Maris Nartiss ()
 escribió:

> Hello Anna, Vero.
> I added the welcome screen idea we discussed during our Prague
> meeting. I think it would be a good GSOC project as it is quite easy
> and at the same time will allow to understand if it is the way to go.
> Anna, would you be able to be a co-mentor as it is a GUI project? Or
> who else could be?
> Vero, your user-centric view also would be valuable.
> Please edit the wiki accordingly.
>
> Thanks,
> Māris.
>
> sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
> grass-dev () rakstīja:
> >
> > Hi,
> >
> > I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac
> wiki, which I think we should be moving away from):
> > https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
> >
> > It's not updated yet, I plan to add more topics. If you want to
> mentor a topic, we can discuss it here.
> >
> > Anna
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>


 --
 Dra. Verónica Andreo
 Investigadora Adjunta 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-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

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

I believe the welcome screen would most likely be dismissed. The other
possible solutions Brendan brings up may be difficult to implement with
wxpython. But we tried to do something similar with Linda using the info
bar, which shows info/buttons for first-time users. She tested that with
mixed results, people often just dismissed it. But I think it could be
further refined. For example, maybe we could move it to map display to make
it more prominent. The other direction is to better detect when users are
doing something likely wrong (import projected data to default project) and
then suggest alternatives.

On Thu, Feb 15, 2024 at 12:05 PM Brendan  wrote:

> Personally I like the new interface, but Maris' proposal for wizards to
> create new projects sounds helpful. Rather than a startup screen that
> stalls users, there could be temporary icons floating on the map canvas
> that prompt users to create a new project in different ways. Would
> disappear as soon as data is added to the map. A helpful guide/shortcut
> that users could choose to ignore. Still, any startup hints might be
> annoying like Clippy the infamous paperclip. I can find an example from
> other software if the idea is of interest. Or the logo that pops up when
> you start GRASS could have buttons for creating new projects; if a user
> doesn't click on them while GRASS is starting, then it will open in the
> default / previous project.
> Best, Brendan
>
> On Thu, Feb 15, 2024 at 8:35 AM Anna Petrášová via grass-dev <
> grass-dev@lists.osgeo.org> wrote:
>
>> I agree with Vero. I am not sure we had enough time to evaluate the
>> current state yet. I don't remember the details of our discussions, so if
>> you provide a description of what exactly you mean, that would be helpful.
>> In terms of a GSoC project, the main issue I see is that the mentors need
>> to provide clear instructions on what the student should do, especially for
>> this case, and we apparently don't have a consensus here. So I would be
>> willing to mentor it only as long as we develop a plan ahead of time we can
>> all agree on. Given the past experience, I am somewhat skeptical we can all
>> agree on something:) But I'll try to be open to ideas!
>>
>> On Thu, Feb 15, 2024 at 8:12 AM Veronica Andreo 
>> wrote:
>>
>>> Hi Maris,
>>>
>>> Would you mind sharing more details on this idea? I'm afraid I was not
>>> able to attend/hear the discussion about this welcome screen in Prague. I
>>> hope though we do not end up with a new startup screen. It took so much
>>> time to reach an agreement and finally remove it.
>>>
>>> Vero
>>>
>>> El jue, 15 feb 2024 a las 9:00, Maris Nartiss ()
>>> escribió:
>>>
 Hello Anna, Vero.
 I added the welcome screen idea we discussed during our Prague
 meeting. I think it would be a good GSOC project as it is quite easy
 and at the same time will allow to understand if it is the way to go.
 Anna, would you be able to be a co-mentor as it is a GUI project? Or
 who else could be?
 Vero, your user-centric view also would be valuable.
 Please edit the wiki accordingly.

 Thanks,
 Māris.

 sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
 grass-dev () rakstīja:
 >
 > Hi,
 >
 > I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac
 wiki, which I think we should be moving away from):
 > https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
 >
 > It's not updated yet, I plan to add more topics. If you want to
 mentor a topic, we can discuss it here.
 >
 > Anna
 > ___
 > grass-dev mailing list
 > grass-dev@lists.osgeo.org
 > https://lists.osgeo.org/mailman/listinfo/grass-dev

>>>
>>>
>>> --
>>> Dra. Verónica Andreo
>>> Investigadora Adjunta 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-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Brendan via grass-dev]

Personally I like the new interface, but Maris' proposal for wizards to
create new projects sounds helpful. Rather than a startup screen that
stalls users, there could be temporary icons floating on the map canvas
that prompt users to create a new project in different ways. Would
disappear as soon as data is added to the map. A helpful guide/shortcut
that users could choose to ignore. Still, any startup hints might be
annoying like Clippy the infamous paperclip. I can find an example from
other software if the idea is of interest. Or the logo that pops up when
you start GRASS could have buttons for creating new projects; if a user
doesn't click on them while GRASS is starting, then it will open in the
default / previous project.
Best, Brendan

On Thu, Feb 15, 2024 at 8:35 AM Anna Petrášová via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> I agree with Vero. I am not sure we had enough time to evaluate the
> current state yet. I don't remember the details of our discussions, so if
> you provide a description of what exactly you mean, that would be helpful.
> In terms of a GSoC project, the main issue I see is that the mentors need
> to provide clear instructions on what the student should do, especially for
> this case, and we apparently don't have a consensus here. So I would be
> willing to mentor it only as long as we develop a plan ahead of time we can
> all agree on. Given the past experience, I am somewhat skeptical we can all
> agree on something:) But I'll try to be open to ideas!
>
> On Thu, Feb 15, 2024 at 8:12 AM Veronica Andreo 
> wrote:
>
>> Hi Maris,
>>
>> Would you mind sharing more details on this idea? I'm afraid I was not
>> able to attend/hear the discussion about this welcome screen in Prague. I
>> hope though we do not end up with a new startup screen. It took so much
>> time to reach an agreement and finally remove it.
>>
>> Vero
>>
>> El jue, 15 feb 2024 a las 9:00, Maris Nartiss ()
>> escribió:
>>
>>> Hello Anna, Vero.
>>> I added the welcome screen idea we discussed during our Prague
>>> meeting. I think it would be a good GSOC project as it is quite easy
>>> and at the same time will allow to understand if it is the way to go.
>>> Anna, would you be able to be a co-mentor as it is a GUI project? Or
>>> who else could be?
>>> Vero, your user-centric view also would be valuable.
>>> Please edit the wiki accordingly.
>>>
>>> Thanks,
>>> Māris.
>>>
>>> sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
>>> grass-dev () rakstīja:
>>> >
>>> > Hi,
>>> >
>>> > I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac
>>> wiki, which I think we should be moving away from):
>>> > https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>>> >
>>> > It's not updated yet, I plan to add more topics. If you want to mentor
>>> a topic, we can discuss it here.
>>> >
>>> > Anna
>>> > ___
>>> > grass-dev mailing list
>>> > grass-dev@lists.osgeo.org
>>> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>>
>>
>> --
>> Dra. Verónica Andreo
>> Investigadora Adjunta 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-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

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

I agree with Vero. I am not sure we had enough time to evaluate the current
state yet. I don't remember the details of our discussions, so if you
provide a description of what exactly you mean, that would be helpful. In
terms of a GSoC project, the main issue I see is that the mentors need to
provide clear instructions on what the student should do, especially for
this case, and we apparently don't have a consensus here. So I would be
willing to mentor it only as long as we develop a plan ahead of time we can
all agree on. Given the past experience, I am somewhat skeptical we can all
agree on something:) But I'll try to be open to ideas!

On Thu, Feb 15, 2024 at 8:12 AM Veronica Andreo 
wrote:

> Hi Maris,
>
> Would you mind sharing more details on this idea? I'm afraid I was not
> able to attend/hear the discussion about this welcome screen in Prague. I
> hope though we do not end up with a new startup screen. It took so much
> time to reach an agreement and finally remove it.
>
> Vero
>
> El jue, 15 feb 2024 a las 9:00, Maris Nartiss ()
> escribió:
>
>> Hello Anna, Vero.
>> I added the welcome screen idea we discussed during our Prague
>> meeting. I think it would be a good GSOC project as it is quite easy
>> and at the same time will allow to understand if it is the way to go.
>> Anna, would you be able to be a co-mentor as it is a GUI project? Or
>> who else could be?
>> Vero, your user-centric view also would be valuable.
>> Please edit the wiki accordingly.
>>
>> Thanks,
>> Māris.
>>
>> sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
>> grass-dev () rakstīja:
>> >
>> > Hi,
>> >
>> > I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
>> which I think we should be moving away from):
>> > https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>> >
>> > It's not updated yet, I plan to add more topics. If you want to mentor
>> a topic, we can discuss it here.
>> >
>> > Anna
>> > ___
>> > grass-dev mailing list
>> > grass-dev@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
> --
> Dra. Verónica Andreo
> Investigadora Adjunta 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-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Veronica Andreo via grass-dev]

Hi Maris,

Would you mind sharing more details on this idea? I'm afraid I was not able
to attend/hear the discussion about this welcome screen in Prague. I hope
though we do not end up with a new startup screen. It took so much time to
reach an agreement and finally remove it.

Vero

El jue, 15 feb 2024 a las 9:00, Maris Nartiss ()
escribió:

> Hello Anna, Vero.
> I added the welcome screen idea we discussed during our Prague
> meeting. I think it would be a good GSOC project as it is quite easy
> and at the same time will allow to understand if it is the way to go.
> Anna, would you be able to be a co-mentor as it is a GUI project? Or
> who else could be?
> Vero, your user-centric view also would be valuable.
> Please edit the wiki accordingly.
>
> Thanks,
> Māris.
>
> sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
> grass-dev () rakstīja:
> >
> > Hi,
> >
> > I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
> which I think we should be moving away from):
> > https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
> >
> > It's not updated yet, I plan to add more topics. If you want to mentor a
> topic, we can discuss it here.
> >
> > Anna
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>


-- 
Dra. Verónica Andreo
Investigadora Adjunta 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-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Maris Nartiss via grass-dev]

Hello Anna, Vero.
I added the welcome screen idea we discussed during our Prague
meeting. I think it would be a good GSOC project as it is quite easy
and at the same time will allow to understand if it is the way to go.
Anna, would you be able to be a co-mentor as it is a GUI project? Or
who else could be?
Vero, your user-centric view also would be valuable.
Please edit the wiki accordingly.

Thanks,
Māris.

sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
grass-dev () rakstīja:
>
> Hi,
>
> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which 
> I think we should be moving away from):
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>
> It's not updated yet, I plan to add more topics. If you want to mentor a 
> topic, we can discuss it here.
>
> Anna
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Luca Delucchi via grass-dev]

On Mon, 12 Feb 2024 at 18:08, Markus Neteler  wrote:
>
> On Tue, Feb 6, 2024 at 12:11 AM Luca Delucchi via grass-dev
>  wrote:
> > On Mon, 5 Feb 2024 at 13:33, Veronica Andreo  wrote:
> > > That would be cool Luca! eodag allows you to download different EO 
> > > datasets.
> > >
> > > Do you think of a GSoC project idea to include eodag support for 
> > > i.sentinel.download, i.landsat.download and i.modis.download or as a new 
> > > module to download EO data in general? If you are willing to mentor, I 
> > > can be your second... mainly to test and make annoying questions :)
> > >
> >
> > Yes, the idea could be to add it to i.*.download, I was also thinking
> > of having a common library in grass python library as an interface to
> > eodag, but I'm not sure if it makes sense...
> >
> > However I tried to log to the wiki and I'm not able, and password
> > recover also didn't work
>
> Regina has updated the GRASS Wiki again and we have done a series of
> tests, fixing plugins and such.
>
> Please try again, now with your OSGeo-LDAP account.
>
> A "user merge" may come up. Let me know if it gets blocked so that I can 
> assist.
>

It worked properly now, I added the EODAG proposal, I didn't add any
test yet but I'll hope to do it ASAP

> Markus
>


ciao
Luca

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

Re: [GRASS-dev] GSoC Ideas

[Markus Neteler via grass-dev]

On Tue, Feb 6, 2024 at 12:11 AM Luca Delucchi via grass-dev
 wrote:
> On Mon, 5 Feb 2024 at 13:33, Veronica Andreo  wrote:
> > That would be cool Luca! eodag allows you to download different EO datasets.
> >
> > Do you think of a GSoC project idea to include eodag support for 
> > i.sentinel.download, i.landsat.download and i.modis.download or as a new 
> > module to download EO data in general? If you are willing to mentor, I can 
> > be your second... mainly to test and make annoying questions :)
> >
>
> Yes, the idea could be to add it to i.*.download, I was also thinking
> of having a common library in grass python library as an interface to
> eodag, but I'm not sure if it makes sense...
>
> However I tried to log to the wiki and I'm not able, and password
> recover also didn't work

Regina has updated the GRASS Wiki again and we have done a series of
tests, fixing plugins and such.

Please try again, now with your OSGeo-LDAP account.

A "user merge" may come up. Let me know if it gets blocked so that I can assist.

Markus


-- 
Markus Neteler, PhD
https://www.mundialis.de - company
https://grass.osgeo.org - FOSS
https://neteler.org - freelancing & blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Luca Delucchi via grass-dev]

On Mon, 5 Feb 2024 at 13:33, Veronica Andreo  wrote:
>
> That would be cool Luca! eodag allows you to download different EO datasets.
>
> Do you think of a GSoC project idea to include eodag support for 
> i.sentinel.download, i.landsat.download and i.modis.download or as a new 
> module to download EO data in general? If you are willing to mentor, I can be 
> your second... mainly to test and make annoying questions :)
>

Yes, the idea could be to add it to i.*.download, I was also thinking
of having a common library in grass python library as an interface to
eodag, but I'm not sure if it makes sense...

However I tried to log to the wiki and I'm not able, and password
recover also didn't work

> Vero



-- 
ciao
Luca

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

Re: [GRASS-dev] GSoC Ideas

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

I sent the ideas page to OSGeo admins (the deadline is today), although I
think we can keep adding topics. Please also fill out this form
https://forms.gle/dZDYovvmhrQRah73A if you plan to mentor.

Thanks,
Anna

On Mon, Feb 5, 2024 at 7:33 AM Veronica Andreo  wrote:

> That would be cool Luca! eodag allows you to download different EO
> datasets.
>
> Do you think of a GSoC project idea to include eodag support for
> i.sentinel.download, i.landsat.download and i.modis.download or as a new
> module to download EO data in general? If you are willing to mentor, I can
> be your second... mainly to test and make annoying questions :)
>
> Vero
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Veronica Andreo via grass-dev]

That would be cool Luca! eodag allows you to download different EO
datasets.

Do you think of a GSoC project idea to include eodag support for
i.sentinel.download, i.landsat.download and i.modis.download or as a new
module to download EO data in general? If you are willing to mentor, I can
be your second... mainly to test and make annoying questions :)

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

Re: [GRASS-dev] GSoC Ideas

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

On Sat, Feb 3, 2024 at 4:39 AM Luca Delucchi  wrote:

>
>
> Il sab 3 feb 2024, 05:34 Anna Petrášová via grass-dev <
> grass-dev@lists.osgeo.org> ha scritto:
>
>> Hi,
>>
>> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
>> which I think we should be moving away from):
>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>>
>> It's not updated yet, I plan to add more topics. If you want to mentor a
>> topic, we can discuss it here.
>>
>
> Do you think an interface to eodag library, to download sentinel and
> Landsat images for example, could be a topic for gsoc?
>

I suppose so. As long as somebody (you?) would mentor it, we can add it
(including test of skills etc).


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

Re: [GRASS-dev] GSoC Ideas

[Luca Delucchi via grass-dev]

Il sab 3 feb 2024, 05:34 Anna Petrášová via grass-dev <
grass-dev@lists.osgeo.org> ha scritto:

> Hi,
>
> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
> which I think we should be moving away from):
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>
> It's not updated yet, I plan to add more topics. If you want to mentor a
> topic, we can discuss it here.
>

Do you think an interface to eodag library, to download sentinel and
Landsat images for example, could be a topic for gsoc?

>
> Anna
>

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

[GRASS-dev] GSoC Ideas

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

Hi,

I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
which I think we should be moving away from):
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024

It's not updated yet, I plan to add more topics. If you want to mentor a
topic, we can discuss it here.

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

[GRASS-dev] GSoC Contribution

[Kartik kumar]

Hello GRASS Developers,
My name is Kartik. I have been following OsGeo previously , I am very much
interested in contributing for the GIS application.I have been doing
development in C/C++,OpenGL,graphic programming and looking to contribute
to OSGeo/GRASS.

   - I went through the project ideas on page link:
   https://trac.osgeo.org/grass/wiki/GSoC/2022

   - I am very excited to try hands on some of the projects:

   - *Enhance 3D rendering capabilities in GRASS GIS*
   


   link:
   
https://trac.osgeo.org/grass/wiki/GSoC/2022#Enhance3DrenderingcapabilitiesinGRASSGIS
   - QGIS 3D: support for 3D Tiles and I3S
   link:
   
https://github.com/qgis/QGIS/wiki/Google-Summer-of-Code-2021-Ideas#qgis-3d-support-for-3d-tiles-and-i3s
   - *Are these projects still available?* so that i can start picking
   them? or they are completed already?
   - And If there are more projects related to graphics & rendering
   please let me know
   - I have started installing and compiling GRASS by source
   - Can someone help me with the important module/folder/files of the
   codebase related to C, OpenGL as specified in the project ideas.

It would be a great help.
Regards
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2022

[Anna Petrášová]

Hi devs,

just a reminder, now is the time to update GSoC 2022 ideas page:
https://trac.osgeo.org/grass/wiki/GSoC/2022

So in case you would like to suggest a topic or sign-up as a (co)mentor,
please edit it within the next couple of weeks.

Note, this year GSoC is open to anybody (not just students) who is a
newcomer to open source development, so if you know somebody who could
benefit from this new rule, please let them know.

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

Re: [GRASS-dev] GSoC Final Report: Improved Integration of GRASS GIS and Jupyter Notebooks

[Veronica Andreo]

Dear Caitlin,

Thanks for such a nice report and for your contribution to GRASS by making
it easier to integrate with Jupyter. This is a great improvement!

Once again, huge thanks to your mentors Vaclav, Helena and Stefan for their
dedication and for their commitment to the project!! Great team!

We look forward to seeing your contributions after GSoC! Welcome onboard!

All the best,
Vero

ps: apologies for the delay in getting your email through, luckily we
managed now

El dom, 29 ago 2021 a las 16:56, Caitlin Haedrich (<
caitlin.haedr...@gmail.com>) escribió:

> Hello all,
>
> Here is my final report on my GSoC project, Improved Integration of GRASS
> GIS and Jupyter Notebooks. Thank you to all who provided comments, feedback
> and tested my work in Binder. Also, a *huge* thank you to my mentors
> Vaclav Petras, Helena Mitasova and Stefan Blumentrath.
>
> You can find a more detailed version of this report on the wiki page:
> https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
>
> You can also test out grass.jupyter, the subpackage I wrote this summer,
> from your browser in Binder here:
> https://mybinder.org/v2/gh/OSGeo/grass/c173461?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks%2Fgrass_jupyter.ipynb
>
> Best,
> Caitlin
>
> *Improved Integration of GRASS GIS and Jupyter Notebooks*
>
> *Abstract:*
> This project introduces a new subpackage for GRASS GIS, grass.jupyter that
> improves the integration of GRASS GIS with Jupyter Notebooks. The
> grass.jupyter subpackage introduces a new startup function, init(), and two
> display classes, GrassRenderer and InteractiveMap, specifically for making
> the usage of GRASS in Jupyter more simple and intuitive. GrassRenderer
> renders GRASS maps as PNG images and InteractiveMap displays rasters and
> vectors interactively with folium [1], a leaflet library for Python.
>
> *The state of integration BEFORE GSoC:*
> The previous integration of GRASS GIS and Jupyter Notebooks required a
> cumbersome environment variable setup after launching GRASS from within the
> notebook. There is an external python library grass_session that can be
> installed to shorten this launch substantially but, as an external library,
> it is not included in a typical GRASS install. Additionally, maps were
> rendered as PNG images using a relatively unintuitive sequence: calling
> d.erase, then modules from the display family and finally rendering the
> image with IPython.display.Image(). There was also no simple way to zoom or
> toggle between layers.
>
> *The state of integration AFTER GSoC:*
> With the help of my mentors, I introduced a new package grass.jupyter that
> contains a new init() function to shorten the launch and two
> display-related classes, GrassRenderer and InteractiveMap. GrassRenderer
> wraps the previous approach, rendering PNG images but with a more intuitive
> syntax. InteractiveMap, the other display-related class in `grass.jupyter`,
> allows users to view GRASS vectors and rasters in folium, a leaflet library
> for Python. After creating an instance of InteractiveMap, users can add
> vectors and rasters with add_vector() and add_raster(). Users can also add
> a layer control element with add_layer_control().
>
> *Conclusion:*
> In this project, I was successful in accomplishing the three goals stated
> at the beginning (thanks to my mentors!):
>
>1. creating new initiation functions for the launch of GRASS GIS in
>Jupyter Notebooks (init())
>2. creating functions for more intuitive map display (GrassRenderer)
>3. introducing an interactive map display function (InteractiveMap)
>
> I am grateful for the support I've received this summer and for the
> opportunity to contribute to GRASS GIS. I'm looking forward to continuing
> to improve `grass.jupyter`.
>
> *Future Work:*
>
>- Height and width defaults in `GrassRenderer` should be derived from
>computational region
>- init() should fail and report an appropriate error if a mapset that
>doesn't exist is provided
>- Add folium Tooltip method to InteractiveMap, allowing users to
>access vector attribute data by clicking on feature
>- Add simpleCRS option to add_raster method in InteractiveMap
>- Improve color options in InteractiveMap
>- Add option to display rasters as vectors (pixels -> polygon) in
>InteractiveMap
>- Clip vectors to computational region in InteractiveMap (currently
>the whole vector dataset is displayed)
>- Add more interactive functions such as a timeline slider for
>temporal datasets
>- InteractiveMap doesn't allow users to fully access folium. In the
>future, a new interface that allows users direct access to folium should be
>added. For example, it could look like:
>gj.Raster("elevation").add_to(folium_map)
>
> *Permanent Links:*
> *OSGeo Wiki Page:*
> https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
> *OSGeo-GRASS github project page:*
> https://github.com/OSGeo/grass/projects/7
> *Github repo*:
> ht

Re: [GRASS-dev] GSoC 2021: Final report: First steps towards a new GRASS GIS Single-Window GUI

[Veronica Andreo]

Dear Linda,

Thanks for such a detailed final report and for all your contributions to
make GRASS GUI easier and straightforward for users, especially first time
users! And thanks much for this cool new experimental single window GUI,
I'm eager to test :)

Once again, huge thanks to your mentors Anna, Vaclav, Stefan and Martin for
their dedication and for their commitment to the project!! Great team!

I'm sure we'll keep seeing your contributions after GSoC!

All the best,
Vero


El dom, 22 ago 2021 a las 20:15, Linda Kladivová ()
escribió:

> Hello everyone,
>
>
> I am sending my Final GSoC report. The more detailed version with
> permanent links on GitHub PRs and with several screenshots can be found at
> the project wiki:
> https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#FinalReport
> .
>
> *Abstract:*
> The project was focused mainly on the extensive Graphical User Interface
> refactoring necessary to prepare GRASS for Single-Window GUI. In addition
> to a good programming base, the simple working Single-Window GUI prototype
> was built in a parallel environment. This Single-Window frame largely
> copies the design (mockup) which the author had proposed for the GSoC
> application (see ​
> [1]).
> All main functionality will be put into operation after the successful
> merge of PR [2] and PR [3]. However,
> to completely replace the current Multi-Window GUI solution, many other
> improvements are still expected.
>
>
> *The state of the art BEFORE the start of GSoC:*
> Although the GRASS GUI has been enriched with many new features since last
> year, the basic Multi-Window GUI concept used in all historical GRASS
> versions has been preserved. As the name suggests Multi-Window GUI consists
> of several windows (frames) - the control window and additional separate
> map display windows. The control window includes a notebook containing 5
> tabs in a standard 2D map view - Data, Display, Modules, Console, and
> Python.
>
>
> *The state of the art AFTER GSoC:*
> A large part of the project was focused on GUI refactoring. The core work
> had to be done all at once in the PR ​
> [2] and since it overturns the
> core logic of map display widgets, it was decided to merge it after GSoC
> when the GRASS 8 will be released. To sum it up, we are probably not
> entirely done with the refactoring, but the main part was managed.
>
> In addition, a Single-Window GUI prototype has been coded in a parallel
> environment. I with help of my mentors handled to get to the stage where
> most of the functions are working. There is just missing completion of PR
> [3] and possible check/fix of workspaces functioning. It is important to
> emphasize here that I'm talking about basic functionality. To provide a
> really user-friendly environment, many other things will have to be changed
> or reprogrammed. All those steps are summed up in the "Next steps"
> paragraph.
>
>
> *Conclusion:*
> To follow the project idea I wrote for the GSoC application, I succeeded
> (with help of my mentors) to provide the first steps for a new era of
> Single-Window GUI. Those steps have a form of refactoring as well as a new
> parallel simple Single-Window GUI prototype. I believe it's one big step
> forward and I am looking forward to further development of which I would
> like to be a part.
>
>
> *Next Steps:*
> All these following points assume that the main functionality is working.
> In other words, we must have a merged main refactoring PR [2] and a merged
> PR [3]  aiming at the
> implementation of the AuiNotebook closing event. Then several improvements
> are possible (and probably necessary):
>
>- Enable undocking the Map Display notebook tab to a separate window.
>It will allow each user to use the Single-Window GUI as the Multi-Window
>GUI.
>- Fix switching to the Console pane in an automatic notebook if any
>information is written there.
>- Check/test if workspaces are functioning properly.
>- Focus on a newly added Map Display tab in the Display pane (now it
>may not be clear at first glance that it has been added).
>- Modify the appearance for the dark mode. Some parts are ugly and
>illegible (names of AuiNotebook tabs, names of panes, ugly gradients etc.).
>- Add the option for starting GRASS as the Single-Window GUI => we
>want GRASS geeks to try it out. :-)
>
> Other improvements mainly concern the organization of widgets and possible
> ideas for the future:
>
>- It is necessary to change the rendering of the 3D View panel. Now
>the 3D View pane is added as another panel under the Display tab - very
>problematic in terms of space.
>- A part of the Console pane in the startup Single-Window layout is
>not visible. We should completely reorganize the Console tab, su

[GRASS-dev] GSoC 2021: Final report: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,





I am sending my Final GSoC report. The more detailed version with permanent
links on GitHub PRs and with several screenshots can be found at the project
wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#
FinalReport
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#FinalReport)
.





Abstract:
The project was focused mainly on the extensive Graphical User Interface 
refactoring necessary to prepare GRASS for Single-Window GUI. In addition to
a good programming base, the simple working Single-Window GUI prototype was
built in a parallel environment. This Single-Window frame largely copies the
design (mockup) which the author had proposed for the GSoC application (see
​(https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/SingleWindow)[1]). All
main functionality will be put into operation after the successful merge of
PR [2] and PR [3]. (https://github.com/OSGeo/grass/pull/1789)However, to 
completely replace the current Multi-Window GUI solution, many other
improvements are still expected.




The state of the art BEFORE the start of GSoC:
Although the GRASS GUI has been enriched with many new features since last
year, the basic Multi-Window GUI concept used in all historical GRASS
versions has been preserved. As the name suggests Multi-Window GUI consists
of several windows (frames) - the control window and additional separate map
display windows. The control window includes a notebook containing 5 tabs in
a standard 2D map view - Data, Display, Modules, Console, and Python.




The state of the art AFTER GSoC:
A large part of the project was focused on GUI refactoring. The core work 
had to be done all at once in the PR ​
(https://github.com/OSGeo/grass/pull/1675)[2] and since it overturns the 
core logic of map display widgets, it was decided to merge it after GSoC 
when the GRASS 8 will be released. To sum it up, we are probably not
entirely done with the refactoring, but the main part was managed.

In addition, a Single-Window GUI prototype has been coded in a parallel 
environment. I with help of my mentors handled to get to the stage where 
most of the functions are working. There is just missing completion of PR 
[3] and possible check/fix of workspaces functioning. It is important to 
emphasize here that I'm talking about basic functionality. To provide a 
really user-friendly environment, many other things will have to be changed
or reprogrammed. All those steps are summed up in the "Next steps"
paragraph.




Conclusion:
To follow the project idea I wrote for the GSoC application, I succeeded 
(with help of my mentors) to provide the first steps for a new era of Single
-Window GUI. Those steps have a form of refactoring as well as a new
parallel simple Single-Window GUI prototype. I believe it's one big step 
forward and I am looking forward to further development of which I would 
like to be a part.




Next Steps:
All these following points assume that the main functionality is working. In
other words, we must have a merged main refactoring PR [2] and a merged PR
[3](https://github.com/OSGeo/grass/pull/1789) aiming at the implementation
of the AuiNotebook closing event. Then several improvements are possible 
(and probably necessary):

   * Enable undocking the Map Display notebook tab to a separate window. It
   will allow each user to use the Single-Window GUI as the Multi-Window 
   GUI.
   * Fix switching to the Console pane in an automatic notebook if any
   information is written there.
   * Check/test if workspaces are functioning properly.
   * Focus on a newly added Map Display tab in the Display pane (now it may
   not be clear at first glance that it has been added).
   * Modify the appearance for the dark mode. Some parts are ugly and
   illegible (names of AuiNotebook tabs, names of panes, ugly gradients 
   etc.).
   * Add the option for starting GRASS as the Single-Window GUI => we want
   GRASS geeks to try it out. :-)


Other improvements mainly concern the organization of widgets and possible
ideas for the future:

   * It is necessary to change the rendering of the 3D View panel. Now the 3
   D View pane is added as another panel under the Display tab - very
   problematic in terms of space.
   * A part of the Console pane in the startup Single-Window layout is not
   visible. We should completely reorganize the Console tab, such as the 
   Output window and Command prompt data outputs go into two separate tabs.
   * If both Map Display tabs are displayed side by side, the status bar 
   cannot fit in the space. The solution is to create a separate dialog, 
   which will contain a check box and other settings for the Map Display 
   notebook tab.
   * Each user should be able to choose a convenient layout of widgets and
   save this setting for future sessions. It should be possible via
   perspectives.
   * Creating, saving, and selecting perspectives along with switching to 
   dark mode could be part of a new tab menu 

[GRASS-dev] GSoC 2021: Week 10: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,





I am sending my Week 10 report (August 9 - August 13). It can be also found
at the project wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/
SingleWindowLayout#Week
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week10)10
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week10).




1) What did I complete this week?

First of all, I fixed the size of the automatic notebook which is used for
the startup layout. The related PR [1] has still some minor shortcomings 
with cmd warnings messages but we decided to let it be for now since it 
would require more intervention in the construction of the map panel status
bar widget which is anyway likely to be very simplified or replaced by the
settings dialog in the future.

Secondly, I implemented the new changing tab event for the center
AuiNotebook. You can have a look at PR [2] which is already merged. To
provide the fully working GRASS Single-Window GUI prototype, I also opened
the PR [3] which addresses several smaller things related to the AuiNotebook
closing event. This PR is not merged yet but I plan to have it done by the
end of GSoC. Merging this PR will close the Issue [4] with the new
AuiNotebook events.

Thirdly, I moved the NewDisplay button to the upper Tools toolbar, see the
PR [5] (merged).

Lastly, each layer tree is about to have one independent toolbar. I have 
coded it in the PR [6] which is not in the master branch yet.





2) What am I going to achieve for next week?

The priorities for the next week are mainly to finish PRs [3] and [6].
Unfortunately, we still have not merged the main refactoring PR [7] because
it waits for the GRASS 8 release.

It probably gets into the GRASS dev version after GSoC.

Anyway, I would also like to prepare some startup settings that allow GRASS
geeks to try out the GRASS Single-Window prototype. And of course, I am 
going to finish the final evaluation and sum up my work to the final GSoC 
report.





3) Is there any blocking issue?
No, It is not. Please, if you would like to know more info, have a look at
my Twitter thread [8] where I presented some screenshots of the prepared 
GUI. :-)





[1] ​(https://github.com/OSGeo/grass/pull/1675)https://github.com/OSGeo/
grass/pull/1775(https://github.com/OSGeo/grass/pull/1775)

[2] https://github.com/OSGeo/grass/pull/1780
(https://github.com/OSGeo/grass/issues/1750)

[3] https://github.com/OSGeo/grass/pull/1789
(https://github.com/OSGeo/grass/pull/1789)


[4] https://github.com/OSGeo/grass/issues/1750
(https://github.com/OSGeo/grass/issues/1750)

[5] https://github.com/OSGeo/grass/pull/1783
(https://github.com/OSGeo/grass/pull/1783)

[6] https://github.com/OSGeo/grass/pull/1785
(https://github.com/OSGeo/grass/pull/1785)

[7] https://github.com/OSGeo/grass/pull/1675
(https://github.com/OSGeo/grass/pull/1675)

[8] https://twitter.com/GRASSGIS/status/1423254298587275264
(https://twitter.com/GRASSGIS/status/1423254298587275264)



Best wishes,

Linda Kladivova

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

[GRASS-dev] GSoC Week 9: Improved Integration of GRASS GIS and Jupyter Notebooks

[Caitlin Haedrich]

Hi all,

Happy last week of coding! Here's an update of my GSoC project, "Improved
Integration of GRASS GIS and Jupyter Notebooks." Per usual, you can find
more information on the wiki page [1].

1) What did I accomplish this week?

   - I had a meeting with my mentors, Vaclav Petras and Helena Mitasova. We
   discussed some of the existing PR's and goals for the rest of the summer.
   - Rasters reproject and display much faster now! You can test it out in
   Binder at [2].  As Vaclav pointed out, it was oversampling the raster when
   it reprojected - adding a method to estimate the resolution in target
   location fixed this.
   - Re-arranged code for InteractiveMap and improved documentation [3]
   - Added save as HTML method for InteractiveMap [3]


2) What do I plan to do next week?

   - I have a meeting with my mentors planned for today
   - Add simple CRS option for raster display in folium
   - Finish test script [4]
   - Improve/finish GRASS-Jupyter Demonstration notebook

3) Am I blocked on anything?

   - No, I'm not currently blocked on anything.


Feedback, comments, questions and ideas welcome!

Best,
Caitlin

References:
[1] https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
[2]
https://mybinder.org/v2/gh/chaedri/grass/interactive-rasters?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks%2Fjupyter_integration.ipynb
[3] https://github.com/OSGeo/grass/pull/1769
[4] https://github.com/OSGeo/grass/pull/1739
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2021: Week 9: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,





I am sending my Week 9 report (August 2 - August 6). It can be also found at
the project wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/
SingleWindowLayout#Week9
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week9).




1) What did I complete this week?

First of all, I completed the big refactoring PR [1]. It is ready for review
and will be merged after GRASS 8 release.

Secondly, I  implemented the layout which will be used for startup [2]. It
looks exactly as the third option presented here: [3]. Unfortunately, I am a
bit stuck here with size settings for the automatic notebook I made. As for
this PR, we had a video call with Anna on Thursday and agreed to not deal
with perspectives now because there are still more crucial things that need
to be fixed or reorganised. Lastly, I started to work on events. This PR [4]
deals with the first of two events in this Issue [5] - AuiNotebook changing
event.




2) What am I going to achieve for next week?

The priorities for the next week are first to finish PRs [2] and [4] and to
set up a new PR for AuiNotebook closing event. We also decided to move New
Display button to a different place and to have one independent toolbar for
each Display tab. So if some time remains, I would also implement this
reorganising stuff. But generally speaking, the closing event for
AuiNotebook is the last thing which is needed to do for the working Single-
Window GUI prototype.




3) Is there any blocking issue?
No, It is not.




[1] ​(https://github.com/OSGeo/grass/pull/1675)https://github.com/OSGeo/
grass/pull/1675(https://github.com/OSGeo/grass/pull/1675)

[2] https://github.com/OSGeo/grass/pull/1775
(https://github.com/OSGeo/grass/pull/1775)

[3] https://github.com/OSGeo/grass/issues/1747
(https://github.com/OSGeo/grass/issues/1747)

[4] https://github.com/OSGeo/grass/pull/1780
(https://github.com/OSGeo/grass/pull/1780)

[5] https://github.com/OSGeo/grass/issues/1750
(https://github.com/OSGeo/grass/issues/1750)




Best wishes,

Linda Kladivova


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

[GRASS-dev] GSoC Week 8: Improved Integration of GRASS GIS and Jupyter Notebooks

[Caitlin Haedrich]

Hi all,

Here's a quick update on what I worked on this past week for my GSoC
project, "Improved Integration of GRASS GIS and Jupyter Notebooks." I came
down with a stomach bug this week and didn't get as much as I hoped done
but I did wrap up some things I'd been working on for a while. Per usual,
you can find more information on the wiki page [1].

1) What did I accomplish this week?

   - I had a brief meeting with my mentor, Vaclav Petras. We discussed some
   of the existing PR's I had open and goals for the rest of the summer.
   - Got rasters to display with folium (finally)! You can check out the
   functionality in Binder at [2] and see the PR at [3]. It takes a while to
   reproject the raster (folium only excepts rasters in Pseudo-mercator). As
   Stefan recommended, I'm hoping to write a "simple CRS" option that won't
   require reproject and will be faster. But that's for next week...
   - Merged shortcuts and temporary files for `GrassRenderer` ([4] and [5]).
   - Continued working on test script for `GrassRenderer`, the
   non-interactive display class [6].


2) What do I plan to do next week?

   - I have a meeting with my mentors planned for tomorrow
   - Add simple CRS option for raster display in folium
   - Edit and finish exiting PRs
   - Add option to save/export folium map as HTML

3) Am I blocked on anything?

   - No, I'm not currently blocked on anything.


Feedback, comments, questions and ideas welcome!

Hope you all had a great week,
Caitlin

References:
[1] https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
[2]
https://mybinder.org/v2/gh/chaedri/grass/interactive-rasters?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks%2Fjupyter_integration.ipynb
[3] https://github.com/OSGeo/grass/pull/1769
[4] https://github.com/OSGeo/grass/pull/1723
[5] https://github.com/OSGeo/grass/pull/1727
[6] https://github.com/OSGeo/grass/pull/1739
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2021: Week 8: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,




I am sending my Week 8 report (July 26 - July 30). It can be also found at
the project wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/
SingleWindowLayout#Week
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week8)8
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week8).


1) What did I complete this week?

The success of this week lies in the merge of 2 PRs - the refactoring [1] 
and the [2] dealing with the basic map panel integration to Single-Window 
GUI. Just before that I had to make 2 rebases since my mentor Anna had
merged a different refactoring PR [3] which influenced PR [1] as well as 
[4].


In the second half of the week I went back to the PR [4]. I integrated wx.
Panel to three remaining tools namely g.gui.photo2image
(http://g.gui.photo2image), g.gui.image2target, g.gui.example
(http://g.gui.image2target). I have also started to test this PR and written
down shorcomings we will discuss and probably fix with the help of my
mentors.

We had the video call on Wednesday where we went through possible options of
startup layout I put here: [5] and decided that the third option is the most
suitable one and thus will be implemented. We use "Perspectives" for this 
purpose.





2) What am I going to achieve for next week?

The priorities for the next week are first of all to test PR [4], secondly
to create a startup Single-Window GUI perspective and lastly to develop 
event handlers for map Aui.Notebook. For the second point I am going to 
study the wx.lib.agw.aui concept of so-called perspectives.



3) Is there any blocking issue?
No, It is not.




[1] ​(https://github.com/OSGeo/grass/pull/1675)https://github.com/OSGeo/
grass/pull/16(https://github.com/OSGeo/grass/pull/1689)89
(https://github.com/OSGeo/grass/pull/1689)

[2] https://github.com/OSGeo/grass/pull/1732
(https://github.com/OSGeo/grass/pull/1732)

[3] https://github.com/OSGeo/grass/pull/1729
(https://github.com/OSGeo/grass/pull/1729)

[4] ​https://github.com/OSGeo/grass/pull/1675
(https://github.com/OSGeo/grass/pull/1675)

[5] https://github.com/OSGeo/grass/issues/1747
(https://github.com/OSGeo/grass/issues/1747)




Best wishes,
Linda Kladivova___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Week 7: Improved Integration of GRASS GIS and Jupyter Notebooks

[Caitlin Haedrich]

Hello everyone,

Here's a quick update on what I worked on this past week for my project
Improved Integration of GRASS GIS and Jupyter Notebooks. Per usual, you can
find more information on the wiki page [1].

1) What did I accomplish this week?

   - This week, I had another two meetings with my mentor, Vaclav Petras.
   We've been discussing best practices and conventions for GRASS and Python
   and questions that come up as I'm working.
   - Merged 'add_vector' method for InteractiveMaps in folium [2].
   - Improved error handling and documentation on the shortcut for calling
   GRASS display modules for "GrassRenderer" [3].
   - Wrote a test module for the "GrassRenderer" class - a class which
   displays GRASS maps in Jupyter Notebooks as PNG images. I haven't opened a
   PR since there are a couple things I need to add after some other PRs are
   merged.
   - Continued to work on overlaying rasters in folium - this is taking me
   a while because the raster and raster bounds have to be reprojected since
   folium only takes WGS84 and Pseudo-Mercator projections.


2) What do I plan to do next week?

   - I have another meeting planning with Vaclav on Monday.
   - Finish and merge existing PRs
   - Continue writing test module for GrassRenderer

3) Am I blocked on anything?

   - No, I'm not currently blocked on anything.


Feedback, comments, questions and ideas welcome!

Hope you all had a great week,
Caitlin

References:
[1] https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
[2] https://github.com/OSGeo/grass/pull/1710
[3] https://github.com/OSGeo/grass/pull/1723
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2021: Week 7: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,




I am sending my Week 7 report (July 19 - July 23). It can be also found at
the project wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/
SingleWindowLayout#Week
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week7)7
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week7).




I would also like to do a little advertising here, so that's the reason why
I am sending this e-mail to all GRASS users :-) If you are interested in 
real Single-Window proposals (not just mock-ups [1]), feel free to look at
the new discussion Issue here [5]. The comments of your opinions/preferences
will be very appreciated!





And now, back to the report :-) :





1) What did I complete this week?

This week I have been working on the coding of basic functionalities for the
Single-Window layout on my locally merged branch. First I set up several 
Issues for those, however, since I am still working on my local branch, I 
eventually decided to address more Issues within one PR (so previously
created Issues were merged into two larger ones - see [2], [3]).




I integrated the Map Display into a new AuiNotebook and fixed the existing
events - see PR [4]. These changes are ready to merge.




I also created two Issues that will be important after the integration of 
basic functionalities and the creation of new events for the AuiNotebook 
center pane. The first one is kind of a discussion Issue. We can share
suggestions there for what the startup GUI could look like. I have already
added some proposals based on my local branch, see [5]. I am aware of the 
priority of the G8 release, so I feel it is something to be discussed later
on.




The second Issue [6] talks about an important enhancement that allows a user
to undock the AuiNotebook pane into the wx.Frame widget (will be enabled 
through a button probably). This enhancement is very crucial as it will 
allow users who like the Multi-Window layout to continue using it even
within this new GUI. It will probably be the last functionality I will
complete within GSoC - or it is at least a plan - there might be some
shortcomings in the refactoring PRs needed to be repaired, as big changes 
often cause minor errors.




2) What am I going to achieve for next week?
I am gonna work on the implementation of new events for AuiNotebook (see 
[3]) and I also need to go back to PR [7]. It needs more testing and there
still remains to integrate wx.Panel into g.gui.photo2image and g.gui.image2
target GUI tools. I also have some problems with closing events for
independent GUI Map Displays here that need to be sorted out.





3) Is there any blocking issue?
No, It is not.




[1] https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/SingleWindow
(https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/SingleWindow)


[2] https://github.com/OSGeo/grass/issues/1735
(https://github.com/OSGeo/grass/issues/1735)


[3] https://github.com/OSGeo/grass/issues/1750
(https://github.com/OSGeo/grass/issues/1750)

[4] https://github.com/OSGeo/grass/pull/1732
(https://github.com/OSGeo/grass/pull/1732)

[5] https://github.com/OSGeo/grass/issues/1747
(https://github.com/OSGeo/grass/issues/1747)


[6] https://github.com/OSGeo/grass/issues/1748
(https://github.com/OSGeo/grass/issues/1748)


[7] ​https://github.com/OSGeo/grass/pull/1675
(https://github.com/OSGeo/grass/pull/1675)




Best wishes,
Linda Kladivova___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Week 6: Improved Integration of GRASS GIS and Jupyter Notebooks

[Caitlin Haedrich]

Hi all,

Here's a weekly update on my GSoC project, Improved Integration of GRASS
GIS and Jupyter Notebooks. You can find more details about the project on
the wiki page [1].

1) What did I accomplish this week?

   - This week, I had two meetings with my mentor, Vaclav Petras. We've
   been discussing how to improve my workflow, best practices and conventions
   for GRASS and Python and questions that come up as I'm working.
   - Instituted the use of temporary PNG files for displaying
   static/non-interactive maps [2] and temporary directories for passing
   vectors between GRASS and folium [3]
   - Continued to edit the InteractiveMap class and mapping GRASS vectors
   in folium PR [4]
   - Created a shortcut for calling GRASS display modules using __getattr__
   [5]
   - Completed evaluation and received feedback.

2) What do I plan to do next week?

   - I have another meeting planning with Vaclav tomorrow.
   - Finish and merge existing PRs
   - Continue writing test module for Non-Interactive Vectors
   - Support Raster display in folium map
   - Clean-up function


3) Am I blocked on anything?

   - No, I'm not currently blocked on anything.


Feedback, comments, questions and ideas welcome!

Best,
Caitlin

References:
[1] https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
[2] https://github.com/OSGeo/grass/pull/1727
[3]
https://github.com/chaedri/grass/blob/InteractiveMaps-add-temp-files/python/grass/jupyter/interact_display.py
(PR coming soon...)
[4] https://github.com/OSGeo/grass/pull/1710
[5] https://github.com/OSGeo/grass/pull/1723
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2021: Week 6: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,




I am sending my Week 6 report (July 12 - July 16). The more detailed version
can be found at the project wiki: https://trac.osgeo.org/grass/wiki/GSoC/
2021/SingleWindowLayout#Week
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week6)6
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week6).




1) What did I complete this week?
This week was very important. In the first part, I worked on PR [1] which is
already done in terms of the main Map Display panel but needs many other 
changes related to other widgets. On Wednesday's video call we decided to 
work on the local merged branch because it will probably take some time to
merge PR [1](https://github.com/OSGeo/grass/pull/1675) (also with regard to
the new G8 release). So, I set up the new PR ​
(https://github.com/OSGeo/grass/pull/1732)[2] mining from both refactoring
PRs ​(https://github.com/OSGeo/grass/pull/1675)[1], [3]. By the time we
merge them(https://github.com/OSGeo/grass/pull/1675), I can solve here many
things related to the Single-Window GUI... I have already composed the new
Map Display panel and started to repair existing events and methods and to
implement new methods. There are several basic things I would like to
address in this PR:

   * repair GRASS GIS exit (generally speaking all closing stuff is broken
   now)
   * adding maps to map display does not work when switching to a different
   location
   * adding and removing 3D View does not work
   * remove methods applied on wx.Frame
   * implement new events or repair the existing ones
   * when renaming the Display tab, the related Map notebook tab is renamed


I have also noticed a small issue concerning g.gui.iclass toolbars and I set
up the issue for it (see ​(https://github.com/OSGeo/grass/issues/1731)[4]).




2) What am I going to achieve for next week?
I am gonna work on coding the above-mentioned basic functionalities for the
Single-Window layout on my locally merged branch. Although, it is not
possible for my mentors to test it, I will share changes to the PR [2] so we
can at least discuss them.





3) Is there any blocking issue?
No, It is not.





[1] ​https://github.com/OSGeo/grass/pull/1675
(https://github.com/OSGeo/grass/pull/1675)

[2] https://github.com/OSGeo/grass/pull/1732
(https://github.com/OSGeo/grass/pull/1732)

[3] https://github.com/OSGeo/grass/pull/1689
(https://github.com/OSGeo/grass/pull/1689)

[4] https://github.com/OSGeo/grass/issues/1731
(https://github.com/OSGeo/grass/issues/1731)




Any suggestions are welcome.


Best wishes,
Linda Kladivova
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2021: Week 5: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,




I am sending my Week 5 report (July 5 - July 9), you can also find it in the
project wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/
SingleWindowLayout#Week5
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week5).





1) What did I complete this week?
I worked mainly on the PR [1] which was again opened after our discussion 
last week. Anna took care of solving the bug concerning hiding and showing
status bar and toolbars [2] and then based on these changes I rebased PR 
[1]. This PR is now in the reviewing process and will be early merged.

I am also still working on the main refactoring PR [3]. Unfortunately, many
things are influenced and need to be changed. These changes are so connected
together that it is not possible to divide PR [3]
(https://github.com/OSGeo/grass/pull/1675) into several different PRs... 

Meantime, I also discovered the bug in the Show comp. extent option in the
status bar and corrected it (see PR ​
(https://github.com/OSGeo/grass/pull/1717)[4] and issue [5]).




2) What am I going to achieve for next week?


After merging PR [1], I will again focus on PR [3].




3) Is there any blocking issue?
No, it is not.





[1] https://github.com/OSGeo/grass/pull/1689
(https://github.com/OSGeo/grass/pull/1689)

[2] https://github.com/OSGeo/grass/issues/1691
(https://github.com/OSGeo/grass/issues/1691)

[3] https://github.com/OSGeo/grass/pull/1675
(https://github.com/OSGeo/grass/pull/1675)

[4] ​https://github.com/OSGeo/grass/pull/1717
(https://github.com/OSGeo/grass/pull/1717)

[5] https://github.com/OSGeo/grass/issues/1714
(https://github.com/OSGeo/grass/issues/1714)




Any suggestions are welcome.


Best wishes,
Linda Kladivova___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Week 4: Improved Integration of GRASS GIS and Jupyter Notebooks

[Caitlin Haedrich]

Hello everyone,

With week 4 wrapping up, here is a brief update of what I've been working
on. Per usual, you can find more information on the project on the wiki
page [1] and you can try proposed changes out in the Binder link in the
description of each PR.

1) *What did I accomplish during Week 1?*

   - I had a productive meeting with my mentors: Vaclav Petras, Helena
   Mitasova and Stefan Blumentrath. We discussed how environments work and the
   purpose of copying the environment each time an instance of GrassRenderer
   is called.
   - I finished and merged a class called GrassRenderer for non-interactive
   map displays [2].
   - I continued to work on interactive mapping with folium. In particular,
   I changed how data is passed to folium so that it is first reprojected to
   WGS84 (required by folium/leaflet) in a new location/mapset [3].

2) *What do I plan on doing next week?*

   - Continue to work on interactive functions with folium.


3) *Am I blocked on anything?*

   - No, I'm not blocked on anything at the moment.


Until next week,
Caitlin

[1] https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
[2] https://github.com/OSGeo/grass/pull/1668
[3] https://github.com/OSGeo/grass/pull/1710
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2021: Week 4: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,




I am sending my Week 4 report (June 28 - July 2), you can also find it in 
the project wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/
SingleWindowLayout#Week4
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week4).





1) What did I complete this week?
Similarly as the last week, I focused on the GUI refactoring. I worked on 
the main refactoring PR (see [1]). In terms of the main Map Display I am 
done here. However, me and my mentors realized that these changes influence
also other Map Frames - particularly g.gui.rdigit, d.mon, Map Swipe, Ground
Control Point and IClass frame.

There were two possible ways how to proceed. First, I started with the
statusbars for all the frames that we need newly to be created based on wx.
Statubar widget (see [2]​(https://github.com/OSGeo/grass/pull/1689)). Then
we came up with another concept, namely delegating methods using
metaprogramming. Although this path seemed cheap at first (we talked about
it very intensively on videocall on Wednesday), after a few hours of
studying, we came to the conclusion that it is inappropriate in our case. 
And this decision subsequently opened PR [2] again
(https://github.com/OSGeo/grass/pull/1689).

Meantime, I also discovered the bug related to hiding statusbar and
toolbars. Hiding does not work properly for above-mentioned map frames as e.
g. Map Swipe. I set up the issue [3].

To sum it up, this week was not so productive in terms of code, but key in
determining what to do next and especially how.




2) What am I going to achieve for next week?
In the next step, the focus will be on the completion of PR ​https://github.
com/OSGeo/grass/pull/1689(https://github.com/OSGeo/grass/pull/1689), which
will then allow the completion of the large PR ​​https://github.com/OSGeo/
grass/pull/1675(https://github.com/OSGeo/grass/pull/1675).




3) Is there any blocking issue?
No, it is not. However, as I have already mentioned I am on holiday from 
Saturday to Tuesday.

I am looking forward to new energy coming after the rest. :-)





[1] https://github.com/OSGeo/grass/pull/1675
(https://github.com/OSGeo/grass/pull/1675)

[2] https://github.com/OSGeo/grass/pull/1689
(https://github.com/OSGeo/grass/pull/1689)

[3] https://github.com/OSGeo/grass/issues/1691
(https://github.com/OSGeo/grass/issues/1691)




Any suggestions are welcome.


Best wishes,
Linda Kladivova___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Week 3: Improved Integration of GRASS GIS and Jupyter Notebook

[Caitlin Haedrich]

Hi all,

Here is a brief update on what I accomplished during Week 3 of Google
Summer of Code for the new GRASS library *grass.jupyter*. Per usual, you
can find more updates on the wiki page [1]. I have also started posting
links to Binder Jupyter Notebooks in each PR if you would like to try any
of the features and functions I've been working on.

*1. What did I accomplish this week?*

   - Edited and discussed functions for displaying non-interactive maps in
   Jupyter [2].
   - Drafted an interactive display function for rasters with folium [3].
   - Made a few minor edits to the example_notebook.ipynb that is linked in
   the README [4].


*2.What do I plan on doing next week?*

   - I have a meeting planned with my mentors.
   - I will continue working on interactive functions for Jupyter. In
   particular, I'm working on passing GRASS rasters to folium.
   - I'll begin writing functions for displaying GRASS vectors with folium.


*3. Am I blocked on anything?*

   - I'm not blocked at the moment. But, I have been working on finding a
   good way to pass raster data between GRASS and Jupyter and I'm not sure my
   current method is particularly fast or robust [3]. Luckily, I have a
   meeting tomorrow with my mentors where we will discuss this.


Any suggestions and feedback are welcome!

Best,
Caitlin

[1] https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
[2] https://github.com/OSGeo/grass/pull/1668
[3] https://github.com/OSGeo/grass/pull/1684
[4] https://github.com/OSGeo/grass/pull/1686
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2021: Week 3: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,




I am sending my Week 3 report (June 21 - June 27), you can also find it in
the project wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/
SingleWindowLayout#Week
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week3)3
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week3).





What did I complete during the second week?

In order to add Map Display to the notebook widget, we need to have it in 
the form of wx.Panel. This week I worked quite hard on the main refactoring
PR (see ​(https://github.com/OSGeo/grass/pull/1656)[1]). The core lies in
adding the intermediate wx.Panel widget. However, this PR influences quite
many things much more than we first expected. I am changing the way how Map
Display is built which has an impact on single map display stuff as well as
double frame stuff. So that, this PR also requires very intense testing 
since all things then go straight to the master - adapting the independent
Single-Window GUI environment is planned to be another step forward.




What am I going to achieve for next week?


I plan to finish the refactoring of Map Display related stuff (see [1]) and
test this PR very intensively.





Is there any blocking issue?

No, it is not. However, next week on Saturday I am going on four day holiday
to Slovakia. I hope I will be able to merge this big refactoring PR by
Friday.






[1] https://github.com/OSGeo/grass/pull/1675
(https://github.com/OSGeo/grass/pull/1675)




Any suggestions are welcome. :-)


Best wishes,
Linda Kladivova___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2021: Week 2: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,




I am sending my Week 2 report (June 14 - June 20), you can also find it in
the project wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/
SingleWindowLayout#Week2
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week2).





What did I complete during the second week?
I focused on the GUI refactoring. In order to add Map Display to the
notebook widget, we need to have it in the form of wx.Panel. I divided the
work into several steps:

   * I changed the way of creating the Map Display status bar (which is now
   independent of the parent widget) [1]. However, this PR caused the bug 
   related to the workspace saving [2] which I corrected ASAP [3].


   * Meantime, I started more complex PR changing the way the Map Display is
   built (see ​(https://github.com/OSGeo/grass/pull/1656)[4]). The core lies
   in adding the intermediate wx.Panel widget. This PR aims at more general
   Map Display refactoring, do not change the code in the Single-Window 
   parallel environment - adapting the S-W GUI is planned to be another step
   forward.


What am I going to achieve for next week?


   * I plan to finish the refactoring of Map Display related stuff (see [4])
   and utilize it in the Single-Window GUI environment. It will lead to a 
   new Map Display notebook widget (composed of wx.Panel Map Displays). This
   notebook will be then used as the content pane.


Is there any blocking issue?

No, it is not.






[1] https://github.com/OSGeo/grass/pull/1646
(https://github.com/OSGeo/grass/pull/1646)

[2] https://github.com/OSGeo/grass/issues/1657
(https://github.com/OSGeo/grass/issues/1657)

[3] https://github.com/OSGeo/grass/pull/1665
(https://github.com/OSGeo/grass/pull/1665)

[4] ​https://github.com/OSGeo/grass/pull/1656
(https://github.com/OSGeo/grass/pull/1656)




Any suggestions are welcome. :-)


Best wishes,
Linda Kladivova___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Week 1: Improved Integration of Jupyter and GRASS

[Caitlin Haedrich]

Hi Everyone,

With Week 1 wrapping up, here is a brief update on what I worked on this
week and where I'm headed next week. A more detailed update can be found on
the project wiki page [1].

*1. What did I accomplish during Week 1?*


   - Finish binder setup. The main GRASS branch now launches in Binder.
   - Added Binder Button to README.md which links to an Example Notebook
   (copied from [2]) in Jupyter Lab in Binder [3]. When users click the Binder
   Button, they will be directed to the example notebook where they can try
   GRASS.
   - Wrote draft of GRASS initiation functions for Jupyter [4].
   - Added Makefile and __init__.py file for grass.jupyter [4].
   - Created a Jupyter Notebook where others can view and test the
   grass.jupyter functions [4].

*2. What do you plan on doing next week?*
I plan to start working on display functions and familiarizing myself with
Folium.

*3. Are you blocked on anything?*
No, I'm not currently blocked on anything.

Discussion, feedback and comments welcome!

Best,
Caitlin

[1] https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
[2] https://github.com/wenzeslaus/try-grass-in-jupyter
[3] https://github.com/OSGeo/grass/pull/1628
[4] https://github.com/OSGeo/grass/pull/1629
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2021: Week 1: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,




I am sending my Week 1 report (June 6 - June 13), more detailed version can
be found in the project wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/
SingleWindowLayout#Week1
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Week1).





What did I complete during the first week?

   * I started to develop Single-Window GUI in the prepared parallel
   environment. I arranged basic widgets (Data Catalog, Display, Modules, 
   Console, Python), you can have a look at this PR: ​https://github.com/
   OSGeo/grass/pull/1621(https://github.com/OSGeo/grass/pull/1621). After a
   discussion with mentors and other members of the GRASS community, it was
   decided to use Map Display as the center content pane. At the same time,
   we decided to use the python wx.lib.agw.aui library for Single-Window GUI
   development. This library contains a bunch of interesting functions as e.
   g. grouping dockable panes into notebooks. The picture of the current 
   Single-Window layout state can be seen on the project wiki.
   * At the same time, I also fixed a bug ​https://github.com/OSGeo/grass/
   issues/1636(https://github.com/OSGeo/grass/issues/1636) (​https://github.
   com/OSGeo/grass/pull/1637(https://github.com/OSGeo/grass/pull/1637)). 


What am I going to achieve for next week?


   * Implement a Map Display as a wx.Panel (now it is only in the form of 
   wx.Frame) and integrate this Map Display as a center content pane.


Is there any blocking issue?

No, it is not.






Any suggestions are welcome. :-)





Best wishes,
Linda Kladivova___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2021: Community Bonding Period Report: First steps towards a new GRASS GIS Single-Window GUI

[Linda Kladivová]

Hello everyone,




I am sending my bonding period report (May 17 - 6 June), more detailed
version can be found in the project wiki: https://trac.osgeo.org/grass/wiki/
GSoC/2021/SingleWindowLayout#Bondingperiodreport
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#Bondingperiodreport)
.





What did I complete during the Bonding period?

   * Introduced myself in dev list, get in contact with my mentors


After being accepted as a student for GSoC 2021, on May 25 I introduced 
myself and my project to grass dev lists (1) and set up the video call with
my mentors  - Anna Petrasova, Vaclav Petras, Martin Landa, and Stefan
Blumentrath. We met on May 25 and discussed various Single-Window GUI
options and their possible shortcomings. We decided to set up a parallel 
environment determined for the independent Single-Window GUI development.

   * Prepared the wiki page about the project and set up the GitHub
   repository of the project


I created my project wiki page (2) and added the link to the GSoC 2021
Accepted proposals page (3). I already have GitHub GRASS fork in usage (4)
so I only added the link to the GSoC 2021 Accepted proposals page (3), to my
wiki page (2) and shared it with my mentors.


   * Two PRs regarding Single-Window GUI already merged


The first PR ​https://github.com/OSGeo/grass/pull/1591
(https://github.com/OSGeo/grass/pull/1591) deals with general refactoring.
The second one creates the parallel environment where I am gonna further 
independently develop the Single-Window GUI, see ​https://github.com/OSGeo/
grass/pull/1604(https://github.com/OSGeo/grass/pull/1604). I also created 
the PR https://github.com/OSGeo/grass/pull/1598
(https://github.com/OSGeo/grass/pull/1598) enhancing GRASS for version 8.0.
It implements easier switching between mapsets in different locations as we
would like GRASS to be as user-friendly as possible. All mentioned PRs are
already merged to master. Meantime, I played with wx.aui demo in order to 
create a prototype of the Single-Window GRASS GUI.




Plans for the next week:

   * Start developing the Single-Window GUI
   * Integrate main parts that do not involve much refactoring
   * Have a meeting with mentors on Wednesday

(1) ​https://lists.osgeo.org/pipermail/grass-dev/2021-May/095168.html
(https://lists.osgeo.org/pipermail/grass-dev/2021-May/095168.html)
(2) ​https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout
(https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout)
(3) ​https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2021_Accepted
(https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2021_Accepted)
(4) ​https://github.com/lindakladivova/grass
(https://github.com/lindakladivova/grass)



Any suggestions are welcome. :-)





Best wishes,
Linda Kladivova___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Introduction: GRASS and Jupyter Notebooks

[Caitlin Haedrich]

Hello everyone,

My name is Caitlin Haedrich and I'm one of the OSgeo Google Summer of Code
participants. I'm a first year PhD student in Geospatial Analytics at North
Carolina State University in Raleigh, NC. You can read more about my
background and interests on my website [1].

This summer, I'll be working on improving the integration of GRASS GIS and
Jupyter Notebooks. I'm proposing a new python library, 'grass.jupyter',
that will contain functions for:
* initiating GRASS sessions in Jupyter
* displaying maps in a more intuitive way (wrapping 'd.erase' and other
required modules into one function)
* displaying interactive maps with folium

You can read more about the project in my proposal [2] and follow my
progress on the project wiki page [3].  I'd love to hear any ideas or
feedback you have for the project.

Lastly, I'd like to thank OSGeo and Google for giving me this opportunity.
I'm really looking forward to working with you all this summer and being
part of the OSGeo community.

Best,
Caitlin

[1] https://chaedri.github.io/
[2]
https://docs.google.com/document/d/1ZT0cZobd87YCb3Ogis7RzWPj02XZkCpAHbC3VBGh7gc/edit?usp=sharing
[3] https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC welcome

[Moritz Lennert]

Welcome and congratulations to all three of you !

I'm looking forward to your three exciting projects.

Moritz

On 18/05/21 05:12, Anna Petrášová wrote:

Hi GRASS devs and new (and old) GSoC students!

Congrats to Linda, Caitlin and Aaron for being selected to participate 
in GSoC this year [1], we hope this will be productive for all and a 
great learning experience for the students. During this community 
bonding period (until June 7th when the coding starts) students should 
work with mentors and the broader community to refine the project ideas, 
so that it's clear what to do and perhaps start working on the project 
itself.


I think it would be nice to have a call to introduce students and 
mentors, I will try to set up something soon. In the meantime, students 
should reach out to mentors to start discussing their respective 
projects. Let me know if you have any questions or concerns.


Best,
Anna

[1] 
https://summerofcode.withgoogle.com/organizations/5336634351943680/#projects 



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



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

[GRASS-dev] GSoC welcome

[Anna Petrášová]

Hi GRASS devs and new (and old) GSoC students!

Congrats to Linda, Caitlin and Aaron for being selected to participate in
GSoC this year [1], we hope this will be productive for all and a great
learning experience for the students. During this community bonding period
(until June 7th when the coding starts) students should work with mentors
and the broader community to refine the project ideas, so that it's clear
what to do and perhaps start working on the project itself.

I think it would be nice to have a call to introduce students and mentors,
I will try to set up something soon. In the meantime, students should reach
out to mentors to start discussing their respective projects. Let me know
if you have any questions or concerns.

Best,
Anna

[1]
https://summerofcode.withgoogle.com/organizations/5336634351943680/#projects
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Application on Integrating Jupyter Notebooks and GRASS GIS

[Caitlin Haedrich]

Hello All,

I'm applying to Google Summer of Code to work on the "Seamless integration
of GRASS GIS and Jupyter Notebooks" project [1]. I've written a draft of my
application [2] and I'd be grateful for any feedback from the GRASS-dev
community.

I'm also including a brief summary of my ideas here. I hope to make a
Python module or package called grass.jupyter that will make GRASS easier
to use and more intuitive in Jupyter Notebooks (for an example of the
current integration, see [3]). I'm proposing to work on three main tasks:
(1) updating the launch of GRASS GIS in Jupyter Notebooks by
introducing a new startup function that will make GRASS initiation more
succinct by setting default options (i.e. raise exceptions, show standard
output and allow overwriting).
(2) creating a more intuitive way to display maps by creating a new
class called grassRenderer
(3) introducing an interactive map display function using folium, a
python mapping package that creates interactive maps.

I'd love any feedback on those ideas and on my attached proposal [2]. In
particular, I'm interested in your thoughts about the interactive map
display workflow. My current plan would be to render images with GRASS
(d.rast and d.vect) then overlaying the resulting .png image in folium
using the georeferencing information from the GRASS region. An alternative
would be to export GeoTIFF/GeoJSONs then import these to folium. The user
would then set the coloring and style options in folium. The advantages of
the latter would be better display of vector data (since it is not
rasterized) and more future options for interactivity (such as turning on
and off layers). But, it could also make layer styling and coloring more
difficult and add complexity to the module.

Thank you and Happy Friday,
Caitlin


[1]https://trac.osgeo.org/grass/wiki/GSoC/2021
[2]
https://docs.google.com/document/d/1GC3Jc9sDRRPUJSFi3Okvep1N0VCiJkwxVcYZwQtKOag/edit?usp=sharing
[3]https://github.com/chaedri/grass-zonal-of-watersheds
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Mentors needed (coding and non-coding)

[Vaclav Petras]

Dear all,

Please consider adding yourself as mentor or co-mentors to the ideas wiki
page. Note that coding experience is *not* required from all mentors.
Inputs on design and behavior, testing, and general mentoring of the
student are greatly appreciated.

https://trac.osgeo.org/grass/wiki/GSoC/2021
In addition to editing the wiki page, please fill out the form below:

https://forms.gle/9Na1vzGX3ESxqgpj9

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

Re: [GRASS-dev] GSoC 2021 Project - Sunveer Singh

[Sunveer Singh]

On Sat, Feb 6, 2021 at 9:17 AM Vaclav Petras  wrote:

>
>
> On Wed, Feb 3, 2021 at 8:15 AM Sunveer Singh 
> wrote:
>
>>
>> I am Sunveer Singh, I graduated from high school in 2021 and will start
>> my undergraduate studies in Fall 2021 and have been accepted into a
>> university so it makes me eligible to participate in GSoC this year.
>>
>
> Congratulations and welcome back!
>
Thanks a lot!

>
>
>> I found this following project and I would be happy to work on it this
>> year:
>> https://trac.osgeo.org/grass/wiki/GSoC/2017#Toolsforgeneratingunittestsfromexamplesinthemanual
>>
>>
>
> This is indeed related to what you did before, so it is a hopeful choice.
> However, there is an additional challenge now and that is a poor
> integration of the testing framework with current technologies namely
> pytest and GitHub Actions.
>
> The choices I made when designing and implementing the framework are not
> as advantageous as they seemed in 2014 (there was no 6 hours of runtime
> from GitHub for free on every commit, NumPy and GDAL switched to pytest in
> 2018, ...). You can see the idea for this year here:
>
>
> https://trac.osgeo.org/grass/wiki/GSoC/2021#IntegratetestingframeworkwithGitHubActions
>
> This is not to say that you can't propose/do the documentation-to-test
> idea, but you will need to take into account the current state and needs as
> well.
>
>
>> I see that this project was skipped after 2017 and no one had worked on
>> it, so I would like to work on this as it is totally of my interest and my
>> skills. Will the mentors written on the page will be the same i.e Vaclav
>> Petras and Soeren Gebbert?
>>
>
> I'm making this a call for mentors. I can comment on the integration into
> the current code and the updates needed, but I would like some else to
> bring ideas on how this would be useful from a power user perspective
> and/or, from a development perspective, if documentation-to-test idea is
> where our priorities are.
>
> For your proposal, it would be good to have a clear idea on what it is you
> are going to implement and how. You don't have to resolve that yourself.
> You can discuss the ideas on the mailing list which would be also a way to
> get more people interested in this idea.
>

I got what you are trying to say. I think there can be two possible ways to
implement our project:

1.  i) To implement GitHub actions and testing the checking the changes a
PR is making to the files.
 ii) Documnetions to tests - using our guinttest library and creating
an AddOn to generate tests for the modules

2) i) To implement GitHub actions and testing the checking the changes a PR
is making to the files.
ii) Using pytest for our tests.

Let me know what you all think about this and which will be more
appropriate for GRASS GIS. In my opinion, I think (1(ii)) Will be more
usable and can be handy as every time we need to run a test on a module we
would not have to write code instead we would just have to update the
documentation(examples) to test our modules and it will be more accessible
to everyone as it will work as an AddOn, and everyone can use it, which is
what I think. Also, please correct me if I am wrong :)


>
> As you probably know, besides preparing your proposal, you will need to do
> some tasks to show you current coding skills. There are a couple of things
> you can work on and obviously there is no upper limit. 1) Fixing broken
> tests would be really good because it will take you through the current
> interface of tests which can inform your proposal. 2) You can always add
> new tests. Testing Python functions in addition to modules would be
> relevant to the task at hand. 3) Taking code from abandoned PR #704, fixing
> it and submitting a new PR is low hanging fruit, but interesting enough.
>
> https://github.com/OSGeo/grass/pull/704
>

Yes sure, I will start working on them.

>
> Best,
> Vaclav
>

Looking forward to hearing from you.
Thank You
Sunveer
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2021 Project - Sunveer Singh

[Vaclav Petras]

On Wed, Feb 3, 2021 at 8:15 AM Sunveer Singh 
wrote:

>
> I am Sunveer Singh, I graduated from high school in 2021 and will start my
> undergraduate studies in Fall 2021 and have been accepted into a university
> so it makes me eligible to participate in GSoC this year.
>

Congratulations and welcome back!


> I found this following project and I would be happy to work on it this
> year:
> https://trac.osgeo.org/grass/wiki/GSoC/2017#Toolsforgeneratingunittestsfromexamplesinthemanual
>
>

This is indeed related to what you did before, so it is a hopeful choice.
However, there is an additional challenge now and that is a poor
integration of the testing framework with current technologies namely
pytest and GitHub Actions.

The choices I made when designing and implementing the framework are not as
advantageous as they seemed in 2014 (there was no 6 hours of runtime from
GitHub for free on every commit, NumPy and GDAL switched to pytest in 2018,
...). You can see the idea for this year here:

https://trac.osgeo.org/grass/wiki/GSoC/2021#IntegratetestingframeworkwithGitHubActions

This is not to say that you can't propose/do the documentation-to-test
idea, but you will need to take into account the current state and needs as
well.


> I see that this project was skipped after 2017 and no one had worked on
> it, so I would like to work on this as it is totally of my interest and my
> skills. Will the mentors written on the page will be the same i.e Vaclav
> Petras and Soeren Gebbert?
>

I'm making this a call for mentors. I can comment on the integration into
the current code and the updates needed, but I would like some else to
bring ideas on how this would be useful from a power user perspective
and/or, from a development perspective, if documentation-to-test idea is
where our priorities are.

For your proposal, it would be good to have a clear idea on what it is you
are going to implement and how. You don't have to resolve that yourself.
You can discuss the ideas on the mailing list which would be also a way to
get more people interested in this idea.

As you probably know, besides preparing your proposal, you will need to do
some tasks to show you current coding skills. There are a couple of things
you can work on and obviously there is no upper limit. 1) Fixing broken
tests would be really good because it will take you through the current
interface of tests which can inform your proposal. 2) You can always add
new tests. Testing Python functions in addition to modules would be
relevant to the task at hand. 3) Taking code from abandoned PR #704, fixing
it and submitting a new PR is low hanging fruit, but interesting enough.

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

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

Re: [GRASS-dev] GSoC 2021 Project - Sunveer Singh

[Luca Delucchi]

On Wed, 3 Feb 2021 at 14:15, Sunveer Singh  wrote:

> Dear Team,
>
> Dear Devs,


> I am Sunveer Singh, I graduated from high school in 2021 and will start my
> undergraduate studies in Fall 2021 and have been accepted into a university
> so it makes me eligible to participate in GSoC this year.
>
> I was Google Code-in 2017 Grand Prize Winner, Google Code-in 2018
> Finalist, and Google Code-in 2019 Mentor with OSGeo. And I majorly worked
> on GRASS GIS unit testing tasks during that time. And I would like to work
> on a GSoC project with GRASS GIS related to it.
>

you can see his tests here
https://github.com/OSGeo/grass/search?q=Sunveer&type=code


> I found this following project and I would be happy to work on it this
> year:
> https://trac.osgeo.org/grass/wiki/GSoC/2017#Toolsforgeneratingunittestsfromexamplesinthemanual
>
>
> I see that this project was skipped after 2017 and no one had worked on
> it, so I would like to work on this as it is totally of my interest and my
> skills. Will the mentors written on the page will be the same i.e Vaclav
> Petras and Soeren Gebbert?
>
>
Sunveer showed a lot of dedication and interest in GRASS GIS project, I
think he would be a great candidate for GSOC

Thank You
> Sunveer
> https://sunveersingh.github.io/
>
> --
ciao
Luca

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

[GRASS-dev] GSoC 2021 Project - Sunveer Singh

[Sunveer Singh]

Dear Team,

I am Sunveer Singh, I graduated from high school in 2021 and will start my
undergraduate studies in Fall 2021 and have been accepted into a university
so it makes me eligible to participate in GSoC this year.

I was Google Code-in 2017 Grand Prize Winner, Google Code-in 2018 Finalist,
and Google Code-in 2019 Mentor with OSGeo. And I majorly worked on GRASS
GIS unit testing tasks during that time. And I would like to work on a GSoC
project with GRASS GIS related to it.
I found this following project and I would be happy to work on it this
year:
https://trac.osgeo.org/grass/wiki/GSoC/2017#Toolsforgeneratingunittestsfromexamplesinthemanual


I see that this project was skipped after 2017 and no one had worked on it,
so I would like to work on this as it is totally of my interest and my
skills. Will the mentors written on the page will be the same i.e Vaclav
Petras and Soeren Gebbert?

Thank You
Sunveer
https://sunveersingh.github.io/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2020- Final Report: Creation of a new GRASS GIS startup mechanism

[Helmut Kudrnovsky]

Hi Linda,

>I would like to present to you the final report. The final report can be
also found at
https://trac.osgeo.org/grass/wiki/GSoC/2020/StartupWindow#FinalReport.

thanks for your comprehensive final report and your nice GSoC work to revamp
the GRASS GIS startup!



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2020- Final Report: Creation of a new GRASS GIS startup mechanism

[L.Kladivova]

Dear Community,

 

I would like to present to you the final report. The final report can be 
also found at https://trac.osgeo.org/grass/wiki/GSoC/2020/StartupWindow#
FinalReport.

I am very proud to be part of this project. I think it brought me lots of 
new experience and it is a great thing that I could contribute to such a 
great project as GRASS GIS is!

 

Title: Creation of a new GRASS GIS startup mechanism
Community: GRASS GIS - OSGeo

 

Abstract:
This project focused on the creation of a more user-friendly GRASS GIS
startup. The general idea was to make the initial user’s contact easier and
with a less steep learning curve. While programming new GRASS startup GUI 
several tasks were solved – changes in Location wizard structure, Data
Catalog as well as general GUI. The initial motion was that the Data Catalog
would be only expanded so that in addition to raster and vector data, it can
even manage Locations and Mapsets. Eventually, the Data Catalog took over 
the role of the Startup screen and completely replaced it. After these
changes when starting GRASS GIS we are directly redirected to Data Catalog
which became the focal point of the whole system.

 

The state of the art BEFORE the start of GSoC:
Every new GRASS GIS user was always redirected to the Startup screen, where
he had to perform several steps (set up a database, location, and mapset).
It was quite confusing without knowing what each of these elements actually
means. So It can happen that a new potentially satisfied user could give up
working with this software right at the beginning (I speak from my own
experience). And that's a shame because GRASS GIS offers a lot of great 
features! Before GSoC, the main role was played by the Startup screen and 
after somewhat confusing setup the GRASS was launched on the Layers tab. At
this point, the Data Catalog only allowed to work with layers and did not 
allow to manage mapsets and locations. It also does not allow adding more 
than one database.

 

The state of the art AFTER GSoC:
First, let's focus on the first important utility, and that is the Location
Wizard. This guide for creating a new location has changed quite a lot. The
first page has been streamlined and somewhat misleading names of the
individual attributes have also been changed. Similarly, the next page, 
originally named "Choose method for creating a new location", is now much 
more clearly defined with the new name "Select Coordinate Reference System
(CRS)". CRS can be newly specified using WKT string. However, the biggest 
change has affected the page with the original name "Choose EPSG Code", now
"Select CRS from list". This window newly supports dynamic search as well as
a hyperlink to EPSG pages which changes dynamically according to the filter
set by the user.

The second thing I focused on throughout July and August was the Data
Catalog. For this tool, it was necessary to take over all the functionality
of the canceled Startup screen. I would like to emphasize here the most 
important functionalities that were coded. The data catalog now supports the
addition of multiple databases. These databases can be deleted from the tree
or deleted directly from the disk. The Data Catalog also supports the
creation, renaming, and deletion of mapsets and locations. Among other
things, it also supports deleting multiple mapsets and locations. Several 
icons have also been added for easy manipulation. Another important thing 
that has been addressed is the distinguishing of mapsets. In the Data
Catalog, mapsets owned by a different user are now grayed out as well as 
mapsets that are "in use". These cases were also considered when renaming/
deleting, therefore several checks were performed. When switching mapsets,
it is possible to remove gislock (make available the mapset which is "in 
use"). The term gislock is no longer confused with the lock icon in the 
context menu which allows or restricts editing outside the current mapset 
and which now has the character of an editing pencil. At this point, I would
also like to emphasize the great contribution that Anna Petrasova coded, and
that does the differentiation of databases, locations, mapsets, and layers
in Data Catalog by icons.

The third thing that has undergone a big change is the very start of GRASS.
GRASS GIS no longer uses the Startup screen. The default tab in GUI is now
the Data tab which contains the Data Catalog. For the first-time user, GRASS
is launched in the Demolocation "world_latlong_wgs84" which should be an 
example of the correct use of the PERMANENT mapset and other user-created 
mapsets. If you are not a first-time user, Data Catalog is opened in the 
last used mapset.

 

Conclusion:
The main task to create a new starting mechanism has been completed.
Features have also been added compared to the original Startup screen, such
as deleting mapsets and locations, resolving mapsets by ownership and lock,
etc. The Data Catalog can be enhanced with additional fe

[GRASS-dev] GSoC 2020 - Linda Kladivova - Creation of a new GRASS GIS startup mechanism

[L.Kladivova]

Dear GRASS GIS community,


I am Linda Kladivova, a master student of Geomatics from Czech Technical 
University in Prague.

My project for GSoC 2020 called "Creation of a new GRASS GIS startup
mechanism"[1] is focused on the creation of a more user-friendly GRASS GIS
startup. The general idea is to make the initial user's contact easier. 
While programming several tasks will be addressed - changes in Location 
Wizard structure, Data Catalog as well as general GUI. The comprehensive 
description is included in my GSoC proposal [2].





I will be implementing this coding  through a GitHub GRASS fork [3] and will
be regularly updating the weekly reports on the project wiki [4], which will
show my regular progress.




I am very happy to participate in this project and looking forward to dive
into it!


Will be glad to receive any suggestions and feedback from the community.




See you guys on a video call on Thursday, May 14 starting at 18:00 UTC if 
interested.

Regards,

Linda K.





[1] https://summerofcode.withgoogle.com/projects/#6062634991878144

[2] https://docs.google.com/document/d/18bVt_bjCDgy2v79Y68rf6-nJgz8
rTJkdkjbqN52YGmM/edit#heading=h.z80kwwj3ld9u

[3] https://github.com/lindakladivova/grass

[4] https://trac.osgeo.org/grass/wiki/GSoC/2020/StartupWindow
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

[Markus Metz]

On Mon, Apr 22, 2019 at 4:45 AM Facundo Ferrín 
wrote:
>
> Hello!
>
> I don't know if I'm expressing myself well. The use of GRASS is
command-line, in the sense:
>
> rass run --mapset=/some/directory/grassdata/ncspm/practice1 r.lake
elevation=some/file.tiff
>
>
> What I propose is the use of a package to import from any Python script.
For example, read a TIFF with GDAL or GeoPandas, perform some operations
like removing some data and finally simplify the polygon.

GRASS is essentially a toolset consisting of several hundred modules which
are called on the command line or in scripts. If you want to use this
functionality, you need to call GRASS modules as done in e.g.
https://trac.osgeo.org/grass/browser/grass/trunk/scripts
>
> GRASS is something like GDAL's option to create polygons from images:
>
> https://gdal.org/gdal_polygonize.html

The GRASS equivalent is 'r.to.vect type=area'
>
> My idea, or my need, is to use GRASS functions programmatically, as in
this case.
>
>
https://pcjericks.github.io/py-gdalogr-cookbook/raster_layers.html#polygonize-a-raster-band

Convert an OGR File to a Raster
more generic: convert a vector to a raster
The GRASS equivalent is 'v.to.rast'

Clip a GeoTiff with Shapefile
more generic: clip a raster to vector polygons
In GRASS: convert to vector polygons to raster with 'v.to.rast', then
create a MASK with 'r.mask'

Calculate zonal statistics
more precisely here: get raster statistics for each vector polygon
The GRASS equivalent is 'v.rast.stats'

Raster to vector line
In GRASS: use 'r.reclass' or 'r.mapcalc' to select pixel values that need
to be converted to vector lines, then use r.to.vect type=line. BTW, the
green lines in the example are wrong because they don#t go through the
pixel centers.

Create raster from array
The GRASS equivalent is 'r.in.ascii'

Create least cost path
The GRASS equivalent is 'r.cost' + 'r.path'

Replace No Data Value of Raster with new value
The GRASS equivalent is 'r.mapcalc' using "if(isnull(rastermap),
, rastermap)"

>
> Is that among your ideas for the future? If that's the case and you're
interested, let me know. If so, you could make some prototype use to start
migrating the functionalities.

All this can be easily implemented as a GRASS GIS addon in a Python script
with much less code than in your example. Please have a look at
https://trac.osgeo.org/grass/browser/grass/trunk/scripts
to get started.
Alternatively, a QGIS plugin using GRASS GIS functionality would be an
option (QGIS has a GRASS GIS interface that can be used for inspiration).

my2c,
Markus M

>
> Cheers!
>
>
> On 10/04/2019 16:47, Vaclav Petras wrote:
>
> Hello Facundo,
>
> Using the GRASS GIS algorithms in various settings is certainly something
we are aiming for. However, as you probably understood from the
conversation here, it is not clear what exactly you are trying to achieve
considering the already available ways (APIs if you will). Also, to
evaluate your proposal, we need to test your skills for this particular
project. Therefore, I suggest you 1) implement a prototype of what you have
in mind, 2) compare it with the existing approaches (see e.g. email from
Markus M.), and 3) identify what is missing in the existing approaches and
what would you need to add in order to make you prototype work.
>
> Alternatively, or ideally in addition to the above, you can implement
couple of the test and training tasks from the proposal already linked by
Luca:
>
>
https://trac.osgeo.org/grass/wiki/GSoC/2019#Neweasy-to-useCLIandAPIforGRASSGIS
>
> Best,
> Vaclav
>
> On Thu, Mar 28, 2019 at 4:13 AM Markus Metz 
wrote:
>>
>>
>>
>> On Thu, Mar 28, 2019 at 9:02 AM Maris Nartiss 
wrote:
>> >
>> > Hello Facundo,
>> > the easiest way would be moving functions of v.generalize into a
>> > library (e.g. grass_generalize) and thus make available for calling
>> > via ctypes.
>> > In the past I have had a good success manipulating GRASS vectors via
>> > ctypes. It takes more skill than a plain Python implementation but it
>> > is easier than a full blown C code and faster than pure Python one.
>> >
>> > Māris.
>> >
>> > ceturtd., 2019. g. 28. marts, plkst. 03:13 — lietotājs Facundo Ferrin
>> > () rakstīja:
>> > >
>> > > Hi Luca!
>> > >
>> > > Thanks for replying! In my job, there were things we had to do
programmatically. For example, to manipulate geometries that reach the
backend from a GeoJSON we use tools like these:
>> > >
>> > >
https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt
>> > >
>> > > However, polygon simplification does not work very well because it
does not take topology into account. My idea was to port part of the GRASS
algorithms to be able to use them without needing the graphical interface
or command line, but only importing a library in a Python script.
>>
>> In this particular case, the core of the corresponding python script
would be three lines (import, simplify, export):
>>
>> -->
>> import grass.script as grass
>>
>> grass.run_command(

Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

[Vaclav Petras]

Hello Facundo,

Using the GRASS GIS algorithms in various settings is certainly something
we are aiming for. However, as you probably understood from the
conversation here, it is not clear what exactly you are trying to achieve
considering the already available ways (APIs if you will). Also, to
evaluate your proposal, we need to test your skills for this particular
project. Therefore, I suggest you 1) implement a prototype of what you have
in mind, 2) compare it with the existing approaches (see e.g. email from
Markus M.), and 3) identify what is missing in the existing approaches and
what would you need to add in order to make you prototype work.

Alternatively, or ideally in addition to the above, you can implement
couple of the test and training tasks from the proposal already linked by
Luca:

https://trac.osgeo.org/grass/wiki/GSoC/2019#Neweasy-to-useCLIandAPIforGRASSGIS

Best,
Vaclav

On Thu, Mar 28, 2019 at 4:13 AM Markus Metz 
wrote:

>
>
> On Thu, Mar 28, 2019 at 9:02 AM Maris Nartiss  wrote:
> >
> > Hello Facundo,
> > the easiest way would be moving functions of v.generalize into a
> > library (e.g. grass_generalize) and thus make available for calling
> > via ctypes.
> > In the past I have had a good success manipulating GRASS vectors via
> > ctypes. It takes more skill than a plain Python implementation but it
> > is easier than a full blown C code and faster than pure Python one.
> >
> > Māris.
> >
> > ceturtd., 2019. g. 28. marts, plkst. 03:13 — lietotājs Facundo Ferrin
> > () rakstīja:
> > >
> > > Hi Luca!
> > >
> > > Thanks for replying! In my job, there were things we had to do
> programmatically. For example, to manipulate geometries that reach the
> backend from a GeoJSON we use tools like these:
> > >
> > >
> https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt
> > >
> > > However, polygon simplification does not work very well because it
> does not take topology into account. My idea was to port part of the GRASS
> algorithms to be able to use them without needing the graphical interface
> or command line, but only importing a library in a Python script.
>
> In this particular case, the core of the corresponding python script would
> be three lines (import, simplify, export):
>
> -->
> import grass.script as grass
>
> grass.run_command('v.in.ogr', ...)
> grass.run_command('v.generalize', ...)
> grass.run_command('v.out.ogr', ...)
> <--
>
> The import step with v.in.ogr is needed because the vector to be
> simplified must be a native GRASS vector with topology.
>
> How does your proposal differ from the QGIS-GRASS interface?
>
> Markus M
> > >
> > > Is it something that you have in mind to do or that might be useful to
> you?
> > >
> > >
> > > El jue., 28 de mar. de 2019 a la(s) 00:32, Luca Delucchi (
> lucadel...@gmail.com) escribió:
> > >>
> > >> On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin <
> facundo.fer...@gmail.com> wrote:
> > >> >
> > >> > Hi there!
> > >>
> > >> Hi Facundo,
> > >> >
> > >> >
> > >> > My name is Facundo Ferrin. I am a nuclear engineer who is taking a
> master in Computer Vision in Barcelona, and finally I found my opportunity
> to contribute to OSGeo by applying two things that I really like: Python
> and Backend development . I do not know exactly what I should write in this
> first email, so I'll start by listing the projects I'm interested in.
> > >> >
> > >> > I'm working in a company that is developing a platform for
> precision agriculture called Auravant (https://www.auravant.com/). I work
> as a backend developer and data analyst and I use daily almost every tool
> that you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a
> tool for polygon simplification called topoJSON (
> https://github.com/fferrin/topojson).
> > >> >
> > >> > ---
> > >> > MY MAIN IDEA is to start porting GRASS tools into a python package
> that can be used in other projects (beyond the client to use by command
> line). I don't know if it's something you have in mind but for offline and
> automated analysis it would be very useful. I particularly had problems
> when I tried to simplify geometries since the geometry of polygons was not
> taken into account.
> > >> > ---
> > >>
> > >> Your idea is not clear to me, there are already two Python library to
> > >> work with GRASS. you can find some ideas in the proposal page
> > >> https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
> > >> Neweasy-to-useCLIandAPIforGRASSGIS) and
> > >> https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS
> integration
> > >> in QGIS 3)
> > >>
> > >> > Hope to hear from you soon!
> > >> >
> > >>
> > >> --
> > >> ciao
> > >> Luca
> > >>
> > >> www.lucadelu.org
> > >
> > > ___
> > > grass-dev mailing list
> > > grass-dev@lists.osgeo.org
> > > https://lists.osgeo.org/mailman/listinfo/grass-dev
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https:/

Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

[Markus Metz]

On Thu, Mar 28, 2019 at 9:02 AM Maris Nartiss  wrote:
>
> Hello Facundo,
> the easiest way would be moving functions of v.generalize into a
> library (e.g. grass_generalize) and thus make available for calling
> via ctypes.
> In the past I have had a good success manipulating GRASS vectors via
> ctypes. It takes more skill than a plain Python implementation but it
> is easier than a full blown C code and faster than pure Python one.
>
> Māris.
>
> ceturtd., 2019. g. 28. marts, plkst. 03:13 — lietotājs Facundo Ferrin
> () rakstīja:
> >
> > Hi Luca!
> >
> > Thanks for replying! In my job, there were things we had to do
programmatically. For example, to manipulate geometries that reach the
backend from a GeoJSON we use tools like these:
> >
> >
https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt
> >
> > However, polygon simplification does not work very well because it does
not take topology into account. My idea was to port part of the GRASS
algorithms to be able to use them without needing the graphical interface
or command line, but only importing a library in a Python script.

In this particular case, the core of the corresponding python script would
be three lines (import, simplify, export):

-->
import grass.script as grass

grass.run_command('v.in.ogr', ...)
grass.run_command('v.generalize', ...)
grass.run_command('v.out.ogr', ...)
<--

The import step with v.in.ogr is needed because the vector to be simplified
must be a native GRASS vector with topology.

How does your proposal differ from the QGIS-GRASS interface?

Markus M
> >
> > Is it something that you have in mind to do or that might be useful to
you?
> >
> >
> > El jue., 28 de mar. de 2019 a la(s) 00:32, Luca Delucchi (
lucadel...@gmail.com) escribió:
> >>
> >> On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin 
wrote:
> >> >
> >> > Hi there!
> >>
> >> Hi Facundo,
> >> >
> >> >
> >> > My name is Facundo Ferrin. I am a nuclear engineer who is taking a
master in Computer Vision in Barcelona, and finally I found my opportunity
to contribute to OSGeo by applying two things that I really like: Python
and Backend development . I do not know exactly what I should write in this
first email, so I'll start by listing the projects I'm interested in.
> >> >
> >> > I'm working in a company that is developing a platform for precision
agriculture called Auravant (https://www.auravant.com/). I work as a
backend developer and data analyst and I use daily almost every tool that
you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool
for polygon simplification called topoJSON (
https://github.com/fferrin/topojson).
> >> >
> >> > ---
> >> > MY MAIN IDEA is to start porting GRASS tools into a python package
that can be used in other projects (beyond the client to use by command
line). I don't know if it's something you have in mind but for offline and
automated analysis it would be very useful. I particularly had problems
when I tried to simplify geometries since the geometry of polygons was not
taken into account.
> >> > ---
> >>
> >> Your idea is not clear to me, there are already two Python library to
> >> work with GRASS. you can find some ideas in the proposal page
> >> https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
> >> Neweasy-to-useCLIandAPIforGRASSGIS) and
> >> https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS integration
> >> in QGIS 3)
> >>
> >> > Hope to hear from you soon!
> >> >
> >>
> >> --
> >> ciao
> >> Luca
> >>
> >> www.lucadelu.org
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

[Maris Nartiss]

Hello Facundo,
the easiest way would be moving functions of v.generalize into a
library (e.g. grass_generalize) and thus make available for calling
via ctypes.
In the past I have had a good success manipulating GRASS vectors via
ctypes. It takes more skill than a plain Python implementation but it
is easier than a full blown C code and faster than pure Python one.

Māris.

ceturtd., 2019. g. 28. marts, plkst. 03:13 — lietotājs Facundo Ferrin
() rakstīja:
>
> Hi Luca!
>
> Thanks for replying! In my job, there were things we had to do 
> programmatically. For example, to manipulate geometries that reach the 
> backend from a GeoJSON we use tools like these:
>
> https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt
>
> However, polygon simplification does not work very well because it does not 
> take topology into account. My idea was to port part of the GRASS algorithms 
> to be able to use them without needing the graphical interface or command 
> line, but only importing a library in a Python script.
>
> Is it something that you have in mind to do or that might be useful to you?
>
>
> El jue., 28 de mar. de 2019 a la(s) 00:32, Luca Delucchi 
> (lucadel...@gmail.com) escribió:
>>
>> On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin  
>> wrote:
>> >
>> > Hi there!
>>
>> Hi Facundo,
>> >
>> >
>> > My name is Facundo Ferrin. I am a nuclear engineer who is taking a master 
>> > in Computer Vision in Barcelona, and finally I found my opportunity to 
>> > contribute to OSGeo by applying two things that I really like: Python and 
>> > Backend development . I do not know exactly what I should write in this 
>> > first email, so I'll start by listing the projects I'm interested in.
>> >
>> > I'm working in a company that is developing a platform for precision 
>> > agriculture called Auravant (https://www.auravant.com/). I work as a 
>> > backend developer and data analyst and I use daily almost every tool that 
>> > you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool 
>> > for polygon simplification called topoJSON 
>> > (https://github.com/fferrin/topojson).
>> >
>> > ---
>> > MY MAIN IDEA is to start porting GRASS tools into a python package that 
>> > can be used in other projects (beyond the client to use by command line). 
>> > I don't know if it's something you have in mind but for offline and 
>> > automated analysis it would be very useful. I particularly had problems 
>> > when I tried to simplify geometries since the geometry of polygons was not 
>> > taken into account.
>> > ---
>>
>> Your idea is not clear to me, there are already two Python library to
>> work with GRASS. you can find some ideas in the proposal page
>> https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
>> Neweasy-to-useCLIandAPIforGRASSGIS) and
>> https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS integration
>> in QGIS 3)
>>
>> > Hope to hear from you soon!
>> >
>>
>> --
>> ciao
>> Luca
>>
>> www.lucadelu.org
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

[Facundo Ferrin]

Hi Luca!

Thanks for replying! In my job, there were things we had to do
programmatically. For example, to manipulate geometries that reach the
backend from a GeoJSON we use tools like these:

https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt

However, polygon simplification does not work very well because it does not
take topology into account. My idea was to port part of the GRASS
algorithms to be able to use them without needing the graphical interface
or command line, but only importing a library in a Python script.

Is it something that you have in mind to do or that might be useful to you?


El jue., 28 de mar. de 2019 a la(s) 00:32, Luca Delucchi (
lucadel...@gmail.com) escribió:

> On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin 
> wrote:
> >
> > Hi there!
>
> Hi Facundo,
> >
> >
> > My name is Facundo Ferrin. I am a nuclear engineer who is taking a
> master in Computer Vision in Barcelona, and finally I found my opportunity
> to contribute to OSGeo by applying two things that I really like: Python
> and Backend development . I do not know exactly what I should write in this
> first email, so I'll start by listing the projects I'm interested in.
> >
> > I'm working in a company that is developing a platform for precision
> agriculture called Auravant (https://www.auravant.com/). I work as a
> backend developer and data analyst and I use daily almost every tool that
> you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool
> for polygon simplification called topoJSON (
> https://github.com/fferrin/topojson).
> >
> > ---
> > MY MAIN IDEA is to start porting GRASS tools into a python package that
> can be used in other projects (beyond the client to use by command line). I
> don't know if it's something you have in mind but for offline and automated
> analysis it would be very useful. I particularly had problems when I tried
> to simplify geometries since the geometry of polygons was not taken into
> account.
> > ---
>
> Your idea is not clear to me, there are already two Python library to
> work with GRASS. you can find some ideas in the proposal page
> https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
> Neweasy-to-useCLIandAPIforGRASSGIS) and
> https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS integration
> in QGIS 3)
>
> > Hope to hear from you soon!
> >
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

[Luca Delucchi]

On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin  wrote:
>
> Hi there!

Hi Facundo,
>
>
> My name is Facundo Ferrin. I am a nuclear engineer who is taking a master in 
> Computer Vision in Barcelona, and finally I found my opportunity to 
> contribute to OSGeo by applying two things that I really like: Python and 
> Backend development . I do not know exactly what I should write in this first 
> email, so I'll start by listing the projects I'm interested in.
>
> I'm working in a company that is developing a platform for precision 
> agriculture called Auravant (https://www.auravant.com/). I work as a backend 
> developer and data analyst and I use daily almost every tool that you post in 
> the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool for polygon 
> simplification called topoJSON (https://github.com/fferrin/topojson).
>
> ---
> MY MAIN IDEA is to start porting GRASS tools into a python package that can 
> be used in other projects (beyond the client to use by command line). I don't 
> know if it's something you have in mind but for offline and automated 
> analysis it would be very useful. I particularly had problems when I tried to 
> simplify geometries since the geometry of polygons was not taken into account.
> ---

Your idea is not clear to me, there are already two Python library to
work with GRASS. you can find some ideas in the proposal page
https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
Neweasy-to-useCLIandAPIforGRASSGIS) and
https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS integration
in QGIS 3)

> Hope to hear from you soon!
>

-- 
ciao
Luca

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

[GRASS-dev] GSoC Proposal: Python package for topology tools

[Facundo Ferrin]

Hi there!

My name is Facundo Ferrin. I am a nuclear engineer who is taking a master
in Computer Vision in Barcelona, and finally I found my opportunity to
contribute to OSGeo by applying two things that I really like: Python and
Backend development 🙌. I do not know exactly what I should write in this
first email, so I'll start by listing the projects I'm interested in.

I'm working in a company that is developing a platform for precision
agriculture called Auravant (https://www.auravant.com/). I work as a
backend developer and data analyst and I use daily almost every tool that
you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool
for polygon simplification called topoJSON (
https://github.com/fferrin/topojson).

---
*MY MAIN IDEA* is to start porting GRASS tools into a python package that
can be used in other projects (beyond the client to use by command line). I
don't know if it's something you have in mind but for offline and automated
analysis it would be very useful. I particularly had problems when I tried
to simplify geometries since the geometry of polygons was not taken into
account.
---

If it's not a viable project at this point, there are two projects that
also caught my attention:
- Create new rules for the Topology Framework in gvSIG Desktop

- QGIS 3D Improvements


I think that maybe I can apply some of the things that I learned from
topoJSON for the first project, and things that I learned from the master
to the second project. Learn C++ is in my schedule (because for Computer
Vision is really important) so it will be really useful for me to program
in C++, and in case that the project is hard enough, I could make it in
Python (which has support for Qt) and it could be translated into C++ as a
GSoC 2020 project.

Hope to hear from you soon!
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2019 Idea: Continuous Fuzzing for GRASS GIS to uncover software bugs

[Even Rouault]

Note that OSS-Fuzz only supports C/C++ libs. Not Python
Fuzzed binaries must statically link all their dependencies:
https://github.com/google/oss-fuzz/blob/master/docs/fuzzer_environment.md

Even

> Hi,
> 
> here an idea for https://trac.osgeo.org/grass/wiki/GSoC/2019
> 
> Since I am not the right person to follow a student on this, I put it here:
> 
> === Continuous Fuzzing for GRASS GIS to uncover software bugs ===
> 
>  * TL;DR: Fuzz testing is a well-known technique for uncovering
> various kinds of programming errors in software. Many of these
> detectable errors (e.g. buffer overflow) can have serious security
> implications. The student will make GRASS GIS ready for OSS-Fuzz.
>   * https://github.com/google/oss-fuzz OSS-Fuzz - Continuous Fuzzing
> for Open Source Software
>  * Requirements:
>   * Student needs to show understanding of the GRASS GIS software
> structure and significantly extend on text above in the proposal.
>   * Language: Python, C
>  * Mentors: ...
>  * Co-mentors: ...
>  * Proposed by: ...
> 
> Here the full template to be used:
> https://lists.osgeo.org/pipermail/discuss/2019-February/038233.html
> 
> Maybe someone here would like to take over to write up the idea properly?
> 
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2019 Idea: Continuous Fuzzing for GRASS GIS to uncover software bugs

[Markus Neteler]

Hi,

here an idea for https://trac.osgeo.org/grass/wiki/GSoC/2019

Since I am not the right person to follow a student on this, I put it here:

=== Continuous Fuzzing for GRASS GIS to uncover software bugs ===

 * TL;DR: Fuzz testing is a well-known technique for uncovering
various kinds of programming errors in software. Many of these
detectable errors (e.g. buffer overflow) can have serious security
implications. The student will make GRASS GIS ready for OSS-Fuzz.
  * https://github.com/google/oss-fuzz OSS-Fuzz - Continuous Fuzzing
for Open Source Software
 * Requirements:
  * Student needs to show understanding of the GRASS GIS software
structure and significantly extend on text above in the proposal.
  * Language: Python, C
 * Mentors: ...
 * Co-mentors: ...
 * Proposed by: ...

Here the full template to be used:
https://lists.osgeo.org/pipermail/discuss/2019-February/038233.html

Maybe someone here would like to take over to write up the idea properly?

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

[GRASS-dev] GSoC 2019 - Call for mentors and ideas

[Helmut Kudrnovsky]

Dear OSGeo community,

It is time for *GSoC* [1] this year, so this is our starting information to get 
involved!

If you are willing to act as a mentor [2], fill in this form:

< https://goo.gl/forms/njL27YLWBVensZ3m1 >

If you want to participate proposing ideas, you just need 
to send us (admins:  ) the URL for your project's
ideas page.

Remember that every idea should indicate:

• A title
• A description
• 2 mentors 
• A test for the students to submit to your evaluation. The test aims at 
evaluating if the student is capable for the project, so please design the test 
having in mind the skills required to complete the project.

Time is short, we need to collect all URLs by Feb 4. Here the timeline [3].

Thanks and please forward to your project community.

Your OSGeo GSoC admins

[1] https://summerofcode.withgoogle.com/
[2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2019_Administrative
[3] https://summerofcode.withgoogle.com/how-it-works/#timeline
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2018 final report week 13 - GRASS GIS module for Sentinel-2 cloud and shadow detection

[Roberta Fagandini]

Hi Helmut,

2018-08-21 19:52 GMT+02:00 Roberta Fagandini :

> Hi Helmut,
>
> 2018-08-21 18:46 GMT+02:00 Helmut Kudrnovsky :
>
>> Hi Roberta,
>>
>> >The title of the project is "GRASS GIS module for Sentinel-2 cloud >and
>> shadow detection". It adds new tools for the processing of >Sentinel 2
>> images to GRASS GIS software (Organization: OSGeo).
>>
>> Thanks for the nice addon!
>>
>
> Thank you, I hope it will be useful for the GRASS community!
>
>
>>
>> Does your addon also  work with already atmospheric corrected sentinel
>> data
>> by other software, or is the step with i.sentinel.preproc  needed?
>>
>
> Sure, it works with bands corrected with other software. For instance
> before developing i.sentinel.preproc I used arcsi to correct bands (I also
> tested i.sentinel.mask with bands corrected using Qgis).
> It also works with Sentinel images of the L2A level. If I remember
> correctly Stefan told me to have tested i.sentinel.mask with L2A images
> obtaining good results.
>
>
>>
>> Is there maybe a workflow with such data documented in the wiki?
>>
>
> you can find more information and a general workflow about the module and
> the developed algorithm in the manual page [0]. Hope this helps!!
>
> [https://grass.osgeo.org/grass74/manuals/addons/i.sentinel.mask.html]
>

sorry, I thought you were referring to my GSoC wiki page but maybe I
understood what you meant for 'wiki' [0]. I will add the documentation
about i.sentinel.mask and i.sentinel.preproc in the next days.

Kind regards,

Roberta

[0] https://grasswiki.osgeo.org/wiki/SENTINEL


>
> kind regards
>
> Roberta
>
>
>>
>>
>>
>> -
>> best regards
>> Helmut
>> --
>> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2018 final report week 13 - GRASS GIS module for Sentinel-2 cloud and shadow detection

[Roberta Fagandini]

Hi Helmut,

2018-08-21 18:46 GMT+02:00 Helmut Kudrnovsky :

> Hi Roberta,
>
> >The title of the project is "GRASS GIS module for Sentinel-2 cloud >and
> shadow detection". It adds new tools for the processing of >Sentinel 2
> images to GRASS GIS software (Organization: OSGeo).
>
> Thanks for the nice addon!
>

Thank you, I hope it will be useful for the GRASS community!


>
> Does your addon also  work with already atmospheric corrected sentinel data
> by other software, or is the step with i.sentinel.preproc  needed?
>

Sure, it works with bands corrected with other software. For instance
before developing i.sentinel.preproc I used arcsi to correct bands (I also
tested i.sentinel.mask with bands corrected using Qgis).
It also works with Sentinel images of the L2A level. If I remember
correctly Stefan told me to have tested i.sentinel.mask with L2A images
obtaining good results.


>
> Is there maybe a workflow with such data documented in the wiki?
>

you can find more information and a general workflow about the module and
the developed algorithm in the manual page [0]. Hope this helps!!

[https://grass.osgeo.org/grass74/manuals/addons/i.sentinel.mask.html]

kind regards

Roberta


>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2018 final report week 13 - GRASS GIS module for Sentinel-2 cloud and shadow detection

[Helmut Kudrnovsky]

Hi Roberta,

>The title of the project is "GRASS GIS module for Sentinel-2 cloud >and
shadow detection". It adds new tools for the processing of >Sentinel 2
images to GRASS GIS software (Organization: OSGeo).

Thanks for the nice addon!

Does your addon also  work with already atmospheric corrected sentinel data
by other software, or is the step with i.sentinel.preproc  needed? 

Is there maybe a workflow with such data documented in the wiki?



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2018 final report week 13 - GRASS GIS module for Sentinel-2 cloud and shadow detection

[Roberta Fagandini]

Thank you Moritz for your support!!

Roberta

2018-08-13 12:06 GMT+02:00 Moritz Lennert :

> Great work, Roberta !
>
> Thanks for these two very useful modules !
>
>
> Moritz
>
> On 13/08/18 10:20, Roberta Fagandini wrote:
>
>> Hi all!
>> I'm Roberta Fagandini and this is the final report of my GSoC project.
>>
>> The title of the project is "GRASS GIS module for Sentinel-2 cloud and
>> shadow detection". It adds new tools for the processing of Sentinel 2
>> images to GRASS GIS software (Organization: OSGeo).
>>
>> *Abstract:*
>> Optical sensors are unable to penetrate clouds leading to related
>> anomalous reflectance values. Unlike Landsat images, Sentinel 2 datasets do
>> not include thermal and Quality Assessment bands that simplify the
>> detection of clouds avoiding erroneous classification. At the same time,
>> also clouds shadows on the ground lead to anomalous reflectance values
>> which have to be taken into account during the image processing.
>> The project creates a specific module for GRASS GIS application
>> (i.sentinel.mask) which implements an automatic procedure for clouds and
>> shadows detection for Sentinel 2 images. The procedure is based on an
>> algorithm, developed within my PhD research, which allows to automatically
>> identify clouds and their shadows applying some rules on reflectance values
>> (values thresholds, comparisons between bands, etc.). These have been
>> defined starting from rules found in literature and conveniently refined.
>> In order to increase the accuracy of the final results, a control check is
>> implemented. Clouds and shadows are spatially intersected in order to
>> remove misclassified areas. The final outputs are two different vector maps
>> (OGR standard formats), one for clouds and one for shadows.
>> To run i.sentinel.mask, the bands of the desired Sentinel 2 images have
>> to be imported and the atmospheric correction has to be applied.
>> In order to make the data preparation easier, another GRASS
>> GISaddonmodule has been developed within the GSoC project.
>> i.sentinel.preprocis a module for the preprocessing of Sentinel 2 images
>> (Level-1C Single Tile product) which wraps the import and the atmospheric
>> correction using respectively two existing GRASS GIS modules,
>> i.sentinel.import and i.atcorr.
>>
>> *The state of the art before the project:*
>> Before this GSoC 2018 project, no modules for the detection of clouds and
>> shadows were available for Sentinel 2 images. Only a specific module for
>> Landsat automatic cloud coverage assessment was available within GRASS GIS
>> (i.landsat.acca) while regarding shadows, no specific module was available.
>> Moreover, performing the atmospheric correction was a bit complicated
>> especially for unexperiencedusers who have to process one band at a time
>> and provide all input parameters manually.
>>
>> *The added value that the project brought to GRASS GIS:*
>> Now a specific module for clouds and shadows detection,
>> i.sentinel.mask,is available in GRASS GIS.
>> Moreover, i.sentinel.preprocprovides a simplified module which allows
>> importing images and performing the atmospheric correction avoiding users
>> to supply all the required input parameters manually. The module should
>> help users in preparing data to use as input for i.sentinel.mask. In fact,
>> it makes especially the atmospheric correction procedure easier and faster
>> because it allows performing atmospheric correction of all bands of a
>> Sentinel 2 scene with a single process and it retrieves most of the
>> required input parameters from the image itself. Moreover, one of the
>> possible output of i.sentinel.preprocis a text file to be used as input for
>> i.sentinel.mask.
>>
>> *Follow up:*
>> Both i.sentinel.mask and i.sentinel.preprocare complete and working
>> modules which can be easily installed with g.extension from the official
>> GRASS GIS SVN repository.
>> Obviously, they can be improved therefore the next steps could be:
>>
>>   * Implementation of other existing algorithms of clouds and shadows
>> detection (i.sentinel.mask)
>>   * Implementation of a new download procedure avoiding dependencies
>> (i.sentinel.preproc)
>>   * Integration of the Topographic Correction (i.sentinel.preproc)
>>
>> NOTE: Implementation of other existing algorithms of clouds and shadows
>> detection was one of the possible goals of the GSoC project but the
>> codingand debuggingof some parts of the twoaddonsrequired more time than
>> expected.
>>
>> *Permanent links:*
>> *
>> *
>> /Code developed during the GSoC coding period: /
>> https://github.com/RobiFag/GRASS_clouds_and_shadows <
>> https://github.com/RobiFag/GRASS_clouds_and_shadows>
>>
>> /Codes on the official GRASS GIS SVN repository:/
>> https://trac.osgeo.org/grass/browser/grass-addons/grass7/ima
>> gery/i.sentinel.mask > browser/grass-addons/grass7/imagery/i.sentinel.mask>
>> https://trac.osgeo.org/grass/browser/grass-addons/grass7

Re: [GRASS-dev] GSoC 2018 final report week 13 - GRASS GIS module for Sentinel-2 cloud and shadow detection

[Moritz Lennert]

Great work, Roberta !

Thanks for these two very useful modules !


Moritz

On 13/08/18 10:20, Roberta Fagandini wrote:

Hi all!
I'm Roberta Fagandini and this is the final report of my GSoC project.

The title of the project is "GRASS GIS module for Sentinel-2 cloud and 
shadow detection". It adds new tools for the processing of Sentinel 2 
images to GRASS GIS software (Organization: OSGeo).


*Abstract:*
Optical sensors are unable to penetrate clouds leading to related 
anomalous reflectance values. Unlike Landsat images, Sentinel 2 datasets 
do not include thermal and Quality Assessment bands that simplify the 
detection of clouds avoiding erroneous classification. At the same time, 
also clouds shadows on the ground lead to anomalous reflectance values 
which have to be taken into account during the image processing.
The project creates a specific module for GRASS GIS application 
(i.sentinel.mask) which implements an automatic procedure for clouds and 
shadows detection for Sentinel 2 images. The procedure is based on an 
algorithm, developed within my PhD research, which allows to 
automatically identify clouds and their shadows applying some rules on 
reflectance values (values thresholds, comparisons between bands, etc.). 
These have been defined starting from rules found in literature and 
conveniently refined. In order to increase the accuracy of the final 
results, a control check is implemented. Clouds and shadows are 
spatially intersected in order to remove misclassified areas. The final 
outputs are two different vector maps (OGR standard formats), one for 
clouds and one for shadows.
To run i.sentinel.mask, the bands of the desired Sentinel 2 images have 
to be imported and the atmospheric correction has to be applied.
In order to make the data preparation easier, another GRASS 
GISaddonmodule has been developed within the GSoC project.
i.sentinel.preprocis a module for the preprocessing of Sentinel 2 images 
(Level-1C Single Tile product) which wraps the import and the 
atmospheric correction using respectively two existing GRASS GIS 
modules, i.sentinel.import and i.atcorr.


*The state of the art before the project:*
Before this GSoC 2018 project, no modules for the detection of clouds 
and shadows were available for Sentinel 2 images. Only a specific module 
for Landsat automatic cloud coverage assessment was available within 
GRASS GIS (i.landsat.acca) while regarding shadows, no specific module 
was available.
Moreover, performing the atmospheric correction was a bit complicated 
especially for unexperiencedusers who have to process one band at a time 
and provide all input parameters manually.


*The added value that the project brought to GRASS GIS:*
Now a specific module for clouds and shadows detection, 
i.sentinel.mask,is available in GRASS GIS.
Moreover, i.sentinel.preprocprovides a simplified module which allows 
importing images and performing the atmospheric correction avoiding 
users to supply all the required input parameters manually. The module 
should help users in preparing data to use as input for i.sentinel.mask. 
In fact, it makes especially the atmospheric correction procedure easier 
and faster because it allows performing atmospheric correction of all 
bands of a Sentinel 2 scene with a single process and it retrieves most 
of the required input parameters from the image itself. Moreover, one of 
the possible output of i.sentinel.preprocis a text file to be used as 
input for i.sentinel.mask.


*Follow up:*
Both i.sentinel.mask and i.sentinel.preprocare complete and working 
modules which can be easily installed with g.extension from the official 
GRASS GIS SVN repository.

Obviously, they can be improved therefore the next steps could be:

  * Implementation of other existing algorithms of clouds and shadows
detection (i.sentinel.mask)
  * Implementation of a new download procedure avoiding dependencies
(i.sentinel.preproc)
  * Integration of the Topographic Correction (i.sentinel.preproc)

NOTE: Implementation of other existing algorithms of clouds and shadows 
detection was one of the possible goals of the GSoC project but the 
codingand debuggingof some parts of the twoaddonsrequired more time than 
expected.


*Permanent links:*
*
*
/Code developed during the GSoC coding period: /
https://github.com/RobiFag/GRASS_clouds_and_shadows 



/Codes on the official GRASS GIS SVN repository:/
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.sentinel.mask 

https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.sentinel.preproc 



/Documentation:/
https://grass.osgeo.org/grass74/manuals/addons/i.sentinel.mask.html 

https://grass.osgeo.org/grass

[GRASS-dev] GSoC 2018 final report week 13 - GRASS GIS module for Sentinel-2 cloud and shadow detection

[Roberta Fagandini]

Hi all!
I'm Roberta Fagandini and this is the final report of my GSoC project.

The title of the project is "GRASS GIS module for Sentinel-2 cloud and
shadow detection". It adds new tools for the processing of Sentinel 2
images to GRASS GIS software (Organization: OSGeo).

*Abstract:*
Optical sensors are unable to penetrate clouds leading to related anomalous
reflectance values. Unlike Landsat images, Sentinel 2 datasets do not
include thermal and Quality Assessment bands that simplify the detection of
clouds avoiding erroneous classification. At the same time, also clouds
shadows on the ground lead to anomalous reflectance values which have to be
taken into account during the image processing.
The project creates a specific module for GRASS GIS application
(i.sentinel.mask) which implements an automatic procedure for clouds and
shadows detection for Sentinel 2 images. The procedure is based on an
algorithm, developed within my PhD research, which allows to automatically
identify clouds and their shadows applying some rules on reflectance values
(values thresholds, comparisons between bands, etc.). These have been
defined starting from rules found in literature and conveniently refined.
In order to increase the accuracy of the final results, a control check is
implemented. Clouds and shadows are spatially intersected in order to
remove misclassified areas. The final outputs are two different vector maps
(OGR standard formats), one for clouds and one for shadows.
To run i.sentinel.mask, the bands of the desired Sentinel 2 images have to
be imported and the atmospheric correction has to be applied.
In order to make the data preparation easier, another GRASS GIS addon module
has been developed within the GSoC project.
i.sentinel.preproc is a module for the preprocessing of Sentinel 2 images
(Level-1C Single Tile product) which wraps the import and the atmospheric
correction using respectively two existing GRASS GIS modules,
i.sentinel.import and i.atcorr.

*The state of the art before the project:*
Before this GSoC 2018 project, no modules for the detection of clouds and
shadows were available for Sentinel 2 images. Only a specific module for
Landsat automatic cloud coverage assessment was available within GRASS GIS
(i.landsat.acca) while regarding shadows, no specific module was available.
Moreover, performing the atmospheric correction was a bit complicated
especially for unexperienced users who have to process one band at a time
and provide all input parameters manually.

*The added value that the project brought to GRASS GIS:*
Now a specific module for clouds and shadows detection, i.sentinel.mask, is
available in GRASS GIS.
Moreover, i.sentinel.preproc provides a simplified module which allows
importing images and performing the atmospheric correction avoiding users
to supply all the required input parameters manually. The module should
help users in preparing data to use as input for i.sentinel.mask. In fact,
it makes especially the atmospheric correction procedure easier and faster
because it allows performing atmospheric correction of all bands of a
Sentinel 2 scene with a single process and it retrieves most of the
required input parameters from the image itself. Moreover, one of the
possible output of i.sentinel.preproc is a text file to be used as input
for i.sentinel.mask.

*Follow up:*
Both i.sentinel.mask and i.sentinel.preproc are complete and working
modules which can be easily installed with g.extension from the official
GRASS GIS SVN repository.
Obviously, they can be improved therefore the next steps could be:

   - Implementation of other existing algorithms of clouds and shadows
   detection (i.sentinel.mask)
   - Implementation of a new download procedure avoiding dependencies
   (i.sentinel.preproc)
   - Integration of the Topographic Correction (i.sentinel.preproc)

NOTE: Implementation of other existing algorithms of clouds and shadows
detection was one of the possible goals of the GSoC project but the coding and
debugging of some parts of the two addons required more time than expected.

*Permanent links:*

*Code developed during the GSoC coding period: *
https://github.com/RobiFag/GRASS_clouds_and_shadows

*Codes on the official GRASS GIS SVN repository:*
https://trac.osgeo.org/grass/browser/grass-addons/grass7/ima
gery/i.sentinel.mask
https://trac.osgeo.org/grass/browser/grass-addons/grass7/ima
gery/i.sentinel.preproc

*Documentation:*
https://grass.osgeo.org/grass74/manuals/addons/i.sentinel.mask.html
https://grass.osgeo.org/grass74/manuals/addons/i.sentinel.preproc.html

*Weekly reports: *
https://trac.osgeo.org/grass/wiki/GSoC/2018/CloudsAndShadowsDetection

*Images to showcase the project:*
i.sentinel.mask
https://raw.githubusercontent.com/RobiFag/GRASS_clouds_and_s
hadows/master/images/i_sentinel_mask_GWF.png
https://raw.githubusercontent.com/RobiFag/GRASS_clouds_and_s
hadows/master/images/i_sentinel_mask_CD.png
https://raw.githubusercontent.com/RobiFag/GRASS_clouds_and_s
hado

[GRASS-dev] GSoC 2018 report week 12 - GRASS GIS module for Sentinel-2 cloud and shadow detection

[Roberta Fagandini]

Hi all!
I'm Roberta Fagandini and I'm working on my GSoC project, a GRASS GIS
module for Sentinel-2 cloud and shadow detection.
This is my report for the twelfth week of coding.

1) What did I complete this week?

   - Taking the suggestions of the dev community into account and after a
   long discussion with my mentor, I decided to not implement
   i.sentinel.download in order to avoid dependencies due to the
   implementation of an existing module that users can use separately
   - Added support for the Old format Naming Convention of Sentinel 2
   images in i.sentinel.preproc  [0]
   - Improved the manual page of i.sentinel.preproc [1]
   - Small changes to the code and the GUI of i.sentinel. preproc in order
   to make it more congruent with the manual page of i.atcorr (e.g. change AOT
   in AOD) [2]
   - Improved the manual page of i.sentinel.mask adding a more detailed
   example and other information [3]
   - Started preparing deliverables for the final evaluation (updated the
   readme file of my GitHub repository) [4][5][6]
   - Tested both modules i.sentinel.mask and i.sentinel.preproc in order to
   improve and debug the code (small changes to the codes and the GUIs)

2) What am I going to achieve for next week?

   - Last tests and possible changes
   - Clean up the code of i.sentinel.preproc (PEP8 style guide and GRASS
   Python Scripting Library rules)
   - Final check to both modules, i.sentinel.preproc and i.sentinel.mask
   (codes and manual pages)
   - Preparing deliverables for the final evaluation
   - Check everything (codes, manuals and deliverables ) with my mentor

3) Is there any blocking issue?
No.

Here the links to my GitHub repository [7] and wiki page [8]

Kind regards,
Roberta

[0] https://github.com/RobiFag/GRASS_clouds_and_shadows/
commit/3bb503d2eb860dede36710ba7fb913de4fad17bf
[1] https://github.com/RobiFag/GRASS_clouds_and_shadows/
commit/b7e69b1bdbaa8e9c91579091febf46718cbaf4ee#diff-15b47cd
1e07802ebc64446c2fce5fef0
[2] 
*https://github.com/RobiFag/GRASS_clouds_and_shadows/commit/949100564d79895bd992e62e3d214752e704faf7#diff-84085907e0e00fead4cef44afe6eb4e7
*
[3] https://github.com/RobiFag/GRASS_clouds_and_shadows/
commit/fe2aa29bc656d436e28579f1086d6c60bce678aa
[4] https://github.com/RobiFag/GRASS_clouds_and_shadows/
commit/fbcaa32d9fa2bbd92e85f16ec6a828aaa575a85b
[5] https://github.com/RobiFag/GRASS_clouds_and_shadows/
commit/9ad83e286594012f58e44de63c9af9c9d8ce2c07
[6] https://github.com/RobiFag/GRASS_clouds_and_shadows/
commit/48f3747888eed2bcbde3ea95c318be3a2ef17d11
[7] https://github.com/RobiFag/GRASS_clouds_and_shadows
[8] https://trac.osgeo.org/grass/wiki/GSoC/2018/CloudsAndShadowsDetection
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev