使用furrr对sf对象并行计算：future_map与map处理差异排查

这个错误的核心是sf的sfc_POINT对象在并行计算环境中无法被正确序列化/识别为符合vctrs包要求的向量类型，导致vec_size函数抛出类型不匹配的错误。具体原因和对应解决方式如下：

1. 并行环境下的sf对象序列化缺失 #

future框架默认的序列化机制无法完整保留sfc对象的空间元数据，当分组后的sf子对象被传递到并行进程时，会丢失部分类属性，被识别为非向量类型。

解决办法： #

显式设置future的序列化方式为transparent，并确保在并行任务中重新确认sf对象的类：

library(furrr)
library(sf)
library(dplyr)

# 启动多会话并行，设置透明序列化
plan(multisession, workers = 4, .options = furrr_options(serialize = "transparent"))

# 并行计算逻辑
result <- your_sf_data %>%
  group_by(city) %>%
  nest() %>%
  mutate(
    # 计算最近邻平均距离
    nn_avg_dist = future_map_dbl(data, function(sub_sf) {
      # 确保子对象是完整的sf类（修复序列化丢失的属性）
      if (!inherits(sub_sf, "sf")) sub_sf <- st_as_sf(sub_sf)
      dist_matrix <- st_distance(sub_sf, sub_sf)
      mean(dist_matrix[lower.tri(dist_matrix)])
    }),
    # 计算城市点计数
    point_count = future_map_int(data, nrow)
  ) %>%
  ungroup()

2. 映射逻辑中传递了孤立的sfc列而非完整sf对象 #

如果你的代码中直接对sfc列（比如geometry列）进行future_map，而不是对分组后的完整sf数据框操作，会导致孤立的sfc对象被传递，触发vec_size的类型检查错误。

解决办法： #

始终传递完整的分组sf数据框，而非单独的sfc列。如果需要单独处理空间坐标，可以提前提取为普通矩阵，绕开sfc对象的序列化问题：

result <- your_sf_data %>%
  group_by(city) %>%
  # 提取坐标为普通矩阵并嵌套
  mutate(coords = list(st_coordinates(geometry))) %>%
  nest(data = -city, coords = -city) %>%
  mutate(
    # 用base::dist计算距离，避免处理sfc对象
    nn_avg_dist = future_map_dbl(coords, ~ mean(dist(.x))),
    point_count = future_map_int(data, nrow)
  ) %>%
  ungroup() %>%
  select(city, nn_avg_dist, point_count)

3. 并行返回结果的类型不匹配 #

如果future_map的返回值是sfc对象或其他非标准向量类型，后续dplyr的列合并操作会调用vec_size检查，导致错误。

解决办法： #

确保映射函数返回的是标准R向量类型（如数值、整数），而非空间对象。比如直接返回距离的平均值，而不是距离矩阵或sfc对象。

内容的提问来源于stack exchange，提问作者pgourdon