[R-sig-Geo] Which dimension should a matrix returned by a binary topological operaor have?

Colin Rundel rundel at gmail.com
Fri Sep 9 15:46:25 CEST 2016


This is a mistake I made when originally working on the package that didn’t get caught at the time. I think Edzer is correct and ideally his example should be producing a 2x3 matrix, but at this stage switching the ordering in rages is too likely break existing code. 

sf having a argument that lets you t() the result makes sense to me if only as a backwards compatibility feature.

-Colin

-----

Colin Rundel
Assistant Professor of the Practice
Duke University, Department of Statistical Science
colin.rundel at stat.duke.edu
www.stat.duke.edu/~cr173/

> On Sep 7, 2016, at 8:23 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
> 
> On Wed, 7 Sep 2016, Edzer Pebesma wrote:
> 
>> In sp and rgeos, we currently have
>> 
>>> library(sp)
>>> library(rgeos)
>>> p1 = SpatialPoints(matrix(1:4,2))
>>> p2 = SpatialPoints(matrix(1:6,3))
>>> gRelate(p1,p2,byid=TRUE)
>> 1           2
>> 1 "FF0FFF0F2" "FF0FFF0F2"
>> 2 "FF0FFF0F2" "FF0FFF0F2"
>> 3 "FF0FFF0F2" "FF0FFF0F2"
>>> dim(gRelate(p1,p2,byid=TRUE))
>> [1] 3 2
>>> length(p1)
>> [1] 2
>>> length(p2)
>> [1] 3
>> 
>> Meaning: arguments with lengths 2 and 3 result in a 3 x 2 matrix. This
>> is true for all binary operators (covers, intersects, etc) and byid=TRUE.
> 
> In src/rgeos_predicate_binary.c, you'll see that rgeos_binpredfunc() can return a matrix or a list. For rgeos_relate() the list option should be unused (it will be trapped in the next release), because the output must be a dense matrix by design. In other cases where the output is a logical matrix with many FALSE entries, a sparse list output object is perhaps more logical. sf should not return dense matrices where sparse binary matrices would suffice. However, the "relate" binary predicate is different.
> 
> We could try to add an option to t() the output matrix, and see what got broken among dependent packages. The returned list is the length of spgeom1, by the way, with components 1-base indexing spgeom2. These would be like the columns in a data frame if the numbers of indexed components were equal, but a matrix is more natural.
> 
> Shall we test the dependencies for breakage? Scripts will break too I expect, but we can't check them.
> 
> Roger
> 
>> 
>> I always found this counterintuitive, and consider implementing it the
>> other way around (2 and 3 -> 2 x 3) in package sf. Or am I overlooking
>> something obvious?
>> 
> 
> -- 
> 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 <mailto:Roger.Bivand at nhh.no>
> http://orcid.org/0000-0003-2392-6140 <http://orcid.org/0000-0003-2392-6140>
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en <https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en>
> http://depsy.org/person/434412 <http://depsy.org/person/434412>
> 
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo at r-project.org <mailto:R-sig-Geo at r-project.org>
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>

	[[alternative HTML version deleted]]



More information about the R-sig-Geo mailing list