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

GRASS GRASS developer
1

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
of 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

Markus Neteler wrote:
>
> Hi David,
>
> may I bother you again with a vector problem? You
> are the specialist... :slight_smile:
>
> Hope you don't mind,
> many thanks in advance
>
> Markus
>
> ------------------------------------------------------------------------
>
> Subject: Bugreport GRASS 5
> Date: Fri, 27 Oct 2000 04:13:38 +0100
> From: caj78500@pop16.odn.ne.jp ()
> To: neteler@geog.uni-hannover.de
>
> Below is the result of your feedback form. It was submitted by
> (caj78500@pop16.odn.ne.jp) on Friday, October 27, 2000 at 04:13:38
> ---------------------------------------------------------------------------
>
> subject: Bugreport GRASS 5
>
> platform: Linux/Intel
>
> vendor: RedHat
>
> cputype: Intel (i486, i586, pentium ...)
>
> grassversion: I compiled the sources myself
>
> cvsyesno: no, I got a source code package from the server
>
> source_version: 5beta8
>
> module: v.mkgrid, v.support
>
> bugreport: I am working with etopo5 sample dataset, and have a problem
> in the follwing operation.
>
> -----------------------------------------------------------
> Mapset <TEST> in Location <etopo5>
> GRASS 5.0beta8 > v.mkgrid map=aaa grid=1,1 coordinate=135,38 box=1,1 angle=0 type=const value=1
>
> Creating vector header...
> Creating vector grid...
> Writing out vector rows...
> Writing out vector columns...
> Finished
>
> Mapset <TEST> in Location <etopo5>
> GRASS 5.0beta8 > v.support option=build map=aaa
>
> V.SUPPORT:
>
> Selected information from vector header
> Organization: US Army Const. Eng. Rsch. Lab
> Map Name:
> Source Date:
> Orig. Scale: 0
> No snapping will be done
>
> Reading Vector file.
> 100%
> Building areas
> Building islands
> Attaching labels
> PNT_TO_AREA failed: (135.500000, 38.500000) (Category 1)
> Number of lines: 8
> Number of nodes: 10
> Number of areas: 0
> Number of isles: 0
> Number of atts : 0
> Number of unattached atts : 1
> Snapped lines : 0
> -----------------------------------------------------------
>
> Please help me to solve this "PNT_TO_AREA failed" problem.
> What does influence v.support. I want to add attributes to
> the grids automatically without v.digit. Using this "PNT_TO_AREA
> failed" map as the cutter file, v.cutter fails to extruct
> the vector objects from the vector map.
>
> Thanks in advance.
>
> -- caj78500
>
> compiler: gcc
>
> name: caj78500
>
> ---------------------------------------------------------------------------
>
> REMOTE_HOST: ige.mi.mss.co.jp

--
Dipl.-Geogr. Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

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

2

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@geog.uni-hannover.de with
subject 'unsubscribe grass5'