OGC WKT坐标系问题

This document is intended to discuss some issues that arise in attempting to use OpenGIS Well Known Text descriptions of coordinate systems. It discusses various vendor implementations and issues between the original "Simple Features" specification (ie. SF-SQL 99-049) and the newer Coordinate Transformation Services (CT) specification (01-009) which defines an extended form of WKT.

WKT实施

目前，我至少知道以下软件包在内部使用某种形式的WKT，或用于坐标系描述的交换：

• Oracle Spatial（WKT在MDSYS.WKT内部使用，松散地基于SFSQL）

• ESRI—Arc8系统的投影引擎使用了一个与投影功能兼容的简单描述。我相信ESRI为简单特性规范提供了WKT定义。

• Cadcorp-具有读写CT 1.0风格WKT的能力。Cadcorp编写了CT规范。

• OGR/GDAL-读取/写入WKT作为其内部坐标系描述格式。尝试支持新旧表单以及来自ESRI的表单。

• FME—包括基于OGR构建的WKT读/写功能。

• MapGuide-在SDP数据访问API中使用WKT。大致符合SF标准。

• PostGIS-将WKT保存在spatial-ref-sys表中，但要由客户转换为PROJ.4格式以供实际使用。我相信space_ref_sys表是使用OGR生成的翻译填充的。

投影参数

各种等级库不列出一组投影及其相关参数。这将导致从不同的供应商中选择不同的参数名（有时还有投影名）。我试图维护不同投影的WKT绑定列表，作为我的 GeoTIFF Projections List 登记处。请尝试遵守此处列出的投影名称和参数。该列表还试图将预测与GeoTIFF、EPSG和PROJ.4公式联系起来。

有一个例子，在它后面没有一个供应商，我知道ESRIs定义的Lambert共形二次曲线。在EPSG中有一个1SP和一个2SP的形式。ESRI将它们合并，并根据类型有不同的参数。

另一个问题是CT规范明确列出了横向墨卡托、LCC 1SP和LCC 2SP投影的参数；但是，它将标准_parallel1和标准_parallel2列为LCC 2SP的参数，这与标准_parallel_1和标准_parallel_2的现有用法相冲突，并且与同一CT规范中的示例相冲突。我的立场是，CT规范第10.x节中的表格有误，并且广泛使用的表格是正确的。请注意，CT规范中的表与同一规范中的其他示例冲突。

第三个问题是制定反照率。当我使用中心经度和中心纬度时，ESRI使用中心子午线和中心纬度。

血沉：

PROJECTION["Albers"],
PARAMETER["False_Easting",1000000.0],
PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",-126.0],
PARAMETER["Standard_Parallel_1",50.0],
PARAMETER["Standard_Parallel_2",58.5],
PARAMETER["Latitude_Of_Origin",45.0],

OGR:

PROJECTION["Albers"],
PARAMETER["standard_parallel_1",50],
PARAMETER["standard_parallel_2",58.5],
PARAMETER["longitude_of_center",-126],
PARAMETER["latitude_of_center",45],
PARAMETER["false_easting",1000000],
PARAMETER["false_northing",0],

基准名称

在简单要素样式WKT中，与基准关联的名称是标识基准的唯一方式。在CT WKT中，数据还可以有一个TOWGS84参数，指示其与WGS84的关系，以及一个与EPSG或某些其他权限空间相关的权限参数。然而，在SF WKT中，名字本身是唯一的关键。

按照惯例，OGR和Cadcorp已经从EPSG数据库以特定的方式翻译了数据名称，以便生成可比较的名称。规则是将所有非字母数字字符转换为下划线，然后去掉任何前导、尾随或重复下划线。这就产生了表现良好的基准名称，如“新三角测量法”。

然而，其他供应商做了不同的事情。ESRI似乎遵循了类似的约定，但也在所有的数据名前面加上了“D”前缀，给出了类似于“D戋WGS戋1972”的名称。此外，他们还有许多其他的分歧，原因尚不清楚。例如，Cadcorp和OGR称之为“新三角测量法”，他们称之为“D-NTF”。Oracle似乎未经清理就使用原始名称。所以对于NTF他们使用“NTF（巴黎子午线）”。

这样做的简短结果是，几乎不可能识别和比较不同简单功能实现之间的基准，尽管我在翻译ESRI基准名称以匹配Cadcorp/OGR约定方面取得了一些成功，并使用了一些特殊的大小写。

参数排序

值得注意的是，SF规范中WKT的BNF语法和CT规范暗示了大多数项目的特定顺序。例如，CT规范中PROJCS项的BNF是

<projected cs> =
  PROJCS["<name>", <geographic cs>, <projection>, {<parameter>,}* <linear unit> {,<twin axes>}{,<authority>}]

This clearly states that the PROJECTION keyword follows the GEOGCS, followed by the UNIT, AXIS and AUTHORITY items. Providing them out of order is technically a violation of the spec. On the other hand, WKT consumers are encouraged to be flexible on ordering.

参数单位

投影仪中的线性参数值必须以该投影的线性单位为单位。我认为唯一的线性单位是假东距和北距类型值。因此，在通常情况下，如以英尺为单位的国家平面区域，假东距和北距也将以英尺为单位。

投影仪中的角参数值必须是GEOGCS的角度单位。例如，如果GEOGCS是水平的，那么所有的投影角也必须是水平的！

质数单位

本初子午线应该以什么单位出现？

• CT 1.0规范（7.3.14 primer）规定 “的单位必须从上下文中推断出来。如果PRIMEM子句出现在GEOGCS中，则经度单位将与地理坐标系的经度单位匹配。” 注：对于地心坐标系 如果prime子句出现在geocs中，则单位为度 .

• SF-SQL规范（99-049）没有试图解决本初子午线的单位问题。

• 现有的ESRI-EPSG到WKT的转换使用基本子午线的度数，即使GEOGCS是梯度的，如EPSG 4807的转换所示：

  GEOGCS["GCS_NTF_Paris",
    DATUM["D_NTF",
      SPHEROID["Clarke_1880_IGN",6378249.2,293.46602]],
    PRIMEM["Paris",2.337229166666667],
    UNIT["Grad",0.015707963267948967]]
  

• OGR为其OGRSpatialReference类实现了与ESRI相同的解释：原始经度始终以度为单位。见 GDAL Ticket #4524

  GEOGCS["NTF (Paris)",
      DATUM["Nouvelle_Triangulation_Francaise_Paris",
          SPHEROID["Clarke 1880 (IGN)",6378249.2,293.4660212936269,
              AUTHORITY["EPSG","7011"]],
          TOWGS84[-168,-60,320,0,0,0,0],
          AUTHORITY["EPSG","6807"]],
      PRIMEM["Paris",2.33722917,
          AUTHORITY["EPSG","8903"]],
      UNIT["grad",0.01570796326794897,
          AUTHORITY["EPSG","9105"]],
      AUTHORITY["EPSG","4807"]]
  

• Cadcorp根据其翻译的EPSG 4807所示的CT 1.0规范实施：

  GEOGCS["NTF (Paris)",
    DATUM["Nouvelle_Triangulation_Francaise",
      SPHEROID["Clarke 1880 (IGN)",6378249.2,293.466021293627,
        AUTHORITY["EPSG",7011]],
      TOWGS84[-168,-60,320,0,0,0,0],
      AUTHORITY["EPSG",6275]],
    PRIMEM["Paris",2.5969213,
      AUTHORITY["EPSG",8903]],
    UNIT["grad",0.015707963267949,
      AUTHORITY["EPSG",9105]],
    AXIS["Lat",NORTH],
    AXIS["Long",EAST],
    AUTHORITY["EPSG",4807]]
  

• OracleSpatial8.1.7使用了以下定义，我假设它应该是EPSG4807。有趣的是，它不费心使用梯度，而且似乎本初子午线以弧度表示，精度非常低！

  GEOGCS [ "Longitude / Latitude (NTF with Paris prime meridian)",
    DATUM ["NTF (Paris meridian)",
      SPHEROID ["Clarke 1880 (IGN)", 6378249.200000, 293.466021]],
    PRIMEM [ "", 0.000649 ],
    UNIT ["Decimal Degree", 0.01745329251994330]]
  

TOWGS84旋转迹象

讨论

在EPSG中有两种定义7参数bursa-wolf参数的方法：9606（位置向量7参数）和9607（坐标系旋转）。唯一的区别是旋转系数的符号在它们之间是相反的。

我（Frank wartemdam）不知怎么说服自己，WKT中的TOWGS84值应该使用9606中的sense（位置向量7参数）来完成，如果我读到9607，我需要在WKT中放入TOWGS84块之前切换旋转符号。

然而，我看到在WKT垃圾场你（马丁从Cadcorp）寄给我你是使用9607的意义。例如，此项似乎直接使用9607个值而不切换符号。

GEOGCS["DHDN",
   DATUM["Deutsche_Hauptdreiecksnetz",
     SPHEROID["Bessel 1841",6377397.155,299.1528128,AUTHORITY["EPSG","7004"]],
     TOWGS84[582,105,414,-1.04,-0.35,3.08,8.3],
     AUTHORITY["EPSG","6314"]],
   PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
   UNIT["DMSH",0.0174532925199433,AUTHORITY["EPSG","9108"]],
   AXIS["Lat",NORTH],AXIS["Long",EAST],AUTHORITY["EPSG","4314"]]

我阅读了1.0ct规范中的TOWGS84[]条款，它只是谈到它们是Bursa Wolf转换参数（第22页，7.3.18）。我还扫描了12.3.15.2和12.3.27，它们对TOWGS84旋转的利手没有特异性。

我要求澄清TOWGS84是否与EPSG 9606或EPSG 9607匹配。此外，我希望看到规范的任何未来版本都能澄清这一点，引用EPSG方法定义。

Martin wrote back that he was uncertain on the correct signage and that the Adam had programmed the Cadcorp implementation empirically, according to what seemed to work for the test data available.

我准备遵守Cadorp标志使用（根据EPSG 9607），如果这可以在规范中澄清。

OGR实现的现状

OGR从WKT导入/导出假定EPSG 9606约定（位置向量7-参数），如下 proj.4 does .

当从用EPSG 9607表示的EPSG参数导入时，它进行适当的转换（否定旋转项的符号）。

相对于质数的经度？

另一个相关的问题是，长径投影参数（即中央子午线）是相对于GEOGCS本初子午线还是相对于格林威治。虽然最简单的方法是把所有经度都看作是相对于格林威治的，但我不知何故在某一点上说服了自己，经度本来是相对于本初子午线的。然而，在CT 1规范中对7.3.11（描述参数）的评论没有支持这一观点，并且在CADCORP中对EPSG 25700的检查也表明中央子午线是相对于格林尼治而不是原始子午线的。

PROJCS["Makassar (Jakarta) / NEIEZ",
    GEOGCS["Makassar (Jakarta)",
        DATUM["Makassar",
            SPHEROID["Bessel 1841",6377397.155,299.1528128,
                AUTHORITY["EPSG","7004"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6257"]],
        PRIMEM["Jakarta",106.807719444444,
            AUTHORITY["EPSG","8908"]],
        UNIT["DMSH",0.0174532925199433,
            AUTHORITY["EPSG","9108"]],
        AXIS["Lat","NORTH"],
        AXIS["Long","EAST"],
        AUTHORITY["EPSG","4804"]],
    PROJECTION["Mercator_1SP",
        AUTHORITY["EPSG","9804"]],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",110],
    PARAMETER["scale_factor",0.997],
    PARAMETER["false_easting",3900000],
    PARAMETER["false_northing",900000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["X","EAST"],
    AXIS["Y","NORTH"],
    AUTHORITY["EPSG","25700"]]

基于此，我假设参数是以GEOGCS为单位的，但它们不是相对于GEOGCS本初子午线的。

WKT中的数值精度

The specification does not address the precision to which values in WKT should be stored. Some implementations, such as Oracles apparently, use rather limited precision for parameters such as Scale Factor making it difficult to compare coordinate system descriptions or even to get comparable numerical results.

最佳实践是保持源数据库中指定的原始精度，如可能的话，EPSG。考虑到许多系统不跟踪精度，至少建议生成相当于C“%.16g”格式的值，保持16位精度，捕获双精度IEEE浮点值的大部分精度。

其他音符

1. ESRI似乎使用等距圆柱来表示我所知道的等矩形。

---

历史

• 2018年：甚至鲁奥：明确OGR为TOWGS84执行EPSG 9606公约。

• 2018:Even Rouault:删除关于CT 1.0规范（7.3.14 primer）有错误的说明，并明确提到OGR使用度表示primer经度。

• 2018:Even Rouault:添加超链接

• 2007年或以前：原作者 Frank Warmerdam .