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

[Glynn Clements]

Hamish wrote:

> > > > re. r34409: Replace r.buffer with a script using r.grow.distance
> > > > 
> > > > I am wondering, does r.grow.distance do the right thing in Lat/Lon?
> G:
> > > No.
> > > 
> > > I'll look into adding metric=geodesic, but I'm not entirely certain
> > > that it's compatible with the algorithm.
> > 
> > Done, and modified the r.buffer script to use it.
> 
> 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)?

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

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

> if (strcmp(opt.met->answer, "euclidean") == 0) {
>   if (window.proj == PROJECTION_LL)
>        G_fatal_error(_("metric=euclidean is not valid for lat/lon"));
>   ...
> ?
> 
> 
> > The results appear to be identical to the C version.
> 
> good stuff. any reason to keep the C version then?

For metric=geodesic, the C version is significantly faster (at least
for simple test cases), although it requires reading the entire map
into memory.

It should be possible to optimise the metric=geodesic case to perform
fewer calls to G_geodesic_distance(), although it wouldn't be trivial.

-- 
Glynn Clements <glynn at gclements.plus.com>