[GRASS5] Re: [caj78500@pop16.odn.ne.jp: Bugreport GRASS 5]

Radim Blazek Radim.Blazek at dhv.cz
Sun Oct 29 11:13:52 EST 2000


> Hi David, hi all
> 
> [I switch to the devel list]
> 
> On Fri, Oct 27, 2000 at 03:02:26PM +0000, David D Gray wrote:
> > Hi Markus
> > 
> > This seems to be a `snap' problem. I've seen the same thing myself.
> > Occasional grid cells don't show correct topology when using v.mkgrid. I
> > think it must be because of micro-misalignments during the build
> > process. A very small snap coefficient has always fixed it. You can't
> > call this a feature, so it is probably a bug. But it is very difficult
> > to secure exact coincidence of points without using tolerance limits of
> > some kind (impossible - if different platforms have different fp
> > behaviour). So the answer is probably to create a default snap radius of
> > a very small amount, say 10e-6 * <ground resolution> (what do you think
> > of this scale in general mapping terms - could it be a problem?), in
> > v.support, though it would still be possible to over-ride it with
> > threshold=0.
> ..mhhh, difficult question. I always hesitate to have auto-correction
> oof data, but in this case it seems to be required. The question is
> what is the smallest usable value for <factor> * <ground resolution>:
> Would 10e-9 do as well?
> 
> How to other GIS packages fix such a problem (they will have it, too).
> 
> > At some point we need to thoroughly overhaul v.build. This is now the
> > commonest source of problems. I don't think there's anything
> > release-critical that can't be worked around - as here.
> 
> Other developers, what's your recommendation/experience?
> 
> Kind regards
>  
>  Markus
> 

I agree that it is bug but in v.mkgrid and not in v.build. (I don't say v.build doesn't have any bug.)
v.mkgrid calculates x once as:

x_len = length/3.; 
x_cols = cols*3.;
for (){
  next_x = x + x_len;
}
and then:
for(){
  x += length;
}

It is obvious that lines are not connected.

I am strongly against possible building areas from dirty data. It could have some dangerous
consequences:
- data built and displayed correctly in GRASS exported to some other SW will not work.
- we could not rely on areas in GRASS at all. For example analysis between point and areas
   could find no area or more areas for points near dirty connections:
                 |                                                  Legend:   
  area1       |       area2                                    -- boundary
                                                                     +    point 
------    +    --------                               |<----->|   snapping tolerance
 
  area3       |       area4
                 |

Areas would be built correctly but point is outside. You could see point in
place correctly covered by areas on monitor.



Radim








---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list