java中用double[][]存储二维网格坐标最直接：外层数组按行（如纬度带），内层数组存该行各列的坐标对，如{{116.4,39.9},{116.5,39.8}}；静态初始化适合小范围已知坐标，动态分配grid[i]=new double[]{x,y}适配不规则网格，避免冗余的double[][][]或内存连续假定。
Java 中用 double[][] 存储二维网格坐标最直接
GIS 网格坐标通常是成对的经纬度或平面直角坐标（x, y），每个格网单元对应一个点或一个范围。用 double[][] 是最自然的选择：外层数组按行（如纬度带），内层数组存该行上各列的坐标对。
常见错误是试图用 double[x][y][2] 表示“x 行 y 列，每格含 2 个坐标值”——这虽可行，但访问 grid[i][j][0] 显得冗余；更简洁的做法是让每个元素本身就是一个长度为 2 的 double[]：
-
double[][] grid = {{116.4, 39.9}, {116.5, 39.8}, {116.6, 39.7}};—— 静态初始化，适合小范围已知坐标 -
double[][] grid = new double[1000][];→ 后续逐行分配：grid[0] = new double[]{116.4, 39.9};—— 动态构建，适配不规则行列或运行时读取 - 别写
double[][] grid = new double[1000][2];再挨个赋值grid[i][0] = x; grid[i][1] = y;，除非你明确需要内存连续布局（一般 GIS 应用不需要）
C# 里必须用 double[,] 还是 double[][]？看是否需要矩形结构
C# 区分“矩形数组”（double[,]）和“交错数组”（double[][]）。GIS 网格若严格是规则栅格（如 512×512 像素的 DEM），double[,] 支持快速索引和底层优化；但若每行格网数不同（比如按地理区划拼接的非均匀网格），只能用 double[][]。
典型误用：声明 double[,] coords = new double[3, 2]; 后想用 coords[0] = new double[]{116.4, 39.9}; —— 编译失败。double[,] 是单一块内存，不能给“行”重新赋整个数组。
- 规则网格（推荐）：
double[,] grid = { {116.4, 39.9}, {116.5, 39.8}, {116.6, 39.7} };（注意是逗号分隔，不是嵌套大括号） - 不规则网格（唯一选择）：
double[][] grid = new double[3][]; grid[0] = new double[]{116.4}; grid[1] = new double[]{116.5, 39.8}; - 从 ArcGIS Pro 或 netCDF 读坐标时，通常拿到的是交错结构，直接映射到
double[][]更安全
避免把多维数组当“三维坐标容器”来用
有人会想：“经纬度+高程=三维，那我该用 double[][][] 吧？”——实际极少需要。GIS 中高程通常是独立栅格层（另一个 double[][]），或作为属性附加在点要素中。强行塞进第三维会导致：
- 内存浪费：大部分格网无高程值，填
Double.NaN或 0 后难以区分真实零值 - 访问复杂：要写
coords[i][j][2]而不是elevations[i][j]，后续做坡度、视线分析等操作时逻辑割裂 - 与标准格式脱节：netCDF 多维变量是按维度（
lat,lon,time）正交组织的，不是[i][j][k]套娃
真正需要第三维的场景，是时间序列栅格（如每日降水），此时应按 double[time][row][col] 组织，并用 netCDF 或 crf 格式持久化，而非裸数组。
从 netCDF 加载坐标时，double[][] 很可能只是中间表示
如果你正在解析 netCDF 文件里的 lat 和 lon 变量，它们大概率是两个一维数组：double[] lats, double[] lons。生成二维网格坐标矩阵其实是笛卡尔积，不是直接读出的：
double[][] coords = new double[lats.length * lons.length][2]; → 这种写法容易 OOM；更合理的是按需计算，或用 GridGeometry 类封装索引逻辑。
容易被忽略的一点：netCDF 的 lat/lon 常是非线性采样（如极投影），直接双循环生成 [i][j] 对可能丢失地理精度。ArcGIS 的 arcpy.mdinfo 或 GDAL 的 GetGeoTransform() 才是可靠坐标推算依据。
