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?
If not, then the C version of r.buffer still has an important advantage
and should stay.
> > 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.
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?
> > > 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.
> 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?
