在处理GIS源代码时，您经常需要编写纬度和经度坐标元组 .
例如 . 在谷歌 Map 链接（123,456）：
http://maps.google.com/maps/ms?msid=214518704716144912556.00046d7689a99e95b721c&msa=0&ll=123,456&spn=0.007996,0.026865
哪个是首选顺序（为什么？）
纬度，经度
经度，纬度
我已经看到两者都在各种系统中使用，我希望找到一些证据来坚持使用其他系统 .
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
首选订单按惯例 latitude, longitude . 据报道International Maritime Organization，这可能是International Maritime Organization的标准化 . Google还在其Maps和Earth中使用此订单 . 我记得这个顺序是通过考虑 latitude, longitude 的字母顺序 .
latitude, longitude
在几乎所有专业GIS应用中，正确的顺序是经度，纬度，就像在传统的数学中一样（即 f(x ,y, z) ） . GeoJSON标准非常典型和简洁：
f(x ,y, z)
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).
主要的开放地理空间联盟标准（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).
好的经验法则：如果您知道元组是什么并且正在编程，那么您应该使用 lon ， lat . 如果您的最终用户（比如飞行员或船长）更愿意在 lat ， lon 中查看输出，我甚至会说这适用 . 如有必要，您可以在UI中切换顺序，但绝大多数数据（shapefile，geojson等）都将采用正常的笛卡尔顺序 .
lon
lat
按惯例，在给出一个位置时，纬度（即北/南）总是给定为1，例如， 20°N 56°W（但是，如果考虑标准的笛卡尔网格，这不遵循正常惯例）;类似地，维基百科上的所有坐标都遵循此约定（例如，参见Southampton的位置：http://en.wikipedia.org/wiki/Southampton） . 为了避免混淆，特别是当单位不是't being included, I'时，总是建议在元组中给出纬度第一 .
我个人从来没有见过任何东西，只有经度跟随纬度 .
并且，当使用和 - 而不是N和S时，它总是N和 - 是S.
我观察到变化时使用和 - 对于E和W.一般是E和 - 已经是W.然而，在他们与W经度过度交易的旧应用程序中，我已经看到W和 - 是E.
希望你不必处理旧的应用程序 .
除了GeoJSON规范，其他人已经提到过，还有其他一些实际情况，建议使用经度，拉丁文顺序，甚至是强制性的 - 例如：geospatial indexing in MongoDB . 如果您在那里得到错误的订单，您的查询将返回错误的结果，就像再次执行转置数据集一样 .
所以首选顺序取决于个人喜好！
纬度排在第一位;昼夜平分点以“太阳越过赤道”的日子而闻名于千年;三月从S到N和9月从N到S.唯一的问题可能是赤道是否应该是0度或90度 . 通过取0度，昼夜平分点上的垂直和正午太阳天顶之间的角度是地球上任何地方的纬度 . 主要纬度或主要平行有效地定义了它自己 .
经度只能通过协议来实现 . 英国获得了经度奖 . 英国需要它的船只知道它们在哪里，需要更好的 Map . 哈里森（http://www.youtube.com/watch?v=T-g27KS0yiY）制作了精确的航海天文台表;他们发送了 Map 制作航行旅行，例如詹姆斯库克1770年代 . 因此，英国通过使用格林威治作为他们的 Map 的000deg来获得Prime Meridian . 经过100年的使用，Prime Meridian于1884年在国际上被接受 .
在克里斯托弗哥伦布时间，纬度是他们唯一的数字 . 策略是在向左或向右转向目的地之前穿越平行线;看着 Cloud 朵或鸟儿 . 每小时测量结节速度很常见但不考虑电流 . 也许哥伦布的最大成就是四次从西印度群岛回到家乡 . 没有它，他发现的土地无法添加到 Map 中 .
阅读Dava Sobel的“经度”（ISBN：9780007214228）
ISO 6709标准化将订单列为纬度，经度以确保安全 . 格雷厄姆上面的解释对我来说也是正确的 . 有人认为这个答案与问题无关 - 它绝对是，并解释了为什么订单通常以纬度，经度给出 .
无论漫长的导航员使用该系统，它都是如此被列出的;改变这一点现在会令人困惑，而且正如ISO所暗示的那样，有潜在危险 . GIS软件（如ArcMap）以相反的方式列出它们，因为这是x，y坐标对的典型约定 . 纬度是y，经度是x，所以这就是Arc列出它们的方式 .
经度然后纬度（lon，lat） .
当投影到墨卡托经度时，定义x方向，纬度定义y方向 . 大多数几何库严格使用（lon，lat）格式，因为它是在2D平面中考虑地理坐标的最直观方式 .
9 回答
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
首选订单按惯例
latitude, longitude. 据报道International Maritime Organization，这可能是International Maritime Organization的标准化 . Google还在其Maps和Earth中使用此订单 . 我记得这个顺序是通过考虑latitude, longitude的字母顺序 .在几乎所有专业GIS应用中，正确的顺序是经度，纬度，就像在传统的数学中一样（即
f(x ,y, z)） . GeoJSON标准非常典型和简洁：主要的开放地理空间联盟标准（WKT和WKB，以及EWKB等扩展）也是如此 . 同样，谷歌可能会输出Lat / Lon中的订单，以使熟悉该习惯的用户更熟悉（即来自IMO等导航标准，而非计算导航标准 . ）但KML标准本身就像几乎所有其他GIS系统一样：
好的经验法则：如果您知道元组是什么并且正在编程，那么您应该使用
lon，lat. 如果您的最终用户（比如飞行员或船长）更愿意在lat，lon中查看输出，我甚至会说这适用 . 如有必要，您可以在UI中切换顺序，但绝大多数数据（shapefile，geojson等）都将采用正常的笛卡尔顺序 .按惯例，在给出一个位置时，纬度（即北/南）总是给定为1，例如， 20°N 56°W（但是，如果考虑标准的笛卡尔网格，这不遵循正常惯例）;类似地，维基百科上的所有坐标都遵循此约定（例如，参见Southampton的位置：http://en.wikipedia.org/wiki/Southampton） . 为了避免混淆，特别是当单位不是't being included, I'时，总是建议在元组中给出纬度第一 .
我个人从来没有见过任何东西，只有经度跟随纬度 .
并且，当使用和 - 而不是N和S时，它总是N和 - 是S.
我观察到变化时使用和 - 对于E和W.一般是E和 - 已经是W.然而，在他们与W经度过度交易的旧应用程序中，我已经看到W和 - 是E.
希望你不必处理旧的应用程序 .
除了GeoJSON规范，其他人已经提到过，还有其他一些实际情况，建议使用经度，拉丁文顺序，甚至是强制性的 - 例如：geospatial indexing in MongoDB . 如果您在那里得到错误的订单，您的查询将返回错误的结果，就像再次执行转置数据集一样 .
所以首选顺序取决于个人喜好！
纬度排在第一位;昼夜平分点以“太阳越过赤道”的日子而闻名于千年;三月从S到N和9月从N到S.唯一的问题可能是赤道是否应该是0度或90度 . 通过取0度，昼夜平分点上的垂直和正午太阳天顶之间的角度是地球上任何地方的纬度 . 主要纬度或主要平行有效地定义了它自己 .
经度只能通过协议来实现 . 英国获得了经度奖 . 英国需要它的船只知道它们在哪里，需要更好的 Map . 哈里森（http://www.youtube.com/watch?v=T-g27KS0yiY）制作了精确的航海天文台表;他们发送了 Map 制作航行旅行，例如詹姆斯库克1770年代 . 因此，英国通过使用格林威治作为他们的 Map 的000deg来获得Prime Meridian . 经过100年的使用，Prime Meridian于1884年在国际上被接受 .
在克里斯托弗哥伦布时间，纬度是他们唯一的数字 . 策略是在向左或向右转向目的地之前穿越平行线;看着 Cloud 朵或鸟儿 . 每小时测量结节速度很常见但不考虑电流 . 也许哥伦布的最大成就是四次从西印度群岛回到家乡 . 没有它，他发现的土地无法添加到 Map 中 .
阅读Dava Sobel的“经度”（ISBN：9780007214228）
ISO 6709标准化将订单列为纬度，经度以确保安全 . 格雷厄姆上面的解释对我来说也是正确的 . 有人认为这个答案与问题无关 - 它绝对是，并解释了为什么订单通常以纬度，经度给出 .
无论漫长的导航员使用该系统，它都是如此被列出的;改变这一点现在会令人困惑，而且正如ISO所暗示的那样，有潜在危险 . GIS软件（如ArcMap）以相反的方式列出它们，因为这是x，y坐标对的典型约定 . 纬度是y，经度是x，所以这就是Arc列出它们的方式 .
经度然后纬度（lon，lat） .
当投影到墨卡托经度时，定义x方向，纬度定义y方向 . 大多数几何库严格使用（lon，lat）格式，因为它是在2D平面中考虑地理坐标的最直观方式 .