EQUATOR GNSS / BY TECHNOGIS독일 · 인도네시아
좌표와 높이

GNSS 데이터의 좌표 축 순서: 그럴듯한 실수 방지

모든 수입, 변환 및 교환 경계에서 경도-위도, 위도-경도 및 동쪽 좌표-북 좌표 규칙을 명시합니다.

GNSS 데이터의 좌표 축 순서: 그럴듯한 실수 방지

축 순서를 참조의 일부로 취급합니다

좌표는 정의된 참조 및 인터페이스 규칙에 따라 의미가 달라지는 순서 값입니다. 지리적 데이터는 위도-경도 또는 경도-위도로 표시될 수 있으며 투영된 데이터는 일반적으로 동쪽 좌표-북 좌표를 사용합니다. x로 향하는 열은 그 의미를 결정하기에 충분하지 않습니다. 하나의 응용 프로그램의 습관에 의존하기보다 축 이름, 단위 및 순서를 기록하십시오.

소프트웨어가 명시적으로 처리할 때 동일한 물리적 위치를 서로 다른 정렬된 규칙을 통해 올바르게 나타낼 수 있습니다. 순서를 다르게 해석하는 인터페이스 간에 값이 전달될 때 문제가 발생합니다. 신뢰할 수 있는 워크플로는 각 경계에서 규칙을 식별하고 테스트합니다. 이것은 단순히 숫자가 화면에 표시되는 방식에 대한 선호도가 아니라 데이터 의미 문제입니다.

더 알아보기 UTM 좌표: 구역, 반구와 흔한 내보내기 오류

추측하기 전에 소스 문서를 읽으십시오

들어오는 토지 조사 데이터에 대한 소스 CRS 및 현장 정의를 얻습니다. 컨트롤러 설정을 검사하고 필요한 경우 문서를 내보냅니다. 비공식 파일 이름의 컬럼 위치 또는 북쪽 및 동쪽과 같은 레이블에서만 축 순서를 추론하지 마십시오. 로컬 그리드는 표준 예상 참조와 다른 비정상적인 축 방향 또는 엔지니어링 규칙을 사용할 수도 있습니다.

숫자 범위는 명백한 실수를 드러낼 수 있지만 결정적이지 않습니다. 일부 지역에서는 경도와 위도 값이 모두 교환될 때 그럴듯한 범위 내에 있을 수 있습니다. 지점에서 멀리 이동하는 동안 지점이 육지에 남아 있을 수 있습니다. 결과가 분명히 불가능하지 않기 때문에 지도를 수락하기보다 알려진 위치와 문서화된 참조 정의를 비교하십시오.

더 알아보기 GNSS 측량에서 가져온 CSV 좌표 가져오기 검증

API 데이터 순서와 CRS 축을 구별합니다

CRS 정의는 하나의 축 순서를 지정할 수 있고 애플리케이션 인터페이스는 데이터 배열에 대해 다른 규칙을 사용합니다. Proj 문서는 축 처리 및 변환 동작을 설명하지만 정확한 인터페이스와 버전은 여전히 중요합니다. 실제로 사용된 도구에 대한 설명서를 읽으십시오. 모든 라이브러리, 명령줄 및 파일 형식이 동일한 방식으로 동일한 값 쌍을 해석한다고 가정하지 마십시오.

워크플로에서 모든 축 정규화 옵션 또는 명시적 스왑 작업을 기록합니다. 생산 전 대표점을 테스트합니다. 숨겨진 호환성 설정은 동일한 CRS 식별자를 사용하는 다른 스크립트가 실패하는 동안 하나의 스크립트를 작동하게 할 수 있습니다. 인터페이스 규칙을 가시화하면 프로세스를 더 쉽게 검토하고 문서화되지 않은 소프트웨어 기본값에 대한 의존도를 줄일 수 있습니다.

더 알아보기 GNSS 토지 조사 데이터의 좌표 에포크 문서화

형식별 교환 규칙을 존중합니다

RFC 7946 GeoJSON 위치는 WGS84 경도와 위도를 10진수로 사용합니다. 이 규칙은 Source Land Survey 또는 Software Display가 Latitude를 먼저 사용하는 경우에도 적용됩니다. 예상 좌표는 표준을 준수하는 내보내기 전에 변환되어야 합니다. 값을 교환하는 것만으로는 동쪽 좌표와 북쪽 좌표를 지리적 좌표로 변환하지 않습니다.

다른 형식과 서비스에는 고유한 규칙이 있을 수 있으므로 관련 사양을 확인하십시오. 좌표 순서, 단위, 참조 및 높이 처리를 식별하는 간결한 교환 계약을 유지하십시오. 수신 팀은 의도한 위치를 찾기 위해 여러 스왑을 실험할 필요가 없습니다. 데이터가 동일한 프로젝트에서 웹 맵, 스프레드시트 및 토지 조사 소프트웨어를 통해 이동할 때 명시적 규칙이 특히 중요합니다.

더 알아보기 GNSS Land Survey 데이터를 검토하기 위한 QGIS 워크플로

측량 삼각대에 설치된 GNSS 수신기.
측량 삼각대에 설치된 GNSS 수신기. · Rowan Johnson / USGS / Public Domain

알려진 기준점으로 가져오기를 테스트합니다

승인된 참조에서 예상 위치가 알려진 잘 정의된 위치의 작은 집합을 선택합니다. 잘못된 스왑을 쉽게 인식할 수 있도록 좌표 값이 다른 점을 포함합니다. 실제 프로덕션 워크플로를 통해 가져오고 변환합니다. 즉석 변환이 기본 파일에 포함된 내용을 가릴 수 있으므로 저장된 값과 표시된 위치를 비교하십시오.

테스트 입력, 예상 해석 및 관찰된 출력을 유지합니다. 참조 정보가 없는 스크린샷보다 반복 가능한 테스트가 더 유용합니다. 가져오기 매핑, 라이브러리 버전 또는 인터페이스 구성이 변경되면 영향을 받는 테스트를 다시 실행합니다. 목표는 대규모 데이터 세트에 영향을 미치거나 다운스트림 디자인 파일에 포함되기 전에 규칙 불일치를 포착하는 것입니다.

더 알아보기 UTM 좌표: 구역, 반구와 흔한 내보내기 오류

수직 및 시간 치수를 별도로 유지합니다

축 순서 문제는 처음 두 값으로 제한되지 않습니다. 3차원 위치에는 정의된 높이 유형과 단위가 필요하지만 시간 종속 변환에는 좌표 에포크가 필요할 수 있습니다. 추가 슬롯이 있다고 해서 엔지니어링 고도나 타임스탬프를 배열에 배치하지 마십시오. 모든 구성 요소에 대한 인터페이스의 예상 의미를 확인합니다.

설명 없이 0을 삽입하지 않고 누락된 값을 명시적으로 보존합니다. 0 높이 또는 시간 구성 요소는 실제 값으로 해석되어 결과를 변경할 수 있습니다. 선택적 구성 요소가 처리되는 방법을 문서화하십시오. 이는 2차원 GIS 워크플로가 높이 또는 시간 정보를 사용하는 보다 완전한 토지 조사 변환과 연결될 때 특히 중요합니다.

더 알아보기 GNSS 측량에서 가져온 CSV 좌표 가져오기 검증

불일치를 일관되게 수정하십시오

축 오류가 확인되면 원본 소스로 돌아가 전체 데이터 세트를 통해 문서화된 수정을 적용합니다. 눈으로 포인트를 개별적으로 움직이지 마십시오. 원본 파일을 보존하고 영향을 받는 릴리스를 식별합니다. 단순한 스왑은 순서만으로는 틀렸다는 증거가 있을 때 적절할 수 있지만 실제 소스 참조를 식별하는 것을 대체해서는 안 됩니다.

수정 후 알려진 점을 테스트하고 데이터 세트 범위, 식별자 및 속성을 검사합니다. 동일한 실수를 상속했을 수 있는 관련 제품을 확인하십시오. 점 레이어, 라인워크 및 파생 표면은 일관성을 유지해야 합니다. 향후 가져오기가 동일한 숨겨진 규칙 불일치를 반복하지 않도록 원인을 기록하십시오.

더 알아보기 GNSS 토지 조사 데이터의 좌표 에포크 문서화

명시적 규칙을 사용하여 좌표를 제공합니다

데이터 사전에 축 이름, 순서, 단위, CRS 정의 및 높이 처리를 제공하거나 프로젝트 결과 주를 제공합니다. 형식이 허용하는 설명 열 이름을 사용합니다. 해석이 모호하지 않은 대표적인 예를 포함하십시오. 받는 사람이 좌표 크기에서 의미를 추론하도록 하는 일반 레이블을 피하십시오.

릴리스를 사용하여 가져오기 및 변환 매핑을 아카이브합니다. 신뢰할 수 있는 GNSS 좌표 워크플로는 주문을 현장 내보내기에서 최종 응용 프로그램까지 교환 계약의 일부로 처리합니다. 이 작은 분야는 여러 다운스트림 데이터 세트가 생성되면 수치적으로 그럴듯하고 시각적으로 오해의 소지가 있으며 추적하는 데 비용이 많이 드는 오류를 방지합니다.

더 알아보기 GNSS Land Survey 데이터를 검토하기 위한 QGIS 워크플로

웹 맵에 대한 Latitude-First 소스를 검토합니다

토지 측량 테이블이 첫 번째 열의 위도와 두 번째 열의 경도를 명확하게 기록한다고 가정합니다. 의도된 웹 교환은 GeoJSON입니다. 소스 테이블을 유지하고 경도-위도 배열을 생성하는 워크플로를 통해 올바른 참조 및 내보내기를 할당합니다. 값을 이전 순서로 남겨두고 대상 규칙과 같이 보이도록 소스 열의 이름을 바꾸지 마십시오.

수신 맵에서 알려진 여러 위치를 테스트하고 실제 내보낸 배열을 검사합니다. 주문 변경 외에 필요한 참조 변환이 발생했는지 확인합니다. 릴리즈 노트와 함께 매핑을 유지합니다. 이 예는 소스 해석과 대상 서식이 별도의 단계인 이유를 보여줍니다. 시스템 간에 의미를 유지하려면 좌표 쌍이 모두 정확해야 합니다.

필드 이름 옆에 예상 순서가 표시되어 있는 현실적이지만 명확하게 식별된 프로젝트 테스트 좌표를 사용하는 Exchange 문서에서 예를 유지하십시오. 두 값이 유사한 예는 스왑을 표시하지 못할 수 있으므로 피하십시오. 다른 운영자가 반복하기 쉬워야 합니다. 수신 시스템이 자체 축 정규화 설정을 사용하는 경우 내보낸 배열만으로도 모든 응용 프로그램에서 올바른 해석을 보장한다고 가정하지 않고 해당 설정을 인터페이스 계약의 일부로 기록하십시오.

더 알아보기 UTM 좌표: 구역, 반구와 흔한 내보내기 오류

실무 점검 목록

실무 점검 목록

  1. 모든 인터페이스 경계에서 축 순서를 문서화합니다.
  2. 알려진 점을 테스트하고 저장된 값과 표시를 검사합니다.
  3. 적절한 변환 후에 geojson 경도-위도도를 사용하십시오.
EQUATOR GNSS

GNSS 구성을 계획하세요

EQ10과 EQ20 수신기의 사양을 비교한 후 프로젝트에 필요한 구성과 지원을 상담하세요.

GNSS 수신기 비교

참고 자료

  1. PROJ Documentation — Geodetic Transformation
  2. PROJ Documentation — Axis Swap
  3. IETF — RFC 7946: The GeoJSON Format