[GRASS-dev] r34409: Replace r.buffer with a script using r.grow.distance

[Hamish]

H:
> > why add metric=geodesic for lat/lon instead of automatically switching
> > to geodesic distance if the location is LL? adherence to strict
> > definition of "euclidean"? is there another word that would cover both?
> > Eucl. dist in lat/lon doesn't really make any sense to me.
> 
> Does it "make sense" to use anything other than metric=geodesic in any
> location (aside from the fact that it is currently only supported in
> lat/lon)?

grid euclidean distance * scale factor for geodeTic distance at least has
some approximation to the "true" geodeSic distance, much more than treating
degrees lat the same as deg long for trig calcs.
see recent threads on the proj4 ML + collected summary in
  http://trac.osgeo.org/proj/wiki/GeodesicCalculations

> If it's going to permit e.g. metric=manhattan in lat/lon, why not
> metric=euclidean?

I guess metric=manhattan doesn't make much sense either, but not knowing
when that is useful in general, I pause to comment.

 
> It may be worth adding e.g. metric=default, which is
> equivalent to geodesic in lat/lon and euclidean elsewhere.

how about "metric=shortest" with an explanation in the man page and/or
opt->descriptions (with an s$) entry explaining that it'll use one method
in lat/lon and other in a grid proj?


Hamish