LatLon 또는 LonLat로 좌표 및 입력 표시?

이것이 다른 사람들에게 문제가되거나 모든 입력 / 출력에 레이블을 지정하여 사용자가 혼란스럽지 않고 그냥 가야하는지 이해하려고합니다.

나는 거의 모든 사람들이 그것을 "LatLon"이라고 발음한다고 생각합니다.

누가 시작 했습니까?

"LonLat"에 비해 알파벳 순서로되어 있습니까?

Lat 및 Lon을 직교 평면에 매핑 Lon은 "x"이고 Lat는 "y"이므로 "(x, y)"라고 말하면 "LonLat"이라고합니다. 이제 정보를 표시합니다.

매핑 응용 프로그램의 상태 표시 줄에 La, Lo 또는 Lo, Lat이 표시되어야합니까?

한 가지 방법으로 만 레이블을 지정하고 사용자가 처리하도록해야합니까?

입력과 마찬가지로 필드를 주문하는 올바른 방법은 무엇입니까?

KML의 형식은 Lon, Lat, Altitude입니다. 다른 앱은 Lat이지만, Long은 형식을 변환 할 때 매우주의해야합니다.

표준이 있습니까?

ISO 표준 6709를 살펴 봐야합니다. 위키피디아 항목은 다음과 같습니다. ISO 6709

주요 항목은 순서가 항상 위도 경도 여야한다는 것입니다.

위도는 경도보다 먼저 온다

[현재 6709 : 2008의 사본이 있으므로 편집하십시오]

데이터 교환에는 DD를 사용하지만 이전 버전과의 호환성에는 sexagesimal이 유효합니다.

그림과 함께 "위도와 경도 좌표는 고유하지 않습니다"라는 섹션이 있습니다.

표시를 위한 좌표 순서 (교환이 아님)에 대해 매우 강력한 문구가 있습니다. 네비게이터는 전통적으로 위도 경도 순서를 사용했으며 순서를 변경하면 안전이 손상 될 수 있다고합니다. +/- 대신 sexagesimal, 방향 기호를 사용하십시오. Z 값은 경도를 따릅니다. 그리드 / 평면 값은 CRS 정의에 지정된 순서를 사용해야합니다.

34 ° 05'09.76 "N 117 ° 02'01.23"W 829.1m

(아! 나는 샘플을 쓰기 시작했고 경도 값을 먼저 자동으로 썼다)

지구상의 위치를 ​​나타내는 것은 지구상의 일반적으로 (위도, 경도, 고도)로 표현되는 2 개가 아닌 3 개의 값이 필요합니다. 컴퓨터는 일반적으로 (x, y) 좌표로 이해하기 쉬운 종이지도와 같이 데카르트 공간에서 작동하므로 충돌이 발생합니다.

이 순서는 구형 좌표에 대한 몇 가지 역사적 규칙을 따르며 다음과 같이 지리적 좌표에 매핑됩니다.

geographic spherical   symbol
---------- ---------   ------
longitude  azimuth       φ
latitude   inclination   θ 
elevation  radius        r

(r, θ, φ) ( 물리 커뮤니티 의 ISO 표준 이지만 다른 곳 에서는 정하지는 않음)의 일반적인 순서는 우리가 단위 구에서 작업하고 있다고 가정 할 때 (θ, φ)로 단순화합니다. 경도).

직교 좌표를 사용하는 환경에서 GIS가 구현되어 나머지 시스템 전체에서 사용되므로 약간의 충돌이 있습니다. 중요한 문제는 사용중인 것을 명확하게하고 고수하는 것입니다.

나는 개인적으로 다른 곳의 공통점 때문에 데카르트 단위를 선호하며 구형 좌표에 대한 학문적 연결은 잊혀지지 않지만 새로운 시스템을 구현할 때 실용적인 선택은 아닙니다. (x, y) 형식은 WKT, Shapefiles, GeoJSON 등과 같은 대부분의 공간 파일 형식에서 내부적으로 사용됩니다. 그러나 일반 청중에게 데이터를 제공하는 경우 올바른 내용은 이해하기 쉬운 항목에 따라 다릅니다. .

이전의 두 가지 답변은 이미 역사를 다루고 있습니다. 여기 표준에 대한 2 센트가 있습니다.

데이터 교환을 위해 좌표 순서는 OGC가 Axis Order Policy Guidance Note에 제시 한 CRS의 선택에 따라 결정됩니다 .

자세히 살펴보면 EPSG CRS는 축의 순서를 지정하며, 이는 CRS를 사용하도록 표시된 페이로드에서 존중되어야합니다. 예를 들어, epsg : 4326 (WGS 84 geographic 2D)로 데이터를 게시하는 모든 것은 (lat, lon)으로 표시되는 좌표를 가져야합니다. EPSG 레지스트리를 직접 확인할 수 있습니다 (코드 4326을 검색하고 Ellipsoidal CS / Axes를보십시오).

CRS를 지정하는 데 널리 사용되는 또 다른 방법은 Projection WKT (섹션 7; 여기서도 사용 가능 )이며 주문을 규정합니다. 예를 들어

...
AXIS["Lat",NORTH],
AXIS["Lon",EAST],
...

그러나 AXIS 매개 변수는 선택 사항 이며이 사양에 따른 기본값은 다음과 같습니다.

AXIS["Lon",EAST],AXIS["Lat",NORTH].

EPSG와 동일한 축 순서를 명시 적으로 지정하지는 않지만 epsg : 4326 ( 예 : patialreference.org에있는 파일)을 참조하는 많은 .prj 파일이 있음을 의미하기 때문에 전체 문제를 매우 혼란스럽게 만듭니다. EPSG 코드는 OGC 지침 노트와 충돌합니다.

이것은 일반적인 문제입니다. 여기에 또 다른 이전 토론이 있습니다.

• 일부 좌표계가 x 축을 북쪽으로 정의하고 일부는 동쪽으로 정의하는 이유는 무엇입니까?

http://wiki.osgeo.org/wiki/Axis_Order_Confusion 에서 매우 철저한 토론이 있습니다 .

@wwnick는 위의 정보를 중복 질문에 대한 의견으로 제공했습니다.

이것은 AutoCAD가 2 년 동안 90d 위치에서 시작하여 0도 각도로 시계 반대 방향으로 각도를 읽는다는 사실로 인해 큰 문제를 일으켰습니다. 한동안 나는 x가 북쪽이되고 y가 동쪽이되도록 UCS를 바꿔서 해결했다고 생각하고 싶었다. 2D 속성 계획을 계속해서 작성하는 한 실제로 내 오류에 직면하지 못했습니다. z 축이 잘못된 방향을 가리 켰습니다.

물론 내 치수 문자는 일반적으로 오른쪽에서 왼쪽으로 읽었지만 정확한 각도 판독 및 포인트까지 지불하는 것이 작은 가격이라고 생각했습니다. 컨벤션). 그런 다음 Autocad Civil 3d를 졸업하고 트릭을 다시 수행하고 결론을 내 렸습니다. y는 북쪽 / 위도, x는 동쪽 / 길이입니다. 받아 들여