Re: [R-sig-Geo] Subset SpatialGridDataFrame by retrieving xy coordinates from bounding box

2012-10-15 Thread Robert J. Hijmans
Natalie,

library(raster)
b <- brick(SGDF)
e  <- extent(457446, 457506, 5384573, 5384633)
bb <- crop(b, e)

# not sure what you want to do next,  perhaps

sge <- as(bb, 'SpatialGridDataFrame')

Robert


On Mon, Oct 15, 2012 at 5:54 PM, Nathalie Morin <
nathalie.m.mo...@usherbrooke.ca> wrote:

> Hello !
>
>
>
> I am trying to subset elements from a SpatialGridDataFrame not by
> attribute,
> nor by indexing of rows/columns such as X[rows, columns], but by retrieving
> the xy coordinates from the bounding box.
>
>
>
> Example :
>
> > bbox(SGDF)
>
>   min max
>
> x  457446  457512
>
> y 5384573 5384637
>
>
>
> The x min and ymin are good but I want to select elements for which
>
> x max <= 457506
>
> y max <= 5384633
>
>
>
> The question seems probably trivial but it does not come out very clearly
> on
> the forum. I would very much appreciate it if anyone could shed some light
> on it.
>
> Many thanks in advance for your help !
>
> Nathalie
>
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


Re: [R-sig-Geo] Subset SpatialGridDataFrame by retrieving xy coordinates from bounding box

2012-10-15 Thread Rolf Turner


This can be easily done in the "spatstat" package if you convert
the object of interest to a spatial point pattern (object of class "ppp").
See the vignette "shapefiles" for some guidance on how to do the
conversion.

cheers,

Rolf Turner

On 16/10/12 13:54, Nathalie Morin wrote:

Hello !

  


I am trying to subset elements from a SpatialGridDataFrame not by attribute,
nor by indexing of rows/columns such as X[rows, columns], but by retrieving
the xy coordinates from the bounding box.

  


Example :


bbox(SGDF)

   min max

x  457446  457512

y 5384573 5384637

  


The x min and ymin are good but I want to select elements for which

x max <= 457506

y max <= 5384633

  


The question seems probably trivial but it does not come out very clearly on
the forum. I would very much appreciate it if anyone could shed some light
on it.

Many thanks in advance for your help !

Nathalie


[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


[R-sig-Geo] Subset SpatialGridDataFrame by retrieving xy coordinates from bounding box

2012-10-15 Thread Nathalie Morin
Hello !

 

I am trying to subset elements from a SpatialGridDataFrame not by attribute,
nor by indexing of rows/columns such as X[rows, columns], but by retrieving
the xy coordinates from the bounding box.

 

Example :

> bbox(SGDF)

  min max

x  457446  457512

y 5384573 5384637

 

The x min and ymin are good but I want to select elements for which

x max <= 457506

y max <= 5384633

 

The question seems probably trivial but it does not come out very clearly on
the forum. I would very much appreciate it if anyone could shed some light
on it.

Many thanks in advance for your help !

Nathalie


[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


Re: [R-sig-Geo] spml, spfeml and tolerance level

2012-10-15 Thread Ariel Ortiz-Bobea
After some exploration and a hint from the package administrator, the
quickest way I found to avoid this problem (without having to customize
functions within the package) was setting:

.Machine$double.eps <- .Machine$double.eps^2

Just in case anyone faces this.

cheers.

AOB




-
Ariel Ortiz-Bobea
PhD Candidate in Agricultural & Resource Economics
University of Maryland - College Park
--
View this message in context: 
http://r-sig-geo.2731867.n2.nabble.com/spml-spfeml-and-tolerance-level-tp7581089p7581285.html
Sent from the R-sig-geo mailing list archive at Nabble.com.

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


Re: [R-sig-Geo] problem creating psp

2012-10-15 Thread Michael Sumner
It works for this example, so either something is wrong with your data
or the packages are out of date. Can you provide
summary(SierraLeone.roads) and/or the data file, and sessionInfo()?

library(maptools)
xx <- readShapeLines(system.file("shapes/fylk-val.shp", package="maptools")[1],
   proj4string=CRS("+proj=utm +zone=33 +datum=WGS84"))

library(spatstat)
xx.p <- as.psp(xx)

summary(xx)
Object of class SpatialLinesDataFrame
Coordinates:
  min max
x   -4867.832 1084722
y 6456207.000 7841997
Is projected: TRUE
proj4string : [+proj=utm +zone=33 +datum=WGS84]
Data attributes:
 FNODE_   TNODE_   LPOLY_ RPOLY_
 Min.   :  1.00   Min.   :  2.00   Min.   :1.00   Min.   :1.00
 1st Qu.: 40.00   1st Qu.: 39.00   1st Qu.:2.00   1st Qu.:2.00
 Median : 74.00   Median : 77.00   Median :2.00   Median :2.00
 Mean   : 77.62   Mean   : 77.55   Mean   :1.99   Mean   :1.99
 3rd Qu.:115.00   3rd Qu.:114.00   3rd Qu.:2.00   3rd Qu.:2.00
 Max.   :160.00   Max.   :159.00   Max.   :2.00   Max.   :2.00
 LENGTHVALINJE_VALINJE_ID LTEMA  VANNBR
 Min.   :   106.4   Min.   : 1   Min.   : 55.00   Min.   :3211   Min.   :13
 1st Qu.: 11866.5   1st Qu.:25   1st Qu.: 74.00   1st Qu.:3211   1st Qu.:13
 Median : 31910.9   Median :49   Median : 95.00   Median :3211   Median :13
 Mean   : 41374.7   Mean   :49   Mean   : 94.32   Mean   :3211   Mean   :13
 3rd Qu.: 59311.8   3rd Qu.:73   3rd Qu.:114.00   3rd Qu.:3211   3rd Qu.:13
 Max.   :176540.1   Max.   :97   Max.   :135.00   Max.   :3211   Max.   :13
  DATO
 Min.   :19970630
 1st Qu.:19970630
 Median :19970630
 Mean   :19970630
 3rd Qu.:19970630
 Max.   :19970630

sessionInfo()
R version 2.15.1 Patched (2012-10-07 r60893)
Platform: x86_64-w64-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_Australia.1252  LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  compiler  methods
[8] base

other attached packages:
[1] spatstat_1.28-2 deldir_0.0-20   mgcv_1.7-21 maptools_0.8-16
[5] lattice_0.20-10 sp_1.0-0foreign_0.8-50

loaded via a namespace (and not attached):
[1] grid_2.15.1  Matrix_1.0-9 nlme_3.1-104


Cheers, Mike.

On Tue, Oct 16, 2012 at 7:34 AM, Reeder, Bryce Wesley
 wrote:
> Hello Everyone,
>
> I am currently trying to complete the simple task of converting a
> SpatialLinesDataFrame to PSP so that I can do kernel density estimation on
> the line pattern (density.psp).  When I do this, however, I get an error
> that does not allow me to proceed.  Here is the code I am using (along with
> the error):
>
>> rm(list=ls(all=TRUE))
>> library(spatstat) # spatial tools
>> ## Read in road data
>>
> setwd("~/Dropbox/Spatial_Project/Hot_Spots_Civil_Conflict/Data/SierraLeone_roads/")
>> SierraLeone.roads <- readShapeLines("Sierra_Leone_highway", repair=T)
>> plot(SierraLeone.roads)
>> SierraLeone.psp <- as.psp(SierraLeone.roads)
> Error in as.data.frame.vector(x, ..., nm = nm) :
>   formal argument "nm" matched by multiple actual arguments
>
> I have not worked with line data much so any assistance would be greatly
> appreciated.
>
> --
> Bryce W. Reeder
> University of Illinois, Urbana-Champaign
> PhD Student - Department of Political Science
> Editorial Assistant, International Interactions
> Office: David Kinley Hall, Room 323
> Email: reed...@illinois.edu
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo



-- 
Michael Sumner
Hobart, Australia
e-mail: mdsum...@gmail.com

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


[R-sig-Geo] problem creating psp

2012-10-15 Thread Reeder, Bryce Wesley
Hello Everyone,

I am currently trying to complete the simple task of converting a
SpatialLinesDataFrame to PSP so that I can do kernel density estimation on
the line pattern (density.psp).  When I do this, however, I get an error
that does not allow me to proceed.  Here is the code I am using (along with
the error):

> rm(list=ls(all=TRUE))
> library(spatstat) # spatial tools
> ## Read in road data
>
setwd("~/Dropbox/Spatial_Project/Hot_Spots_Civil_Conflict/Data/SierraLeone_roads/")
> SierraLeone.roads <- readShapeLines("Sierra_Leone_highway", repair=T)
> plot(SierraLeone.roads)
> SierraLeone.psp <- as.psp(SierraLeone.roads)
Error in as.data.frame.vector(x, ..., nm = nm) :
  formal argument "nm" matched by multiple actual arguments

I have not worked with line data much so any assistance would be greatly
appreciated.

-- 
Bryce W. Reeder
University of Illinois, Urbana-Champaign
PhD Student - Department of Political Science
Editorial Assistant, International Interactions
Office: David Kinley Hall, Room 323
Email: reed...@illinois.edu

[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


Re: [R-sig-Geo] rgeos: gOverlaps not working properly?

2012-10-15 Thread zbynek.jano...@centrum.cz
Thank you very much, problem solved.
Zbynek



--
View this message in context: 
http://r-sig-geo.2731867.n2.nabble.com/rgeos-gOverlaps-not-working-properly-tp7581278p7581282.html
Sent from the R-sig-geo mailing list archive at Nabble.com.

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


Re: [R-sig-Geo] rgeos: gOverlaps not working properly?

2012-10-15 Thread Barry Rowlingson
 ‘gOverlaps’ returns TRUE when the geometries share some but not
 all interior points, and the intersection has the same dimension
 as the geometries themselves.

Hence gOverlaps(A,A) == FALSE due to that 'but not all' part of the
documentation.

Barry

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


Re: [R-sig-Geo] rgeos: gOverlaps not working properly?

2012-10-15 Thread zbynek.jano...@centrum.cz
Absolutely, sorry for that

> dput(CooA)
structure(c(-506157.3827, -506046.35779, -506021.42681, 
-505984.87158, -505953.70149, -505910.16251, -505883.4289, 
-505840.08242, -505800.22761, -505771.72411, -505735.3649, 
-505701.88969, -505651.2245, -505614.66318, -505545.83811, 
-505484.8244, -505430.20259, -505328.65069, -505275.85461, 
-505238.9824, -505194.54191, -505155.12901, -505111.05739, 
-505042.6708, -504996.18691, -504932.434, -504898.39449, 
-504869.15548, -504825.24902, -504787.71111, -504719.05841, 
-504695.12331, -504616.54891, -504558.19972, -504523.85249, 
-504448.19909, -504299.84931, -504219.99611, -504128.72619, 
-503978.41369, -503909.83309, -503865.87001, -503774.7731, 
-503671.45011, -503524.94771, -503413.37249, -503314.52518, 
-503240.01351, -503162.6184, -503113.6351, -503045.51819, 
-502921.99749, -502782.08281, -502649.0647, -502509.1699, 
-502390.5407, -502364.87029, -1122381.2702, -1122297.4208, 
-1122278.8389, -1122252.8248, -1122230.3717, -1122200.2902, -1122182.2913, 
-1122152.1603, -1122126.0303, -1122107.2919, -1122084.4322, -1122062.3233, 
-1122030.914, -1122009.476, -1121969.1182, -1121933.7249, -1121903.6434, 
-1121849.694, -1121821.4481, -1121803.2753, -1121781.8486, -1121762.539, 
-1121741.4268, -1121710.27, -1121689.9333, -1121662.4216, -1121647.6448, 
-1121635.7911, -1121618.3343, -1121603.2663, -1121576.5973, -1121567.8993, 
-1121539.3452, -1121519.0154, -1121507.6544, -1121482.2603, -1121433.8681, 
-1121408.7487, -1121380.1772, -1121333.3369, -1121311.3593, -1121297.0581, 
-1121266.869, -1121231.1033, -1121177.324, -1121133.065, -1121091.724, 
-1121058.8434, -1121022.7963, -1120999.1913, -1120966.3657, -1120903.015, 
-1120825.6379, -1120747.9998, -1120661.0955, -1120583.5099, -1120566.644
), .Dim = c(57L, 2L))

> dput(CooB)
structure(c(-506157.3827, -506046.35779, -506021.42681, 
-505984.87158, -505953.70149, -505910.16251, -505883.4289, 
-505840.08242, -505800.22761, -505771.72411, -505735.3649, 
-505701.88969, -505651.2245, -505614.66318, -505545.83811, 
-505484.8244, -505430.20259, -505328.65069, -505275.85461, 
-505238.9824, -505194.54191, -505155.12901, -505111.05739, 
-505042.6708, -504996.18691, -504932.434, -504898.39449, 
-504869.15548, -504825.24902, -504787.71111, -504719.05841, 
-504695.12331, -504616.54891, -504558.19972, -504523.85249, 
-504448.19909, -504299.84931, -504219.99611, -504128.72619, 
-503978.41369, -503909.83309, -503865.87001, -503774.7731, 
-503671.45011, -503524.94771, -503413.37249, -503314.52518, 
-503240.01351, -503162.6184, -503113.6351, -503045.51819, 
-502921.99749, -502782.08281, -502649.0647, -502509.1699, 
-502390.5407, -502364.87029, -502271.69092, -502251.20828, 
-1122381.2702, -1122297.4208, -1122278.8389, -1122252.8248, -1122230.3717, 
-1122200.2902, -1122182.2913, -1122152.1603, -1122126.0303, -1122107.2919, 
-1122084.4322, -1122062.3233, -1122030.914, -1122009.476, -1121969.1182, 
-1121933.7249, -1121903.6434, -1121849.694, -1121821.4481, -1121803.2753, 
-1121781.8486, -1121762.539, -1121741.4268, -1121710.27, -1121689.9333, 
-1121662.4216, -1121647.6448, -1121635.7911, -1121618.3343, -1121603.2663, 
-1121576.5973, -1121567.8993, -1121539.3452, -1121519.0154, -1121507.6544, 
-1121482.2603, -1121433.8681, -1121408.7487, -1121380.1772, -1121333.3369, 
-1121311.3593, -1121297.0581, -1121266.869, -1121231.1033, -1121177.324, 
-1121133.065, -1121091.724, -1121058.8434, -1121022.7963, -1120999.1913, 
-1120966.3657, -1120903.015, -1120825.6379, -1120747.9998, -1120661.0955, 
-1120583.5099, -1120566.644, -1120505.4237, -1120491.6229), .Dim = c(59L, 
2L))

Zbynek



--
View this message in context: 
http://r-sig-geo.2731867.n2.nabble.com/rgeos-gOverlaps-not-working-properly-tp7581278p7581280.html
Sent from the R-sig-geo mailing list archive at Nabble.com.

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


Re: [R-sig-Geo] rgeos: gOverlaps not working properly?

2012-10-15 Thread Roman Luštrik
Would it be possible to provide your output in a form that we can read it?
I suggest dput().

Cheers,
Roman



On Mon, Oct 15, 2012 at 2:20 PM, zbynek.jano...@centrum.cz <
zbynek.jano...@centrum.cz> wrote:

> Hello,
> I have following problem with gOverlaps function:
> I have two lines, A and B.
> line A has 57 vertexes, all identical with vertexes of line B
> yet, gOverlaps(A,B) gives FALSE
>
> the code follows...
>
> > CooA # coordinates of line A
>[,1] [,2]
>  [1,] -506157.4 -1122381
>  [2,] -506046.4 -1122297
>  [3,] -506021.4 -1122279
>  [4,] -505984.9 -1122253
>  [5,] -505953.7 -1122230
>  [6,] -505910.2 -1122200
>  [7,] -505883.4 -1122182
>  [8,] -505840.1 -1122152
>  [9,] -505800.2 -1122126
> [10,] -505771.7 -1122107
> [11,] -505735.4 -1122084
> [12,] -505701.9 -1122062
> [13,] -505651.2 -1122031
> [14,] -505614.7 -1122009
> [15,] -505545.8 -1121969
> [16,] -505484.8 -1121934
> [17,] -505430.2 -1121904
> [18,] -505328.7 -1121850
> [19,] -505275.9 -1121821
> [20,] -505239.0 -1121803
> [21,] -505194.5 -1121782
> [22,] -505155.1 -1121763
> [23,] -505111.1 -1121741
> [24,] -505042.7 -1121710
> [25,] -504996.2 -1121690
> [26,] -504932.4 -1121662
> [27,] -504898.4 -1121648
> [28,] -504869.2 -1121636
> [29,] -504825.2 -1121618
> [30,] -504787.7 -1121603
> [31,] -504719.1 -1121577
> [32,] -504695.1 -1121568
> [33,] -504616.5 -1121539
> [34,] -504558.2 -1121519
> [35,] -504523.9 -1121508
> [36,] -504448.2 -1121482
> [37,] -504299.8 -1121434
> [38,] -504220.0 -1121409
> [39,] -504128.7 -1121380
> [40,] -503978.4 -1121333
> [41,] -503909.8 -1121311
> [42,] -503865.9 -1121297
> [43,] -503774.8 -1121267
> [44,] -503671.5 -1121231
> [45,] -503524.9 -1121177
> [46,] -503413.4 -1121133
> [47,] -503314.5 -1121092
> [48,] -503240.0 -1121059
> [49,] -503162.6 -1121023
> [50,] -503113.6 -1120999
> [51,] -503045.5 -1120966
> [52,] -502922.0 -1120903
> [53,] -502782.1 -1120826
> [54,] -502649.1 -1120748
> [55,] -502509.2 -1120661
> [56,] -502390.5 -1120584
> [57,] -502364.9 -1120567
>
> > CooB # coordinates of line B
>[,1] [,2]
>  [1,] -506157.4 -1122381
>  [2,] -506046.4 -1122297
>  [3,] -506021.4 -1122279
>  [4,] -505984.9 -1122253
>  [5,] -505953.7 -1122230
>  [6,] -505910.2 -1122200
>  [7,] -505883.4 -1122182
>  [8,] -505840.1 -1122152
>  [9,] -505800.2 -1122126
> [10,] -505771.7 -1122107
> [11,] -505735.4 -1122084
> [12,] -505701.9 -1122062
> [13,] -505651.2 -1122031
> [14,] -505614.7 -1122009
> [15,] -505545.8 -1121969
> [16,] -505484.8 -1121934
> [17,] -505430.2 -1121904
> [18,] -505328.7 -1121850
> [19,] -505275.9 -1121821
> [20,] -505239.0 -1121803
> [21,] -505194.5 -1121782
> [22,] -505155.1 -1121763
> [23,] -505111.1 -1121741
> [24,] -505042.7 -1121710
> [25,] -504996.2 -1121690
> [26,] -504932.4 -1121662
> [27,] -504898.4 -1121648
> [28,] -504869.2 -1121636
> [29,] -504825.2 -1121618
> [30,] -504787.7 -1121603
> [31,] -504719.1 -1121577
> [32,] -504695.1 -1121568
> [33,] -504616.5 -1121539
> [34,] -504558.2 -1121519
> [35,] -504523.9 -1121508
> [36,] -504448.2 -1121482
> [37,] -504299.8 -1121434
> [38,] -504220.0 -1121409
> [39,] -504128.7 -1121380
> [40,] -503978.4 -1121333
> [41,] -503909.8 -1121311
> [42,] -503865.9 -1121297
> [43,] -503774.8 -1121267
> [44,] -503671.5 -1121231
> [45,] -503524.9 -1121177
> [46,] -503413.4 -1121133
> [47,] -503314.5 -1121092
> [48,] -503240.0 -1121059
> [49,] -503162.6 -1121023
> [50,] -503113.6 -1120999
> [51,] -503045.5 -1120966
> [52,] -502922.0 -1120903
> [53,] -502782.1 -1120826
> [54,] -502649.1 -1120748
> [55,] -502509.2 -1120661
> [56,] -502390.5 -1120584
> [57,] -502364.9 -1120567
> [58,] -502271.7 -1120505
> [59,] -502251.2 -1120492
>
> nrow(CooA)*ncol(CooA) # number of values in CooA
> length(which(CooA %in% CooB)) # all values of CooA are also in CooB (and
> ordering is the same)
> A <- SpatialLines(list(Lines(list(Line(CooA)),ID=1)))
> B <- SpatialLines(list(Lines(list(Line(CooB)),ID=2)))
> gOverlaps(A,B) # gives FALSE
>
> I can not see the reason why this returns FALSE (or does it on your
> computer?)
> Even if I specify the coordinate system, returned value is still FALSE.
>
> Any help would be appreciated,
> Thanks
> Zbynek
>
>
>
> --
> View this message in context:
> http://r-sig-geo.2731867.n2.nabble.com/rgeos-gOverlaps-not-working-properly-tp7581278.html
> Sent from the R-sig-geo mailing list archive at Nabble.com.
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>



-- 
In God we trust, all others bring data.

[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


[R-sig-Geo] rgeos: gOverlaps not working properly?

2012-10-15 Thread zbynek.jano...@centrum.cz
Hello,
I have following problem with gOverlaps function:
I have two lines, A and B.
line A has 57 vertexes, all identical with vertexes of line B
yet, gOverlaps(A,B) gives FALSE

the code follows...

> CooA # coordinates of line A
   [,1] [,2]
 [1,] -506157.4 -1122381
 [2,] -506046.4 -1122297
 [3,] -506021.4 -1122279
 [4,] -505984.9 -1122253
 [5,] -505953.7 -1122230
 [6,] -505910.2 -1122200
 [7,] -505883.4 -1122182
 [8,] -505840.1 -1122152
 [9,] -505800.2 -1122126
[10,] -505771.7 -1122107
[11,] -505735.4 -1122084
[12,] -505701.9 -1122062
[13,] -505651.2 -1122031
[14,] -505614.7 -1122009
[15,] -505545.8 -1121969
[16,] -505484.8 -1121934
[17,] -505430.2 -1121904
[18,] -505328.7 -1121850
[19,] -505275.9 -1121821
[20,] -505239.0 -1121803
[21,] -505194.5 -1121782
[22,] -505155.1 -1121763
[23,] -505111.1 -1121741
[24,] -505042.7 -1121710
[25,] -504996.2 -1121690
[26,] -504932.4 -1121662
[27,] -504898.4 -1121648
[28,] -504869.2 -1121636
[29,] -504825.2 -1121618
[30,] -504787.7 -1121603
[31,] -504719.1 -1121577
[32,] -504695.1 -1121568
[33,] -504616.5 -1121539
[34,] -504558.2 -1121519
[35,] -504523.9 -1121508
[36,] -504448.2 -1121482
[37,] -504299.8 -1121434
[38,] -504220.0 -1121409
[39,] -504128.7 -1121380
[40,] -503978.4 -1121333
[41,] -503909.8 -1121311
[42,] -503865.9 -1121297
[43,] -503774.8 -1121267
[44,] -503671.5 -1121231
[45,] -503524.9 -1121177
[46,] -503413.4 -1121133
[47,] -503314.5 -1121092
[48,] -503240.0 -1121059
[49,] -503162.6 -1121023
[50,] -503113.6 -1120999
[51,] -503045.5 -1120966
[52,] -502922.0 -1120903
[53,] -502782.1 -1120826
[54,] -502649.1 -1120748
[55,] -502509.2 -1120661
[56,] -502390.5 -1120584
[57,] -502364.9 -1120567

> CooB # coordinates of line B
   [,1] [,2]
 [1,] -506157.4 -1122381
 [2,] -506046.4 -1122297
 [3,] -506021.4 -1122279
 [4,] -505984.9 -1122253
 [5,] -505953.7 -1122230
 [6,] -505910.2 -1122200
 [7,] -505883.4 -1122182
 [8,] -505840.1 -1122152
 [9,] -505800.2 -1122126
[10,] -505771.7 -1122107
[11,] -505735.4 -1122084
[12,] -505701.9 -1122062
[13,] -505651.2 -1122031
[14,] -505614.7 -1122009
[15,] -505545.8 -1121969
[16,] -505484.8 -1121934
[17,] -505430.2 -1121904
[18,] -505328.7 -1121850
[19,] -505275.9 -1121821
[20,] -505239.0 -1121803
[21,] -505194.5 -1121782
[22,] -505155.1 -1121763
[23,] -505111.1 -1121741
[24,] -505042.7 -1121710
[25,] -504996.2 -1121690
[26,] -504932.4 -1121662
[27,] -504898.4 -1121648
[28,] -504869.2 -1121636
[29,] -504825.2 -1121618
[30,] -504787.7 -1121603
[31,] -504719.1 -1121577
[32,] -504695.1 -1121568
[33,] -504616.5 -1121539
[34,] -504558.2 -1121519
[35,] -504523.9 -1121508
[36,] -504448.2 -1121482
[37,] -504299.8 -1121434
[38,] -504220.0 -1121409
[39,] -504128.7 -1121380
[40,] -503978.4 -1121333
[41,] -503909.8 -1121311
[42,] -503865.9 -1121297
[43,] -503774.8 -1121267
[44,] -503671.5 -1121231
[45,] -503524.9 -1121177
[46,] -503413.4 -1121133
[47,] -503314.5 -1121092
[48,] -503240.0 -1121059
[49,] -503162.6 -1121023
[50,] -503113.6 -1120999
[51,] -503045.5 -1120966
[52,] -502922.0 -1120903
[53,] -502782.1 -1120826
[54,] -502649.1 -1120748
[55,] -502509.2 -1120661
[56,] -502390.5 -1120584
[57,] -502364.9 -1120567
[58,] -502271.7 -1120505
[59,] -502251.2 -1120492

nrow(CooA)*ncol(CooA) # number of values in CooA
length(which(CooA %in% CooB)) # all values of CooA are also in CooB (and
ordering is the same)
A <- SpatialLines(list(Lines(list(Line(CooA)),ID=1)))
B <- SpatialLines(list(Lines(list(Line(CooB)),ID=2)))
gOverlaps(A,B) # gives FALSE

I can not see the reason why this returns FALSE (or does it on your
computer?)
Even if I specify the coordinate system, returned value is still FALSE.

Any help would be appreciated,
Thanks
Zbynek



--
View this message in context: 
http://r-sig-geo.2731867.n2.nabble.com/rgeos-gOverlaps-not-working-properly-tp7581278.html
Sent from the R-sig-geo mailing list archive at Nabble.com.

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


[R-sig-Geo] kernel2d -> raster/grid

2012-10-15 Thread Raffaele Morelli
Hi,

how can I convert kernel2d estimation to a raster in order to use it as a
mapserver layer?
I saw maptools can save kernel2d to contour to shape file
with ContourLines2SLDF.

Any hints?
Regards
-r

-- 
*L'unica speranza di catarsi, ammesso che ne esista una, resta affidata
all'istinto di ribellione, alla rivolta non isterilita in progetti, alla
protesta violenta e viscerale. (V. Evangelisti)
*

[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo