[GRASS-dev] Re: r.walk, r.cost & r.drain patches posted

[Michael Barton]

I'd first say that probably a) or c) is the best. But b) is  
intriguing, however. Thinking about it, it's not all that specific. It  
currently handles several different kinds of rasters, blocks of cells,  
scattered individual cells, and linear arrays of cells. This woulc  
simply be adding another kind of raster configuration to read from.

Michael
______________________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 14, 2009, at 10:36 AM, Colin Nielsen wrote:

> I agree that since vectorization is needed, something built-in is
> required. I think it would require one of the following:
>
> a) borrow sections of code from r.to.vect to add a new section to
> r.drain (not optimal since it's duplicating code)
>
> b) alter r.to.vect to include a "-k knight's move input" flag and
> ability to read a this type of path (with converging or nearly
> parallel paths I can see the errors already)... on second though
> having r.to.vect read the direction raster would be less error prone
> than reading the path since by definition the paths are already
> connected. But this isn't optimal either since it's adding very
> specific functionality to a module meant for generic functionality.
>
> c) have r.drain generate an ascii file to be read back in by
> v.in.ascii which could be called by r.drain itself (probably the
> easiest solution, but not particularly eloquent).
>
> Other ideas? Suggestions?
>
> -Colin
>
> On Mon, Jan 12, 2009 at 4:49 PM, Michael Barton <michael.barton at asu.edu 
> > wrote:
>> Maybe what is needed is a built in vectorization algorithm that will
>> transform the paths to vectors is a flag is set.
>>
>> Michael
>> ____________________
>> C. Michael Barton, Professor of Anthropology
>> Director of Graduate Studies
>> School of Human Evolution & Social Change
>> Center for Social Dynamics & Complexity
>> Arizona State University
>>
>> Phone: 480-965-6262
>> Fax: 480-965-7671
>> www: <www.public.asu.edu/~cmbarton>
>>
>>
>>
>> On Jan 7, 2009, at 9:32 AM, Colin Nielsen wrote:
>>
>>>> Thanks for the updates. I'll give them a try. While I understand  
>>>> the
>>>> reason
>>>> for the gaps in the paths now, I think that it is important to  
>>>> find some
>>>> way
>>>> to get rid of them. That is, there needs to be some algorithm  
>>>> that will
>>>> 'connect the dots' of knights move jumps.
>>>
>>> I certainly agree but it should be done without adding cells in
>>> between. The knight's moves should be retained in the output. We  
>>> need
>>> some kind of vectorization algorithm which connects cell center to
>>> cell center, or which joins all the little line segments that  
>>> would be
>>> produced by a discontinuous path.
>>>
>>>> Even without vectorizing, the cell accumulation
>>>> values will be inaccurate if cells are skipped in a path from  
>>>> point A to
>>>> point B.
>>>
>>> The algorithm accounts for the accumulation value in these larger
>>> jumps using pythagoras. Just as diagonals are multiplied by ~1.4,
>>> knight's move jumps are multiplied by ~2.2 (but depending on the
>>> resolution, etc.).
>>>
>>> -Colin
>>
>>