Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LSMetrics does not keep MASKs and process the whole maps #6

Open
bniebuhr opened this issue Dec 4, 2018 · 9 comments
Open

LSMetrics does not keep MASKs and process the whole maps #6

bniebuhr opened this issue Dec 4, 2018 · 9 comments
Assignees
Labels

Comments

@bniebuhr
Copy link
Contributor

bniebuhr commented Dec 4, 2018

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.

@bniebuhr bniebuhr added the bug label Dec 4, 2018
@bniebuhr bniebuhr self-assigned this Dec 4, 2018
@bniebuhr
Copy link
Contributor Author

@miltinhoastronauta , @mauriciovancine

This was based on some user that used LSMetrics before.
Do you think we need to include this explicitly in the functions? I guess the mask is already considered, i.e., if there is a mask, the LSMetrics funtions well not change it. However, in the beginning of each calculation, we make sure to do a g.region raster=input_map, which means the region will be the whole map (even if a mask for a smaller part is present).
maybe we could just check at this point if a mask is present, and if it is, use g.region raster=MASK.

Does it make sense?

@mauriciovancine
Copy link
Contributor

Hi @bniebuhr.

I do not know if I understand.

My idea was that LSM will perform the calculation of the metrics for the region and mask defined, no?

@JohnWRRC
Copy link
Contributor

JohnWRRC commented Jun 12, 2020 via email

@JohnWRRC
Copy link
Contributor

JohnWRRC commented Jun 12, 2020 via email

@bniebuhr
Copy link
Contributor Author

Hi @bniebuhr.

I do not know if I understand.

My idea was that LSM will perform the calculation of the metrics for the region and mask defined, no?

Yes. But currently it does not do anything regarding the MASK. Of course the mask works, but the region is defined based on the input_map, even if a mask is present. That means that a great part of the output raster may be composed by NULL pixels (if the mask is a small extent of the input_map or even all NULL if the mask is outside the input_map of interest.

That's why I think we could look for a MASK in the beginning of the function, then use g.region raster=MASK instead of g.region raster=input_map.

As John suggested, we can also think about an option ignore_mask = False/True. If True, everything keeps the same as it is; otherwise we would follow a rule as I described above (g.region raster=MASK is the mask is present, g.region raster=input_map otherwise).

What do you think?

@JohnWRRC
Copy link
Contributor

JohnWRRC commented Jun 13, 2020 via email

@bniebuhr
Copy link
Contributor Author

Hey John,

I'll keep the text in English, is that ok?
So, we are trying to disentangle the code of LSMetrics from the graphical interface, so that it can be used from the command line also, as any other GRASS GIS addon. That will make things very useful for other GRASS GIS users. So I do not think it would be useful to couple this functionality with the GUI.
That's why I was thinking whether we should include it in the body of the LSMetrics functions...

@bniebuhr
Copy link
Contributor Author

Esse é o caminho Ber, o que vc sugeriu mesmo. if ignore_mask = false: r.mask -r # eu sempre garanto fazendo uma remocao mesmo sabendo que nao tem g.region rast=mapainteiro else: g.region map =rastermask r.mask inp= rastermask r.mask -r # no fim do codigo la no fim remove a mascara pq se nao pode dar problemas depois que fechar a aplicação Acho que é isso

Great, John, I haven't seen this answer. But we just need to take care and avoid removing masks, since we want it to be used as any other GRASS GIS addon (see last answer above).

@JohnWRRC
Copy link
Contributor

JohnWRRC commented Jun 15, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants