On 24/09/11 02:32, tkdweber wrote:> Dear Community
>
> I am at my wits end and seek advice.
> My wish is to plot coordinates (x,y in WGS84_UMTS for the ones interested)
> of sampling points.
> This I can do by the standard spatstat prodcedure via owin.
You appear to be rather confused from the very start.
The function owin() does not *plot* anything; it is used to
create an *observation window* for a spatial point pattern.
In spatstat every spatial point pattern object must include
such a window.> I then try to
> add an image, which is
> a map/satellite photo in the background.
You would probably do better by plotting the image first
and then adding the points on top of the image. In general,
in my experience, plotting an image on top of points obscures
the points (hides them completely).
To avoid this you have to mess around with the value of ``alpha''
somehow, and the game is not worth the candle.> Firstly
> Problem: With the current code, I can not get the edges of the image to
> match the boarders of the plot
> itself (not the entire plot window, solely the coordinate system)
> The size of the image I have (from GPS work)
I have absolutely no idea what you are asking here.> Any ideas?
>
> Secondly, I am confused of how to get coordinates into an owin plot. It
> doesnt want to work.
Likewise. This is far too vague for me (or anyone else) to be able
to give a reasonable answer.> Thirdly, is with spatstat only always one mark possible? Or can I
> differentiate further?
I am again not sure what you are asking here, but I think
the answer is ``No.'' That is, more than one mark is
``possible''.
The marks component of a spatial point pattern (an object of
class "ppp") can be a *data frame*. See ?ppp.
Currently the tools available in spatstat don't do much with data
frame marks, but such mark structures are allowed, and you can
write your own code to deal with such structures in any manner
you wish.> Code, for reference purposes
> ~~~~~~~~~~~~~~~~ CODE ~~~~~~~~~~~~~~
> data data = read.xls("name.xls")
>
> x1=floor(min( data[,2],na.rm=T )*(1-b))
> x2=ceiling(max(data[,2],na.rm=T )*(1+b))
> y1=floor(min(data[,3],na.rm=T )*(1-c))
> y2=ceiling(max(data[,3],na.rm=T )*(1+c))
> x1
> x2
> y1
> y2
What (WTF) are b and c???> w = owin(c(x1,x2),c(y1,y2))
> w
> dat1 = as.ppp(data[,2:4],w)
> is.ppp(dat1)
> str(dat1)
>
> #Get the plot information so the image will fill the plot box, and draw it
> ima = readPNG("file.png")
> lim = par()
> rasterImage(ima, lim$usr[1], lim$usr[3], lim$usr[2], lim$usr[4])
> par(new=T)
>
> plot(dat1, use.marks=T)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This code is not really much use to anyone since we don't have
access to "name.xls" or "file.png". (Or, as indicated
above, to
the values of "b" and "c".)
Read the posting guide. Examples given should be that ``people
can actually run.''> Thank you for any advice.
I don't have any experience with readPNG() (*from the png package*,
which
you might have mentioned!) nor with rasterImage().
However, after some thrashing around and experimenting with a toy
example
I have come to the conclusion that the problem arises from the fact
that
readPNG() creates a large border of white space around the image.
To fix this, I cobbled together the function:
raster2im <- function (A,xrange,yrange) {
B <- apply(A,c(1,2),function(x){rgb(x[1],x[2],x[3])})
B <- B[nrow(B):1,]
suppressWarnings({
i1 <-
min(apply(B,2,function(x){min(which(x!="#FFFFFF"))}))
i2 <-
max(apply(B,2,function(x){max(which(x!="#FFFFFF"))}))
j1 <-
min(apply(B,1,function(x){min(which(x!="#FFFFFF"))}))
j2 <-
max(apply(B,1,function(x){max(which(x!="#FFFFFF"))}))
})
C <- B[i1:i2,j1:j2]
im(C,xrange=xrange,yrange=yrange)
}
I suggest that you try something like the following:
require(spatstat)
require(png)
require(gdata)
data <- read.xls("name.xls")
X <- as.ppp(data[,2:3],window=ripras(data[,2:3],shape="rectangle"))
R <- readPNG("file.png")
IM <- raster2im(R,xrange=X$window$xrange,yrange=X$window$yrange)
plot(IM,valuesAreColours=TRUE)
plot(X,add=TRUE)
Note that raster2im() strips away any white edges from an image. If you
actually *want* this ``white space'' (or part of it) you'll have to
do
something
else.
cheers,
Rolf Turner