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

[Markus Metz]

On Wed, Apr 10, 2013 at 2:58 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> 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..

This is up to the user to decide. Snapping is optional and disabled by default.
>
> If small changes to coordinates break the topology, the topology was
> broken to start with.

Here I am considering cases where topology was broken in the
beginning, before GRASS starts its cleaning procedures.
>
> 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).

Exactly this happens during polygon import.

> Similiarly, extremely thin polygons (where the area divided by
> the length of the longest edge is very small) should be a warning
> sign.

That could be implemented as an additional cleaning procedure.

Regarding a reasonable snapping threshold, I noticed that sometimes
using the ULP rounding error for double precision is enough for
cleaning. Sometimes not. Generally, the history of vectors to be
imported is unknown, thus also any potential causes for topological
errors. Without this knowledge, v.in.ogr could only suggest a minimum
threshold using the ULP rounding error for double precision, smaller
values don't make sense IIUC.

Markus M