From a070ed89639bf522743f45f11710f09f7d0435cb Mon Sep 17 00:00:00 2001 From: Wilmund Date: Tue, 6 Oct 2026 16:40:21 +0200 Subject: [PATCH 1/2] geolocate_radius(): read sfc_POINT coordinates in X=lon, Y=lat order sf::st_coordinates() returns columns in (X, Y) = (longitude, latitude) order, but parse_point_radius() assigned element [1] to lat and [2] to lon. As a result, any sfc_POINT supplied to geolocate_radius() / galah_radius() had its coordinates transposed: points with |lon| > 90 (including every point in Australia) error with 'Point location outside of possible range', and points with |lon| <= 90 silently query the transposed location. The existing unit test passed because it constructed its test point as st_point(c(lat, lon)), encoding the same transposition; the test input is corrected here so the expected lat/lon values now prove the right behaviour. --- R/geolocate_radius.R | 5 +++-- tests/testthat/test-geolocate_radius.R | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/R/geolocate_radius.R b/R/geolocate_radius.R index 2dd410b7..20120767 100644 --- a/R/geolocate_radius.R +++ b/R/geolocate_radius.R @@ -57,8 +57,9 @@ parse_point_radius <- function(..., } # extract point coordinate values - lat <- sf::st_coordinates(coords)[1] - lon <- sf::st_coordinates(coords)[2] + # (`st_coordinates()` returns columns in X (longitude), Y (latitude) order) + lon <- sf::st_coordinates(coords)[1] + lat <- sf::st_coordinates(coords)[2] } else { # Coords are supplied as lon/lat arguments diff --git a/tests/testthat/test-geolocate_radius.R b/tests/testthat/test-geolocate_radius.R index f9baac30..35b465fe 100644 --- a/tests/testthat/test-geolocate_radius.R +++ b/tests/testthat/test-geolocate_radius.R @@ -29,7 +29,7 @@ test_that("`geolocate_radius()` assigns default radius when missing argument", { }) test_that("`geolocate_radius()` returns radius for sf_POINT object", { - point <- sf::st_sfc(sf::st_point(c(-33.66741, 151.3174)), + point <- sf::st_sfc(sf::st_point(c(151.3174, -33.66741)), crs = 4326) expected_object <- list(lat = -33.66741, lon = 151.3174, From 586e6665cd83fd60534cd46b0b9912e5bca96db6 Mon Sep 17 00:00:00 2001 From: Wilmund Date: Tue, 6 Oct 2026 16:40:35 +0200 Subject: [PATCH 2/2] geolocate_polygon(): count features via st_geometry(), not $geometry The 'too many polygons' guard counted features with length(query$geometry), which only works for sf data.frames whose geometry column is literally named 'geometry'. For sfc input, and for sf objects with a differently-named geometry column (e.g. 'geom', the common name for layers read from PostGIS/GeoPackage), query$geometry is NULL, the guard never fires, and a multi-feature object falls through to build_wkt(), where the vectorised st_geometry_type() comparison crashes with 'the condition has length > 1' instead of the intended error message. sf::st_geometry() returns the geometry set for both sf and sfc input regardless of column name. --- R/geolocate_polygon.R | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/R/geolocate_polygon.R b/R/geolocate_polygon.R index aad486c6..22ca6f2f 100644 --- a/R/geolocate_polygon.R +++ b/R/geolocate_polygon.R @@ -97,11 +97,11 @@ parse_polygon <- function(query, # to avoid any issues, any polygons are converted to multipolygons if(inherits(query, "sf") || inherits(query, "sfc")) { - if(length(query$geometry) < 2) { + if(length(sf::st_geometry(query)) < 2) { out_query <- build_wkt(query) } else { # multiple polygons - n_polygons <- length(query$geometry) + n_polygons <- length(sf::st_geometry(query)) c("Too many polygons.", i = "`galah_polygon` cannot accept more than 1 polygon at a time.", x = "{n_polygons} polygons detected in spatial object.") |>