[Gstat-info] non-Euclidean distance functions?

[Edzer Pebesma]

That depends on the definition of your distance function. For Euclidian 
and great circle distances, this works. If distance depends on location, 
it probably doesn't.
--
Edzer

Carlos Rueda wrote:
> Thanks again Edzer,
>
> Yes, we can ignore the quadtree search mechanism for now, so our 
> point-bbox function will be 0.
>
> Regarding the norm function ||p||, I'm thinking on arbitrarily 
> choosing one of the observation locations as the origin in our space, 
> and then define ||p|| := dist(origin,p). Do you think this approach is 
> sound for the all-direction semivariogram computation?
>
> Carlos
>
>
> On Tue, Mar 18, 2008 at 1:24 AM, Edzer Pebesma 
> <edzer.pebesma at uni-muenster.de <mailto:edzer.pebesma at uni-muenster.de>> 
> wrote:
>
>     Carlos, here's a comment:
>
>     if you ignore the quadtree search structure, you can get away without
>     working point-block distance function; see the examples of
>     pb_norm_gc in
>     data.c, where great-circle distances are used without quadtrees (could
>     never figure out how/whether a quadtree on a globe works).
>     --
>     Edzer
>
>     Carlos Rueda wrote:
>     > Many thanks Edzer for your suggestions.
>     >
>     > The function pointers in the DATA structure easily allow one to
>     > register customized functions! I already have plugged in my
>     > point-to-point distance function and made a preliminary test of
>     > computing the semivariogram. However, I still need to think
>     about the
>     > vector norm and the point-bbox functions so everything is of course
>     > consistent. What happens is that I'm using a 'network distance' (ie,
>     > computed as the shortest path between the two points over a network,
>     > eg, a stream network, but ignoring flow direction for now). All
>     > pair-wise distances are pre-computed and saved in a look-up table,
>     > which is then used by the point-to-point distance function. I will
>     > continue examining the code and looking into the related math,
>     but any
>     > further comments are most welcome!
>     >
>     > Carlos
>     >
>     > On Fri, Mar 14, 2008 at 12:27 AM, Edzer Pebesma
>     > <edzer.pebesma at uni-muenster.de
>     <mailto:edzer.pebesma at uni-muenster.de>> wrote:
>     >
>     >> It can be done at the C code level only. In data.h you'll find
>     three
>     >>  functions,
>     >>
>     >>    double (*point_norm)(const DPOINT *); /* eucl. vector length */
>     >>    double (*pp_norm2)(const DPOINT *, const DPOINT *); /*
>     point-point
>     >>  squared distance */
>     >>    double (*pb_norm2)(const DPOINT *, BBOX); /* point-BBOX
>     distance:
>     >>  nsearch.c */
>     >>
>     >>  that a DATA structure needs; they are set in data.c. They are
>     used to
>     >>  compute distances. See how they're set currently; you would
>     have to
>     >>  override them with your own versions. The question of course
>     is whether
>     >>  the input arguments provide sufficient information to compute your
>     >>  distance.
>     >>
>     >>  Another option I can see is non-linearly transformating your
>     space to a
>     >>  space where you can use the Euclidian distance measure, then
>     >>  back-transforming.
>     >>  --
>     >>  Edzer
>     >>
>     >>
>     >>
>     >>  Carlos Rueda wrote:
>     >>  > Hello list,
>     >>  >
>     >>  > I'm just starting to look into gstat to see the feasibility of
>     >>  > incorporating user-defined distance functions to compute
>     models and do
>     >>  > interpolation. I already searched the gstat-info archives
>     but it seems
>     >>  > this aspect hasn't been discussed here. I'm not an expert in
>     >>  > geostatistical analysis but, according to some
>     references(*), it would
>     >>  > be sufficient that the distance function be a valid metric.
>     Is this
>     >>  > correct? If so, can anyone provide some hints regarding the
>     parts in
>     >>  > the source code that would have to be modified? (I already have
>     >>  > glanced over the code and have a preliminary approach that I can
>     >>  > discuss off-list.)
>     >>  >
>     >>  >    (*) -
>     http://www.mail-archive.com/ai-geostats@jrc.it/msg03008.html
>     >>  >         - A geostatistical approach for describing spatial
>     pattern in
>     >>  > stream networks.
>     >>  >           Ganio, Torgersen, Gresswell. Frontiers in Ecology
>     and the
>     >>  > Environment. 2005
>     >>  >
>     >>  > Thanks!
>     >>  >
>     >>  > Carlos Rueda
>     >>  > Postdoctoral Researcher
>     >>  > Center for Spatial Technologies and Remote Sensing
>     >>  > University of California, Davis
>     >>  > _______________________________________________
>     >>  > Gstat-info mailing list
>     >>  > Gstat-info at geo.uu.nl <mailto:Gstat-info at geo.uu.nl>
>     >>  > http://mailman.geo.uu.nl/mailman/listinfo/gstat-info
>     >>  >
>     >>
>     >>
>     >>
>
>