1

The documentation for v.clean in GRASS 7 says of tool rmarea (which absorbs polygons below a certain area into a larger neighbour):

Threshold must always be in square meters, also for latitude-longitude
locations or locations with units other than meters.

I have a location in EPSG:4283 (GDA94). Running v.clean with the rmarea option prints the following warning to the console:

Note: In latitude-longitude coordinate system specify threshold in degree
unit

These warnings contradict each other. Which is correct? I've been getting the same results on my test dataset using threshold 2500 (assuming square meters) and threshold 0.00000025 (assuming 'square decimal degrees' which I know is dodgy). In both cases, small polygons do disappear, but so do a number of larger ones that shouldn't be caught by either threshold.

edit:

I've traced back through the source code: vector/v.clean/main.c line 438 calls Vect_remove_small_areas, which lives in lib/vector/vlib/remove_areas.c. For a native GRASS-format dataset that uses Vect_remove_small_areas_nat, which on line 240 calls Vect_get_area_area, which lives in lib/vector/vlib/area.c. That function in turn uses G_area_of_polygon, which lives in lib/gis/area.c. That in turn calls G_ellipsoid_polygon_area for lat-long data. That function is in lib/gis/area_poly1.c and does the actual calculation (cripes!).

The documentation for that last function indicates that a threshold in meters is fine. This means my real question is why v.clean is removing polygons that it shouldn't. All I could think of is that some vertices might be too close together for the math in G_ellipsoid_polygon_area to work, as there are comments in the code referencing that as an issue. I can't see any obvious candidates in my data, though. Are there any other possible confounding factors I'm missing?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.