-
Notifications
You must be signed in to change notification settings - Fork 12
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
Problems with ML methods at the edge of maps #6
Labels
Comments
Greetings!
I had previously replied privately to Bernardo because I didn't know
how github works (shame on me, shame! :-) ). So now I'm responding
here as well, for us to have the conversation registered here etc.
As I see it, what we have is a boundaries effect issue. When the
window overlaps the study area's boundary, part of it are occupied by
NA (or NULL?) values - missing data - and something must be done about
it. Bernardo said that the GRASS function used in LSCorridors exludes
the NULL values and calculates the summary statistics for the other
cells, but perhaps this is not happening here.
In any case, I think there are three ways of dealing with boundaries
effects in our case:
1) Do not create the corridor and provide a warning or error message:
"Corridor not created due to proximity to the map's boundaries. Try
selecting a smaller window size."
2) Calculate average, min and max values considering only the pixels
for which there is information. This will likely increase variation at
the map's edges, as uncertainty is greater when there are fewer
pixels.
3) Mirror the map inside the window: for example, if we have PASTURE
PASTURE FOREST FOREST FOREST NULL NULL NULL..., this becomes PASTURE
PASTURE FOREST FOREST FOREST FOREST FOREST FOREST PASTURE PASTURE. Not
really realistic, but may be a plausible alternative.
Another option is to wrap the map - when the eastern corner is
reached, the calculation continues from the eastern corner. Not really
realistic, but might make sense if land use patterns are stationary.
Spatial pattern analysis also sometimes uses zero-padding:
artificially replacing NULL value with zeroes, but this would make no
sense whatsoever here.
It'd be nice also if the output map could show the parts of it that
are subjected to boundary effects, as results in these areas must
always be interpreted with caution. It will probably be a small part
of the map, but perhaps not.
Best,
Pave
…On 4/12/18, Bernardo Niebuhr ***@***.***> wrote:
The user Laura Nery Silva commented on an issue dealing with corridor
simulations when the source-target (ST) points are near the edges of the
resistance map (closer than the scale parameter), when using one of the ML
methods (MLavg, MLmin, or MLmax).
She noticed that corridors for these ST points were not created, and this
may be related to what happens at the edges of the map, and to the
moving-window process to create the input resistance map for these methods.
This is just a reminder for us to take a look at that.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#6
--
-------
Pavel Dodonov
Post-doctorate fellow – Universidade Estadual de Santa Cruz – UESC
Laboratório de Ecologia Aplicada à Conservação - LEAC
Rodovia Ilhéus-Itabuna, km16 /Salobrinho, Ilhéus , Bahia, Brasil, CEP 45662-000
Skype: pdodonov1
Papers:
https://www dot researchgate dot net/profile/Pavel_Dodonov
Lattes CV: http://lattes dot cnpq dot br/9008153877455949
Linux user #624671 (via linuxcounter.net)
*"The highest function of ecology is understanding consequences." - Frank
Herbert, Dune, 1965*
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The user Laura Nery Silva commented on an issue dealing with corridor simulations when the source-target (ST) points are near the edges of the resistance map (closer than the scale parameter), when using one of the ML methods (MLavg, MLmin, or MLmax).
She noticed that corridors for these ST points were not created, and this may be related to what happens at the edges of the map, and to the moving-window process to create the input resistance map for these methods.
This is just a reminder for us to take a look at that.
The text was updated successfully, but these errors were encountered: