FAQ

PROJ支持哪些文件格式?

这个 command line applications PROJ只支持文本输入和输出(除了 proj 它也接受一个简单的二进制数据流)。 projcs2cscct 需要文本文件,每行一个坐标,每个坐标标注在单独的列中。

注解

如果您的数据是以通用的地理数据文件格式存储的,那么您可以使用 GDAL 作为前端,使用 ogr2ogr 应用。

我可以从 abcxyz 是吗?

可能。PROJ支持在EPSG注册表中注册的大多数坐标参考系之间的转换,以及许多其他坐标参考系之间的转换。最好的办法是用 projinfo 应用程序。下面是一个检查ETRS89/UTM32N之间是否存在转换的示例(EPSG:25832)和ETRS89/DKTM1(EPSG:4093):

$ ./projinfo -s EPSG:25832 -t EPSG:4093 -o PROJ
Candidate operations found: 1
-------------------------------------
Operation n°1:

unknown id, Inverse of UTM zone 32N + DKTM1, 0 m, World

PROJ string:
+proj=pipeline +step +inv +proj=utm +zone=32 +ellps=GRS80
+step +proj=tmerc +lat_0=0 +lon_0=9 +k=0.99998 +x_0=200000 +y_0=-5000000 +ellps=GRS80

projinfo documentation 有关如何使用它的详细信息。

坐标参考系 xyz 不在EPSG注册表中,我该怎么办?

通常,项目将接受WKT、WKT2和项目字符串形式的坐标参考系描述。如果你能用这两种格式中的任何一种来描述你想要的CRS,PROJ很有可能会理解它。

如果将给定的CRS添加到EPSG注册表中对您很重要,您应该联系您当地的大地测量机构,并要求他们提交CRS以纳入注册表。

我在PROJ中发现了一个bug,如何修复它?

请将发现的错误报告给GitHub上的问题跟踪器。 Here's how .

如果你知道如何编程,你也可以尝试自己修复它。欢迎您就其中一个问题寻求指导 communication channels 用于项目。

我如何为项目做出贡献?

欢迎项目社区的任何贡献。看到了吗 贡献 了解更多详细信息。

如何计算地球表面的距离/方向?

这些被称为测地线计算。这里有一个关于它的页面: 测地计算 .

描述坐标参考系的最佳格式是什么?

项目中的坐标参考系(CRS)可以用几种方式描述:作为项目字符串、众所周知的文本(WKT)和空间参考ID(如EPSG代码)。通常,WKT或SRID优先于PROJ字符串,因为它们可以包含有关给定CRS的更多信息。在大多数情况下,WKT和PROJ字符串之间的转换将导致信息丢失,可能导致错误的转换。

出于兼容性原因,PROJ支持几种WKT方言(参见 projinfo -o ). 如有可能,应使用WKT2。

为什么项目中的轴顺序不一致?

项目尊重轴的顺序,因为它是由主管给定坐标系的机构定义的。这符合ISO19111标准 [ISO19111] . 不幸的是,市场上大多数GIS软件都不遵循这个标准。在版本6之前,PROJ也不遵守这个标准。这导致了一些问题,而其他行业符合标准。对于这个项目来说,它是一个很好的例子。

通常在GIS中,坐标元组中的第一个分量与东/西方向对齐,第二个分量与北/南方向对齐。对于许多坐标参考系,这也是管理局定义的。但是也有例外,特别是在处理与指南针基本方向不一致的坐标系时。例如,在与北向成45度角的倾斜坐标系中,哪个坐标分量与哪个轴对齐并不明显。类似地,地心笛卡尔坐标系通常具有与地球自转轴对齐的z分量,因此轴指向北方。这两种情况都不符合x分量始终为东/西轴、y分量始终为北/南轴、z分量始终为上/下轴的惯例。

在大多数情况下,具有大地坐标的坐标参考系期望输入按纬度/经度排序(通常使用EPSG数据集),但是,内部PROJ期望所有投影按经度/纬度排序。对于用户来说,这通常是隐藏的,但在少数情况下,它暴露在项目的表面级别,最显著的是在 proj 期望输入日期的经度/纬度排序的实用程序(除非 proj -r 使用)。

如果对特定CRS的轴顺序有疑问 projinfo 能够提供答案。只需查找CRS并检查已知文本输出的轴规格:

projinfo EPSG:4326
PROJ.4 string:
+proj=longlat +datum=WGS84 +no_defs +type=crs

WKT2:2019 string:
GEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    USAGE[
        SCOPE["unknown"],
        AREA["World"],
        BBOX[-90,-180,90,180]],
    ID["EPSG",4326]]

为什么会出现“找不到”的错误项目数据库"?

文件 proj.db 必须可读,库才能正常运行。像其他人一样 resource files ,它使用一组搜索路径进行定位。在大多数情况下,按顺序检查以下路径:

  • 环境变量提供的路径 PROJ_LIB .

  • 内置到PROJ中作为其资源安装目录的路径(通常是相对于PROJ库的../share/PROJ)。

  • 当前目录。

请注意,如果使用conda,则激活环境 PROJ_LIB 到位于该环境中的资源目录。

4号项目怎么了?

项目的第一个化身在1983年看到了曙光。那时候它被简单地称为PROJ。最终发布了一个新版本,称为PROJ.2,以区分这两个版本。后来,项目3和项目4都发布了。到PROJ.4发布时,软件已经足够成熟,不需要立即发布新的主要版本。项目4已经存在了25年多,现在又是更新的时候了。这使得这个项目在名称上有点棘手。在产品的大部分生命周期中,它被称为PROJ.4,但随着版本5的发布,名称不再与版本号一致。因此,决定将名称与版本号分离,再次简单地调用软件PROJ。

名称PROJ.4的使用现在严格保留用于描述软件的遗留行为,例如“PROJ.4 strings”,如中所示 projinfo 输出。