If there are special characters in the column names for an input sfc object, such as "(" or "-", elevatr functions like get_elev_point will convert them to "." without any sort of warning. If unnoticed this can cause major problems trying to process data.
I have not traced down the source of this bug, but I suspect it is caused by a call to the base function as.data.frame which does these column conversions (for some arcane unknown to me reason). If that is the source, it can be fixed by passing the optional = TRUE argument to as.data.frame.
library(sf)
library(dplyr)
library(magrittr)
library(elevatr)
# Read a row from an sf example file, cast as points.
# Then put some dashes in the column names:
st_read(system.file("shape/nc.shp", package="sf")) %>%
head(1) %>%
st_cast("POINT") %>%
rename_with(~ gsub("_","-",.x, fixed= TRUE)) ->
nc_dash
#> Reading layer `nc' from data source
#> `C:\Users\jweissman\Documents\R\win-library\4.1\sf\shape\nc.shp'
#> using driver `ESRI Shapefile'
#> Simple feature collection with 100 features and 14 fields
#> Geometry type: MULTIPOLYGON
#> Dimension: XY
#> Bounding box: xmin: -84.32385 ymin: 33.88199 xmax: -75.45698 ymax: 36.58965
#> Geodetic CRS: NAD27
#> Warning in st_cast.sf(., "POINT"): repeating attributes for all sub-geometries
#> for which they may not be constant
# New sfc object with elevation:
nc_dash %>%
get_elev_point(src = "epqs") ->
nc_dash_elev
#> Downloading point elevations:
#> Note: Elevation units are in meters
# Remove new columns:
nc_dash_elev %>%
select(-elevation,
-elev_units) ->
nc_dash_noelev
# Check if the column names have changed:
all(names(nc_dash) == names(nc_dash_noelev))
#> [1] FALSE
@rgzn thanks for the issue and the reprex. I need to carve out some time soon to work on elevatr. I hope to do that in the next few weeks and I will take a look at this then.
If there are special characters in the column names for an input
sfc
object, such as "(" or "-",elevatr
functions likeget_elev_point
will convert them to "." without any sort of warning. If unnoticed this can cause major problems trying to process data.I have not traced down the source of this bug, but I suspect it is caused by a call to the base function
as.data.frame
which does these column conversions (for some arcane unknown to me reason). If that is the source, it can be fixed by passing theoptional = TRUE
argument toas.data.frame
.This same issue was present in
sf::st_read
and was fixed: https://github.com/r-spatial/sf/issues/1916Reprex:
Created on 2022-04-21 by the reprex package (v2.0.1)