On Sun, 26 Apr 2009, Edzer Pebesma wrote:
Jarek has sent me the data off-line, and it turns out that the data are
three-dimensional, but lack variability in the third dimension:
This smells like an installed GRASS/OGR plugin, which if autodetected
generates a spurious third coordinate (probably to match ESRIs usual
idiocies?). I added an argument to turn this off in spgrass6 CVS last week
(and corresponding pass-through to rgdal on CVS). So if Jarek updates to
latest spgrass6 and rgdal from CVS (different sourceforge projects), it
should help, or do readVECT6(..., plugin=FALSE).
Doing summary(p) would reveal the problem.
Roger
summary(p)
Object of class SpatialPointsDataFrame
Coordinates:
min max
coords.x1 3560158 3575935
coords.x2 5636873 5653748
coords.x3 0 0
Is projected: TRUE
proj4string :
[+proj=stere +lat_0=51.67083333333333 +lon_0=16.67222222222222
+k=0.999800 +x_0=3703000 +y_0=5627000 +no_defs +a=6378245 +rf=298.3
+towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +to_meter=1]
Number of points: 200
Data attributes:
...
Using the "degree=1" way of trend analysis, a first order linear trend
is computed in the coordinates, meaning in z as well, and this is the
cause of failure. Ignoring z, one can e.g. do
p$x=coordinates(p)[,1]
p$y=coordinates(p)[,2]
r$x=coordinates(r)[,1]
r$y=coordinates(r)[,2]
pg=gstat(id="p_1", formula=rzedna~x+y,data=p)
p_1=predict(pg,r)
spplot(p_1)
of course, no standardization of coordinates takes place here, so this
approach will fail for high order trends.
--
Edzer
Jarek Jasiewicz wrote:
Edzer Pebesma pisze:
Jarek Jasiewicz wrote:
Hi
during trend calculation I recive following error:
R
library(spgrass6)
library(gstat)
raster=readRAST6("rzedna")
p=readVECT6("punkty")
p...@proj4string=raster@proj4string
pg_1=gstat(id="p_1", formula=rzedna~1,data=p, degree=1)
p_1=predict(pg_1,raster)
[ordinary or weighted least squares prediction]
"solve.c", line 87: singular matrix in function Usolve()
Error in predict.gstat(pg_1, raster) : Usolve
There are several situations why this can happen that are hard to
distinguish from the point where the error happens. The most likely in
your case (first order trend surface estimation) is that your data are,
geographically, on a line, i.e. one-dimensionally. Or similary, that you
have less than 3 observations. Is that the case?
--
Edzer
Thanks for answer, but none of that case. Tt is regular data file
with 200 random observations generated with v.random in GRASS and
stored as SpatialPointDataFrame.
before I posted to the list I had tried to reproduce it on my
archive data with archive scripts (which worked in older R
compilation) and it ALWAYS fail (on every data I tested).
In general, the possible problem on my side coud be that I
(experientally) installed R from CRAN ubuntu repository instead to
compile from source. The ubuntu CRAN-R packages do not include lapack.
This is the only difference I noticed.
If you need I can send you sample R file (is small, no more than 2MB)
Jarek
my system information:
Ubuntu 8.04
R 2.8.1
gstat 0.9.59
the error have appeared first time on gstat 0.9.49
Errors apears on all my data, even these, where trend was calculated
some times ago. Commads coming from old data
The error is also reproducible on spearfish dataset with elevation.dem
and random points generated by v.random
Jarek
_______________________________________________
grass-stats mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-stats
_______________________________________________
grass-stats mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-stats
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [email protected]
_______________________________________________
grass-stats mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-stats
