[Gstat-info] non-Euclidean distance functions?

Carlos Rueda carueda at ucdavis.edu
Wed Mar 19 20:13:00 CET 2008


Edzer,
Distance doesn't depend on location in our case: distance is defined as the
minimum travel distance between the two locations over the network, so it
satisfies the conditions for a metric. However, I found that the metric
condition is in general not sufficient to get valid variograms; see eg.,

http://www.bepress.com/cgi/viewcontent.cgi?article=1094&context=jhubiostat

http://www.blackwell-synergy.com/doi/abs/10.1111/j.1365-2427.2006.01686.x
So, our next step will be to examine our distance metric in terms of the
necessary conditions.

Carlos

On Wed, Mar 19, 2008 at 2:06 AM, Edzer Pebesma <
edzer.pebesma at uni-muenster.de> wrote:

> 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
> >     >>  >
> >     >>
> >     >>
> >     >>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.geo.uu.nl/pipermail/gstat-info/attachments/20080319/e45de43d/attachment.html


More information about the Gstat-info mailing list