[Rspatial-devel] SpatialMultiPoints

Roger Bivand Roger.Bivand at nhh.no
Fri Aug 14 11:47:47 CEST 2015 

On Fri, 14 Aug 2015, Edzer Pebesma wrote:

> In an early stage of sp we decided first against, later in favour of
> using data.frame for attribute data, the reason being character
> row.names (which were first compulsory, but abandoned later on): they
> are overhead in memory and computation, and cause bad scaling if you go
> in the direction of 1e6 - 1e9 points. Allowing for multi points as
> special case of SpatialPoints* would introduce this scaling problem
> again, unless we allow for absence of rownames in @coords, which leads
> to complex code.

My tendency would be to keep SpatialPoints (and its inheritors 
SpatialPixels and SpatialPixelsDataFrame) as they are. It makes, arguably, 
more sense to have SpatialLines depend on SpatialMultiPoints, with one (or 
more) MultiPoint object in each observation (MultiPoints object), and if 
it is a Line/Lines, the sequencing of the coordinates means something, 
otherwise not. Doesn't this feed forward to trajectories?

Roger

>
> I still wonder whether users will be helped by having one class that
> represents both simple points and multi points.
>
> I tend to make students believe that data.frames are lists with equal
> length column vectors. They're not:
>
>> data.frame(a = 1:2, b = list(1:3, 2:1))
> Error in data.frame(1:3, c(2L, 1L), check.names = FALSE,
> stringsAsFactors = TRUE) :
>  arguments imply differing number of rows: 3, 2 # OF COURSE!
>> d = data.frame(a = 1:2)
>> d$b = list(1:3, 2:1) # ???
>> d
>  a       b
> 1 1 1, 2, 3
> 2 2    2, 1
>> d$c = data.frame(d = 4:3) # ????
>> d
>  a       b d
> 1 1 1, 2, 3 4
> 2 2    2, 1 3
>> class(d$c)
> [1] "data.frame"
>> d$c
>  d
> 1 4
> 2 3
>
> and people actually use this ability for sp objects.
>
> Just read in your google location history dump with jsonlite to see how
> messy things can get.
>
> On 08/13/2015 08:36 PM, Roger Bivand wrote:
>> On Thu, 13 Aug 2015, Robert J. Hijmans wrote:
>>
>>> Or use a third column for the coordinates, that, when present, serves
>>> as the key to the attributes? Perhaps that is, in the long run, easier
>>> than row names as row names cannot be directly operated on, and are
>>> characters.
>>
>> All unique strings are hashed internally in base R, so string lookup in
>> R is cheap - this applies to the strings used for row.names:
>>
>> https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#The-CHARSXP-cache
>>
>>
>> Bets would be off in C/C++, unless going through SEXP (which we could
>> check that we do?).
>>
>> Roger
>>
>>>
>>> On Thu, Aug 13, 2015 at 9:57 AM, Edzer Pebesma
>>> <edzer.pebesma at uni-muenster.de> wrote:
>>>>
>>>> On 08/13/2015 06:17 PM, Robert J. Hijmans wrote:
>>>>> Edzer, That's great. But why not make it more consistent with the
>>>>> other classes by modifying SpatialPoints* such that it can have
>>>>> multiple points per record; just like for SpatialLines and
>>>>> SpatialPolygons? Would that guarantee to break too much; or perhaps be
>>>>> too much work to avoid that?  Robert
>>>>
>>>> That is a clever idea; the match to the data slot would then be done by
>>>> the rownames of the coords slot, and allow for many-to-one, in which
>>>> case the number of rows in the coords slot gets larger than the number
>>>> of attribute records.
>>>>
>>>> Would users understand this?
>>>>
>>>> I was looking at support by rgeos, but it seems we (nearly) have this
>>>> already when rownames of the coords slot are present, and indicate group
>>>> (not sure if this is documented at all!):
>>>>
>>>>> m = matrix(1:8,4,2, dimnames = list(c(1,1,2,2)))
>>>>> m
>>>>   [,1] [,2]
>>>> 1    1    5
>>>> 1    2    6
>>>> 2    3    7
>>>> 2    4    8
>>>>
>>>>> library(rgeos)
>>>> rgeos version: 0.3-11, (SVN revision 479)
>>>>  GEOS runtime version: 3.4.2-CAPI-1.8.2 r3921
>>>>  Linking to sp version: 1.1-1
>>>>  Polygon checking: TRUE
>>>>
>>>>> gIntersects(SpatialPoints(m), byid=T) # NOT 4x4!!!
>>>>       1     2
>>>> 1  TRUE FALSE
>>>> 2 FALSE  TRUE
>>>>
>>>>> m2 = matrix(1:8,4,2)
>>>>> gIntersects(SpatialPoints(m2), byid=T)
>>>>       1     2     3     4
>>>> 1  TRUE FALSE FALSE FALSE
>>>> 2 FALSE  TRUE FALSE FALSE
>>>> 3 FALSE FALSE  TRUE FALSE
>>>> 4 FALSE FALSE FALSE  TRUE
>>>>> gIntersects(SpatialPoints(m), SpatialPoints(m2), byid=T)
>>>>       1     2
>>>> 1  TRUE FALSE
>>>> 2  TRUE FALSE
>>>> 3 FALSE  TRUE
>>>> 4 FALSE  TRUE
>>>>
>>>>
>>>>>
>>>>> On Wed, Aug 12, 2015 at 8:43 AM, Edzer Pebesma
>>>>> <edzer.pebesma at uni-muenster.de> wrote:
>>>>>> The development version of sp, on r-forge, now provides objets with
>>>>>> MultiPoint geometries, called SpatialMultiPoints and
>>>>>> SpatialMultiPointsDataFrame.
>>>>>>
>>>>>> It can do things like:
>>>>>>
>>>>>> cl1 = cbind(rnorm(3, 10), rnorm(3, 10))
>>>>>> cl2 = cbind(rnorm(5, 10), rnorm(5,  0))
>>>>>> cl3 = cbind(rnorm(7,  0), rnorm(7, 10))
>>>>>>
>>>>>> library(sp)
>>>>>> mp = SpatialMultiPoints(list(cl1, cl2, cl3))
>>>>>> plot(mp, col = 2, cex = 1, pch = 1:3)
>>>>>> mp
>>>>>> mp[1:2]
>>>>>>
>>>>>> print(mp, asWKT=TRUE, digits=3)
>>>>>>
>>>>>> mpdf = SpatialMultiPointsDataFrame(list(cl1, cl2, cl3),
>>>>>> data.frame(a = 1:3))
>>>>>> mpdf
>>>>>>
>>>>>> plot(mpdf, col = mpdf$a, cex = 1:3)
>>>>>> as(mpdf, "data.frame")
>>>>>> mpdf[1:2,]
>>>>>>
>>>>>> Comments are welcome.
>>>>>> --
>>>>>> Edzer Pebesma
>>>>>> Institute for Geoinformatics (ifgi),  University of Münster,
>>>>>> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
>>>>>> Journal of Statistical Software:   http://www.jstatsoft.org/
>>>>>> Computers & Geosciences:   http://elsevier.com/locate/cageo/
>>>>>> Spatial Statistics Society http://www.spatialstatistics.info
>>>>
>>>> --
>>>> Edzer Pebesma
>>>> Institute for Geoinformatics (ifgi),  University of Münster,
>>>> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
>>>> Journal of Statistical Software:   http://www.jstatsoft.org/
>>>> Computers & Geosciences:   http://elsevier.com/locate/cageo/
>>>> Spatial Statistics Society http://www.spatialstatistics.info
>>>>
>>> _______________________________________________
>>> Rspatial-devel mailing list
>>> Rspatial-devel at lists.r-forge.r-project.org
>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rspatial-devel
>>>
>>
>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: Roger.Bivand at nhh.no

More information about the Rspatial-devel mailing list