gridfs本身不支持地理空间索引，需手动在fs.files的metadata.location字段创建2dsphere索引；geojson必须符合wgs84坐标系且坐标顺序为[经度,纬度]；fs.chunks不可加地理索引；空间查询仅用于元数据过滤，无法实现地理范围内的chunk级流式读取。
GridFS 本身不支持地理空间索引
GridFS 是文件分块存储机制，fs.files 存元数据、fs.chunks 存二进制块，两个集合默认都不带 2dsphere 索引。即使你在 fs.files 文档里写了 location 字段并填了 GeoJSON，MongoDB 也不会自动识别为地理空间字段——必须手动建索引，否则所有 $near、$geoWithin 查询都会报错或全表扫描。
- GeoJSON 必须严格符合格式：
{ type: "Point", coordinates: [longitude, latitude] }，经度在前、纬度在后，顺序反了会导致索引构建失败或查询结果异常 -
fs.files是普通集合，可像其他集合一样添加索引，但fs.chunks不应加地理索引（它只存二进制块，无空间意义） - 索引命令必须显式执行：
db.fs.files.createIndex({ "metadata.location": "2dsphere" })，不能依赖驱动自动创建
把 GeoJSON 放进 metadata 字段最安全
GridFS 规范明确建议将自定义元数据写入 metadata 子文档，而不是平铺在 fs.files 顶层。这样既避免和 GridFS 内置字段（如 filename、uploadDate）冲突，也方便后续统一管理遥感影像的时空属性。
- 上传时用驱动的
put()方法传入metadata对象，例如 Python PyMongo：fs.put(data, filename="S2A_20240512_B04.tif", metadata={"location": {"type":"Point","coordinates":[116.35,39.98]}, "acquisition_date": "2024-05-12"}) - 不要把
location直接写在根级，比如{ location: {...}, filename: ... }—— 某些旧版驱动会忽略非metadata下的字段，或导致聚合管道引用混乱 - 如果需支持多点/多边形覆盖范围（如整景影像的 footprint），用
Polygon更合适：{"type":"Polygon","coordinates":[[[116.3,39.9],[116.4,39.9],[116.4,40.0],[116.3,40.0],[116.3,39.9]]]}
查询遥感影像时注意坐标系与精度陷阱
MongoDB 的 2dsphere 索引强制要求 GeoJSON 使用 WGS84 坐标系（EPSG:4326），且所有坐标值必须是数字类型。遥感影像的原始坐标如果是平面坐标（如 UTM）、或带单位字符串（如 "116.35°E"）、或用了科学计数法（1.1635e2），查询会静默失败或返回空结果。
- 入库前务必清洗：用
parseFloat()或等效方法确保coordinates数组内全是浮点数，且范围合法（经度 -180~180，纬度 -90~90） - 避免在
metadata里混用不同坐标系字段，比如同时存location_wgs84和location_utm—— 查询时容易选错字段，且无法跨字段做空间运算 - 对大范围影像（如 Landsat 整轨），优先用
Polygon描述 footprint；用Point只适合中心点粗略检索，实际匹配率低
读取影像时无法直接按空间范围流式拉取
GridFS 支持按字节范围读取（如视频“跳转”），但这个能力基于 fs.chunks 的 n 字段顺序，和地理空间无关。你不能用 $geoWithin 查出一批影像后，再让 GridFS “只传其中经纬度矩形框内的像素块”——chunk 是按文件偏移切的，不是按地理格网切的。
- 典型流程只能是两步：先用
fs.files做空间查询拿到_id列表，再用这些_id调用get()下载完整文件 - 若真需要地理子区提取（如只取某县范围的 TIFF 片段），得靠应用层解析影像格式（如 GDAL），在下载后裁剪，GridFS 不参与这个过程
- 高频空间查询 + 大文件场景下，
fs.files的2dsphere索引要配合filename或时间字段做复合索引，否则单靠地理索引性能会随数据量陡增
