You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
geos_relate_pattern() is a really useful function for comparing two individual geometries. It would be great to have this same functionality made available in the _matrix() format. If made available, it could be used to speed up neighbor matching in spdep.
Looking at queen contiguity with self included using geos_intersects_matrix() is very fast. Rook contiguity requires a relate which the existing functions do not provide a way to harness the tree.
It's certainly possible to provide the same interface; however, a generic version that uses the tree might require some explicit inspection of the relate pattern which I don't really know much about. The geos_strtree_query() function will get you potential intersection slightly faster than a matrix intersection and you could do lapply() + geos_relate_pattern(). Also, there is geos_basic_strtree() which would let you do something like geos_relate_pattern(vec_a[query_result[[1]]], vec_b[query_result[[2]]) (i.e., skipping the lapply).
Probably also possible to wire up a matrix version but it would probably involve skipping patterns where the "potential intersection" filter would end up generating incorrect results (e.g., disjoint).
geos_relate_pattern()
is a really useful function for comparing two individual geometries. It would be great to have this same functionality made available in the_matrix()
format. If made available, it could be used to speed up neighbor matching in spdep.Looking at queen contiguity with self included using
geos_intersects_matrix()
is very fast. Rook contiguity requires a relate which the existing functions do not provide a way to harness the tree.The text was updated successfully, but these errors were encountered: