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 <[email protected]
> 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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
