search

pachterlab / voyager

From geospatial to spatial -omics
https://pachterlab.github.io/voyager/
Artistic License 2.0
79 stars 9 forks source link

Question re: running local moran I with different graph types / spot dropout #40

Closed spcdot closed 2 days ago

spcdot commented 3 days ago

Hi,

I've been running Voyager with some spatial ATAC datasets I have kicking around and it works great for the most part. I have been largely generating tri2nb-based graphs and using these for Moran I and it works great for most of my samples. However, in some samples I have areas which did not pass QC causing small holes or defects in the middle of my sample. I find I tend to get artifactual autocorrelation around these regions because of missing data / spurious connections in the neighbourhood graph. I have tried running the analyses using a dnearneigh type graph (which looks better visually and lacks spurious edge / hole neighbours), however, it will crash out because it can't handle spots that don't contain neighbours. Another option I thought about was data imputation for low-quality/high-sparsity spots to reduce zeros, but I typically try to avoid data imputation when I can. Any suggestions would be appreciated!

The message I get is as follows:

Error in cut.default(lx, c(-Inf, lxx, Inf), labels = lbs): number of intervals and length of 'labels' differ In addition: Warning messages: 1: In lag.listw(listw, z, zero.policy = zero.policy, NAOK = NAOK) : NAs in lagged values 2: In lag.listw(listw, x, zero.policy = zero.policy, NAOK = NAOK) : NAs in lagged values

Thanks,

Ana

lambdamoses commented 3 days ago

What's your zero.policy? It will give you a warning if it's NA and error if FALSE when there are singletons that don't have neighbors, resulting into NA in lagged values. You can also check if there are singletons with code like this but use the name you gave to the graph of interest instead:

library(spdep)
degs <- card(colGraph(sfe, "tri2nb")
summary(degs)

That should give the degrees of each graph node.

spcdot commented 3 days ago

Just verified this only happens with singletons (even if there's only one). Thanks for pointing out the zero.policy parameter, I hadn't noticed that. The calculation works and looks reasonable when I set zero.policy to true. I'll have to do some verification to make sure things make biological sense but that looks to have done the trick. Thanks!