[GRASS-dev] Re: [GRASS-user] v.clean tool=prune - 'thresh' interpreted wrong?
dylan.beaudette at gmail.com
Tue Oct 3 14:04:44 EDT 2006
On Tuesday 03 October 2006 09:35, Markus Neteler wrote:
> Moritz Lennert wrote on 10/03/2006 06:26 PM:
> > Maciej Sieczka wrote:
> >> Moritz Lennert wrote:
> >>> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/vector/diglib/prune.c
> >>> There is an explanation of the algorithm at the beginning.
> >> Thanks, I should have looked into the source code first. My only (poor)
> >> excuse is being a non-programmer and "mentally handicapped" due to my
> >> disgraceful pre-Linux/FOSS times ;).
> >> Moritz suggested that maybe "the threshold only applies in cases of
> >> change of direction (i.e. angles)". Please note there is no any
> >> reference to angles or direction in the code or comments. It seems the
> >> threshold refers to distance only.
> >> There is a following comment:
> >> * thresh - the distance that a string must wander from a straight
> >> * line before another point is selected.
> >> As I understand it, this means that if my vertcices are on a straight
> >> line, at intervals of 10, only a thresh of 10 or more should prune
> >> them. But, as you can see in my original example, any thresh>=0.03
> >> prunes them. Do I missunderstand sthing (I'm not sure what the
> >> "straight line" means here)?
> >> So we have 2 possibilities:
> >> 1. If in opposite to my interpretation of the source and manual,
> >> angles/directions DO have something to do with the pruning thresh,
> >> please somebody knowledgeable tell me what is that relation, so I can
> >> fix the part of the manual, that reads "prune: remove vertices in
> >> threshold from lines (...)".
> >> 2. If the pruning thresh doesn't depend on angles/directions, how do I
> >> understand the fact that any thresh>=0.03 prunes points which are at
> >> intervals of 10 on a straight line?
> > To plead in Markus' direction: there is a 3rd possibility:
> > 3. Forget about the current pruning implementation and push the
> > integration of another algorithm (Douglas-Peucker). (I know you are
> > working on a script, but could this wait until this is done ? Maybe if
> > you push hard enough someone will "just do it" - Dylan mentioned it as
> > a potentially "fun" project:
> > http://grass.itc.it/pipermail/grassuser/2006-August/035529.html ;-)
> > and actually links to an implementation in c++, which actually looks
> > like more or less usable C to me).
> > Markus you mentioned the source code on the GMT site. Could you be
> > more precise on where to find it ?
> -> gshhs_1.5_src.tbz
> -> gshhs/gshhs_dp.c
Now that doesn't look like to difficult a snippet of code to port to GRASS.
Only issue would be to make it less dependent on input being in lat/long :
int Douglas_Peucker_i (int x_source, int y_source, int n_source, double
band, int index)
/* x_source: Input coordinates in micro-degrees */
/* y_source: */
/* n_source: Number of points */
/* band: tolerance in kilometers */
/* index: output co-ordinates indices */
then adapting it to GRASS data types / structs
Soils and Biogeochemistry Graduate Group
University of California at Davis
More information about the grass-user