[Soc] GRASS module for kriging - call for users [was: R-sig-Geo Digest, Vol 69, Issue 21]
Ebrahim Jahanshiri wrote:
for kriging a preliminary analysis is important. We should know if the data has trend or how are the ouliers? should we remove them or not. Some of the kriging techniques like universal kriging create very odd values at some points if we dont deal with the data frist hand before kriging. I hope that we can come up with the software that does all this by itselft ( some sort of decision maker like AI). I hope to see this kind of sotware pretty soon and I wish it be open source.
I agree that this would be nice. We discussed this issue quite lengthy in the intamap consortium (see http://www.intamap.org/ , and the wiki as well -- also interesting for the SoC project). We concluded that for a generic automatic interpolation algorithm users don't want this to be done automatically, because no automatic algorithm can decide whether an outlier indicates a measurement error or a disaster. Remember the ozone layer was overlooked for many years because an automatic "outlier" algorithm was built in the data processing chain. Only if your application is domain specific you can do something useful, e.g. use physical limits -- soil moisture content can never exceed 100%; content variables need to be non-negative. Of course you can add options, and build optional outlier filters. Then, how should outliers be marked? Is there any agreement on this? What would be the defaults for necessary parameters? Automatic trend detection is another issue that is very interesting.
On Mon, May 25, 2009 at 6:42 PM, Edzer Pebesma < edzer.pebesma at uni-muenster.de> wrote:
I believe that many interpolation problems "out there" are simple, and
can be solved using geostatistics with a "finish" or "interpolate"
button. A question I find interesting is whether this button should
always do its best, or should it be so clever to warn the user in case a
problem is not "that simple", and what the criteria are for this.
Of course this SoC project is about an "interpolate" button using open
source software, so the user is always able to find out every detail
behind it. But will she or he actually do this in a non-simple case?
As of your claim that no two geostatistical packages provide the same
result, as a more optimistic person I'd like to provide some
counter-evidence; please run:
require(gstat)
require(geoR)
xyz = data.frame(x = c(0,0,1), y = c(0, 1, 1), z = c(1,2,3))
coordinates(xyz)=~x+y
x0 = SpatialPoints(data.frame(x=0,y=.5))
kr1 = krige(z~1,xyz,x0,vgm(1, "Exp", 1))
kr2 = krige.conv(as.geodata(xyz), locations=coordinates(x0),
krige=list(cov.model="exponential", cov.par=c(1,1)))
kr1
c(kr2$predict, kr2$krige.var)
kr1[[1]] - kr2$predict
kr1[[2]] - kr2$krige.var
I'd be more than happy if someone could repeat this, or another example,
with ArcGIS or other software, of course.
--
Edzer
Ebrahim Jahanshiri wrote:
Dear Ann,
I think having a "finish" button is the ulitimate thing that all of us
looking for in a software!. Unfourtunately it is not possible. There are
far
too many issues regarding a good kriging operation that prevents you from
trusting a nice package like "Geostatistical Analyst" in ArcGIS. The
evidence is that you cant find two geostatistical package that their
resutl
is the same (I know this is a big statement but I have seen this for a
couple of softwares!). I cant say the surface that is generated by ArcGIS
is
not accurate but it bothers me to not know what happens beneath the
program
when it fits the variogram and calculates the matrices for kriging and
more
importantly a "routine" that you mentioned will not work for all the
data.
So personaly I will go for the chors of GeoR or Gstat instead of using
the
ArcGIS. Though it is not complete and I have to admit that I have a lot
of
problem adapting to it.
Ebrahim
On Sun, May 24, 2009 at 1:59 AM, Anne Ghisla Insubriae <
a.ghisla at studenti.uninsubria.it> wrote:
Ebrahim Jahanshiri a ?crit:
Dear Anne,
Ebrahim,
Thanks for the enquiry. I think we should have done this long before.
I
havent done any geostatistics with GRASS but I did alot in ArcGIS and
also
in R (variography). I have to tell you that ArcGIS is for those who
want
to
have a surface only by just clicking on "finish" button trought its
powerfull interface. That is, it does not provide a good scientific
backgroud for you to check the procedure. for example how it fitted
the
variogram model or how exactly it does the "validation". That is why
the
"Geostatistical package" objects or classes are not available for the
programmers to program with (there is a kriging in "Spatial analyst"
package
though that its object is programmable and I personally did some with
it.
but it lacks the variogram modeling). I think they are still working
on
it.
In short I dont recommend ArcGIS for the so called scientific kriging.
I was afraid of this. Therefore I guess an interface with too many
mandatory options would be considered overcomplicated.
There should be as more options as needed for a flexible calculations,
and also proper defaults to clik on Ok and get an acceptable result.
What do you think about this solution?
In
the other hand R is very powerfull in that it gives you freedom to do
your
own style through coding. I worked with "GeoR" pakcage and it is
pretty
nice
both in terms of variography and kriging. There are other package like
"Gstat" that I havent worked with but have good qualities. GeoR
implements
the so called "model based geostatistics" which is the application of
bayesian statististics to the geostistics I guess and it is quite new.
I'm presently having a look at both geoR and gstat, and also the wrapper
package automap.
I guess that the first users of the new module would be already familiar
with R and GRASS, so their feedback about most used functions is very
important.
I hope these comments were helpful and please let me know if you need
any
further explanation from me,
Very helpful, thank you very much!
Ebrahim
best regards,
Anne
------------------------------------------------------------------------
_______________________________________________ R-sig-Geo mailing list R-sig-Geo at stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo
-- Edzer Pebesma Institute for Geoinformatics (ifgi), University of M?nster Weseler Stra?e 253, 48151 M?nster, Germany. Phone: +49 251 8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de/ http://www.springer.com/978-0-387-78170-9 e.pebesma at wwu.de
Edzer Pebesma Institute for Geoinformatics (ifgi), University of M?nster Weseler Stra?e 253, 48151 M?nster, Germany. Phone: +49 251 8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de/ http://www.springer.com/978-0-387-78170-9 e.pebesma at wwu.de