同一TIFF文件生成的<code>terra</code> SpatRaster与RasterLayer有何差异？

假设两者均源自同一TIFF文件，核心差异集中在结构、性能、API设计和生态支持上：

1. 对象结构与底层实现 #

• SpatRaster：基于C++后端的轻量化S4类，原生支持多波段存储（单个对象可包含多个栅格图层），内存布局紧凑，避免了raster系列对象的零散结构。
• RasterLayer：纯R实现的S4类，仅支持单图层存储，多波段需依赖RasterStack/RasterBrick，这类组合对象的内存管理效率较低。

2. 性能与内存表现 #

• 速度：terra的核心操作（裁剪、重采样、投影转换）依赖C++优化，比raster快2-10倍不等，大文件处理时差距更明显。
• 内存管理：SpatRaster的延迟加载机制更智能，默认仅读取元数据，按需加载数据块；RasterLayer的延迟加载逻辑较老旧，处理超大文件时易出现内存溢出。
• 并行支持：terra原生支持部分并行操作（如app()函数可指定cores参数），无需额外依赖；raster需结合parallel等包手动实现并行，步骤繁琐。

3. API设计与操作体验 #

• 命名一致性：terra的函数命名更统一，比如用rast()创建对象，crop()、resample()、project()处理空间操作，参数逻辑连贯；raster的函数命名较混乱，比如投影转换用projectRaster()，部分参数与terra不兼容。
• 格式支持：SpatRaster原生支持云优化栅格（COG）、NetCDF4等现代格式，无需额外转换；raster对新格式支持有限，部分格式需要依赖第三方包处理。
• 返回值一致性：terra的所有空间操作基本返回SpatRaster系列对象，无需额外类型判断；raster不同操作可能返回RasterLayer/Stack/Brick，需要手动转换适配。

4. 元数据处理 #

• 便捷性：SpatRaster用crs()、res()、ext()函数可直接读写投影、分辨率、范围，修改后即时生效；RasterLayer修改元数据后常需重新构建对象（如修改投影后必须调用projectRaster才能生效）。
• 坐标系兼容性：SpatRaster支持更多EPSG代码和小众坐标系，识别速度更快；raster在处理非WGS84/UTM类坐标系时，兼容性和稳定性稍差。

5. 生态与维护状态 #

• terra是raster包的官方替代升级，由同一作者开发，新功能（如矢量栅格一体化操作、GPU加速支持）仅在terra中更新；raster已进入维护状态，不再添加新功能，仅修复严重bug。
• 两者可通过as()函数双向转换（as(rast_obj, "RasterLayer")或as(raster_obj, "SpatRaster")），但部分旧raster函数无法直接兼容SpatRaster。

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