[GRASS-dev] grass-dev Digest, Vol 180, Issue 22

[Michael Barton]

Denis,

Thanks for the detailed response. From the sound of it, and from some other responses, the multi-res arguments should probably be removed or commented out until they actually work and are documented.

Also, I'm not sure what is the best to call the ratio of the geomorphon polygon and a maximum search circle. Perhaps relative extent or relative coverage. But it is not "extend". That is the wrong English word for this.

I'll make an issue so that this can be easier to deal with.

Michael
_____________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Director, Network for Computational Modeling in Social & Ecological Sciences
Associate Director, School of Complex Adaptive Systems
Professor, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://shesc.asu.edu, https://complexity.asu.edu, http://www.public.asu.edu/~cmbarton

On Feb 16, 2021, at 7:36 AM, grass-dev-request at lists.osgeo.org<mailto:grass-dev-request at lists.osgeo.org> wrote:

Date: Tue, 16 Feb 2021 02:56:48 +0000
From: Denis Ovsienko <denis at ovsienko.info<mailto:denis at ovsienko.info>>
To: grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>
Subject: Re: [GRASS-dev] r.geomorphon multiresolution mode
Message-ID: <20210216025648.6b98d46d at basepc>
Content-Type: text/plain; charset=US-ASCII

On Mon, 15 Feb 2021 22:23:09 +0000
Michael Barton <Michael.Barton at asu.edu<mailto:Michael.Barton at asu.edu>> wrote:

Can anyone explain how multiresolution model works in r.geomorphon?
It does not seem to respond to any setting changes and seems to
always produce blank maps (testing with NC demo set). There is
nothing about multiresolution mode in the manual for 7.8 or 7.9

Hello Michael.

I had applied a few rounds of cleanups and improvements to this
plugin, one of which was directly related to multires (see commit
867ff057b). Other than that, I didn't study multires closely, but
managed to notice earlier that start_distance and step_distance (which
are derived from the command-line arguments) are never used in the main
multires branch, which also overrides the value of num_of_steps with a
hard-coded value of 5, but I had more pressing problems to solve in the
non-multires branch of main() at the time.

Having looked through the multires branch again just now, it does not
look right that after the call to calc_pattern() the code does not have
a call to determine_form(), the output of which ought to go into
multiple_output[i].forms_buffer before Rast_put_row() stores it. That
would explain why you have blank outputs. That said, I still do not
understand the intended difference between the multiple output rasters.

Also, I think there is a typo in the manual and arguments. I think
that what is meant is the word "extent" (a noun for area) rather than
"extend" (a verb to make larger). I can make an issue for this typo
if helpful.

If you take the 8 cardinal points of a geomorphon without the
elevations, the plane figure will be an octagon (a degenerate one when
more than two cardinal points end up in the centre). In any case, it
will always be a so called simple polygon, let's call its area S1.

If you take a fixed search radius, draw a circle and intersect it with
the 8 cardinal directions (in other word, if you consider the regular
convex case of the above figure), its maximum possible area (let's call
it S2) will be a function of the search radius.

So what is currently known as the "extend" output of r.geomorphon is
S1/S2, hence its value belongs to the [0.0, 1.0] interval. I agree this
might be not the right term, although I am not sure what would be the
most appropriate geometric term in English. For what it is worth, the
function that computes S1 is currently called "extends()", and both the
G_parser props and the HTML document currently give an incorrect
description of what the "extend" output produces, so that would be best
made consistent in the same go.

There are some other long-standing imperfections in both the C code and
the HTML documentation of r.geomorphon, if you have time now to work on
these, I could suggest a few points. That said, it would be nice not to
re-jig r.geomorphon in substantial ways right now, because it is
serving as a foundation for Geomorphon Profiler, and I am busy
finishing another layer of software on top of these two, so a student
can finally get their thesis done.

--
   Denis Ovsienko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20210217/433b7f67/attachment-0001.html>