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

Hamish hamish_b at yahoo.com
Tue Apr 9 13:37:41 PDT 2013


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

> v.in.ogr can not fix errors introduced by cartographic
> projections or datum transformations.

Maybe some tiny 3D changes come in from small dz difference
converting datums from e.g. grs80 to wgs84 ellipsoids?

I'm not saying it's a bad idea to allow an extra import filter,
just that be careful to avoid automatically "fixing" data for
cases that don't ask for it / happen to look bad but are
actually not.

can you provide an example of what the numbers you are seeing
look like?


Hamish


More information about the grass-dev mailing list