r.to.vect: new flag to re-center centroids

[metzm]

r.to.vect creates centroids that are often located near boundaries and not in the center of the areas. This PR adds a new -c flag to re-calculate the position of centroids with Vect_get_point_in_area() as also used by e.g. v.in.ogr.

Red: original centroids calculated by r.to.vect, blue: re-centered centroids with r.to.vect -c

[neteler]

A question: Is re-calculating the positions of the centroids computationally intensive (say, what is the expected slow-down)? I ask because it sound that this new flag might even be(come) the default behavior.

[metzm]

A question: Is re-calculating the positions of the centroids computationally intensive (say, what is the expected slow-down)? I ask because it sound that this new flag might even be(come) the default behavior.

At least for the vector boundary_county from the NC dataset with 4173 centroids, the difference in computional time is not measurable (< 0.05 seconds). The actual vectorization should always take magnitudes more time than any recalculation of the centroids.

As a guideline on how much time calculation of centroids takes, you can have a look at the progress of v.in.ogr with a large vector, specifically the parts "Finding centroids for OGR layer ..." and "Writing centroids..."

[metzm]

There is no simple answer to the increase in computational time: for a large computational region and few areas, the increase will not be noticeable. For a small computational region and many areas, there might be some increase in computational time, but that should not be more than 10% longer, rather 1 - 5% percent longer.