编写纬度和经度元组的首选顺序

Mik*_*maa 128 gis google-maps latitude-longitude

在处理GIS源代码时,您经常需要编写纬度和经度坐标元组.

例如,在谷歌地图链接(123,456):

http://maps.google.com/maps/ms?msid=214518704716144912556.00046d7689a99e95b721c&msa=0&ll=123,456&spn=0.007996,0.026865

哪个是首选顺序(为什么?)

  • 纬度,经度

  • 经度和纬度

我已经看到它们被用于各种系统,我希望找到一些证据来坚持使用其他系统.

Sha*_*ane 195

EPSG:4326明确指出坐标顺序应为纬度,经度.许多软件包仍然使用经度,纬度排序.这种情况对项目期限和程序员的理智造成了难以想象的破坏.

可以提供的最佳指导是充分了解软件堆栈中每个组件的预期轴顺序.PostGIS预计lng/lat.WFS 1.0使用lng/lat,但WFS 1.3.0遵循标准并使用lat/lng.GeoTools默认为lat/lng,但可以使用系统属性覆盖.

有关该问题的历史和解释的GeoTools文档值得一读:http://docs.geotools.org/latest/userguide/library/referencing/order.html

  • 我的回答中的前两句话:*EPSG:4326明确指出坐标顺序应为纬度,经度.许多软件包仍然使用经度,纬度排序.*是不是完全一样? (7认同)
  • 我很少在SO.com上看到答案,说明**为什么**这个好.打败那些"因为MongoDB使用它"的答案. (6认同)
  • 如果其他人在使用Google地图时遇到问题并向其提供KML文件,则订单为经度/纬度!没有KML文件的文档说这个!! (5认同)
  • 您的链接不同意您的观点;_在 EPSG 数据库中,4326 映射到具有(纬度、经度)轴顺序的地理 CRS。然而,该领域的大多数软件将 EPSG:4326 理解为具有(经度、纬度)轴顺序的地理 CRS,因为传统 OGC 规范就是这样设计的。_ (3认同)
  • "没有关于KML文件的文档说这个"是不正确的.https://developers.google.com/kml/documentation/kmlreference#point"由经度,纬度和海拔高度(按此顺序)浮点值组成的单个元组." (2认同)

Jir*_*riz 28

首选顺序是按照惯例latitude, longitude.这可能是国际海事组织在此 报告的标准化.Google还在其地图地球中使用此订单.我通过考虑字母顺序来记住这个顺序latitude, longitude.

  • 除了KML文件.坐标存储为lng,lat,alt; 可能是因为那可以转换为x,y,z (12认同)

unm*_*ted 23

几乎所有专业GIS应用中的正确顺序都是经度,纬度,就像传统的数学(即f(x ,y, z))一样.GeoJSON标准相当典型和简洁:

The order of elements must follow x, y, z order
(easting, northing, altitude for coordinates in a 
projected coordinate reference system, or longitude,
latitude, altitude for coordinates in a geographic
coordinate reference system).
Run Code Online (Sandbox Code Playgroud)

主要的开放地理空间联盟标准(WKT和WKB,以及EWKB等扩展)也是如此.同样,谷歌可以在Lat/Lon中输出订单,使其对那些习惯成长的用户更熟悉(即从IMO等导航标准而非计算导航标准.)但KML标准本身就像几乎所有其他GIS系统一样:

The KML encoding of every kml:Location and coordinate
tuple uses geodetic longitude, geodetic latitude, and
altitude (in that order).
Run Code Online (Sandbox Code Playgroud)

好的经验法则:如果你知道元组是什么并且正在编程,你应该使用lon,lat.我甚至会说这适用于你的最终用户(比如飞行员或船长)更愿意查看输出lat,lon.如有必要,您可以在UI中切换顺序,但绝大多数数据(shapefile,geojson等)都将采用正常的笛卡尔顺序.

  • 我在这里看到一些分歧:我有两个选择 - 太多了! (4认同)
  • 读者应该注意到ISO 6709明确规定你应该在任何用户界面中始终使用[lat,lon]格式,而不是 - 可能推断 - 只是个人偏好的问题. (4认同)

Chr*_*isW 9

按照惯例,在"现实生活中",当给出一个位置时,纬度(即北/南)总是给定为1,例如20°N 56°W(尽管如果考虑标准笛卡尔坐标,这不符合正常惯例网格); 类似地,维基百科上的所有坐标都遵循这个约定(例如,参见Southampton的位置:http://en.wikipedia.org/wiki/Southampton).为了避免混淆,特别是当没有包含单位时,我总是建议在元组中给出纬度第一.


Ter*_*rry 9

我个人从来没有见过任何东西,只有纬度和经度.

并且,当使用+和 - 而不是N和S时,它总是+是N而且 - 是S.

我已经观察到使用+和 - 对于E和W的变化.一般情况下+已经是E和 - 已经是W.然而,在他们与W经度过度交易的旧应用程序中,我看到+是W和 - 是E .

希望你不必处理旧的应用程序.

  • @cazort无论出于什么原因,这里都不会发生。例如,我的家乡俄勒冈州尤金(Eugene)大约在N 44.1,W 123.1。如果在maps.google.com中输入44.1 -123.1,则转到Eugene。如果我输入-123.1 44,它会告诉我找不到它。不过,有趣的是,如果我输入123.1 W 44 N,它将计算得出并转到Eugene,因此具有一定的灵活性。另外,https://www.reference.com/technology/enter-gps-coordinates-google-maps-3de6c79239e4ce0d#似乎表明纬度/经度是首选顺序。此外,就其价值而言,Google Earth使用经/纬度。 (2认同)

小智 7

出于安全原因,ISO 6709 将订单标准化为纬度、经度。格雷厄姆上面的解释对我来说也是正确的。有人建议此答案与问题无关 - 它绝对是,并解释了为什么顺序通常以纬度,经度给出。

无论导航员使用该系统多久,它都是这样列出的;现在改变它会令人困惑,并且正如 ISO 所建议的那样,具有潜在危险。GIS 软件(如 ArcMap)将它们反过来列出,因为这是 x,y 坐标对的典型约定。纬度是 y,经度是 x,这就是 Arc 列出它们的方式。


Ale*_*ski 5

除了其他人已经提到过的GeoJSON规范外,在其他一些实际情况下,建议使用经度,纬度顺序,甚至是强制性的-例如:MongoDB中的地理空间索引。如果那里的订单错误,查询将返回错误的结果,就像再次执行转置数据集一样。


小智 5

因此,首选顺序取决于个人喜好!

纬度排在首位;随着“太阳越过赤道”的日子,春分已经有千年的历史了。3月,从S到N穿过,从N到S穿过。唯一的问题可能是赤道应为0度还是90度。取0度,则春分点的垂直天顶与午间太阳天顶之间的夹角便是地球上所有位置的纬度。素数纬度或素数平行度有效地定义了自己。

经度只能通过协议达成。英国设立了经度奖。英国需要其船只知道它们的位置,并需要更好的地图。哈里森(http://www.youtube.com/watch?v=T-g27KS0yiY)生产了一款精确的航海天文钟;他们派出了制图之旅,例如詹姆斯·库克(James Cook)1770。因此,英国通过使用格林威治作为地图的000deg来宣称本初子午线。经过100年的使用,本初子午线于1884年被国际接受。

在克里斯托弗·哥伦布时代,纬度是唯一的数字。策略是在向左转或向右转到达目的地之前,先经过平行线。看着云还是鸟。每小时以节为单位的速度测量很普遍,但没有考虑到潮流。哥伦布最大的成就也许是四次从西印度群岛回国。没有这些,他发现的土地就无法添加到地图中。

阅读达瓦·索贝尔(Dava Sobel)的“经度”(ISBN:9780007214228)