제9부 규격·프로토콜·인터페이스

9.17 지리공간·임무 데이터 규격: OGC·GeoTIFF·LAS·비행 로그 형식

9.17.1 이 장에서 배우는 것 / 선수 지식 / 특히 중요한 독자

앞의 장들은 센서가 무엇을 얼마나 정확히 재는가(6.6·6.7), 위치 오차가 어떻게 쌓이는가(6.10), 데이터를 어떻게 줄여 보내는가(6.11)를 다루었다. 이 장은 그 결과를 파일로 저장하고 교환하는 형식의 구조와 크기·정밀도 수치를 다룬다. 측량 성과와 영상은 OGC·ASPRS 계열의 공개 형식이, 비행 기록은 오토파일럿 프로젝트의 형식이 맡으며, 형식마다 좌표계·시각·단위를 어디에 어떻게 적는지가 다르다. 군용 지리공간 형식(NITF·STANAG 등)은 이 장의 범위 밖이다(제10~12부, 9.8, 9.2·9.3).

배우는 것:

• OGC 표준의 지도 — GeoTIFF 1.1·COG·GeoPackage·OGC API Features·3D Tiles·WKT2의 지위와 판.
• 좌표 참조계의 표기 — EPSG 코드, WKT2, 형식별로 고정된 좌표계, 높이 기준의 처리.
• GeoTIFF·COG — 태그 구조, 타일·개요 요구, 개요가 추가하는 용량(워크스루 2).
• LAS 1.4·1.5와 LAZ — 헤더 375 B, 점 형식 0~10의 길이, 32비트 정수 좌표의 분해능·범위, 측량 성과의 파일 크기(워크스루 1).
• 영상 메타데이터 — EXIF GPS 유리수의 분해능, XMP와 제조사 태그, GPX.
• 비행 로그 형식 — PX4 ULog, ArduPilot BIN, MAVLink tlog, 제조사 비공개 로그의 한계, 기록 속도와 보존 시간(워크스루 3).
• 정확도 보고 — ASPRS 2판 2버전의 RMSE 체계와 95 % 신뢰 수준 환산.

선수 지식: 4.1(좌표계·높이), 6.10(정확도 표현), 9.5(MAVLink 메시지)을 읽었다고 가정한다. 센서와 처리의 원리는 6.3·6.5~6.7·6.12, DEM과 지오이드는 9.16.7, 지오존·AIXM의 표현 변환은 9.14.8, 로그의 포렌식·감사는 8.23이 다룬다. 이 장은 그 설명을 반복하지 않고 파일 형식의 구조와 수치에 집중한다.

특히 중요한 독자: 측량·매핑 담당자는 9.17.4·9.17.5·9.17.9를, 탑재체·소프트웨어 개발자는 9.17.5·9.17.6·9.17.8을, 사고조사·감사 담당자는 9.17.8과 9.17.14를, 조달·검수 담당자는 9.17.9·9.17.10을 먼저 읽는다.

기준 시점과 정직성. 2026년 11월 기준이다. 원문을 읽은 것: OGC GeoTIFF 1.1(19-008r4, 2019-09-14), OGC Cloud Optimized GeoTIFF 1.0(21-026, 발행 2023-07-14), OGC GeoPackage 1.4.0(12-128r19, 2024-02-06), OGC API Features Part 1 1.0.1(17-069r4, 2022-05-11), OGC 3D Tiles 1.1(22-025r4, 발행 2023-01-12), OGC WKT2(18-010r11, 2.1.11, 2023-08-16), IETF RFC 7946, ASPRS LAS 1.4 R15(2019-07-09, 50쪽 — ASPRS 사이트의 옛 주소는 더 이상 열리지 않아 웹 아카이브 사본을 읽었다), OGC LAS 1.4 커뮤니티 표준(17-030r1, 발행 2018-03-01), LAS 1.5 R00(lasformat.org, 2025-08 승인), OGC LAZ 1.4(24-070r1, 승인 2026-04-23·발행 2026-06-30), CIPA DC-008-2012(Exif 2.3, 190쪽)와 CIPA의 Exif 3.0 개요(2023-12, 9쪽), Adobe XMP 규격 1부(2012-04, ISO 16684-1:2011 본문)와 3부(2020-01), GPX 1.1 스키마, PX4 문서의 ULog 형식·로깅 쪽과 SensorCombined msg 정의, ArduPilot AP_Logger 소스(LogStructure.h·README), MAVLink 가이드의 파일 형식 쪽, QGroundControl의 plan 파일 문서, pymavlink의 mavutil.py, ASPRS 위치 정확도 표준 2판 2버전(2024, 228쪽 — ASPRS의 공식 배포 주소는 로그인을 요구해 열지 못했고 프랑스 CNIG 사이트에 올라 있는 사본을 읽었다). 2차 출처: ExifTool의 DJI·XMP 태그표(2026-10-28 개정), dji-log-parser의 README, libE57 사이트, ISO 19115-1의 공개 목록 정보. 읽지 못한 것: ASTM E2807(E57) 본문과 ISO 19115·19157·19159-1·16739-1 본문(유료), CityGML·WMTS·KML 본문(OGC 목록으로 판만 확인), OGC 06-103r4(WKB), Exif 3.1(2026-01-30)의 본문(배포가 약관 동의 화면 뒤에 있어 자동으로 수락하지 않았다)과 Exif 3.0 본문, ASPRS 2판 1버전(2023), FGDC-STD-007.3(ASPRS의 인용 범위만), 제조사의 공식 XMP·로그 사양(찾지 못했다), PX4 로거의 기본 주제 목록과 주기, ArduPilot의 로그 비트마스크와 기록 주기, 한국의 공공측량 성과 규정. 읽지 못한 부분은 (확인 필요)로 표시했다. KB·MB·GB는 모두 1,000배수로 계산했다.

9.17.2 개념·직관 — 파일은 값과 약속의 묶음이다

위치 값 하나는 숫자 세 개가 아니라 좌표 참조계·높이 기준·단위·시각의 원점·정확도가 함께 있을 때 의미를 갖는다. 파일 형식은 값을 바이트로 배열하는 규칙이면서 이 약속을 어디에 적는지의 규칙이다. 약속이 파일 안에 있으면 자기 기술적(self-describing)이라고 하고(GeoTIFF·LAS·ULog·DataFlash), 파일 밖의 문서에 있으면 읽는 쪽이 그 문서를 알아야 한다(GeoJSON과 GPX의 고정 좌표계, tlog의 메시지 정의 판).

세 축에서 요구가 다르다. 민간 UAS의 측량·점검에서는 납품 형식(GeoTIFF·LAS·GeoPackage)과 정확도 보고(ASPRS)가 계약의 검수 기준이다. AAM은 항공기이므로 비행 기록이 감항과 사고조사의 증거가 되고(8.23, 18.25) 형식의 공개 여부가 중요해진다. 군용은 별도의 형식과 표준을 사용하며 이 장의 범위 밖이다. 이 장은 세 가지 워크스루를 포함한다. ① 측량 성과의 LAS 파일 크기(9.17.5.6), ② 정사영상의 크기와 COG 개요(9.17.4.3), ③ 로그의 기록 속도와 보존 시간(9.17.8.6)이다.

9.17.3 OGC·ISO 지리공간 표준의 지도와 좌표 참조계

9.17.3.1 OGC 표준의 세 부류와 지위

OGC(Open Geospatial Consortium) 표준은 ① 파일·인코딩 표준(GeoTIFF·GeoPackage·KML·CityGML의 GML 인코딩), ② 서비스 API 표준(WMTS·OGC API Features), ③ 개념 모델(CityGML 3.0의 개념 모델)로 나뉜다. OGC 밖에서 개발된 형식을 OGC가 커뮤니티 표준(CS)으로 채택하는 경로도 있으며 LAS 1.4·LAZ 1.4·3D Tiles 1.1이 그 경우이다. 커뮤니티 표준 문서는 원 개발자가 작업을 계속 갱신할 수 있고 OGC 문서는 내용이 고정된다고 표지에 밝힌다(LAZ 1.4 표지의 경고문). 따라서 OGC 사본과 원 개발자의 최신본이 다를 수 있다. LAS 1.4가 그 사례이다(9.17.5.1).

9.17.3.2 좌표 참조계의 표기

EPSG 등록부는 좌표 참조계(CRS)마다 숫자 코드를 정한다. GeoTIFF 1.1의 예시는 4326(WGS 84 지리 2D), 4979(WGS 84 지리 3D, 타원체고), 32660(WGS 84 / UTM 60N), 3855(EGM2008 높이)를 사용한다. 코드는 짧지만 등록부를 아는 소프트웨어가 필요하고, 등록부에 없는 정의는 WKT2(OGC 18-010r11, ISO 19162:2019와 같은 내용)로 전체를 문자열로 적는다. WKT2는 동적 CRS(FRAMEEPOCH), 데이텀 앙상블(낮은 정확도에서 여러 실현을 변환 없이 병합하는 묶음), 3차원 투영 CRS, 복합 CRS를 표현한다. 규격의 복합 CRS 예 가운데 지리 2D에 기압 매개변수 높이를 결합한 항공용 "ICAO layer 0"이 있다.

높이 기준이 형식마다 타원체고 또는 해수면으로 다르므로 형식을 바꾸는 순간 지오이드고만큼의 오차가 생길 수 있다(4.1.3.4, 9.14.8, 9.16.7.4).

9.17.4 GeoTIFF와 COG

9.17.4.1 GeoTIFF 1.1의 구조

GeoTIFF는 TIFF 6.0 파일에 예약 태그 여섯 개를 추가한 것이며 OGC GeoTIFF 1.1(19-008r4, 요구 150개·요구 클래스 31개)이 이를 규정한다. 1995년의 1.0과 호환되는 개정으로, 1.0 이후 EPSG 등록부에 추가된 CRS를 사용할 수 있게 했다. 태그의 구성은 다음과 같다.

ModelTiepointTag와 ModelTransformationTag 중 하나는 반드시 있고, ModelTransformationTag가 있으면 ModelPixelScaleTag가 없어야 한다(요구 1.2). 표준의 UTM 60N 정사영상 예(부속서 F.2.1)는 키 4개(ModelType 1·RasterType 1·ProjectedCRS 32660·ProjectedCitation)로 SHORT 20개, 곧 40 B의 키 디렉터리와 문자열 하나로 정사영상 전체의 지리 참조를 적는다. 다만 이 예에서 문자열 키의 Count가 25인데 |를 포함한 문자열은 26자이므로, Count가 종결자를 포함하는지는 원문만으로 확정하지 못했다 (확인 필요).

화소의 의미(GTRasterTypeGeoKey)도 약속이다. RasterPixelIsArea에서는 화소 (0, 0)이 영상의 왼쪽 위 모서리이고, RasterPixelIsPoint에서는 점 값이어서 표시 영상의 모서리가 (−0.5, −0.5)에 놓인다(부속서 B.2.2). 두 정의를 섞으면 반 화소가 이동한다. 한 화소 3 cm의 정사영상에서는 1.5 cm이지만 DEM 격자 30 m에서는 15 m이다.

9.17.4.2 COG의 요구

COG(OGC 21-026 1.0, 승인 2023-05-08)는 새 파일 형식이 아니라 GeoTIFF의 배치 규칙이다. 요구 클래스는 GeoTIFF Tiles·Overviews·Keys·Optimized·HTTP range의 다섯이다.

• 타일. 모든 IFD를 스트립이 아닌 타일로 구성한다(요구 2). 결과 파일이 4 GB를 넘으면 BigTIFF여야 한다(요구 1).
• 개요(축소 해상도 부분 파일). 개요마다 해상도를 직전보다 최소 2배·최대 10배 줄이고, 마지막 개요는 TilesAcross 또는 TilesDown이 1이 될 때까지 만든다(요구 8). 정사각형 타일을 요구하며(요구 7) 권고 크기는 256·512·1024이다. 개요 IFD에는 지리 참조를 두지 않고 전해상도 IFD의 것을 따른다(요구 6).
• IFD 순서. 권고 3은 모든 IFD를 파일 앞에 모으고 타일은 작은 개요부터 전해상도 순서로 두라고 한다. 헤더 전체를 요청 한 번에 읽기 위해서이며, 표준은 요청 지연을 약 20~30 ms에 전송 지연 약 150 ms가 더해지는 것으로 보고 헤더를 연속 세 번에 읽으면 약 540 ms가 든다고 적는다(요청당 180 ms로 환산된다).
• HTTP 서버. 바이트 범위 요청과 CORS를 지원해야 한다(요구 10·11).

9.17.4.3 워크스루 2 — 정사영상의 크기와 COG 개요

가정: 1 km × 2 km를 지상 화소 크기 3 cm로 촬영해 RGB 8비트 정사영상을 만들고, 타일 512, 개요 배율 2로 COG를 구성한다. 9.17-calc.py의 결과는 다음과 같다.

개요 한 단계는 화소 수가 $1/f^{2}$배이므로 무한히 이어지는 개요의 추가 용량은 등비급수의 합 $1/(f^{2}-1)$에 수렴한다. 배율 2는 파일을 약 1.33배로 만드는 1/3 규칙이다.

비율은 비압축 기준이며 압축 후의 비율은 영상 내용에 따라 달라진다. 배율을 키우면 추가 용량이 줄지만 한 화면에 맞는 해상도 단계가 성겨진다. 이 영상 전체를 높이 1,080화소 화면에 맞추려면 여섯째 개요(521 × 1,042)를 읽는다. 타일은 2 × 3 = 6개이고 비압축 4,718,592 B로 전체의 0.071 %이다. 요청은 헤더 1회와 타일 6회, 모두 7회이며 표준의 예(요청당 180 ms)로 순차 처리하면 1.26초이다. 6.67 GB는 4 GB를 넘으므로 비압축으로는 BigTIFF가 필요하고, 압축 후 크기가 한계 아래이면 TIFF도 가능하다.

9.17.5 LAS와 LAZ

9.17.5.1 판과 지위

LAS 1.4 R14(2019-03)가 분류 19~22와 점 형식별 최소 길이를 추가했으므로 OGC 사본(R13)에는 이 내용이 없다. 계약서가 "LAS 1.4"만 적으면 R13과 R15가 모두 해당하며, "LAS 1.5"는 점 형식 0~5를 허용하지 않는다. 판을 형식 번호와 개정 기호로 함께 지정해야 한다.

9.17.5.2 헤더·VLR·EVLR의 구조

LAS 파일은 공개 헤더 블록, 가변 길이 레코드(VLR), 점 데이터 레코드, 확장 가변 길이 레코드(EVLR) 순이며 모든 값은 리틀 엔디언이다. 헤더 필드 37개의 크기를 합하면 375 B이고(LAS 1.4 R15 2.4절), 1.5 R00은 최대·최소 GPS 시각(8 B씩)과 Time Offset(2 B)을 더해 393 B이다. 1.5 R00 원문이 적은 오프셋 36개가 누적 크기와 모두 일치한다. VLR 머리부는 54 B이고 길이 필드가 2 B라 한 VLR의 자료는 65,535 B 이하이며, EVLR 머리부는 60 B이고 길이 필드가 8 B이다. EVLR은 파일 끝에 덧붙일 수 있어 점 자료를 다시 기록하지 않고 CRS를 추가할 수 있다(이전 VLR의 사양 번호를 Superseded 값 7로 바꾼다). 점 레코드 길이 필드도 2 B이므로 점 형식 길이와 사용자 정의 추가 바이트(Extra Bytes VLR이 기술)를 합해 65,535 B 이하여야 한다. 점 수는 64비트로 적고, 형식 6~10이거나 점 수가 4,294,967,295(UINT32_MAX)를 넘으면 레거시 32비트 점 수 필드를 0으로 둔다.

9.17.5.3 점 데이터 레코드 형식

필드에서 합산한 길이는 원문의 "Minimum PDRF Size" 11개와 모두 같다. 형식 6~10은 반환 번호를 4비트(최대 15회), 분류 플래그를 4비트(합성·키 포인트·제외·중복), 스캐너 채널을 2비트(0~3)로 적고 스캔 각은 0.006° 단위의 16비트 정수(±30,000, 곧 ±180°)로 적는다. 세기와 RGB는 16비트로 정규화하며 8비트 값은 256을 곱해 넣는다. 표준 분류는 2 지면, 3~5 저·중·고 식생, 6 건물, 7 저점(잡음), 9 수면, 10 철도, 11 도로면, 13~16 전선·철탑·연결부, 17 교량 상판, 18 고점(잡음), 19 구조물 상부, 20 무시 지면, 21 눈, 22 시간 제외이고 23~63은 예약, 64~255는 사용자 정의이다. 레거시 형식에서는 8이 모델 키 포인트, 12가 중복 점이었고 형식 6~10에서는 이 두 번호가 예약이며 플래그 비트가 그 역할을 한다.

9.17.5.4 정수 좌표와 시각 필드

점의 X·Y·Z는 32비트 부호 있는 정수로 저장하며 좌표는 다음 식으로 복원한다(LAS 1.4 R15 식 1~3).

$$X=X_{\text{record}}\cdot s_X+o_X$$

정수 한 단계가 스케일 $s$이고 표현 범위는 $[-2^{31},\,2^{31}-1]\cdot s$, 곧 폭 $2^{32}s$이다. 한 단계 안에서 값이 균일하게 분포한다고 보면 반올림 오차의 RMS는 $s/\sqrt{12}$이다.

서울(37.5665°N, 126.978°E, 타원체 표면)의 지심 직교 좌표(ECEF)는 (−3,044,780, 4,043,789, 3,867,417) m로 세 값 모두 1 mm 스케일의 범위 2,147,483.6 m를 넘으므로 오프셋이 필수이다. 스케일은 성과물의 정확도에 맞춰 고른다. ASPRS 2판은 보고하는 정확도 값의 유효숫자를 납품 좌표의 유효숫자와 같게 하라고 요구하며(7절 서두), 정확도가 수 cm인 성과를 0.0001 m 스케일로 저장하면 좌표의 유효숫자가 보고 정확도의 유효숫자보다 많아져 이 요구와 어긋난다.

GPS 시각은 double이므로 값의 크기가 분해능을 정한다. 2026-11-03 12:00 UTC의 표준 GPS 시각은 약 $1.478\times10^{9}$ s이다(가정: GPS−UTC = 18 s (확인 필요)).

펄스율 240 kHz의 펄스 간격 4.167 µs에서 표준 GPS 시각의 238 ns는 간격의 5.72 %이다. 주 시각은 분해능이 가장 좋지만 주 번호를 적는 필드가 없어 주를 넘는 자료를 구분할 수 없다. LAS 1.2에서 도입된 조정 표준 GPS 시각(총 오프셋 $10^{9}$ s)을 1.5판이 Time Offset으로 일반화했다(Time Offset 1,000이 $10^{9}$ s).

9.17.5.5 LAZ와 E57

LAZ(OGC 24-070r1)는 LAS 구조를 유지하고 점 데이터 블록만 무손실 압축한다. 헤더의 점 형식 값에 128을 더해(128~138이 형식 0~10) 압축을 모르는 소프트웨어가 압축 자료를 비압축으로 읽는 일을 막는다. 특수 VLR(사용자 ID laszip encoded, 레코드 ID 22204)이 압축기 종류와 청크 크기를 적고, 산술 부호화를 사용하며, 점을 청크로 나누어 청크마다 독립적으로 복원한다. 임의 접근의 단위가 청크이다. 형식 6~10은 청크를 다시 층(필드의 부분집합)으로 나눠 일부 필드만 복원할 수 있다. 청크 표는 압축 블록의 끝에 놓이고 그 위치를 블록 앞머리(또는 파일 끝 8 B)가 적는다. LAZ는 LAS 1.4 헤더만 허용하고 파형 자료는 외부 .wdp 파일에 둔다. 이 규격은 압축률 수치를 정하지 않으며 원문에서 찾지 못했다 (확인 필요). 저장·전송 용량의 계산에서 압축률은 점군의 성질에 따라 달라지는 가정이다.

E57(ASTM E2807)은 점군·영상·메타데이터를 포함하는 벤더 중립 형식이며, libE57의 안내(2차 출처)에 따르면 파일의 트리 구조 일부는 XML이고 점·영상의 본체는 별도의 이진 구획에 있다. 본문이 유료이므로 구조의 세부는 이 장에서 다루지 않는다. libE57 사이트는 E57 2.0 규격의 개정을 ASTM E57.11 위원회에 요청하고 있다고 적는다.

9.17.5.6 워크스루 1 — 측량 성과의 크기

6.6.10의 시나리오를 그대로 가져온다(6 kg 결합형, 펄스율 240 kHz, 펄스당 평균 1.3 반사, 비행 67분). 점 수는 $240{,}000\times1.3\times4{,}020=1{,}254{,}240{,}000$이다.

읽는 법은 셋이다. 첫째, LAS의 최소 점 길이는 20 B(형식 0)이므로 점당 16 B는 LAS로 존재하지 않는다. 같은 비행을 형식 6으로 저장하면 37.63 GB로 6.6.10의 약 20 GB의 1.88배이다. 둘째, 점 수 $1.25\times10^{9}$은 UINT32_MAX의 29 %이므로 레거시 점 수 필드에 들어가지만, 4,294,967,295점을 넘으면(형식 6에서 128.8 GB) 64비트 필드만 사용한다. 셋째, 데이터율은 312,000점/s × 30 B = 9.36 MB/s = 74.9 Mbit/s이며, 6.11.3의 표(초당 50만 점 × 30 B)와 같은 점 길이이다. 면적 기준으로는 도해 2와 같다. ASPRS 표 B.7이 5-cm 수직 정확도 등급에 권장하는 최소 펄스 밀도 8 pls/m²는 펄스당 반사가 1개일 때 형식 6에서 1 km²당 240 MB이다.

9.17.6 영상·궤적 메타데이터 — EXIF·XMP·GPX

9.17.6.1 EXIF의 GPS IFD

Exif는 JPEG의 APP1 마커 안에 TIFF 구조를 넣은 형식이며 GPS Info IFD는 2.0판(1997)에서 추가되었다(CIPA 개요). Exif 2.3(CIPA DC-008-2012)의 IFD는 개수 2 B, 항목 12 B × N, 다음 IFD 오프셋 4 B로 이루어지고 4 B를 넘는 값은 TIFF 머리부 기준 오프셋 뒤에 둔다. GPS 태그는 표 15에 0~31번 32개이며 지원 수준 표(표 19)는 모두 선택(O)으로 분류한다. 다만 GPS 정보를 기록하면 GPSVersionID는 필수라고 본문이 적는다.

위도·경도·고도·참조 문자만 넣은 7개 항목의 GPS IFD는 2 + 7 × 12 + 4 + (24 + 24 + 8) = 146 B이다. 3.0판 개요는 GPSMeasureMode가 GNSS 위치도 받도록 바뀌고 GPSAltitudeRef의 잘못된 정의가 바로잡혔다고 적지만 정정 내용은 개요에 없고 본문을 읽지 못했다 (확인 필요).

9.17.6.2 위치 표현의 분해능

유리수의 분자·분모는 각각 32비트 부호 없는 정수이므로 표현의 한계는 형식이 아니라 기록하는 쪽이 고른 분모에 있다. Exif 2.3의 예시 JPEG(138~139쪽)는 위도 35/1°·48/1′·8/1″ N, 경도 139/1°·34/1′·55/1″ E, 고도 3048/100 = 30.48 m를 적으며 초가 정수이다. 서울(37.5665°N, 위도 1° = 110,988 m, 경도 1° = 88,347 m, 4.1.3.2)에서 한 단계의 크기는 다음과 같다.

초를 정수로 적으면 반올림해도 최대 15.4 m(내림이면 30.8 m)의 표현 오차가 생긴다. 수 m 정확도의 GNSS 위치라도 EXIF 표현이 정확도를 지배한다. 사진측량에서 카메라 위치를 초기값으로 사용한다면 분모를 확인해야 하며, 제조사 카메라가 실제로 선택하는 분모는 조사하지 못했다 (확인 필요).

9.17.6.3 XMP와 제조사 태그

XMP는 RDF/XML로 직렬화한 메타데이터 패킷이다(Adobe XMP 1부, ISO 16684-1:2011 본문). JPEG에서는 APP1 마커(0xFFE1)에 네임스페이스 식별 문자열 http://ns.adobe.com/xap/1.0/과 NUL(29 B)을 붙이고 UTF-8 패킷을 둔다. 3부는 한 패킷의 최대를 65,502 B로 적는다. 길이 필드 Lp가 2 B이고 Lp = 2 + 29 + 패킷이므로 계산하면 65,504 B이며 원문이 2 B 보수적으로 적었다. 이보다 큰 메타데이터는 ExtendedXMP로 나눈다. Exif APP1을 SOI 바로 뒤에 두고 XMP를 다음에 두기를 권고한다.

드론 제조사의 영상은 XMP에 자체 네임스페이스(drone-dji)의 태그를 둔다. ExifTool의 DJI XMP 태그표 (2차 출처)에는 AbsoluteAltitude·RelativeAltitude, GimbalRollDegree·GimbalYawDegree·GimbalPitchDegree, FlightRollDegree·FlightYawDegree·FlightPitchDegree, FlightXSpeed·FlightYSpeed·FlightZSpeed, RtkFlag와 RtkStdLat·RtkStdLon·RtkStdHgt, CalibratedFocalLength·CalibratedOpticalCenterX·CalibratedOpticalCenterY, DewarpData가 실려 있다. 표는 이름과 자료형(real·string)만 적으며 고도의 기준(해발·타원체·이륙점), 단위, 각도의 부호 규약은 없다. 제조사의 공식 사양서는 찾지 못했다. 따라서 이 값을 사진측량 소프트웨어에 넣기 전에 제조사 문서와 시험 촬영으로 기준을 확인해야 하며(6.10.3.3), 확인하지 않으면 높이 기준이 섞인다.

9.17.6.4 GPX 1.1

GPX 1.1 스키마(topografix.com)는 모든 좌표를 WGS 84로, 모든 측정을 미터법으로 정한다. 위도는 −90~90, 경도는 −180 이상 180 미만이고 시각은 소수 초를 허용하는 UTC(ISO 8601)이다. 고도 ele는 "미터"라고만 적으며 기준을 정하지 않고, 지오이드고 geoidheight는 NMEA GGA의 정의를 따르는 별도의 선택 요소이다. 정확도 정보는 fix·sat와 hdop·vdop·pdop뿐이고 위치 오차의 추정값을 적는 필드는 없다(확장 요소로 추가한다). 궤적을 사람이 확인하는 데는 편리하지만 비행 로그를 대체하지 못한다.

9.17.7 벡터·서비스 교환 — GeoJSON·GeoPackage·OGC API·3D Tiles

GeoJSON(IETF RFC 7946, 2016-08)은 위치를 [경도, 위도, (고도)]로 적고 좌표계를 CRS84로 고정한다(4절). 외곽 링은 반시계 방향이어야 하고 날짜변경선을 지나는 지오메트리는 둘로 자른다. RFC는 소수 6자리가 약 10 cm이며 6자리에서 15자리로 늘리면 텍스트 크기가 거의 2배가 된다고 적는다. 위치 하나를 계산하면 [127.123456,37.123456]이 22자, 15자리는 40자로 1.82배이다.

GeoPackage(OGC 12-128r19, 1.4.0)는 SQLite 3 파일이다. 첫 16 B가 SQLite format 3이고 application_id가 0x47504B47(GPKG), user_version은 5자리 정수(1.4.0은 10400)이며 확장자는 .gpkg이다. 파일의 최대 크기는 약 140 TB이나 FAT32 카드에서는 4 GB로 제한된다고 원문이 밝힌다. 지오메트리 BLOB은 머리부 8 B(매직 GP 2, 버전 1, 플래그 1, srs_id 4)에 선택적 봉투(0·32·48·64 B)와 WKB가 이어진다. 2차원 점 하나는 8 + 21 = 29 B이고(WKB 점은 바이트 순서 1 + 유형 4 + 좌표 16 B이나 OGC 06-103r4는 읽지 못했다 (확인 필요)), 봉투를 붙이면 61 B이다.

OGC API Features Part 1(17-069r4, 1.0.1)은 HTTP 자원 경로 /collections, /collections/{collectionId}/items, /items/{featureId}와 limit·bbox 인수를 정한다. 기본 좌표계는 CRS84(높이 없음)·CRS84h(타원체고)이고 다른 CRS는 별도 파트(Part 2)가 정한다. 3D Tiles(OGC 22-025r4, 1.1)는 tileset.json의 계층 구조와 glTF 2.0 타일 형식으로 대용량 3차원 자료를 스트리밍하며, 경계 region은 [서, 남, 동, 북, 최소 높이, 최대 높이]로 적고(각도는 라디안) geometricError의 단위는 미터이다. 디지털 트윈 배포 맥락은 7.13이 다룬다. CityGML 3.0·WMTS 1.0.0·KML 2.3은 OGC 목록으로 판만 확인했고 본문은 읽지 못했다.

9.17.8 비행 로그와 임무 파일

9.17.8.1 로그의 네 부류

9.17.8.2 PX4 ULog

PX4 문서의 ULog 명세(dev_log/ulog_file_format)에 따르면 파일은 머리부, 정의 구역, 데이터 구역으로 이루어진다. 머리부 16 B는 매직 7 B(ULog와 0x01 0x12 0x35), 버전 1 B, 시작 시각 uint64(µs)이다. 이후 모든 메시지는 크기 2 B와 유형 1 B의 머리부로 시작하고 값은 리틀 엔디언이다.

timestamp 필드는 uint64(µs)이며 같은 구독 안에서 단조 증가해야 한다. 필드가 정렬되어 있지 않을 수 있어 읽는 쪽은 메모리 복사로 접근해야 한다. 파서는 알 수 없는 메시지를 무시하고 알 수 없는 incompat 비트가 있으면 해석을 거부하며 메시지 중간에서 끊긴 로그를 처리해야 한다. 머리부의 버전 바이트는 "현재 1"이라 적히는데 같은 문서의 이력은 B·M 메시지의 추가를 "버전 2"라 부르므로 문서 안의 표기가 일치하지 않는다 (확인 필요). 호환성은 버전 바이트가 아니라 플래그 비트와 알 수 없는 메시지를 무시하는 규칙이 정한다.

9.17.8.3 ArduPilot DataFlash

ArduPilot의 AP_Logger(LogStructure.h·README)에서 모든 메시지는 머리부 3 B(0xA3, 0x95, 유형 1 B)로 시작한다. 유형 128은 FMT이며 유형 번호·길이·이름 4 B·형식 16 B·필드 이름 64 B를 적어 머리부를 포함해 89 B이다. 형식 문자는 Q(uint64)·B(uint8)·f(float)·L(정수 위·경도) 같은 한 글자이고, UNIT·MULT·FMTU 메시지가 단위와 배율을 정한다. README는 지상국이 단위 이름에서 배율을 추론하지 말라고 적는다. 유형 0~31은 기체별 예약이고 32부터가 공통 메시지이다. 파일 이름은 %08u.BIN이고 소스는 LASTLOG.TXT도 함께 둔다.

형식 문자열의 문자 크기를 합산한 값은 구조체 필드의 합과 모두 일치한다.

9.17.8.4 tlog와 임무 파일

tlog는 pymavlink(mavutil.py)가 기록하는 형식이다. 패킷마다 64비트 빅엔디언 마이크로초 타임스탬프를 두고 하위 2비트를 링크 번호로 사용하며(기록은 usec & ~3, 읽기는 tusec & 0x3), 그 뒤에 원시 MAVLink 패킷이 이어진다. 머리부와 형식 정의가 없어 메시지 정의 판을 알아야 복호한다. 8 B의 오버헤드는 MAVLink 2의 HEARTBEAT 21 B를 29 B(패킷 대비 +38.1 %)로, ATTITUDE 40 B를 48 B(+20.0 %)로 만든다(패킷 길이는 9.5.7.3). MAVLink 가이드는 임무에 한해 일반 텍스트 형식을 사실상의 표준으로 인정하고 지오펜스·랠리 포인트·매개변수에는 표준이 없다고 적는다.

임무 파일은 두 가지가 널리 사용된다. QGC WPL 110은 탭으로 구분한 텍스트(색인·현재 여부·좌표 프레임·명령·매개변수 4개·위도·경도·고도·자동 계속)이며 MAVLink 공식 규격이 아니다. QGC .plan은 JSON이며 fileType Plan, version 1이고 mission(version 2)·geoFence·rallyPoints 객체가 필수이다. mission은 firmwareType(MAV_AUTOPILOT)·vehicleType(MAV_TYPE)·cruiseSpeed·hoverSpeed·items·plannedHomePosition[위도, 경도, AMSL 고도]을 갖는다. 임무를 업로드하는 메시지 절차는 9.5.9가 다룬다.

9.17.8.5 제조사 비공개 로그

DJI 등 제조사 로그의 형식 명세는 찾지 못했다. 제3자 파서 dji-log-parser의 README (2차 출처)는 로그 버전 13부터 레코드가 AES로 암호화되며 복호용 키체인을 제조사 API에서 받아야 하고 API 키가 필요하다고 적는다. 키체인을 로그와 함께 저장하지 않으면 오프라인 복호가 불가능하고 제조사 정책에 의존한다. 감사·포렌식에서 형식의 공개 여부는 재현성과 증거 능력에 영향을 주며(8.23), 제조사의 정책과 API는 바뀔 수 있다.

9.17.8.6 워크스루 3 — 기록 속도와 보존 시간

PX4 문서는 기본 주제의 기록 대역을 약 50 KB/s로 적는다 (공개 주장치). 메시지 크기와 시간을 계산한다(250 Hz는 가정이며 PX4 로거의 기본 주기는 읽지 못했다 (확인 필요)).

세 가지를 읽는다. 첫째, 2.10.10.3은 IMU 1 kHz를 표본당 32 B(32 kB/s)로 가정했으나 실제 기록 단위는 PX4 53 B, ArduPilot 54 B로 1.66~1.69배이다. 그 표의 합계 84.6 kB/s에서 IMU 항목만 바꾸어도 105.6~106.6 kB/s가 된다. 둘째, ArduPilot의 IMU 원시 표본 배치를 8 kHz로 기록하면 한 계통만으로 51.75 KB/s(ISBH 머리부 메시지 제외)이며 PX4의 기본 기록 전체와 같은 크기이다. 셋째, PX4는 회전이 기본이어서 파일이 한도에 이르거나 카드가 차면 오래된 .ulg를 삭제하므로, 사고조사에 필요한 기간의 보존은 별도의 정책이 필요하다(8.23, 6.11.8).

9.17.9 정확도와 메타데이터 표준 — ASPRS 2판·NSSDA·ISO 19115

9.17.9.1 ASPRS 2판 2버전의 보고 체계

ASPRS 위치 정확도 표준 2판 2버전(2024, 228쪽, doi 10.14358/ASPRS.PAS.2024)은 본문과 부록 A~D, 부속서 I~VI(일반·현장 측량·사진측량·라이다·UAS·경사 영상)로 이루어진다. 2판의 변경 8항목 가운데 보고와 관련된 것은 다섯 가지이다. ① 95 % 신뢰 수준 참조를 삭제하고 RMSE만 사용한다. ② 기준점 4배·검사점 3배의 정확도 요구(1판)를 완화하되 검사점 오차를 성과 정확도에 포함한다. ③ 식생 수직 정확도(VVA)의 합격 판정을 없앴다. ④ 검사점을 최소 20개에서 30개로 올리고 최대 120개로 제한한다. ⑤ 3차원 위치 정확도를 신설한다.

$$\text{RMSE}_{H}=\sqrt{\text{RMSE}_{X}^{2}+\text{RMSE}_{Y}^{2}},\qquad \text{RMSE}_{3D}=\sqrt{\text{RMSE}_{H}^{2}+\text{RMSE}_{V}^{2}}$$

등급은 "#-cm" 꼴로 RMSE$_H$ ≤ #(정사영상 모자이크의 이음선 불일치는 ≤ 2#)이고 이산 등급이 아니라 7.5-cm 같은 임의의 값을 허용한다. 수직은 비식생 수직 정확도(NVA) RMSE$_V$ ≤ #이며 라이다의 내부 정밀도는 스와스 안 최대 차 ≤ 0.60#, 스와스 사이 RMSDZ ≤ 0.80#, 최대 차 ≤ 1.60#이다. 평균 오차는 목표 RMSE의 25 % 미만을 권하고 목표 RMSE의 3배를 넘는 불일치는 이상치로 조사한다. 검사점 수는 면적 1,000 km² 이하에서 30개이고 1,000 km²마다 10개씩 늘어 9,000 km² 초과에서 120개이며 VVA를 시험하면 30개를 더한다. 보고문은 30개 이상이면 "tested to meet"이고 미만이면 "ONLY n checkpoints"를 명시한다.

가정 RMSE$_X$ = 7 cm, RMSE$_Y$ = 5 cm, RMSE$_V$ = 6 cm의 성과를 환산한다. 표준 부록 B.7의 계수(수평 1.7308, 수직 1.96)를 사용한다.

원문의 예(RMSE$_H$ 15 cm → 25.96 cm, RMSE$_V$ 10 cm → 19.60 cm)와 같은 식이다. 라이다의 수평 정확도 추정식(7.6절) $\text{RMSE}_{H}=\sqrt{e_{\text{GNSS}}^{2}+\big((\tan\varepsilon_{rp}+\tan\varepsilon_{h})\,h/1.478\big)^{2}}$을 GNSS 10 cm, IMU 10″·15″로 계산하면 비행 높이 500~5,000 m에서 표 B.8과 0.2 cm 이내로 일치한다(500 m에서 10.8 대 10.7, 5,000 m에서 42.2 대 42.0). 같은 가정에서 높이 80 m이면 10.02 cm로 GNSS 오차가 지배한다. 라이다 자료의 수평 정확도는 현장에서 시험하기 어려워 제조사의 성능을 신뢰하는 것이 업계의 관행이며 정당한 이유가 없으면 시험과 보고를 요구할 필요가 없다고 2판이 적는다(7.6절).

9.17.9.2 ISO 19115와 파일 메타데이터

ISO 19115-1:2014는 지리 정보와 서비스를 기술하는 메타데이터 스키마로 식별·범위·품질·공간과 시간 참조·내용·배포 등을 필수·조건부·선택 요소로 나눈다. 2014-03-19에 승인되었고 Amd 1:2018·Amd 2:2020이 있으며 개정 작업이 진행 중일 수 있다(공개 목록의 2차 정보 (확인 필요)). 본문은 유료여서 읽지 못했다. 이 표준의 메타데이터는 카탈로그 단위의 설명이어서 파일 안의 자기 기술(GeoKey·WKT·EXIF)과 대체 관계가 아니다. ASPRS 2판은 정확도 보고문을 메타데이터에 기록하라고 요구하므로(7.16.1) 납품 시 파일 내 CRS와 별개로 정확도 보고문·검사점 통계·평균 오차를 메타데이터 문서에 둔다. ISO 19157의 데이터 품질 요소는 판을 확인하지 못했다 (확인 필요).

9.17.10 설계 트레이드오프 — 산출물을 어떤 형식으로 납품할 것인가

방식을 셋으로 펼친다.

① 평문·단순 형식(GeoJSON·GPX·CSV·KML). 모든 도구가 읽고 사람이 확인할 수 있다. 단점은 텍스트 크기(위치 하나 22~40자), 좌표계가 형식에 고정되거나 없다는 점, 높이와 정확도의 약속이 없다는 점이다.

② 자기 기술 이진 표준(GeoTIFF·COG, LAS·LAZ, GeoPackage). 좌표계·스케일·정확도 관련 정보를 파일 안에 두고 크기가 효율적이다. 단점은 판 차이(LAS 1.4 R13·R15·1.5), 도구 호환(1.5는 점 형식 0~5를 허용하지 않는다), TIFF의 4 GB 한계와 BigTIFF의 호환성이다.

③ 서비스·스트리밍(COG와 HTTP 범위 요청, OGC API Features, 3D Tiles). 대용량의 일부만 읽어 배포한다. 단점은 서버·네트워크·접근 통제에 대한 의존이며 인터넷이 없는 현장에서는 사용할 수 없다.

견해: 검수와 보관은 ②(원본 좌표와 정확도 보고문), 열람은 ③ 또는 ①의 파생본으로 이중화하는 구성이 근거가 가장 강하다. 첫째 ASPRS의 검수는 원본 좌표에 대한 RMSE 보고를 요구하는데 파생본은 양자화·압축으로 정밀도가 달라진다. 둘째 ③은 서버가 없으면 열람할 수 없어 보관 형식이 될 수 없다. 셋째 ①의 기본 자릿수인 소수 6자리(약 10 cm)는 cm급 성과에 부족하다. 반대 견해로, 소규모 단발 임무는 ①만으로 충분하고 ②의 도구·교육 비용이 이득보다 클 수 있다. 이 견해는 정확도 보고가 계약에 없는 경우에 타당하다.

9.17.11 세 축 비교

9.17.12 관련 규격·프로토콜

전체 지도는 A.6에 있다.

9.17.13 관련 규제·인증 요구와의 연결

• 측량·매핑 성과(14.9). 성과물의 형식과 정확도 보고가 검수 기준이다. 공공측량의 성과 형식은 국내 규정이 정하며 이 장은 읽지 못했다(9.22, 18.20).
• 영상 메타데이터와 개인정보(6.12.13). EXIF GPS와 촬영 방향은 공유된 영상에서 위치를 노출한다. 형식이 정하는 필드를 배포 전에 제거할지의 정책이 필요하다.
• 비행 기록과 사고조사(8.23, 8.24, 18.25). 로그 형식의 공개 여부가 재현성을 정하고, PX4 문서는 암호화 로그를 지원한다고 적는다(dev_log/log_encryption은 읽지 못했다).
• 보안(9.19, 9.5). MAVLink 서명 블록을 로그에서 제거하라는 권고와 서명된 원본을 증거로 보존하는 요구가 상충할 수 있다고 9.5이 지적한다.
• 판 관리와 적합성 시험(9.1, 9.23). 판과 개정 기호를 계약에 지정하고 파일이 형식을 지키는지 검증한다.
• 지오존·지형 자료(9.14.8, 9.16.7). 공역과 지형 자료의 형식은 각각 그 장이 다룬다.

9.17.14 함정과 한계

미해결 문제. ASTM E57 본문, Exif 3.1 본문, LAZ의 압축률, 제조사의 XMP·로그 공식 사양, PX4·ArduPilot의 기본 기록 주제와 주기, 한국의 공공측량 성과 규정, ISO 19115의 현행판은 이 장의 자료로 답할 수 없다 (확인 필요). 이 장의 수치는 읽은 원문의 상수와 이 책의 가정(촬영 조건, 기록 주기, 오차 값)에서 계산한 것이다.

9.17.15 체크포인트·연구 질문

체크포인트:

1. LAS 점 형식 6의 길이를 필드에서 합산하고(30 B) 형식 7·8·10과의 차이를 설명하라(9.17-calc.py).
2. 스케일 0.001의 범위와 서울의 ECEF 좌표를 저장하는 데 필요한 조건을 구하라.
3. 6.67 GB 정사영상의 COG에서 배율 2와 10의 개요 추가 용량을 계산하라(33.33 %, 1.01 %).
4. EXIF의 초 정수 표현이 서울에서 위도 방향으로 갖는 분해능을 구하라(30.8 m).
5. ULog 한 메시지의 오버헤드와 250 Hz 기록의 속도를 구하고, 8 GB 카드의 보존 시간을 구하라(40.0시간).
6. RMSE$_X$ 7 cm, RMSE$_Y$ 5 cm, RMSE$_V$ 6 cm의 성과를 RMSE$_H$·NSSDA 95 %·RMSE$_{3D}$로 환산하라.

연구 질문(25.7에 모은다):

• LAZ의 압축률을 점밀도·반사 수·분류 분포로 예측하는 모형은 무엇인가.
• 드론 EXIF·XMP 태그의 높이·각도 기준을 시험 촬영으로 자동 검증하는 방법은 무엇인가.
• ULog·BIN·tlog 사이의 변환에서 시각·단위 정보의 손실을 어떻게 정량화하는가.
• 로그의 무결성(해시 체인·서명)을 형식 수준에서 보장하면서 분석 도구의 호환을 유지하는 설계는 무엇인가.

1차 출처(이 장):

• OGC GeoTIFF Standard 1.1(19-008r4, 2019), OGC Cloud Optimized GeoTIFF Standard 1.0(21-026, 2023), OGC GeoPackage Encoding Standard 1.4.0(12-128r19, 2024), OGC API Features Part 1 Core 1.0.1(17-069r4, 2022), OGC 3D Tiles Specification 1.1(22-025r4, 2023), OGC Well-known text representation of coordinate reference systems(18-010r11, 2023).
• IETF RFC 7946, The GeoJSON Format (2016).
• ASPRS, LAS Specification 1.4 – R15 (2019-07-09), OGC LAS 1.4 Community Standard(17-030r1), ASPRS LAS Specification 1.5 – R00(lasformat.org), OGC LAZ 1.4 Community Standard(24-070r1).
• CIPA DC-008-Translation-2012, Exif Version 2.3, CIPA About Exif 3.0(2023-12), Adobe XMP Specification Part 1·Part 3, TopoGrafix GPX 1.1 schema.
• PX4 문서(ULog 파일 형식, 로깅), ArduPilot libraries/AP_Logger(LogStructure.h·README), MAVLink 가이드(File Formats), QGroundControl Plan File Format, pymavlink mavutil.py.
• ASPRS, Positional Accuracy Standards for Digital Geospatial Data, Edition 2, Version 2 (2024).
• ASTM E2807(E57), ISO 19115·19157·19159-1, Exif 3.1·3.0 본문, FGDC-STD-007.3-1998 — 읽지 못함 (확인 필요).

다음 장: 9.18은 군사 중심 장(대드론 상호운용 규격)이므로 건너뛴다(BK-08). 이어서 9.19 — 보안 프로토콜·암호 규격: 링크 암호·키 관리·FIPS 140-3·KCMVP·DO-326A/356A로 간다.