[GRASS-dev] r.in.gdal fp precision loss

[Glynn Clements]

Hamish wrote:

> Markus Metz wrote:
> > Yes, but I would like to suggest a method to fix at least
> > floating-point rounding errors, wherever they come from.
> 
> a bit of a devil's advocate question: how could you ensure that
> in all cases they were really errors and not real? e.g. sometimes
> adding small noise to your data on purpose for sensitivity
> analysis..

If small changes to coordinates break the topology, the topology was
broken to start with.

Consider the following:

             A
             *
            /|\
           / | \
          /  |  \
        D*---*E  *B
          \  |  /
           \ | /
            \|/
             *
             C

If the topology consists of regions ABC, AED, and DEC (i.e. E doesn't
form part of the boundary of ABC), there's a zero-area hole ACE in the
middle. Small changes to the position of E may result in AED and DEC
overlapping ABC (and ACE having a negative area).

OTOH, if the topology is ABCE, AED, and DEC, the three regions form a
tessellation of the region ABCD. Moving the vertices won't affect the
topology unless the movements are enough to turn regions inside-out.

While I wouldn't be surprised if GRASS has to deal with this kind of
data, I'd hope that it doesn't generate it. E.g. "snapping" a vertex
to an edge should break the edge at that vertex (e.g. in the above,
snapping E to CA should break CA into CE and EA and delete any region
ACE). Similiarly, extremely thin polygons (where the area divided by
the length of the longest edge is very small) should be a warning
sign.

Or maybe I'm just misunderstanding what the issue is here.

-- 
Glynn Clements <glynn at gclements.plus.com>