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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
