'Geotagging'에 해당되는 글 2건

  1. 2016.09.03 지오해시(geohash)
  2. 2016.03.25 Mission Planner를 사용한 항공사진 Geotagging (1)
공간정보/측량2016. 9. 3. 22:23

지오해시(geohash)는 Gustavo Niemeyer가 개발하여 퍼블릭 도메인으로 공개한 지오코딩(geocoding) 시스템이다. 지오해시는 공간을 그리드 형태로 분할하는 계층적 공간 데이터 구조로서, Z-order curve, space-filling curve 등과 같은 많은 공간분할 방법중 하나이다. 

지오해시는 정밀도를 마음대로 정할 수 있고, 코드의 끝부분 문자를 순차적으로 제거하면 크기를 줄일 수 있는 (정확도도 떨어지는) 등의 특성이 있다.

점진적 정밀도 저감 특성의 결과, 인근한 지역(항상 그런 것은 아님)은 대부분 접두어(코드의 시작부분)이 비슷하다. 즉, 접두어가 비슷한 부분이 많을 수록 두 지점은 서로 근접한다.

서비스(Service)

지오해시 서비스는 http://geohash.org/에서 제공된다. 2008년 2월에 시작된 서비스의 목적은 지구상의 위치를 고유하게 구분할 수 있는 짧은 URL을 제공함으로써, 이메일이나 포럼, 웹사이트 등에서 편리하게 사용할 수 있도록 하는 것이다.

지오해시(Geohash)를 얻으려면 사용자는 지오코딩할 주소나 경위도 좌표를 작은 입력박스(대부분 널리 사용되는 정위도 포맷을 인식함)에 넣고, 요청을 시행하면 된다.

주어진 지오해시에 해당되는 경위도 좌표를 보이는 외에도 geohash.org에서 지오해시를 둘러보는 사용자는 내장된 지도도 볼 수 있고, GPX 파일로도 다운로드 받을 수 있으며, 직접 해당 지점을 특정한 GPS 수신기로 전송할 수 도 있다. 아울러 링크를 외부사이트에 제공하여, 특정 지점 주변의 보다 상세한 내역을 제공할 수 있다.

예를 들어 경위도 57.64911,10.40744 (덴마크 Jutland 반도 끝부분)는 약간 짧은 해시인 u4pruydqqvj로 나온다.

사용(Uses)

지오해시의 중요한 사용처는

  • 유일 식별자
  • point 자료의 표현 (예를 들어 데이터베이스에서)

지오해시는 아울러 지오태깅의 목적으로도 제안되었다.

지오해시 데이터 구조를 데이터베이스에서 사용하면 두가지 장점이 있다. 첫번째, 지오해시로 인덱싱된 데이터는 주어진 직사각형 면적에 포함되는 모든 점들이 인접해 있는 조각에 들어가게 된다.(이때 조각의 수는 필요한 정밀도 및 지오해시 "fault line"의 존재 여부에 따라 달라진다.) 이는 데이터베이스 시스템에서 매우 유용하다. 하나의 인덱스에 대한 쿼리가 여러개의 인덱스로 구성된 쿼리에 비해 훨씬 쉽고 빠르기 때문이다. 두번째, 이 인덱스 체계는 간이 접근성 검색에 사용할 수 있다는 것이다. 즉, 가까운 점들은 지오해시가 비슷하다. 

설계(Design)

해시 값 ezs42를 예로 들어, 지오해시를 십진 경위도로 해석하는 방법을 보이면 아래와 같다.

첫번째 단계는 아래와 같은 문자맵을 사용하여 32진법으로 해시값을 해석하는 것이다.

Decimal0123456789101112131415
Base 320123456789bcdefg
 
Decimal16171819202122232425262728293031
Base 32hjkmnpqrstuvwxyz

이 연산을 적용하면 ezs42는 01101 11111 11000 00100 00010 이된다. 여기에서 맨 왼쪽을 0번째 값이라고 가정하여, 짝수 비트는 경도 코드(0111110000000), 홀수 비트는 위도 코드(101111001001)로 둔다.

이제 각각의 2진 코드는 분할에 사용된다. 좌측부터 우측으로 한 비트씩 사용하여 분할 한다. 위도의 경우 -90부터 +90을 두개로 분할 하면, -90 에서 0, 0 에서 +90까지 2개의 구간이 만들어진다. 위도 첫비트는 1이므로, 높은 구간을 사용하게 된다. 이러한 방식으로 모든 비트를 반복한다. 마지막으로 위도 값은 마지막으로 남은 구간의 중앙값이 된다. 경도도 이와 같은 방식으로 처리하되, 시작구간이 -180 에서 180이라는 것만 다르다.

이러한 절차를 마치면 대략 위도 42.6, 경도 -5.6이 된다.

위도 2진값 101111001001이 42.6이 되는 과정은 다음과 같다. 맨 처음에 위도는 -90에서 90 사이라는 것을 알고 있다. 아무런 비트도 없으니, 위도는 0이라고 할 수 있고 에러는 ±90이다. 첫번째 비트를 사용하면, -90 에서 0 구간인지, 0에서 +90 구간인지 결정할 수 있다. 첫번째 비트가 높은(1) 값이므로, 우리의 위도는 0에서 90사이 어디쯤이라는 것을 알 수 있다. 만약 다른 비트가 없다면 위도는 45라고 가정할 수 있고, 에러는 ±45가 된다.

비트가 하나씩 추가될 수록 이 에러가 반으로 줄어든다. 아래의 표는 각각의 비트의 효과이다. 각 단계에서 관계되는 범위는 초록색으로 강조하였다. 즉 낮은 비트(0)은 아래 구간, 높은 비트(1)은 높은 구간을 선택한다.

끝에서 두번째 열은 위도값(범위의 산술평균)이다. 비트가 추가될 수록 이 값은 점점 더 정확해진다.

bitminmidmaxvalerr
1-90.0000.00090.00045.00045.000
00.00045.00090.00022.50022.500
10.00022.50045.00033.75011.250
122.50033.75045.00039.3755.625
133.75039.37545.00042.1882.813
139.37542.18845.00043.5941.406
042.18843.59445.00042.8910.703
042.18842.89143.59442.5390.352
142.18842.53942.89142.7150.176
042.53942.71542.89142.6270.088
042.53942.62742.71542.5830.044
142.53942.58342.62742.6050.022

(위 표에 있는 숫자들은 보기 편하도록 소수점 세자리에서 반올림하였다.)

최종 값은 아래와 같이 사용하여야 한다.

    

따라서 42.61에서 42.61 혹은 42.6은 올바르지만, 43은 아니다.

geohash lengthlat bitslng bitslat errorlng errorkm error
123± 23± 23± 2500
255± 2.8± 5.6±630
378± 0.70± 0.7±78
41010± 0.087± 0.18±20
51213± 0.022± 0.022±2.4
61515± 0.0027± 0.0055±0.61
71718±0.00068±0.00068±0.076
82020±0.000085±0.00017±0.019

지오해시 알고리듬의 한가지 제한은 공통 접두어를 근거로 점들간의 근접성을 찾고자하는 경우에 발생한다. 서로 근접해 있지만, 자오선을 기준으로 180도 떨어져 있는 경계 위치에서는 전혀 접두어가 다르다. (물리적으로는 근접해 있지만, 경도가 다를 경우) 아울러 북극 및 남극에 가까운 점들의 경우, 지오해시가 매우 다르게 된다.(물리적으로는 근접해있지만, 경도가 다를 경우)

적도(혹은 본초자오선)를 기준으로 양쪽으로 근접한 지역에서도 서로 다른 '반구'에 속하기 때문에 접두어가 공통되지 않는다. 간단히 말해 한 지역의 경도(또는 위도)는 011111.... 이 되고 반대쪽은 100000... 이 되어, 공통 접두어는 없고 대부분의 비트가 반대로 된다. 이러한 현상은 점들을 순서대로 나열할 때 Z-order 커브(보다 적당하게는 N-order visit)에 의존하는 경우에도 볼 수 있다. 인접해 있는 두점이 아주 멀리 떨어져 있을 수 있기 때문이다. 그러나, 공통접두어가 긴 점들은 서로 근접하다는 것은 항상 진실이다.

In order to do a proximity search, one could compute the southwest corner (low geohash with low latitude and longitude) and northeast corner (high geohash with high latitude and longitude) of a bounding box and search for geohashes between those two. This will retrieve all points in the z-order curve between the two corners, which can be far too many points, this also breaks down at the 180 meridians and the poles. Solr uses a filter list of prefixes, by computing the prefixes of the nearest squares close to the geohash

인접 검색을 하기 위해서는 먼저 경계 사각형(Bounding box)의 남서쪽 구석(작은 경위도 값을 가진 작은 지오해시)와 북동쪽 구석(높은 경위도 값을 가진 높은 지오해시)를 계산한 뒤, 이 두 점사이의 지오해시를 검색해야 한다. 이렇게 하면 두 꼭지점 사이에 있는 z-order curve에 있는 모든 점을 추출하여, 너무 많은 점이 될 수도 있지만, 180도 자오선 및 극지방에서 분할된다. Solr 는 지오해시에 인접한 사각형의 접두어를 계산함으로써, 접두어 필터 리스트를 사용한다.????

세번째로 지오해시는 경위도좌표에 기반하므로, 두 지오해시간의 거리는 두 지점간의 경위도 좌표에서의 거리가 되는데, 이는 실제 거리가 아니다. 자세한 사항은 Haversine 식을 볼 것.

다음은 경위도 체계의 비 선형성을 보여주는 예이다.

  • 적도에서 경도 1도의 길이는 111.320 km 이지만, 위도 1도의 길이는 110.574km로 약 0.67%의 오차가 있다.
  • 위도 30도(중위도)에서 이 오류는 110.852/96.486 = 14.89% 로 커진다.
  • 위도 60도(고위도)에서는 111.412/55.800 = 99.67% 가 되며, 극에서는 무한대에 근접한다.

참고로 이러한 제한은 지오해시 때문이 아니라, 경위도 좌표체계 때문으로, 구면(비선형, 나머지 연산과 비슷하게 값의 겹침 등)상의 좌표를 2차원 좌표로 사상시키는 데 따르는 어려움과 이차원 공간을 균등하게 탐사하는 데 따른 어려움 때문이다. 첫번째는 지리좌표계지도투영에 관련된 사항이며, 두번째는 힐버트(Hilbert) 곡선z-order curve에 의한 문제이다. 점간의 거리가 선형으로 표현되는 좌표계를 사용하고, 경계에서 중복되지 않는다면 균등하게 탐사하는 것이 가능해져 지오해시를 그러한 좌표계에 적용할 경우 위에서 언급한 제한은 발생하지 않는다.

지오해시를 직각 좌표계를 사용하는 지역에도 적용할 수 있지만, 그 경우 해당 좌표계가 적용하는 지역에서만 사용할 수 있다.

이러한 문제에도 불구하고, 여러가지 회피책이 있으며, 근접성 검색을 구현할 수 있도록 Elasticsearch, MongoDB, HBase, Accumulo 등에서 이 알고리듬을 성공적으로 적용해 왔다.

지오해시를 데이터베이스에서 문자열로 저장하는 대신 다른 대안으로서 위치코드(Locational codes)가 있으며, 이는 공간키(Spatial Key)쿼드타일(QuadTiles)과 비슷하게 부른다. 

원문 : https://en.wikipedia.org/wiki/Geohash


Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

드론/쿼드콥터2016. 3. 25. 17:24

쿼드콥터에 사진기를 장착하고, 자동미션을 이용해 항공사진을 촬영하면, 일련의 사진이 촬영됩니다. 


이 사진들은 물론 그냥 사용할 수도 있지만, 대부분의 경우, 특히 항공사진측량의 경우에는 촬영된 위치와 방향이 중요합니다.


그런데, 제가 조립한 기체는 GPS가 따로 달려있지 않은 일반 똑딱이(Canon IXUS 870 IX)를 사용하여 촬영했기 때문에 촬영된 위치나 자세한 정보가 전혀 없습니다. 하지만, Pixhawk의 경우에는 모든 촬영중 발생하는 상황이 LOG 파일로 저장됩니다. 이 정보를 사용하면 사진에 촬영 위치를 넣을 수 있습니다. (이 과정을 Geotagging 이라고 합니다.) 이 글은 ardupilot.org/copter의 글을 참고하여 정리한 것입니다.


먼저 아래 좌측은 제가 맨 처음 시범 촬영한 사진들을 적당한 위치로 배열해 본 것입니다. 오른쪽은 다음 지도에서 동일한 지역을 복사한 것이고요. 


Mission Planner를 이용한 Geotagging 은 두 가지 방법이 있습니다. 하나는 로그에 들어 있는 CAM 메시지를 사용하는 방법이고, 다른 하나는 드론과 카메라의 시간을 동일하게 맞춘 뒤 이를 기준으로 위치를 끌어오는 방법입니다.


먼저 미션 플래너에서 Ctrl+F를 누르면 아래와 같은 화면이 뜹니다. (메뉴에는 없습니다.) 이중에서 맨 위에 있는 메뉴인 [Geo ref Images]를 사용하면 됩니다.



아래는 [Geo ref Images]를 눌렀을 때 나오는 화면입니다. 맨위에 있는 [Browse Log]는 촬영당시의 Log 파일을 찾아서 넣어주고, [Browse Pictures] 에는 촬영된 사진들을 넣어주면 됩니다. 이때 촬영때의 사진만 따로 넣어둔 폴더를 지정하면 됩니다. 이 폴더에는 다른 종류의 파일은 들어있어도 되지만, 사진은 오직 촬영당시의 사진만 존재해야 합니다. 그리고 사진들은 알파벳으로 정렬했을 때 처음 촬영된 사진이 맨 위로 올라오고 순서여야 합니다.



그 아래에 있는 Time offset 과 CAM Message Synchro 가 Geotagging  방식을 선택하는 겁니다. Pixhawk와 연동하여 촬영하면 CAM Message Synchro를 눌러주면 됩니다.


다 준비가 되면 Pre-Process를 눌러줍니다. 그러면 한참 계산을 하고 맨 아래에 Done 이라고 나타납니다. 



다음으로 [Location KML] 을 누르면 촬영된 위치가 맞는지 구글어스에서 확인할 수 있습니다. 아래는 시범 촬영한 사진을 확인해본 모습입니다. 여기에서 하얀줄은 드론의 비행 코스, 노란 핀은 촬영한 위치입니다.



마지막으로 [Geo Tag Images] 를 눌러주면 원본 사진이 있는 폴더 속에 Geotagged 라는 폴더가 생겨 있습니다.


===

위 촬영은 보시는 것처럼 3코스만 촬영했기 때문에 아무래도 부족하여 새로 촬영을 나갔습니다. 이 영상을 사용하여 위의 방법대로 지오태깅을 하려고 했는데 문제가 발생했습니다. Preprocessing을 누르면 아래처럼 사진 매수가 일치하지 않는다고 나오는 겁니다. 정확한 원인은 찾지 못했는데... 아무래도 중복도를 높이다보니(80%) 비행콘트롤러에서 촬영메시지를 자주 보내지만, 카메라에서 이를 처리하지 못했기 때문이 아닌가 하는 생각이 들었습니다. (다음에는 중복도를 좀 낮춰서 촬영해야 할 듯 싶습니다.)



아무튼... 그래서 여러가지를 고민하다가, 시간태그를 이용하는 방법으로 지오태깅을 하기로 했습니다. 이 방법은 [Geo Ref Images] 화면에서 아래와 같이 [Time offset]을 선택하고 [Estimate Offset]을 누르면 아래 알림창에 몇개의 사진을 기준으로 오프셋을 계산해 주는데, 이 값을 "Seconds offset"에 복사해 넣은 뒤 PreProcessing을 눌러주면 됩니다. 나머지 과정은 동일하고요.



그런데 제 경우엔 위에서 보는 것처럼 53.05를 넣으면 아주 이상한 위치로 나와서 촬영된 사진을 보면서 적당히 판독하여 -8로 넣어줬더니 대략 맞더군요.


그 다음도 위에 있는 방법과 동일합니다. [Preprocess]를 누르고 [Location KML]을 통해 위치가 맞는지 확인한 후 마지막으로 [GeoTag Images]를 눌러주면 됩니다.


아래는 이 방법으로 지오태깅을 하면서 만든 KML을 구글어스에서 돌리면서 녹화한 것입니다. 이번엔 총 6개의 코스가 잘 촬영됐네요. ㅎㅎㅎ



===

참고로... 원래 Pixhawk의 로그 파일에는 사진 촬영 당시의 위치 뿐만 아니라, 자세 (기체의 방향) 정보도 들어 있습니다. 아래는 로그파일 첫부분에 들어 있는 필드 정의에 관한 내용인데요, Lat, Lng, Alt 등 위치 뿐 만 아니라, Roll, Pitch, Yaw 등의 자세 정보도 함께 저장됨을 알 수 있습니다. 


- FMT, 148, 39, CAM, QIHLLeeccC, TimeUS,GPSTime,GPSWeek,Lat,Lng,Alt,RelAlt,Roll,Pitch,Yaw


예를 들어, 아래는 맨 첫 사진에 대한 로그입니다. 여기에서 경위도 및 높이는 (37.5154446, 126.8776732, 106.66) 이고, 각도는(<-6.60, -3.55, 21.24) 로 나와 있습니다. 


- CAM, 577738321, 458991000, 1888, 37.5154446, 126.8776732, 106.66, 99.75, -6.60, -3.55, 21.24

다만, 이 값은 그대로 활용하기는 곤란합니다. pixhawk의 IMU 는 Pixhawk 콘트롤러 내부에 들어 있어 카메라가 달려있는 방향과 일치하지도 않을 뿐 더러, 카메라가 별도로 흔들릴 수도 있고... 아주 완벽하게 일치된다고 해도 Pixhawk의 IMU 자체가 별로 정확하지 않기 때문입니다.


그래도... 전문가에겐 이런 정보가 없는 것보다는 도움이 되겠죠. 저도 언젠가 시간이 되면 천천히 한 번 뒤져보고 싶네요.


민, 푸른하늘

===

p.s. : DROTAG를 사용하면 한방에 해결된다네요. Pixhawk 의 Telemetry 포트에 연결만하면 된다는데.. 다만 사진 촬영간격이 최소 3초가 되어야 한다는데... 이건 개선되겠죠. 현재는 품절이라는데 좀더 기다려봐야겠습니다.




p.s. : Mission Planner 대신 UgCS를 사용하면 지오태깅은 해결할 수 있답니다. 이 글을 참고하세요. 무료버전도 가능합니다.

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

  1. willms

    안녕하세요?
    좋은 글 감사합니다.

    글에서 TimeUS가 일반적인 시간(year, month, day, time, minute, second) 형태는 아닌거 같은데 무엇인지 말씀해주실수 있으신가요?


    2018.09.05 10:04 [ ADDR : EDIT/ DEL : REPLY ]