Code review

[bniebuhr]

To do list after talk to Miltinho, Mauricio, Kyle and Felipe

2020-06-12

This is a list of to-do things after out talk on June 2020. We will plan the development of LSMetrics based on that.

• Lansdcape metrics to implement:

  1. function to classify landscape elements (edge, core, matrix, corridor, stepping stone, habitat branch, ...)
     We decided this is not a priority at the moment.

• Coding:

  1. How does GRASS GIS works? Organize Live at GeoCast about GRASS (Mauricio, Bernardo), in Portuguese. This may also be a good introduction on GRASS GIS to Kyle and Felipe.
     Deadline: agosto 2020?
     There is some material here: https://figshare.com/articles/Geoprocessamento_com_GRASS-GIS/3502184
     And here: https://www.youtube.com/watch?v=VDsVcijsrkg&feature=youtu.be

  2. We decided to completely translate GRASS GIS code to Python 3. Python 3 is used on GRASS GIS 7.8 and later version, and this will be kept in the future. Then, we are not going to update the code with Python 2.7 anymore.
     This is one of the priorities - to guarantee that the functions are working.

  3. We will divide the script into core functions and GUI in separate scripts. This is also a priority. We will also create another script for operations involving vectors (e.g. zonal statistics based on the landscape metrics). However, these operations with vectors will be developed only as code/addon, not incorporated into the GUI.

  4. Transform LSMetrics functions into GRASS addon
     The idea is to have a single script for the core functions, both auxiliary functions and the ones used to calculate the landscape metrics, and then build scripts for each function as addon. We can discuss the format of that later (if we'll have r.patch_size or r.ls.patch_size, for instance).
     Some information here: Links: https://grasswiki.osgeo.org/wiki/AddOns

  5. Along with the development of each function and addon, we will build a unit test.
     Idea: to use the dataset from Rio Claro to calculate all metrics and keep that in the database. Then, each time the functions are built and modified, we can compare the maps pixel by pixel. Kyle suggested developing that in two steps:

     1. first, we can only check if the output is or not equal, which is simpler.
     2. in a second phase, we may start to check where there were differences

  6. Vector landscape metrics statistics: we will keep this only as code/addon, not in the GUI

     1. metrics for a vector
     2. metrics for each feature of a vector (zonal statistics)

  7. The last thing will be to deal with the graphical interface. A promising idea is to abandon wxPython and use PyQt instead.

The idea is to do step 1 first (August), then steps 2-6 until December 2020. We may create an issue for each function to be tested and developed, or each enhancement, and work together on that.

Before that, a first thing would be to have a common Git workflow to use, just to avoid unnecessary conflicts in coding. Something like that: https://github.com/piLaboratory/jaguar-codes/wiki

[FelipeSBarros]

Great @bniebuhr ...I think taht the process of updating to Python3 woul be a good way to pratice with Grass...
Perhaps we can think about splitting the tasks in this issue to individual issues...

[bniebuhr]

Sure, that's the idea, @FelipeSBarros. ;-) John, Felipe and Kyle are new members on the Team, we are planning to improve LSMetrics and put it forward for once. Take a look at the private email I sent you about that ;-) Em segunda-feira, 15 de junho de 2020 20:28:40 GMT+2, FelipeSBarros <[email protected]> escreveu: Great @bniebuhr ...I think taht the process of updating to Python3 woul be a good way to pratice with Grass... Perhaps we can think about splitting the tasks in this issue to individual issues... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[JohnWRRC]

Oi Pessoal, como estão? Sobre esse prazo de agosto, ficou definido alguma coisa? Vai rolar esse upgrade ? Estou um pouco atarefado, que não está né? mas consigo encaixar um tempinho para trabalhar em alguma parte. Existem algumas funções que utilizei que não são as mais eficientes em questões de otimização de tempo e memória, isso precisa ser melhorado, depois farei os apontamentos. 1 -A primeira coisa é fazer ele funcionar no Python3 e consequentemente já aproveitar para separar todas as funções em outros .py Acho que em 15 dias dá pra deixar tinindo =) 2 -Remover ele da interface não é difícil, uma vez que as variáveis de entradas não são muitas. Aqui vai +/- uma semana chutando alto. PS: Pessoal, estou com umas ideias Estou desenvolvendo uma aplicação qgis standalone pelo Osgeo4W, e encontrei diversas coisas legais. Uma coisa que vou fazer no Lscoor e que talvez seja interessante fazer com o lsmetrics, é torná-lo além de um add-on grass, criar também plugin-qgis e o mais legal de tudo transformá-lo em um aplicativo externo, Mesmo dependendo das bibliotecas do grass, é possível criar um ambiente qgis/grass/gdal portable e configurá-lo apenas com os módulos que são utilizados. assim a pessoa q for usar o LS_metriccs por exemplo não precisa ter o grass nem o qgis instalado, no PC, ele vai ter uma pastinha em que terá um .'LS_METRICS.bat' que abrirá uma interface Wx ou qq outra isso não importa, q receberá os parâmetros e fará os processamentos para depois serem analisados em qq outro SIG, Qgis/ ArcGis/ GRASS etc, Como eu falei, já estou trabalhando com uma aplicação nessa linha e tenho o caminho das pedras. O que acham da ideia? Abs, John Em sex., 12 de jun. de 2020 às 08:29, Bernardo Brandão Niebuhr < [email protected]> escreveu:

…

To do list after talk to Miltinho, Mauricio, Kyle and Felipe 2020-06-12 This is a list of to-do things after out talk on June 2020. We will plan the development of LSMetrics based on that. - Lansdcape metrics to implement: 1. function to classify landscape elements (edge, core, matrix, corridor, stepping stone, habitat branch, ...) We decided this is not a priority at the moment. - Coding: 1. How does GRASS GIS works? Organize Live at GeoCast about GRASS (Mauricio, Bernardo), in Portuguese. This may also be a good introduction on GRASS GIS to Kyle and Felipe. Deadline: agosto 2020? There is some material here: https://figshare.com/articles/Geoprocessamento_com_GRASS-GIS/3502184 And here: https://www.youtube.com/watch?v=VDsVcijsrkg&feature=youtu.be 2. We decided to completely translate GRASS GIS code to Python 3. Python 3 is used on GRASS GIS 7.8 and later version, and this will be kept in the future. Then, we are not going to update the code with Python 2.7 anymore. This is one of the priorities - to guarantee that the functions are working. 3. We will divide the script into core functions and GUI in separate scripts. This is also a priority. We will also create another script for operations involving vectors (e.g. zonal statistics based on the landscape metrics). However, these operations with vectors will be developed only as code/addon, not incorporated into the GUI. 4. Transform LSMetrics functions into GRASS addon The idea is to have a single script for the core functions, both auxiliary functions and the ones used to calculate the landscape metrics, and then build scripts for each function as addon. We can discuss the format of that later (if we'll have r.patch_size or r.ls.patch_size, for instance). Some information here: Links: https://grasswiki.osgeo.org/wiki/AddOns 5. Along with the development of each function and addon, we will build a unit test. Idea: to use the dataset from Rio Claro to calculate all metrics and keep that in the database. Then, each time the functions are built and modified, we can compare the maps pixel by pixel. Kyle suggested developing that in two steps: 1. first, we can only check if the output is or not equal, which is simpler. 2. in a second phase, we may start to check where there were differences 6. Vector landscape metrics statistics: we will keep this only as code/addon, not in the GUI 1. metrics for a vector 2. metrics for each feature of a vector (zonal statistics) 7. The last thing will be to deal with the graphical interface. A promising idea is to abandon wxPython and use PyQt instead. The idea is to do step 1 first (August), then steps 2-6 until December 2020. We may create an issue for each function to be tested and developed, or each enhancement, and work together on that. Before that, a first thing would be to have a common Git workflow to use, just to avoid unnecessary conflicts in coding. Something like that: https://github.com/piLaboratory/jaguar-codes/wiki — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYCJJY4CWBLZUVD2Q74MMTRWIGRTANCNFSM4N4H3BTA> .

-- *John Wesley Ribeiro* Proprietário na empresa PythonGIS Fone whatsapp: (44) 997538335 CV LATTES : Lattes: http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4889487Y8 <http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4889487Y8>