Hi,

I would like to report an issue (which is probably not from the package but a GIS conflict), ask if other users had the same problem and also check if someone knows how to avoid this problem.

I am using rasters with South_America_Albers_Equal_Area_Conic projection as input, I usually work in ArcGIS. So, I had defined the projection and datum in GRASS through a georeferenced data file (my input rasters).

LS_metrics worked perfectly but I realised that the outputs were projected as Albers_Equal_Area.
As I used ArcGIS to reproject the output rasters to wgs84, I then noticed that the reprojection was not working and fragments reprojected in ArcGIS were 70/80 m displaced ( they were still in albers).

To fix that in ArcGIS I had to define the projection as South_America_Albers_Equal_Area_Conic and then after that reproject the outputs to wgs84.

So maybe it is a conflict between different GIS project system or maybe I should assign the initial projection in a different way (if you know how please let me know), or reproject the outputs within GRASS. But it is good to keep attention if you are using more than one GIS or using the output in R and then assigning the projection there.

Thanks for the package, it is really useful!

Hello,

I have been working with Cerrado biome and the enhanced LS Metrics (new version) for some landscape metrics (patch size, functional connectivity). The problem is: the rasters outputs were exported to the folder, but the statistic text files not. I would like to know what it is probably happening because the LS Metrics keeps going on processing even after the rasters maps were exported.

Obs.: Raster input size (columns and rows): 66977, 85490

Thanks for the package. It has been useful mainly with big landscapes!

Best wishes,

Rafaela

Hello,

I was going to use LS_METRICS for some connectivity analysis and it would be great to have a publication for reference.
I see that in the wiki you report:

Niebuhr, B. B. S.; Martello, F.; Ribeiro, J. W.; Vancine, M. H.; Muylaert, R. L.; Campos, V. E. W.; Santos, J. S.; Tonetti, V. R.; Ribeiro, M. C. Landscape Metrics (LSMetrics): a spatially explicit tool for calculating connectivity and other ecologically-scaled landscape metrics. In preparation.

Is there any news on that front? Also a preprint would make it, but I couldn't find anything!

Cheers and congrats for the software.

We have just started woking on tests to use LSMetrics + GRASS on Mac OS systems. Anyone using Mac is welcome to help us testing.

Hi would it be possible to include checking for null values in the input raster and then transform it to 0 values before calculating the landscape metrics?
Maybe using
grass.run_command('r.null', map = map_for_define_region, null = '0')

Thanks again!

Here are some instructions to test LSMetrics on Mac OS:

1. First, install GRASS GIS. For instructions, please look at the following:
   Installing GRASS on Mac OS
   Note that you'll probably need to install some frameworks before installing GRASS GIS properly.
   Here, how should we suggest users to test if GRASS GIS is working?

2. Then, first create or open a GRASS GIS project. More instructions here.
   To do so, you may use one of the sample maps available in our repository here.

3. Try opening LSMetrics. More instructions in this link.
   Here we should pay attention at two features:

• how the GUI look like (so that we can adjust it);
• run some metrics to test if the package is working.

Anything else?

Just to remark it here: in each function/metric, we need to alow the possibility of processing the metrics either to the whole map or to the MASK, if present.

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