RFC 20:OGRSpatialReference轴支持

作者：弗兰克·温特丹

联系方式：warmerdam@pobox.com

状态：通过

总结

OGRSpatialReference和OGRCoordinateTransformation类假设所有坐标系使用（东距、北距）坐标顺序（或地理术语（经度、纬度））。实际上，一些坐标系使用交替轴方向（如Krovak投影），一些标准（GML、WMS 1.3、WCS 1.1）要求遵守EPSG声明，即其所有地理坐标具有（纬度、经度）坐标顺序。

此RFC尝试扩展OGRSpatialReference和OGRCoordinateTransformation类以支持交替轴方向，并更新选定的驱动程序（GML、WMS、WCS、GMLJP2）以正确支持轴排序。

WKT轴表示

OGC WKT SRS格式（根据OGC 01-？？？）已指示定义坐标系轴的方法，如本例所示：

GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9108"]],
    AXIS["Lat",NORTH],
    AXIS["Long",EAST],
    AUTHORITY["EPSG","4326"]]

每个轴有一个轴定义，其顺序与元组内的位置有关。第一个参数是轴的用户名，不指定确切的值。第二个论点是一个方向，可以是北、南、东或西。

困境

此RFC的核心挑战是增加对轴顺序的支持，包括在适当的情况下遵守EPSG地理坐标系所需的轴顺序，而不破坏现有的文件和代码，这些文件和代码广泛使用EPSG坐标系，但会覆盖轴方向，并假定它们应被视为长轴，不管爱普生怎么说。

特别是，我们提出了适当的政策和机制，以决定何时将EPSG:4326这样的地理坐标系中的文件视为lat/long，何时应为long/lat。由于广泛的现有做法，我们有必要在过去做法的基础上犯错误，并要求“选择”遵守EPSG axis顺序。

黑客

我提出解决这一难题的主要机制是区分设置了轴值的地理坐标系和没有设置轴值的地理坐标系。特别是，WKT坐标系与EPSG权限代码（即4326）集，但不会假设轴声明是长的，即使这与EPSG 4326的定义相反。只有在我们真的 know 我们要遵守EPSG的axis命令，我们将实际填充表示lat，long的axis声明。

希望这将允许我们继续（mis）使用EPSG:4326定义，而不必遵守EPSG axis排序，除非在特定情况下。

OGRSpatialReference

新枚举

typedef enum {
  OAO_Unknown = 0,
  OAO_North = 1,
  OAO_South = 2,
  OAO_East = 3,
  OAO_West = 4
} OGRAxisOrientation;

新方法

const char *GetAxis( const char *pszTargetKey, int iAxis,
                     OGRAxisOrientation *peOrientation );

获取有关一个轴的信息（iAxis是基于零的）。

OGRErr      SetAxes( const char *pszTargetKey,
                     const char *pszXAxisName, OGRAxisOrientation eXAxisOrientation,
                     const char *pszYAxisName, OGRAxisOrientation eYAxisOrientation,
                     const char *pszZAxisName=NULL, OGRAxisOrientation eZAxisOrientation = OAO_Unknown );

定义给定目标键（PROJCS或GEOGCS）的X和Y轴。

int         EPSGTreatsAsLatLong();

如果EPSG希望将此坐标系视为lat/long，则基于EPSG代码返回true。这在WMS 1.3这样的上下文中很有用，其中EPSG:4326由于标准的原因需要解释为lat/long。

OGRErr      importFromEPSGA( int );

这与importFromEPSG（）类似，但将分配EPSG定义的轴定义。

请注意，OGRSpatialReference：：StripNodes（“AXIS”）；可用于删除不需要的轴定义。

重要的

Modify importFromURN（）为EPSG和OGC地理坐标系正确设置轴值。所以urn:…：EPSG:将被假定为真正遵守EPSG惯例。

SetWellKnownGeogCS（）

此方法似乎是唯一的代码

• 将SetWellKnownGeogCS（）修改为 not 设置轴值，并从任何其他硬编码WKT定义中删除轴值。

导入程序（）

• importFromEPSG（）将继续 not 设置GEOGCS坐标系的轴值。

• importFromEPSG（）现在将为投影坐标系设置轴值（至少在Krovak等非默认轴方向的情况下）。

• importFromEPSG（）将通过调用importFromEPSGA（）和从返回定义的地理部分剥离轴定义来实现。

SetFromUserInput（）

• 此方法将有一个新选项，其前缀为EPSG a:的值将传递给importFromEPSGA（）（与EPSG:n传递给importFromEPSG（）类似）。

OGRCoordinateTransformation

如果在源坐标系和/或目标坐标系上设置轴值，则OGRCoordinateTransformation代码将在调用项目之前负责转换为正常的东距/北距。

CPL配置选项“GDAL_IGNORE_AXIS_ORIENTATION”也可以设置为“TRUE”以禁用OGRCoordinateTransformation的检查和轴方向更改的应用。实际上，这是一个后门，以禁用核心影响的RFC。

受影响的司机

• GMLJP2（gcore/gdalgmlcoverage.cpp和gcore/gdaljp2metadata.cpp中的类）。

• WCS（基于对URN的解释）。

• WMS（也许？实际上，我怀疑我们并没有从能力机构得到坐标系）

• OGR GML（也许？只有GML3受到影响？）

• BSB、SARúceo、ENVISAT、HDF4、JDEM、L1B、LAN、SRTMHGT：与setwellknowngecogcs（）一样，这些都在其硬编码WGS84坐标系中包含lat/长轴规范。这些需要删除，因此它们将默认被解释为long/lat。

版本

工作将在GDAL/OGR 1.6.0的中继中，但以下例外情况将在1.5.x中找到：

• 对于地理坐标系，现有的AXIS说明符将从SetWellKnownGeogCS（）和带有硬编码WKT字符串的各种驱动程序中删除。

• 需要在GMLJP2（可能还有WCS）代码中引入某种黑客来翻转EPSG authority lat/long值（细节有待解决）。

实施

实施工作将由Frank wartemdam完成。某些方面（例如正确捕获投影坐标系的轴顺序）可能无法立即实现。

兼容性问题

最令人担忧的是，任何具有LAT/LONG axis排序（例如在VRT文件或.aux.xml文件中）的现有WKT坐标系在GDAL/OGR 1.6.0中的解释与在1.5.0中的解释不同。如果使用WKT坐标系（如JPEG和.aux.xml文件）将BSB或HDF4等格式的文件复制为某种格式，则很容易发生这种情况。为了部分缓解这种情况，我建议从GDAL 1.5.1中删除AXIS定义。

支持信息

• OSGeo Wiki摘要： http://wiki.osgeo.org/index.php/Axis_Order_Confusion