KR102447172B1 - 디지털 지도의 초기 화면에 보이는 장소를 개인화하는 방법 및 이를 이용하는 디지털 지도 시스템 - Google Patents

Abstract

웹앱(web app)으로 실행되는 지도 앱(map app)에 보이는 실내·외의 장소(place)를 문자 메시지(text message)로 보내서 수신인(receiver)과 공유(share)하는 방법이 제공된다. 이 방법은 송신인이 문자 메시지를 보내는 단계와 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계로 구성된다.

Description

디지털 지도의 초기 화면에 보이는 장소를 개인화하는 방법 및 이를 이용하는 디지털 지도 시스템{METHOD OF CUSTOMIZING A PLACE SHOWN IN AN INITIAL SCREEN OF DIGITAL MAP AND DIGITAL MAP SYSTEM USING THE SAME}

본 발명은 디지털 지도의 초기 화면에 보이는 장소를 사용자별로 개인화할 수 있으며, 더 나아가서 디지털 지도의 화면에 보이는 장소를 문자 메시지로 보내서 수신인이 송신인과 동일한 지도 화면을 볼 수 있는 용이한 방법을 제공한다.

1990년대 후반에는 코드분할다중접속(Code-Division Multiple Access, CDMA)이라는 당시로서는 최신 기술이 탑재된 피처폰(feature phone)이 급속하게 확대되기 시작하였다. 그때 개그맨 이창명씨를 전국적인 스타로 만들어 준 TV 광고가 있었다. 제주도 최남단의 섬인 마라도에서 낚싯배를 타고 있는 사람이 전화로 짜장면을 주문하자, 철가방을 든 배달원(이창명)이 바닷가에서 "짜장면 시키신 분!"이라고 큰 소리로 외치며 손님을 찾는 내용이었다.

이 광고는 한 휴대폰 제조사가 '자사의 전화기는 어디서나 잘 터진다.'라는 개념을 코믹하게 호소하기 위하여 고안한 것이었다. 이 광고의 선풍적인 인기로 인하여 바닷가에서 짜장면을 시켜먹는 것이 새로운 유행이 되었으며, 마라도에는 지금도 해물탕집이나 횟집 등 바닷가에 어울릴만한 음식점들이 아니라 다수의 중국집이 성업중이라고 한다.

이제는 스마트폰(smart phone)의 시대이므로 휴대폰(cellular phone)에 GPS(Global Positioning System) 센서와 가속도(加速度) 센서(acceleration sensor), 지자기(地磁氣) 센서(geomagnetic sensor) 등 많은 센서가 내장되어 있고, 또 네이티브 앱(native app, native application)의 형태나 인터넷 브라우저(internet browser)에서 실행되는 웹앱(web app, web application)의 형태로 디지털 지도(digital map)를 사용할 수 있다. 따라서 GPS 센서와 연동되는 지도 앱(map app, map application)을 사용하여 내 위치를 확인한 후, 전화로 짜장면을 시킨다면 예전보다 훨씬 수월하게 배달원이 나를 찾을 수 있을 것이다.

스마트폰에 내장된 GPS 센서를 이용하면 스마트폰의 위치에 해당하는 위도(緯度, latitude)와 경도(經度, longitude) 및 고도(高度, altitude, height)를 알 수 있다. 그런데 스마트폰이나 자동차 내비게이션 시스템(navigation system)에서 사용하는 위도는 초등학교에서 배우는 위도와 다르다. 교과서에서 가르치는 위도는 지구의 형상이 완벽한 구(球, sphere)라고 가정하고 위도와 경도를 설명하기 때문에, 우리의 상식 속에 존재하는 위도는 사실은 지심 위도(地心緯度, geocentric latitude)이다. 그런데 지도나 GPS 시스템에서 사용하는 위도는 측지 위도(測地緯度, geodetic latitude)이다.

측지 위도는 지구의 자전(自轉, rotation of the Earth on its axis)의 영향으로 지구의 형상이 편평한 회전타원체(回轉楕圓體, rotational ellipsoid, ellipsoid of revolution, spheroid), 즉 편구면(偏球面, oblate spheroid)에 가깝다는 사실을 반영한다. 쉽게 말하면 지구의 형상이 배구공을 손으로 눌러서 약간 납작해진 모양과 비슷하다는 뜻이다. 즉, 지구의 형상은 포도알처럼 둥글거나 참외와 같이 길쭉한 모양이 아니라 귤과 비슷하게 납작한 모양이다. 이 지구타원체(Earth ellipsoid)는 지도를 만들 때 그 기준타원체(reference ellipsoid)로 활용된다. 도 1은 측지 위도 φ와 지심 위도 ψ의 차이를 이해하기 위한 개념도이다^비특1.

지구를 모델링하기 위해서는 이 형상뿐만 아니라 실제 지구에 대한 회전타원체의 원점(origin)의 위치와 방향도 결정되어야 한다. 지구타원체의 중심(center) C는 지구의 질량 중심(質量中心, center of mass)에 위치하며, 그 오차는 2cm 이내라고 한다. 지구의 자전축(rotation axis)(102)은 지구의 질량 중심을 지난다. 그리고 지구의 자전축(102)이 지구타원체(101)와 만나는 두 지점이 북극(NP, north pole)과 남극(SP, south pole)이다. 이 지구타원체는 편구면이므로, 이 회전타원체의 단축(短軸, semi-minor axis)이 지구의 자전축과 일치한다.

지구상의 한 점 P의 좌표는 3차원 직각 좌표계(three-dimensional Cartesian coordinate, three-dimensional rectangular coordinate)에서 (X, Y, Z)로 나타낼 수 있다. 3차원 직각 좌표계는 ECEF(Earth-Centered, Earth-Fixed) 방식으로 설정된다. 3차원 직각 좌표계의 원점은 지구타원체의 중심(C)에 위치하며, Z-축은 회전타원체의 단축과 일치한다. 남극에서 북극으로 가는 방향이 Z-축의 양(+)의 방향이고, X-축과 Y-축은 적도면(赤道面, Equtorial plane)에 포함된다. 사실은 지구의 자전축이 지표면과 만나는 두 지점이 북극과 남극이다. 이 북극과 남극은 나침반이 가리키는 자북극(磁北極, magnetic northern pole, north magnetic pole)이나 자남극(磁南極, magnetic southern pole)과 정확히 일치하지는 않는다. 즉, Z-축이 지구의 자전축이고, X-Y 평면이 적도면이다. 지구에 고정되었다(Earth-Fixed)는 말은 이 좌표계가 자전하는 지구와 같이 회전한다는 뜻이다.

이 지구타원체에 최적의 구면좌표계(球面座標係, spherical coordinate system)를 적용한 것을 측지 데이텀(測地 datum, geodetic datum)이라고 한다. 지리 좌표계(geographic coordinate system) 또는 세계 측지 시스템(WGS: World Geodetic System)은 지도 작성(cartography), 측지학(測地學, geodesy) 및 위성 기반 내비게이션(satellite-based navigation)의 표준이다. 가장 최신의 WGS는 WGS 84, WGS 1984 또는 EPSG:4326이라고 부르는 시스템이며, GPS는 이 시스템을 사용한다.

북극과 남극을 포함하는 평면(平面, plane)은 지구타원체의 중심(C)도 포함하며, 이 평면과 지구타원체의 교선(交線, line of intersection)은 타원(楕圓, ellipse)으로 주어진다. 그런데 그 타원의 중심이 지구타원체의 중심과 일치한다는 뜻에서 편의상 대원(大圓, great circle)이라고 부르기로 한다. 북극에서 남극에 이르는 교선, 즉 대원의 절반을 자오선(子午線, meridian) 또는 경선(經線, lines of longitude)이라고 부른다. 그리고 그리니치 천문대(Royal Greenwich Observatory)를 지나는 자오선이 본초자오선(本初子午線, prime meridian)이고, 반대편에 있는 자오선이 반대 자오선(反對子午線, antimeridian)이다.

지구상에서의 한 점 P의 좌표는 측지 위도 φ, 경도 λ 및 타원체고(楕圓體高, ellipsoidal height) h로 표시할 수도 있다. 측지 위도 φ, 경도 λ 및 타원체고 h를 사용하는 좌표계를 측지 좌표계(geodetic coordinate system)라고 한다. 여기서 측지 위도는 3차원 직각 좌표계의 원점 C와 점 P를 잇는 선분(線分, line segment)을 기준으로 측정하는 것이 아니다. 점 P에서 지구타원체(101)에 법선(法線, normal) n을 내린다. 그 법선(n)이 지구타원체(101)와 만나는 점(103)을 타원체점(ellipsoidal point)이라고 지칭하겠다. 타원체점(103)에서 지구타원체(101)에 대한 접평면(tangent plane)(104)을 그린다면, 정의에 의하여 법선은 접평면(104)을 수직으로 지난다. 그 법선이 적도면(X-Y 평면)과 이루는 각도 φ가 측지 위도이다. 그리고 그 법선을 연장하여 Z-축과 만나는 점(105)에서 타원체점(103)까지의 거리가 묘유선(卯酉線)의 곡률 반지름(radius of curvature in the prime vertical) R_N이다^비특2.

지구타원체의 장축 반경(semi-major axis, radius of the semi-major axis)은 6,378,137m이다^비특3. 지구타원체의 장축 반경, 즉 긴 반지름이 a이고, 단축 반경(semi-minor axis, radius of the semi-minor axis), 즉 짧은 반지름이 b라고 하면, 지구타원체의 이심률(離心率, eccentricity) e는 수학식 1과 같이 주어진다.

그리고 묘유선의 곡률 반지름 R_N은 수학식 2와 같이 주어진다.

즉, 묘유선의 곡률 반지름은 상수(constant)가 아니라 측지 위도 φ의 함수로 주어진다. 그리고 3차원 직각 좌표 X, Y, Z는 측지 위도 φ, 경도 λ, 타원체고 h의 함수로 수학식 3 내지 5와 같이 주어진다.

이 지구타원체와 적도면과의 교선이 적도(赤道, Equator)이며, 삼차원 직각 좌표계의 X-축은 지구 중심에서 본초자오선과 적도의 교점(交點, intersection point)을 지나는 직선이다.

지구상에서의 한 점 P의 경도는 그 점을 포함하는 자오면(子午面, meridian plane)이 X-Z 평면과 이루는 각도이며, 수학식 6과 같이 주어진다.

한편 타원체점(103)에서 점 P까지의 거리가 타원체고(楕圓體高, ellipsoidal height) h이다. 그리고 지구타원체의 중심 C에서 타원체점(103)에 이르는 선분이 X-Y 평면과 이루는 각도가 지심 위도 ψ이다. 지심 위도는 수학식 7과 같이 주어진다.

측지 위도의 공식은 상당히 복잡하며, 수학식 8과 같이 주어진다.

즉, 측지 위도를 구하는 공식에 측지 위도가 포함되어 있다. 따라서 단순히 계산기를 두드려서 계산할 수 없다. 우리가 무심코 위도라고 지칭할 때에는 정확하게는 측지 위도를 의미한다. 구글 지도(https://www.google.com/maps)나 네이버 지도(https://map.naver.com)와 같은 디지털 지도에서 표시되는 위도는 측지 위도이다.

사실 현대에 왜 굳이 측지 위도를 사용해야 하는지는 납득하기 어렵다. 아마도 대항해시대(大航海時代, the age of discovery, the age of exploration)에 뱃사람들이 북두칠성(北斗七星, the Big Dipper)과 같은 별자리를 보고서 위도를 측정하고, 시계와 태양의 고도를 비교하여 경도를 측정했던 역사와 관련이 있을 것이다. 한편, 경도는 초등학교 교과서에서 배운 것과 개념이 같지만, 본초자오선이 그린위치 천문대를 정확하게 지나지 않는다는 점에서 미세한 차이가 있다. 어쨌든 이와 같은 수학식을 이용하여 측지 위도 φ, 경도 λ, 타원체고 h를 3차원 직각 좌표계의 좌표 (X, Y, Z)와 상호 변환하는 것이 가능하다.

이상에서 알 수 있는 바와 같이 지구상에서 정확한 3차원적인 위치를 특정하기 위해서는 (측지) 위도와 경도에 더하여 그 지점에서의 타원체고 h가 주어져야 한다. 그런데 스마트폰에서 주어지는 GPS 좌표는 측지 위도와 경도와 해발 고도(海拔高度, height above sea level)이다. 해발 고도는 지오이드(geoid)를 기준으로 측정한 높이이며, 지오이드는 평균 해수면의 높이를 육지까지 확장했을 때 얻어지는 가상의 폐곡면(閉曲面, closed surface)이다. 지오이드의 정확한 형상은 구나 회전타원체가 아니다. 회전타원체에 가깝지만 지하나 지상의 물질의 양과 밀도의 차이로 인하여 울퉁불퉁한 폐곡면으로 주어지며, 지오이드의 전체 형상을 수학적 함수로 기술하기는 사실상 불가능하다.

스마트폰에서 GPS 센서의 값을 보면 (측지) 위도와 경도 및 해발 고도를 알 수 있지만, 그 지점에서의 지오이드의 높이를 알지 못하면 지구상에서의 정확한 3차원적인 위치를 알 수 없다. 그러나 측량, 토목 공사, 건축, 또는 군사 작전 등 정확한 지구의 형상이나 현재 위치, 또는 두 지점 간의 거리 등이 필요한 경우가 아니라면 실제로 지구타원체 상에서 어느 높이에 있는지는 굳이 알 필요가 없을 것이다.

풍선에 붙어있는 개미처럼 지표면이나 해수면에 구속되어 살아가는 대부분의 사람의 위치를 특정하기 위하여 고도는 굳이 필요 없다. 일반인들이 일상생활에서 필요한 GPS의 용도는 내가 지도상에서 어느 위치에 있는지, 또 두 점 사이의 거리 또는 기준점으로부터의 대략적인 거리가 얼마인가를 아는 것일 것이다. 즉, GPS 신호로부터 지도상에서의 정확한 위치만 알 수 있다면, 지구의 형상이 회전타원체이고 우리가 위도라고 부르는 물리량이 정확하게는 측지 위도라는 사실을 몰라도 된다.

그러므로 지구상의 어디에 있더라도 위도와 경도만으로 그 위치를 특정할 수 있다. 즉, 지리산 깊은 산속에서 길을 잃었거나, 광활한 사하라 사막에서 조난을 당했거나, 심지어 배가 난파되어 이름 모를 무인도에 표류했다고 하더라도, 스마트폰이 동작한다면 GPS 센서로 (측지) 위도와 경도를 확인할 수 있다. 또, 그 위도와 경도를 구조대에게 알려준다면, 구조대가 실종자를 탐색하는 수고를 하지 않고 곧바로 구조 대상자를 찾아올 수 있을 것이다.

마라도 앞바다에서 짜장면을 주문하는 경우를 스마트폰의 시대에 다시 생각해보면, 짜장면 배달원이 큰소리로 외치며 주문자를 찾은 이유는 당연히 손님의 정확한 위치를 알 수 없었기 때문이다. 도 2는 네이버 지도에서 마라도 남단을 찾아본 것이다. 도 2에서 볼 수 있는 바와 같이 마라도는 상당히 작은 섬으로 지형지물(地形地物)이 적고, 상세한 주소나 번지로 장소를 특정하기가 쉽지 않다. 따라서 손님은 바다에서 정확한 주소가 없이 '장군바위 앞바다 30m 지점의 흰색 낚싯배'와 같이 다소 두리뭉실하게 자신의 위치를 알려줄 수 밖에 없었을 것이다.

도 3은 구글 지도에서 동일한 마라도 남단으로 이동한 결과이다. 여기서 장군바위 앞바다의 한 지점을 클릭(click)하면, 작은 팝업창이 나타난다. 도 3에는 동중국해(33.112810, 120.269394)라고 표시되어 있다. 즉, 이 지점은 (측지) 위도 33.112810°, 경도 120.269394°인 지점으로 동중국해(남해)에 속한다는 뜻이다.

또, 이 지도 화면의 주소창을 보면 "https://www.google.co.kr/maps/@33.113906,126.2683883,17.5z?hl=ko"라고 표시되어 있다. 이는 GET 방식으로 구글 지도에서 마라도 남단의 주소를 표시한 것이다. 구체적으로는 구글 코리아(https://www.google.co.kr)의 지도(/maps)에서 위도 33.113906°, 경도 126.2683883°인 지점을 검색(@)하여 줌 17.5(17.5z)로 표시하라는 뜻이며, "hl=ko"는 지명 등을 표시하는 언어(language)를 한국어(ko)로 표시하라는 의미이다. 만약 "hl=en"으로 바꾸면 동일한 지도가 영어로 표시된다.

도 4는 데스크톱 컴퓨터(desktop computer)에서 도 3의 주소창(address bar, location bar, URL bar)에 보이는 URL(Uniform Resource Locator), 즉 웹 주소(web address)를 구글의 웹 브라우저(web browser)인 크롬(Chrome)의 주소창에 붙여 넣고 엔터(enter)키를 눌러서 실행한 결과를 보여준다. 도 4에서 알 수 있는 바와 같이 도 3과 거의 동일한 화면이 나타난다. 약간의 차이를 살펴보면 줌(zoom)을 17.5로 입력하였는데, 구글 지도는 줌 레벨을 자연수(natural number)로 절사(切捨, truncate)하여 표시했다.

이와 같은 일이 가능한 이유는 웹(web)으로 실행되는 구글 지도(https://www.google.co.kr/maps)에서 위치 정보(geographic information)가 포함된 검색 문자열(search string)을 처리하는 기능이 구현되어 있기 때문이다. 완전한 위치 정보는 (측지) 위도, 경도, 고도로 구성되는 지리적인 좌표(geographic coordinates)로 주어져야 하지만, 일반도(一般圖, general map)에서 특정 위치로 이동하기 위하여 고도를 알아야 할 필요가 없다. 그리고 도 3에 보이는 문자열은 GET 방식의 표준 문자열이 아니라, 구글의 자체 형식인 것으로 보인다. 처음부터 다른 앱(app, application)과 소통하기 위한 목적의 문자열이 아니므로, 자체적인 형식을 개발하여 사용한 것으로 보인다. 이를 표준적인 문자열로 바꾸면 "https://www.google.co.kr/maps?lat=33.113906&lon=126.2683883&zoom=17.5&hl=ko"와 같이 된다. 이는 구글 코리아의 지도(https://www.google.co.kr/maps)에서 위도는 33.113906°(lat=33.113906)이고, 경도는 126.2683883°(lon=126.2683883)인 지점으로 이동하여 줌을 17.5(zoom=17.5)로 지도를 표시하되, 표시 언어는 한국 어(hl=ko)으로 하라는 의미이다.

그런데 도 3의 주소창에 보이는 지리적인 좌표가 지도상의 정확히 어떤 지점에 대응되는지 파악하기 곤란하다. 지도 중심의 좌표일 것으로 추측되지만, 도 3에서 정확한 지도의 중심이 어디인지도 알기 어렵다.

한편, 안드로이드 스마트폰에서 구글 지도 앱의 검색창에 동일한 문자열을 넣고 검색을 해보면 'Google 지도에서 검색결과 없음'이라고 표시한다. 일단 스마트폰에서 구글 지도는 HTML5/CSS3/JavaScript로 구현된 웹앱(web app)이 아니라 안드로이드 폰(android phone)의 경우에는 Kotlin이라는 언어를, 아이폰(iPhone)의 경우에는 스위프트(Swift)라는 언어를 사용해서 개발된 네이티브 앱(native app)이다. 또, 구글 지도의 검색창은 인터넷 브라우저의 주소창이 아니다. 그리고 구글 지도 앱에서 웹페이지의 주소창에 보이는 문자열을 검색창에서 처리할 수 있는 기능이 구현되지 않았기 때문이다. 따라서 스마트폰의 구글 지도에서 '마라도 장군바위'를 검색할 수는 있지만, 데스크톱 컴퓨터에서 실행되는 구글 지도의 주소창에 보이는 문자열을 넣고 검색할 수는 없다.

GPS 좌표는 항공기에서도, 미사일에서도, 자율주행 자동차에서도, 스마트폰에서도 사용된다. GPS 좌표가 사용되지 않는 분야를 찾아보기가 힘들다. 특히 탐색·구조 작전(search & rescue mission)에서도 GPS 좌표는 매우 중요하다.

예를 들어 사하라 사막 체험 여행(Sahara desert tour)에 나선 여행객이 일행과 떨어져 길을 잃고 조난을 당했는데, 다행히 위성 전화를 가지고 있어서 경찰에게 구조 요청을 하려고 한다고 가정하자. 그러면 일단 주소를 불러줄 수는 없을 것이다. 사막 한가운데에 길 안내 표지판이 없는 것은 물론이고, 주소 자체가 없을 것이기 때문이다.

사구(沙丘, dune)는 바람의 영향으로 끊임없이 모양이 변한다. 그리고 사막 한가운데서 육안으로 보이는 범위에 특이한 지물(地物)이 있을 가능성이 얼마나 되겠는가? 따라서 경찰에게 지형지물을 묘사하여 자신의 위치를 알려주는 것도 불가능하다.

가장 확실한 방법은 스마트폰에서 GPS 좌표를 확인하여 위도와 경도를 불러주는 것이다. 그런데 (측지) 위도와 경도를 사용해서 지리적인 위치를 특정하는 방법은 사실상 불편한 점이 많다. 가장 큰 불편은 미터(meter)나 피트(feet)와 같은 거리(distance)의 단위가 아니므로, 위도와 경도가 다른 두 지점이 거리상으로 얼마나 떨어져 있는지 짐작하기 어렵다는 점이다.

예를 들어 전쟁 중에 아군의 자주포(自走砲, self-propelled artillery)로 적군의 병참 기지(兵站基地, military supply base)를 포격(砲擊)하려고 하는데, 자주포의 경위도와 병참 기지의 경위도를 모두 알고 있다고 하자. 곡사포(曲射砲, high-angle gun)로 병참 기지를 명중시키기 위해서는 자주포에서 병참 기지까지의 정확한 방향과 거리를 알아야 한다. 그런데 두 개의 지리적인 좌표로부터 이를 계산하는 것은 컴퓨터가 없던 과거에는 매우 힘든 계산이었을 것이다.

또, 예를 들어 구조대에게 전화로 자신의 위치의 위도와 경도를 불러 주었는데 소수점 3째 자리의 숫자를 잘못 불러주었다고 가정하면, 그 잘못 불러준 경위도에 해당하는 위치와 조난자의 실제 위치가 얼마나 떨어져 있는지 계산해보기 전에는 알기 어렵다. 즉, 소수점 셋째 자리에서 6을 8로 잘못 불러 주었다고 가정할 때, 그 오차가 1m인지, 10m인지, 1km인지 즉각적으로 답변할 수 있는 사람은 거의 없을 것이다.

참고로 위도와 경도를 소수점 여덟째 자리까지 표시하면 지구상의 어디에 있더라도 위치상의 정밀도가 1mm 이하가 된다. 물론 이는 지구의 크기를 고려해서 그렇다는 의미이며, 달이나 화성에서는 다른 자릿수가 필요하다. 한편, 토목/건축용으로 쓰이는 GPS 측정기의 오차는 2~3cm 정도이며, 스마트폰에서 GPS 좌표의 오차는 5 ~ 15m 정도이다.

도 5는 브리태니커 백과사전에서 제공하는 메르카토르 도법으로 지도를 작성하는 과정을 간단히 예시하는 개념도이다(출처: (https://www.britannica.com/science/Mercator-projection#/media/1/375638/231099). 메르카토르 도법은 원통형 투사 방식(cylindrical projection scheme)의 지도 작성법 중에서 가장 널리 알려진 도법이다. 메르카토르 도법에서는 먼저 구의 중심에서 적도에 접하는 원통에 투사를 한 뒤 그 원통을 전개해서 만들어지므로, 극지방은 표시할 수 없다^비특4. 또 위도가 높아질수록 면적이 과장된다.

도 6은 메르카토르 도법으로 작성한 세계 지도의 예이다(저작자: Justin Kunimune, 출처: https://en.wikipedia.org/wiki/Mercator_projection#/media/File:Mercator_with_Tissot's_Indicatrices_of_Distortion.svg). 도 6에 보이는 원들은 티소 타원(Tissot's indicatrix of deformation)이라고 불리는 것인데, 위치에 따라서 면적이나 형상이 어떻게 왜곡되는가를 표시한 것이다. 만약 왜곡이 전혀 없다면 티소 타원들이 모두 동일한 크기의 원으로 표시되어야 한다. 도 6에서 보면 위도가 커질수록 티소 타원이 커지지만, 그래도 모두 원의 형상을 유지하고 있는 것을 알 수 있다. 즉, 메르카토르 도법은 작은 영역의 각도(angle)와 모양(shape)을 보존한다. 메르카토르 도법은 정각도법(正角圖法, conformal projection)의 대표적인 예이다.

메르카토르 도법의 가장 큰 장점은 방향을 보존한다는 것이며, 이는 특히 과거에 나침반을 이용하여 배로 항해하는데 도움이 되었다. 그런데 메르카토르 도법의 가장 큰 단점은 전술한 바와 같이 면적이 크게 왜곡된다는 것과 극지방을 표시할 수 없다는 것이다. 예를 들면 그린란드(Greenland)는 아프리카와 같은 크기로 나타나지만, 실제로는 아프리카의 면적이 그린란드의 면적의 14배이다.

인터넷 지도가 활성화되면서 메르카토르 도법은 웹 메르카토르 도법(Web Mercator projection)으로 다시 부활하여 널리 쓰이고 있다^비특5. 웹 메르카토르 도법은 Google이 2005년에 채택하여 현재는 대부분의 인터넷 지도 서비스 업체들이 채택하는 투사법이며, SRID(Spatial Reference Identifier)는 EPSG:900913 또는 EPSG:3857로 주어진다. EPSG:3857의 정식 명칭은 WGS 84/Pseudo_Mercator이다. 웹 메르카토르 도법은 구면 메르카토르(spherical Mercator)로 지칭되기도 한다. 웹 메르카토르 도법에서는 경도는 -180°에서 +180°까지 포함되지만, 위도는 ±85.051129°의 범위만 포함된다.

도 7은 웹 메르카토르 도법을 이해하기 위한 개념도이다. 지구상의 한 점 P는 측지 위도 φ와 경도 λ와 타원체고 h를 가지고 있다. 점 P에서 지구타원체(701)에 내린 법선(n)이 지구타원체를 만나는 점이 타원체점(703)이다. 이 법선(n)은 타원체점에서 접평면(704)을 수직으로 지난다. 지구타원체의 적도면(X-Y 평면)에서의 반경은 R이다.

이때 지구타원체(701)와 중심(C)을 공유하고, 반지름이 R인 구(706)를 가정한다. 그리고 지구타원체의 중심 C에서 법선 n에 평행한 직선(n')을 그린다. 이 직선(n')이 구(706)와 만나는 점(707)을 구점(球點, sphere point)이라고 지칭하기로 한다. 그리고 이 구점에서 직선 n'을 따라 거리 h만큼 떨어진 점을 P'이라고 한다. 구면 메르카토르 도법은 점 P를 P'으로 대체하여 메르카토르 도법으로 그린 것이다. 즉, 지구타원체에서 측지 위도 φ와 타원체고 h를 갖는 점 P를 구면 지구(spherical Earth)에서 지심 위도가 φ이고, 고도가 h인 점 P'으로 간주하는 것이다.

이와 같이 지구타원체를 구면 지구로 치환한 후, 메르카토르 도법을 이용하여 지도 투사(map projection)를 수행하기 위하여 지구타원체(701)와 적도에서 접하는 원통(708)을 가정한다. 그러면 P"은 직선 n'이 원통면(708)을 만나는 점이다.

이와 같은 원리에 의하여 웹 메르카토르 도법의 투사 방식은 수학식 9 내지 10과 같이 쓸 수 있다.

여기서 x는 웹 메르카토르 투사 방식에서의 동향거리(東向距離, easting)이고, λ는 경도(longitude)이며, R은 적도에서 지구의 반경인데, 지구타원체의 장축 반경 a와 같다. 즉, R 값으로 6,378,137m를 사용할 수 있다. 한편, y는 웹 메르카토르 투사 방식에서의 북향거리(北向距離, northing)이고, φ는 측지 위도이다. 웹 메르카트로 도법은 측지 위도와 경도를 사용하면서도 지구는 타원체가 아니라 구로 가정하고, 측지 위도를 지심 위도로 가정하여 이를 메르카토르 도법으로 옮긴 것이다.

지구타원체를 구로 근사하지 않고 정확하게 메르카토르 도법으로 지도를 작성할 수도 있다^비특3. 그런데 종이에 인쇄된 지도를 작성할 때는 그렇게 할 수 있지만, 지구타원체 상에서의 수학적 연산이 복잡하여 디지털 세계 지도에 사용하기에는 부적당하다. 또 대한민국전도(大韓民國全圖, complete map of Korea)와 같이 지구에서 국소적인 지역의 지도를 나타낼 때에는 오차가 mm 이하인 도법(圖法)이 가능하지만, 다국적 기업인 구글이 전 세계를 상대로 서비스하는 구글 지도에서는 그런 혜택을 기대할 수 없다. 따라서 전 세계를 상대로 하는 지도 서비스에서 웹 메르카토르 도법은 거의 유일무이한 선택이라고 할 수 있다.

모든 지도 투사(map projection)는 왜곡을 동반한다. 구면 메르카토르 도법에서는 2단계로 왜곡이 발생한다. 첫 번째로 측지 위도 φ를 지심 위도로 간주해서 왜곡이 발생하며, 두 번째는 구면(706)에서 원통(708)으로 투사를 하면서 왜곡이 발생한다. 도 7에서 짐작할 수 있는 바와 같이 웹 메르카토르 도법에서는 지도의 가로축과 세로축이 거리의 단위를 가지지만, 실제 거리와는 차이가 난다. 이런 이유로 미군(US army)은 군사용으로 웹 메르카토르 도법의 지도를 사용하는 것에 대해서 경고를 하고 있다.

지구의 적도 반지름은 약 6,378km이며, 극 반지름은 약 6,357km이다. 즉, 지구타원체는 육안으로는 구분하기 어려울 정도로 구에 가깝다. 지구타원체를 구로 간주하면, 메르카토르 투사 도법에 의한 거리의 왜곡(scale)은 수학식 10으로부터 수학식 11과 같이 주어진다.

따라서 적도(φ = 0°)에서는 1m가 1m로 표시되지만, 위도 30°에서는 1m가 1.15m로 표시되고, 위도 45°에서는 1.41m로, 위도 60°에서는 2.00m로, 위도 85°에서는 11.47m로 표시된다.

UTM 좌표계(Universal Transverse Mercator Coordinate System)는 전 지구상의 위치를 통일된 체계로 나타내기 위한 격자 좌표 체계의 하나로 미국 육군이 1947년에 개발하였다^비특6. 도 8은 UTM 좌표계로 작성한 세계 지도의 예이다(저작자: Jan Krymmel, 출처: https://commons.wikimedia.org/wiki/File:Utm-zones.jpg). UTM 좌표계에서는 지구를 경도 6°간격의 세로띠로 나누어 횡축 메르카토르 도법(橫軸 메르카토르 圖法, transverse Mercator projection)으로 그린 뒤, 각 세로 구역(띠)마다 설정된 원점에 대한 종·횡 좌표로 위치를 나타낸다. 각 세로띠에서 중앙 자오선(central meridian)과 적도의 교점이 원점이다. 지리 좌표계가 극지방으로 갈수록 직사각형이 크게 감소하는 반면 UTM 좌표계는 직사각형 모양을 유지하므로 거리, 면적, 방향 등을 나타내는데 매우 편리하다는 장점이 있다.

UTM 좌표계는 곡률 반경이 불규칙하고 기복이 존재하는 지구의 형상을 기준 타원체로 모델화하여 나타내는데, 개발 당시 미주 지역에는 클라크 1866 타원체가, 그 이외 지역에는 국제 타원체가 사용되었다. UTM 좌표계에서 사용하는 UTM 투영법은 벨기에 출신의 지리학자이자 지도 제작자인 게라르두스 메르카토르(Gerardus Mercator)가 1570년에 개발한 메르카토르 도법을 횡축으로 그린 것이다. UTM 좌표계는 180°W(서경)부터 시작하여 경도 6° 간격으로 지표면을 총 60개의 세로띠로 나누며, 각각의 세로띠는 남북으로는 80°S(남위)부터 84°N(북위)까지에 이른다. 각 세로띠는 (180°W-174°W) 구간에서부터 시작하여 (174°E-180°E) 구간에 이르기까지 동쪽으로 1부터 60까지의 번호가 매겨진다.

도 9는 UTM zone을 예시하는 개념도로서(저작자: Javiersanp, 출처: https://commons.wikimedia.org/wiki/File:Utm-latlon_grid_en.svg), Zone 28의 북반구를 보여준다. 이와 같은 60개의 세로띠에 대하여 남북 방향으로 왜곡이 상대적으로 적은 횡축 메르카토르 도법으로 지도에 옮긴다. 각 구역의 중앙 자오선에서의 축척 계수는 0.9996이며, 구역의 경계에서는 약 1.0010 정도이다. 원점(즉, 중앙 자오선과 적도의 교점)에서 동서로 180km 위치에서 축척 계수가 1이 되어, 그 이내에서는 축척 계수가 1보다 작고, 180km를 벗어나는 지역에서는 축척 계수가 1보다 크게 된다.

각각의 세로띠(UTM zone)는 다시 20개의 위도 밴드(latitude bands)로 나누는데, 이는 UTM 체계가 아니라 군사용 격자 참조 시스템(MGRS: Military Grid Reference System)의 체계에 속한다. 각 위도 밴드는 위도 8° 간격이다. 단, 가장 북쪽의 위도 밴드(72°N-84°N)는 12°로 되어 있다. 최남단인 (80°S-72°S) 밴드(band)에서부터 최북단인 (72°N-84°N) 밴드까지 'C'부터 'X'까지의 알파벳 기호를 매겨 구분하는데, 혼동을 막기 위해 'I'와 'O'는 제외한다. I는 숫자 1과 그리고 'O'은 숫자 0과 혼동될 수 있기 때문이다. 따라서 북반구에서 적도와 접한 위도 밴드(0°N-8°N)의 기호는 'N'이 된다. 각각의 세로띠, 즉 UTM zone 안에서 어느 한 위도 밴드는 숫자와 알파벳으로 된 기호를 함께 써서 나타낸다. 예를 들어, 대한민국은 UTM 좌표계에서 51S, 51T, 52S, 52T 구역에 속해 있다.

전술한 바와 같이 UTM 좌표계는 군사용으로 사용되는 직교 좌표계로서 UTM 좌표계에서의 북향거리(northing)와 동향거리(easting)는 지표면 상에서의 거리에 잘 대응하며, 남북 방향이나 동서 방향이 아닌 사선(斜線, oblique line) 방향에 있는 지점의 거리도 삼각법으로 쉽게 계산할 수 있는 장점이 있다. 그런데 GPS 신호로부터 얻은 측지 위도와 경도를 UTM 좌표계에서의 북향거리 및 동향거리와 상호 변환하는 과정이 너무나 복잡하다는 단점이 있다. 따라서 컴퓨터나 앱을 사용하여 UTM 좌표계를 구할 수는 있지만, 계산기나 수기(手記, handwriting)로 계산하는 것은 사실상 불가능하다.

우리나라에서도 조난당한 등산객이 자신의 위치를 전화로 용이하게 신고할 수 있도록 '국가지점번호'라는 것을 사용하고 있다^비특7. 도 10은 대청호(大淸湖) 주변의 한 국가지점번호 안내판 사진이다. 위키백과는 국가지점번호를 다음과 같이 해설하고 있다.

대한민국의 행정법 중 하나인 《도로명주소법》 제2조 <정의> 9항에서의 국가지점번호란 국토 및 이와 인접한 해양을 격자형으로 일정하게 구획한 지점마다 부여한 번호(문자와 아라비아 숫자를 포함한다)를 말한다.

이러한 국가지점번호는 긴급구조활동 등에서 위치의 표시로 활용한다.

국가지점번호체계

한글 문자 2개와 아라비아 숫자 8개를 조합하여 나타내며, 전국을 하나의 좌표체계로 표현한다.

전국을 100km × 100km 격자로 나눈 뒤, UTM-K원점에서 남쪽 700km, 서쪽 300km 지점을 기준점으로 하여 그 기준점에서부터 각 격자마다 서에서 동으로, 남에서 북으로 각각 가나다순으로 한글 문자를 부여한다. 그 다음, 그 한 격자의 가로와 세로를, 길이가 각각 10미터 단위로 10,000개로 나눈 지점을 기본단위로 하여 숫자를 부여한다. 이때 부여되는 숫자는 4자리로 표시하며, 이 경우 각 정수가 4자리에 미달하는 경우에는 4자리가 될 때까지 그 앞에 "0"을 삽입한다. 지점번호 중 앞에 표시된 4자리 숫자가 동쪽 거리를 나타내는 숫자이고 뒤의 4자리 숫자가 북쪽 거리를 나타낸다. 예를 들면, "라아 8485 1333"(설악산 대청봉)는 기준점에서 동쪽으로 384.85km, 북쪽으로 713.33km 지점을 뜻한다.

위키피디아의 설명과 같이 이 국가지점번호는 조난자가 이 안내판을 보고 119에 자신의 위치를 불러주라는 의도로 개발된 것이다. 즉, 119에 신고하면서 자신의 위치를 "다바 9924 1825"로 신고하면, 구조대는 실종자의 위치를 가로: 세로 10m의 정사각형의 범위로 특정할 수 있다. 위도와 경도를 이용하여 얼마든지 정확하게 위치를 특정할 수 있음에도 불구하고, 이런 국가지점번호 체계를 사용하는 것은 전술한 바와 같이 지리적인 좌표가 사람들이 기억하거나 구술하기에는 불편한 점이 있기 때문이다.

그런데 이 국가지점번호 체계도 불편한 점이 있다. 우선, 이 국가지점번호는 가로: 세로 10m의 오차 범위로 위치를 특정한다. 10m의 오차 범위는 조난자 구조에 사용하기에는 충분하지만, 다른 용도로 사용하기에는 불충분하다. 예를 들어 야구경기장에서 관람객이 전화로 치맥(치킨과 맥주)을 주문하는 경우를 생각해 보면, 가로세로 10m의 정사각형 안에는 약 100명 정도의 사람들이 있을 것이다. 따라서 국가지점번호를 불러 주었다고 하더라도, 배달원이 막상 관중석에 가서는 "치맥 시키신 분!"을 외치지 않고는 손님이 어느 사람인지 알 수 없을 것이다. 또, 대청호에서 조난당한 사람이 근처에서 국가지점번호 표지판을 발견할 수 없다면, 국가지점번호 체계의 도움을 받을 수 없다.

영국의 한 기업(What3words Limited)의 앱(what3words)은 세 단어를 이용하여 지구상의 위치를 특정한다. 도 11은 이 앱을 소개하는 페이지(https://what3words.com/products/what3words-app)의 일부를 캡쳐한 것으로 위도/경도의 쌍을 3개의 단어로 치환한다는 것을 알 수 있다.

[특 1]에는 이 기술의 원리가 다음과 같은 요지로 설명되어 있다. 위치 결정 장치(location determining means)로부터 한 장소의 지리적인 좌표(geographical coordinates)를 받은 후, 이를 하나의 큰 정수(integer) n으로 변환하고, 이를 다시 3개의 정수 (i, j, k)로 분해한다. 그리고 분해된 3개의 정수를 3개의 단어로 치환하여 위치 식별자(location identifier)로 사용한다.

지리적인 좌표는 위도와 경도의 쌍을 말하는데, 위도와 경도를 소수점 6째 자리까지 사용한다. 이는 지구상에서 가로: 세로 3m의 오차 범위로 위치를 특정할 수 있는 정밀도이다. 스마트폰의 GPS 센서는 대략 이 정도의 정확도를 가지고 있다.

위도와 경도의 쌍을 정수 n으로 변환하고, 이를 다시 3개의 정수 (i, j, k)로 분해하며, 이를 또다시 3개의 단어로 치환하는 작업은 조견표(早見表, lookup table)를 사용하여 서버(server)에서 실행된다.

사용자는 이 3 단어를 해당 장소의 위치를 기억하거나 기록하기 위하여 사용할 수 있고, 다른 사람에게 자신의 위치나 제3의 목적지를 불러주기 위하여 사용할 수도 있으며, 문자 메시지(text message)로 보낼 수도 있다. 수신자는 이 3 단어로부터 역으로 지리적인 좌표를 구할 수 있고, 해당 위치를 지도에 표시할 수도 있다.

도 12는 출원인의 사무실에서 가장 가까운 전철역 출구를 이 앱에서 찾아본 것이다. 도 12에서 볼 수 있는 바와 같이 대전 지하철 1호선 중앙로역 9번 출구 근처의 3m × 3m의 정사각형 영역은 'suspect', 'civil', 'bikers'라는 세 단어로 특정된다. 하단의 공유(share) 버튼을 누르면 문자 메시지로 타인에게 전송할 수 있는데, 문자 메시지에는 https://w3w.co/suspect.civil.bikers라는 인터넷 링크(internet link)가 포함되어 있다. 수신된 문자 메시지를 클릭하면 지도가 실행되어 도 13과 같은 화면이 얻어진다.

[특 2]에는 휴대폰의 GPS 센서와 인터넷에 연결된 전용 서버(Buddy Watch sever)를 이용하여 주시 목록(watch list)에 등록된 둘 이상의 사용자(Buddy)들이 양방향으로 위치를 공유하는 기술이 개시되어 있다. 주시 목록에 사용자를 등록하는 과정은 영구적으로 또는 요청(ask)/수락(accept) 기반으로 일시적으로 이루어질 수 있으며, 사용자는 임의로 자신의 위치가 공유되는 것을 중지할 수 있다.

[특 3]에는 GPS 위치 확인 시스템(GPS positioning system)과 휴대폰 통신 네트워크(mobile communication network)를 이용하여 요청/수락 기반으로 다른 휴대폰의 위치를 지도상에서 확인할 수 있는 방법이 개시되어 있다.

[특 4]에는 송신인이 수신인에게 지도(map)가 포함된(embedded) 문자 메시지(text message)를 보내어 수신인이 송신인과 수신인의 위치를 동시에 확인할 수 있으며, 지도 상에서 두 사람의 위치가 실시간으로 갱신되는 기술이 개시되어 있다.

[특 5]에는 송신인(sender)의 스마트폰의 지리적인 위치(geographic location)를 이메일(email)이나 문자 메시지 등 택일적으로 선택 가능한 두 개 이상의 수단을 이용하여 부호화된 데이터(encoded data)로 수신인(receiver)에게 전송하여 송신인의 위치를 공유(location sharing)하는 방법이 개시되어 있다.

[특 6]에는 수신인이 송신인으로부터 문자 메시지를 받아서 이를 처리(process)하여 지도상에 송신인의 위치를 표시하되, 문자 메시지는 송신인의 위치를 포함하는 긴 URL(longer URL)을 해시(hash) 처리한 짧은 URL(shorter URL)을 포함하는 방법이 개시되어 있다.

[특 7]에는 송신인과 수신인이 일정한 시간 동안 지속적으로 위치를 공유하고, 지정한 시간이 경과하면 위치의 공유를 종료하는 기술이 개시되어 있다.

[특 8]에는 이동통신 단말기의 용이한 버튼조작만으로 비상연락처로 비상정보를 송출하여 비상상황을 통보할 수 있도록 함과 아울러, 이동통신 단말기의 무음/무광 모드 전환에 의해 보안이 유지될 수 있도록 하는 이동통신망을 이용한 비상호출 처리장치가 개시되어 있다.

[특 9]에는 지표면을 3차원 표면(three-dimensional curved surface)으로 근사하고, 3차원 표면을 다수의 셀(cell)로 분할한 뒤, 각각의 셀에 대하여 3차원 곡선 좌표계 시스템(three-dimensional curvilinear coordinate system)을 적용하여 지구상의 3차원적인 위치를 특정하는 방법이 개시되어 있다.

[특 10]에는 지리적인 좌표와 함께 전방위 영상(panoramic image)에 마커(marker)와 텍스트(text)를 삽입하여 사전 설정된 공유 링크(pre-set sharing link)로 전송할 수 있는 기술이 개시되어 있다.

한편, 급속한 도시화로 인하여 전 세계의 인구 대부분이 도시에 거주하고 있으며, 또한 많은 건물이 2층 이상의 다층 건물이다. 따라서 특정 건물의 온전한 정보를 온라인 지도상에 표시하고 싶다면 사용자가 특정 층을 선택하면 그 층의 구조와 정보를 보여주는 실내 지도(indoor map)가 필수적이다. 실내 지도는 기본적으로 건물의 층별 평면도(floorplan)에 선택적으로 추가적인 정보를 표시한 것을 말한다. 실내 지도는 독립적으로 사용될 수도 있지만, 실외 지도와 연동하면 그 유용성이 크게 증가한다.

구글은 2005년 2월에 웹으로 실행되는 디지털 지도를 서비스하기 시작하였으며, 실내 지도 서비스는 2011년 3월에 시작되었다^비특8. 크롬(Chrome)에서 '구글 실내 지도'를 검색하면 구글의 실내 지도 서비스를 소개하는 페이지(https://www.google.com/intl/ko/maps/about/partners/indoormaps)를 찾을 수 있으며, 실내 지도의 사례로 미국 뉴욕의 매디슨 스퀘어 가든(Madison Square Garden)을 보여주고 있다. 여기서 'Google 지도에서 보기'라고 표시된 링크를 클릭하면 도 14와 같은 화면이 보여진다(출처: https://www.google.com/maps/place/%EB%A7%A4%EB%94%94%EC%8A%A8+%EC%8A%A4%ED%80%98%EC%96%B4+%EA%B0%80%EB%93%A0/@40.7505029,-73.9936424,19z/data=!3m1!5s0x89c259ae1546fb27:0x93ba42deb43c8368!4m12!1m6!3m5!1s0x89c25a21fb011c85:0x33df10e49762f8e4!2z66ek65SU7IqoIOyKpO2AmOyWtCDqsIDrk6A!8m2!3d40.7505045!4d-73.9934387!3m4!1s0x89c25a21fb011c85:0x33df10e49762f8e4!8m2!3d40.7505045!4d-73.9934387).

도 14에서 보여지는 바와 같이 실외 지도(outdoor map) 상의 올바른 위치에 실내 지도가 중첩되어 표시되고 있으며, 소개 화면에는 6K 층이 보여지고 있다. 또 화면 왼쪽에는 매디슨 스퀘어 가든의 미니 홈페이지가 보여지고 있으며, 오른쪽에는 다른 층을 선택할 수 있는 메뉴가 있다.

도 15에서는 지도 화면을 확대하여 매디슨 스퀘어 가든의 동편을 보여주고 있으며, 도 16에서는 층을 지하 2층(-2)으로 변경한 것이다. 이처럼 다른 층을 선택하면 해당 층의 평면도(floorplan)로 교체되어 표시된다.

[특 11]에는 네트워크 서버(net work server)가 사용자 기기(client device)에게 실내 지도 데이터(indoor map features)를 제공하는 기술이 개시되어 있다. 사용자가 특정한 지리적인 위치와 줌 레벨에 대한 실외 지도 데이터를 요청하면 네트워크 서버는 실외 지도 데이터 중에 다층 건물(multi-floor building)이 있는지 확인한 후, 다층 건물에 대한 기본층(default floor)의 실내 지도와 실내 지도 지시기(indoor map indicator)를 사용자 기기에 표시하며, 사용자가 실내 지도 지시기를 조작함에 따라서 실내 지도가 선택적으로 표시된다.

[특 12] 내지 [특 13]에는 상호 작용이 가능한 디지털 지도에서 다층 건물의 한 층을 선택하는 기술이 개시되어 있다. 디지털 지도에는 다층 건물의 외형(external representation)이 표시되고, 사용자가 이 외형의 한 점을 선택(select)하면, 그 건물의 3D 모형이 나타나며, 그 건물의 층별 평면도가 부분적으로 중첩된 상태로 표시된다. 사용자가 이 모형을 수직 방향으로 쓸어내면(swipe), 선택된 층의 평면도가 나머지 다른 층의 평면도와 구별되는 방식으로 활성화된다.

[특 14]에는 GPS 위치정보를 찾을 수 없는 경우에도 실내 위치 정보를 제공할 수 있으며, 개방형 API를 통해 위치 정보 및 지도정보 기반의 서비스를 제공할 수 있는 기술이 개시되어 있다. 이를 위하여 건물의 실내 지도 및 실내에 설치된 무선 AP(Access Point)의 위치와 식별정보 및 신호 세기를 기초로 실내 지도상에서의 위치를 추정한다.

[특 15] 내지 [특 16]에 개시된 종래 발명에는 지구상에서 실내·외의 위치를 특정하는 새로운 좌표계가 개시되어 있다. 이 좌표계의 구조는 도 7에 예시된 것과 유사한 점이 있다. 즉, 지구상에서 측지 위도 φ와 경도 λ를 가지는 한 점 P를 지심 위도가 φ이고 경도가 λ인 점이라고 가정하는 것이다. 그리고 이 좌표계에서 지리적인 위치는 측지 위도와 경도의 쌍 (φ, λ) 대신에 북향거리(northing) N과 동향거리(easting) E의 쌍 (N, E)을 사용하여 특정하며, 원통형 투사(cylindrical projection)는 적용하지 않는다. 이 좌표계는 지도를 작성하기 위한 좌표계가 아니라, 지구상의 어디에서나 동일한 오차 범위로 위치를 특정하기 위한 좌표계이다.

도 17은 종래 발명에서 사용되는 북향거리와 동향거리의 개념을 설명하기 위한 도면이다. 도 17에서 중심이 지구의 질량 중심에 위치하는 구를 가정하며, 이 구면 모델 지구(spherical model Earth)의 반경은 R이다. R 값은 적도에서의 지구의 반경인 6,378,137m를 사용할 수 있다.

세계 좌표계(World coordinate system), 즉 지구 중심 지구 고정 3차원 직각 좌표계(Earth-Centered Earth-Fixed three-dimensional Cartesian coordinate system)의 원점 C는 지구의 질량 중심에 위치하며, Z-축은 지구의 자전축과 일치하고, X-축은 원점에서 적도와 본초자오선의 교점을 지나는 직선이며, Y-축의 방향은 오른손 좌표계(RHS: Right-Handed coordinate System)의 원리에 의하여 자동적으로 결정된다.

이때 측지 위도 φ와 경도 λ와 타원체고 h를 가지는 한 점의 북향거리 N과 동향거리 E는 다음과 같이 측정한다. 도 7에서와 유사하게 측지 위도 φ와 경도 λ와 타원체고 h를 가지는 한 점을 지심 위도 φ와 경도 λ와 지심 고도 h를 가지는 점 P로 대체한다. 그리고 세계 좌표계의 원점 C에서 점 P에 이르는 선분이 구와 만나는 점을 구점(sphere point) S(φ, λ)이라고 지칭하고, 적도 L_o와 본초자오선이 만나는 점을 경위선의 원점(latitude-longitude origin) O라고 지칭한다. 그리고 지심 위도 φ를 가지는 위선(緯線, parallels, parallels of latitude, lines of latitude)과 본초자오선이 만나는 점 w를 경로점(經路點, waypoint)이라고 지칭한다. 그러면 북향거리는 경위선의 원점 O에서 경로점까지 본초자오선을 따라서 측정한 호(弧, arc)의 길이로 정의하고, 동향거리는 경로점에서 지심 위도 φ와 경도 λ를 가지는 구점 S(φ, λ)까지 위선을 따라서 측정한 호의 길이로 정의한다.

그런데 이 개념을 일반화하여 북향거리와 동향거리의 측정의 시작이 되는 점을 경위선의 원점 O에서 측지 위도 φ_o와 경도 λ_o를 가지는 지표면 상의 다른 기준점(reference point)으로 이동시킬 수 있다. 그러면 기준점은 측지 위도 φ_o를 가지는 위선과 경도 λ_o를 가지는 자오선의 교점(交點, point of intersection)이 되며, 북향거리는 기준점에서 경로점까지 자오선을 따라서 측정한 호의 길이이고, 동향거리는 경로점에서 측지 위도 φ와 경도 λ를 가지는 구점 S(φ, λ)까지 위선을 따라서 측정한 호의 길이이다.

이와 같은 정의에 의하면 북향거리는 측지 위도 φ와 경도 λ의 함수로 수학식 8과 같이 주어지고, 동향거리는 수학식 9와 같이 주어진다.

여기서 R은 지구의 평균 반경이고, N_o는 북향거리의 기본 값이며, E_o는 동향거리의 기본 값이고, φ_o는 기준점의 측지 위도이며, λ_o는 기준점의 경도이다.

이와 같은 공식을 이용하여 지구상의 임의의 점을 기준점으로 삼을 수 있다. 예를 들어 광화문 광장의 세종대왕 동상의 위치를 좌표계의 기준점으로 삼을 수 있다. 또는 대한민국의 영토 안에서만 사용할 용도로 세종 기준점을 사용할 수도 있고, 대한민국의 영토 안에서는 북향거리와 동향거리가 항상 양의 값을 가지도록 북향거리와 동향거리의 기본값을 부여할 수도 있다.

한편, 전 세계를 대상으로 통일된 하나의 좌표계를 사용하고자 할 경우, 북향거리와 동향거리의 측정이 되는 기준점을 위도상으로는 남극(φ_o = -90°)으로 하고, 경도상으로는 반대자오선(λ_o = -180°)으로 하며, 북향거리와 동향거리의 기본값은 0으로 할 수 있다(N_o = 0, E_o = 0). 이와 같은 기준점을 선택하는 이유는 전 지구상에서 북향거리와 동향거리가 양의 값을 갖게 하고, 또 런던(London)과 같은 인구 밀집 지역에서 북향거리나 동향거리의 값이 불연속적이 되는 사태를 방지할 수 있기 때문이다.

이와 같은 선택에 의하여 북향거리는 수학식 14와 같이 주어지고, 동향거리는 수학식 15와 같이 주어진다.

또한, 역으로 북향거리와 동향거리에서 측지 위도와 경도를 얻는 공식은 수학식 16 내지 17과 같이 주어진다.

이러한 좌표계에서 지구상의 대표적인 장소들의 북향거리와 동향거리를 계산해보면 표 1과 같다.

번호	장소	측지 위도	경도	북향거리	동향거리
1	경위도원점	0°	0°	10,018,754.171m	20,037,508.343m
2	대척점	0°	180°	10,018,754.171m	40,075,016.686m
3	북극	90°	0°	20,037,508.343m	0.000m
4	남극	-90°	0°	0.000m	0.000m
5	세종기준점	36.5222134°	127.3031899°	14,084,388.370m	27,491,115.402m
6	시드니 오페라 하우스	-33.8567844°	151.2152967°	6,249,834.172m	30,618,651.175m

표 1에서 볼 수 있는 바와 같이 지구상의 모든 지점에서 북향거리와 동향거리가 유한한 양의 값을 가진다. 한편, 대한민국 영토 안에서 대표적인 지점들의 북향거리와 동향거리를 계산해보면 표 2와 같다.

번호	장소	측지 위도	경도	북향거리	동향거리
1	세종기준점	36.5222134°	127.3031899°	14,084,388.370m	27,491,115.402m
2	대전 중앙로 사거리	36.3286936°	127.4259233°	14,062,845.844m	27,570,728.707m
3	백두산 천지연	42.0072268°	128.0564190°	14,694,977.268m	25,481,535.991m
4	대한민국 최남단비 (마라도)	33.1138727°	126.2684738°	13,704,973.619m	28,556,380.328m
5	독도 영토 표석	37.2399286°	131.8684690°	14,164,284.060m	27,638,526.094m
6	서격렬비도	36.6115719°	125.5439153°	14,094,335.712m	27,302,128.877m

표 2에서 볼 수 있는 바와 같이 대한민국의 영토 안에서 임의의 위치를 1m²의 오차 범위로 특정하고자 한다면, 북향거리와 동향거리를 각각 7자리로 표시하면 된다. 예를 들어 이 좌표계를 국내에서만 사용할 목적이라면, 독도 영토 표석의 좌표는 북향거리 4,164,284m, 동향거리 7,638,526m와 같이 특정할 수 있다. 국가지점좌표계에서 한글 두 자와 4자리 숫자 2개로 수평 방향의 위치를 10m×10m의 오차 범위로 특정하는데 비하여, [특 15]의 좌표계에서는 7자리 숫자 2개로 수평 방향의 위치를 1m×1m의 오차 범위로 특정한다는 점을 고려하면, 좌표를 표시하거나 전송하는데 드는 비용(cost)은 동등하다고 간주할 수 있다.

what3words 앱과 마찬가지로 국가지점 좌표계의 유용성은 전화로 위치를 구술할 때 발휘된다. 그런데 전화가 되는 지역은 문자 메시지(text message)도 된다. 따라서 전화로 구술하지 않고 문자 메시지로 신고를 하는 경우라면 7자리 숫자 두 개를 보내는 것도 무방하고, 경위도와 다르게 거리의 단위를 갖고 있어 상대적인 거리를 추측하기도 용이하다.

더구나 국가지점 좌표계는 컴퓨터나 앱을 이용하지 않고는 지리좌표계에서 국가지점 좌표계를 계산하거나, 역으로 지리적인 좌표, 즉 위도와 경도를 산출할 수 없는데 반하여, [특 15]의 좌표계에서는 간단한 계산기를 이용하여서도 계산할 수 있고, 심지어 종이와 연필만 가지고서도 대략적으로 추측할 수 있다는 장점이 있다.

한편, 대부분의 현대인은 도시에서 살아간다. 도시에는 아파트나 상업용 빌딩 등 수많은 건물이 있으며, 실내 공간에서 살아가거나 근무하는 현대인에게는 위도와 경도로 특정될 수 있는 지리상의 위치와 더불어 건물 내에 있을 때 그 실내 위치를 포함하여 통합적으로 위치를 특정하는 방법이 필요하다.

아파트나 지하상가, 빌딩, 주차 타워와 같은 다층 건물에 있을 때는 해발 고도보다는 층(層, floor) 정보가 더 중요하다. 예를 들어 높은 비즈니스 빌딩에서 누구와 만나기로 했다면, 몇 층에 있는지의 정보가 더 중요하다. 또, 누구나 한번쯤은 지하 주차장에 차를 주차했다가 지하 몇 층에 주차했는지를 잃어버려서 낭패를 당한 경험이 있을 것이다. 이와 같은 다양한 이유에서 해발 고도보다도 층 정보가 더 유용하다.

도 18은 [특 15]의 종래 발명에서 사용하는 층 모델을 이해하기 위한 개념도이다. 단순한 수학적 모델과 일관된 개념으로 지구 전체를 묘사하기 위해서는 지면층(地面層, ground floor)을 0층이라고 부르는 것이 바람직하다. 또한, 지표면이나 호수의 수면, 바다 한가운데에서의 해수면도 모두 0층으로 간주한다. 여기서 0층은 사람이 자연 상태에서 발을 딛고 돌아다닐 수 있는 지표면 및 이 지표면과 연속적으로 이어지는 건물의 층을 말한다. 따라서 갑돌이가 강변도로를 따라서 조깅을 하거나, 호수에서 수영을 하거나, 마음에 드는 가게를 발견하여 인도에서 가게 안으로 들어갔더라도 모두 0층에 있는 것이 된다. 또, 백두산이나 에베레스트산에 등정하여 산 정상에서 만세를 부르고 있을 때에도 역시 0층에 있는 것이다. 즉, [특 15]의 발명에서 0층은 타원체고나 해발 고도와는 아무런 상관이 없다. 한편, 우리가 2층이라고 부르는 층은 +1층이고, 3층은 +2층이다. 또한, 지하 1층은 -1층이고, 지하 2층은 -2층이다.

[특 15]에서는 지심 고도나 타원체고나 해발 고도를 모두 무시하고, 대신에 층을 나타내는 정수 F를 사용한다. 또한, 수평적인 공간에서의 위치는 북향거리 N과 동향거리 E를 사용한다. 그리고 층을 나타내는 정수 F는 선택적으로 사용한다. 즉, 한 지점의 위치를 (N, E, F)라고 특정했다면, 이는 북향거리 N, 동향거리 E인 건물의 F층을 의미한다. 실제로는 어떤 건물의 F층에서 측지 위도와 경도가 북향거리 N과 동향거리 E에 해당하는 특정 지점을 나타낸다. 한편, (N, E)라고만 적는다면 이는 (N, E, 0)를 의미한다. 즉, 층의 개념이 필요없는 야외의 한 장소를 의미할 수도 있고, 다층 건물의 1층을 의미할 수도 있다. 이와 같이 층이라는 개념을 건물 내에서 실외로까지 논리적으로 확장하여 통합적으로 실내·외의 위치를 특정할 수 있다.

이 모델은 다층 건물이 대부분인 대도시에서 배달 음식을 시키거나 우편물을 배달하거나 다른 사람과 만날 약속을 하거나, 또는 인터넷에서 찾은 맛집을 찾아가는 등 다양한 목적에서 사용할 수 있다.

[특 17]에는 이와 같은 위치 식별자(location identifier)를 기반으로 하는 지도 기반의 온라인 플랫폼이 제시되어 있다. 도 19는 웹앱(web app)의 형식으로 실내 지도를 서비스하는 종래 발명의 디지털 지도 시스템(digital map system)의 구성을 보여주는 개념도이다. 스마트폰(smart phone)이나 데스크톱 컴퓨터(desktop computer) 사용자, 혹은 배달 로봇(delivery robot) 등이 인터넷(internet)을 통하여 웹 서버(web server)에 접속하면, 구글 크롬(Google Chrome)이나 마이크로소프트 에지(Microsoft Edge)와 같은 웹 브라우저(web browser)를 사용하여 디지털 지도(digital map)를 이용할 수 있다. 디지털 지도가 웹앱(web app)으로 작동하므로 웹 서버(web server)와 앱 서버(app server)는 사실상 동일하다. 따라서 웹 서버라는 용어와 앱 서버라는 용어를 모두 사용할 수 있다.

디지털 지도 서비스를 원하는 사용자는 컴퓨터나 스마트폰을 이용하여 직접 웹 서버(web server)에 접속하게 되며, 웹 서버는 실외 지도 서버(outdoor map server)와 건물 데이터베이스(building database)와 건물 데이터 저장소(building data store, building data warehouse)에 연결되어 있다. 이들이 통합하여 디지털 지도 시스템(digital map system)의 하드웨어(hardware)를 구성한다고 할 수 있다.

실외 지도 서버(outdoor map server)는 웹 서버에 맵 타일(map tile)을 제공하여 실외 지도를 그리도록 하는 서버이다. 예를 들어 타일 서비스를 제공하는 오픈 스트리트 맵(www.openstreetmap.org)의 서비스 서버를 실외 지도 서버라고 간주할 수 있다.

건물 데이터베이스는 건물의 이름, 주소, 홈페이지, 지리적인 위치, 건물의 외곽선 도면 파일이나 평면도 파일이 저장된 위치 등 건물과 관련된 정보를 조회할 수 있는 데이터베이스이다.

건물 데이터 저장소(building data store)는 건물의 외곽선 도면(building outline drawing)과 층별 평면도(floorplan per level)를 포함하는 실내 지도 파일(indoor map file)이 벡터 데이터(vector data)로 저장되어 있는 곳이다. 건물 데이터 저장소는 인터넷에 연결된 NAS(Network Attached Storage)라고 생각할 수 있으며, 사용자와 콘텐츠가 늘어남에 따라 한 개 이상의 장치 혹은 서버가 될 수 있다. 웹 서버는 건물 데이터 저장소에서 실내 지도 파일을 가져와서 실외 지도상의 올바른 위치에 중첩하여 그린다.

기존의 방식에서는 PC에서는 웹앱으로, 스마트폰에서는 네이티브 앱(native application)으로 각각 지도 앱을 이용할 수 있었다. 이를 위해서 PC용으로는 HTML5/CSS3/JavaScript를 이용하여 디지털 지도의 웹 사이트(web site)를 만들고, 안드로이드 폰에서는 Kotlin으로 네이티브 앱을 만들며, 아이폰(iPhone)에서는 Swift를 이용하여 네이티브 앱을 만든다. Kotlin은 자바(Java)와 유사하며, Swift는 C++과 유사하다. 결국, Java Script, Kotlin, Swift라는 독립된 3개의 언어로 앱을 작성하여야 하며, 이 앱을 유지·보수하는 데에도 3배의 노력이 필요하다.

웹앱의 최대의 장점은 하나의 소스(source)로 PC와 스마트폰에 모두 대응할 수 있으며, 따로따로 앱을 작성·유지·보수할 필요가 없다는 점이다. 이와 같은 일이 가능한 이유는 웹 브라우저(web browser)가 이용할 수 있는 자바스크립트(JavaScript)라는 훌륭한 소프트웨어가 존재하기 때문이다. 즉, PC와 스마트폰에 걸쳐서 존재하는 공통의 플랫폼(platform)이 존재한다. 과거에는 플로피 디스크(floppy disk)나 USB(Universal Serial Bus)에 담긴 프로그램을 PC에 설치해서 사용하던 소프트웨어를 지금은 웹에 접속해서 사용하고, 이용료를 지불하는 방식으로 사용할 수 있게 된 것이 이러한 이유 때문이다. 또한, 웹 기술의 눈부신 발달로 인하여 마이크로소프트 워드(Microsoft Word)나 오토캐드(AutoCAD)와 같은 전문적인 프로그램도 웹앱으로 만들 수 있다.

반면 웹앱의 가장 큰 단점은 매번 해당 웹사이트에 접속하여야 한다는 점이다. 예를 들어 웹앱으로 작성된 마이크로소프트 워드(MicroSoft Word)를 이용하려고 하면, 일단 PC나 스마트폰이 인터넷에 연결되어 있어야 하고, 워드 작업을 하기 위해서 매번 웹사이트를 방문하여야 한다. 웹사이트에 방문하면 클라이언트(client), 즉 웹 브라우저가 호스트(host), 즉 해당 웹서버에 접속하여 필요한 파일들을 가져와서 웹페이지를 만들어서 보여준다.

웹앱으로 만들어진 마이크로소프트 워드를 이용하여 책을 쓰려는 작가가 있다고 하자. 그 작가는 아마도 매일 마이크로소프트 워드의 많은 기능 중 소수의 익숙한 기능만을 이용할 것이다. 그런데 웹앱으로 된 마이크로소프트 워드를 이용하면 어제 가져온 소스 코드를 오늘도 가져오고 내일도 가져와야 한다. 더구나 오늘 가져온 소스는 어제 가져온 소스와 완전히 동일할 수 있다. 그런데도 매번 소스를 가져와야 한다면 엄청나게 비효율적인 시스템이라고 할 수 있다.

만약 그 작가가 공원의 피크닉 테이블(picnic table)에 앉아서 아름다운 경치를 바라보며 원고를 작성하는 사치를 누리고 있다면, 매번 똑같은 소스를 무선 인터넷으로 가져오는 데이터 비용을 지불해야 하고, 앱의 속도도 느려질 것을 예상할 수 있다. 이러한 점이 웹앱의 가장 큰 단점으로 지적되어 왔다.

이와 같은 단점은 프로그레시브 웹앱(PWA, Progressive Web App)이라는 혁신적인 기술이 개발되면서 해결되었다. PWA는 설치가 가능한 웹앱이라고 할 수 있다. 웹앱이 PWA가 되기 위해서는 몇 개의 조건을 만족하여야 한다. 우선 http가 아니라 https 프로토콜(protocol)을 사용하여야 하고, 서비스 워커(service work)라는 자바스크립트 파일을 가져야 한다. 또 매니페스트 파일(manifest file)과 컴퓨터나 스마트폰의 바탕 화면에 보여줄 아이콘(icon) 파일도 있어야 한다.

스마트폰에서 크롬(Chrome)으로 프로그레시브 웹앱의 주소에 접속하면 PWA가 실행되면서 '설치' 버튼이 나타난다. 이 버튼을 클릭(click)하면 PWA가 스마트폰에 설치되고, 바탕 화면에 아이콘(icon)도 나타난다. PWA가 설치되면서 필요한 파일들도 스마트폰에 반영구적으로 저장된다. 따라서 다음번에 접속할 때는 동일한 파일을 다시 가져오지 않아도 된다. 만약 새로운 페이지에 접속하거나, 소프트웨어가 업데이트된 부분이 있다면 그 부분만 새로 가져오게 된다. 따라서 PWA의 등장으로 인하여 웹앱의 가장 큰 단점이 제거되었다고 할 수 있다.

이미 살펴본 바와 같이 구글 지도에서는 여러 층으로 구성된 대형 건물에 대하여 실내 지도(indoor map)를 제공한다. 지도의 줌(zoom)이 사전에 설정된 값 이상이 되면 실내 지도 서비스를 제공하는 대형 건물의 기본층(default floor)의 평면도(floorplan)가 보이며, 그 건물의 다른 층을 선택할 수 있는 메뉴가 지도 화면의 한쪽에 보인다. 그 메뉴에서 다른 층을 선택하면 기본층의 평면도가 해당 층의 평면도로 교체되어 보여진다.

이와 같은 방식은 직관적으로 타당하게 보이지만, 실제로는 모두가 의자에 앉아서 컴퓨터 모니터를 통하여 지도를 보던 시절에 더 적합한 방식이다. 모두가 스마트폰이 있고, 또 무인 자동차와 무인 배달 로봇이 점점 현실화되어 가는 현재에는 가장 좋은 방식이라고 할 수 없다.

스마트폰에서 지도 앱(map app)을 실행하면 스마트폰의 위치가 GPS 신호로부터 계산되어 지도상에 표시된다. 즉, 스마트폰에서 디지털 지도를 실행하면 지도에 나의 현재 위치가 표시되도록 할 수 있고, 또 나의 위치가 항상 지도의 중심에 올 수 있게 지도가 자동으로 패닝(panning)이 되도록 프로그램을 할 수도 있다. 그러므로 스마트폰의 주인이 어떤 건물의 내부로 들어갔다면 굳이 마우스 클릭(click)이나 화면 터치(touch)를 하지 않더라도 층을 선택할 수 있는 메뉴를 보여줄 수 있을 것이다. 즉, 현재 위치가 층을 선택할 수 있는 다층 건물의 내부라면 굳이 클릭이나 터치를 하지 않더라도 층을 선택할 수 있는 메뉴를 보여주는 것이 편리할 것이다.

이 방법에서 스마트폰의 주인이 지면층(ground floor)에 계속 머무른다면 층 선택 메뉴를 무시하면 되고, 계단이나 엘리베이터를 이용하여 다른 층으로 이동하려는 참이라면 층 선택 메뉴를 통하여 해당 층의 평면도를 미리 확인하면 편리할 것이다. 또한, 데스크톱 컴퓨터나 노트북의 경우에도 지도 화면의 중심을 나의 위치라고 가정하고, 지도 화면을 패닝(panning)하여 지도의 중심이 실내 지도를 제공하는 건물의 내부에 위치한다면 자동으로 층 선택 메뉴를 보여줄 수 있다. 또한, 층을 식별할 수 있는 다양한 기술들과 결합하면, 층이 바뀌면 자동으로 평면도도 교체되어 보이도록 할 수도 있을 것이다.

도 20은 디지털 지도(digital map)의 메인 화면(main window)을 보여준다. 과거에는 큰 종이에 한 장으로 인쇄되거나 아니면 지역별로 분할되어 책으로 인쇄된 지도가 여행의 필수품이었다. 그런데 지금은 컴퓨터나 스마트폰이 대중화되면서 디지털 지도가 그 자리를 대신하게 되었다. 디지털 지도의 가장 큰 장점은 우리가 관심 있는 장소로 지도 화면(map screen)의 중심을 옮기고(translate, move), 필요한 배율로 확대하며(zoom), 또한 눈앞에 보이는 실제 풍경과 비교하기 위하여 지도의 방향을 바꿀 수 있다(rotate)는 점일 것이다. 이와 같이 종이로 된 지도에서는 없던 편리한 기능을 구현하기 위한 기본 개념이 뷰(view)이다.

뷰의 개념을 이해하기 위해서는 먼저 자바스크립트 객체(Javascript object)의 개념의 이해가 선행되어야 한다. MDN Web Docs는 자바스크립트 객체를 다음과 같이 설명하고 있다(출처: https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Object).

객체 클래스(Object class)는 자바스크립트의 데이터 유형 중 하나를 나타낸다. 이것은 다양한 키(key)를 가지는 값들의 모음 및 더 복잡한 엔티티들을 저장하는 데 사용된다. 객체는 Object() 생성자 또는 객체 초기자 / 리터럴 구문을 통해 생성할 수 있다.(The Object class represents one of JavaScript's data types. It is used to store various keyed collections and more complex entities. Objects can be created using the Object() constructor or the object initializer / literal syntax.)

예를 들어 좌표(coordinates)라는 사용자 정의 객체를 다음과 같이 정의할 수 있다.

var coordinates = { lat: 36.0, lon: 127.0 };

여기서 lat과 lon은 키(key)이며, 36.0과 127.0은 그 값(value)들이다. 예를 들어 lat의 값은 coordinates.lat으로 구할 수 있다.

대한민국전도 또는 세계지도를 전체 지도라고 한다면, 그 중에서 컴퓨터나 스마트폰에서 보이는 지도의 일부, 또는 그 지도를 보여주는 객체(客體, object)를 뷰라고 생각할 수 있다. 지도 관련하여 대표적인 클라이언트 측 오픈 소스 소프트웨어(client-side open source software)인 오픈레이어(OpenLayers)는 뷰(view)를 다음과 같이 정의하고 있다(출처: https://openlayers.org/en/latest/apidoc/module-ol_View-View.html).

뷰 객체는 지도의 간단한 이차원적인 모습을 나타낸다. 이 객체에 지도의 중심, 해상도, 회전 작업을 적용할 수 있다. 뷰는 투사 방식을 가지고 있다. 이 투사방식은 좌표의 중심을 결정하고, 이 뷰의 단위가 해상도의 단위를 결정한다. 기본적인 투사방식은 구면 메르카토르(EPSG:3857)이다(A View object represents a simple 2D view of the map. This is the object to act upon to change the center, resolution, and rotation of the map. A View has a projection. The projection determines the coordinate system of the center, and its units determine the units of the resolution (projection units per pixel). The default projection is Spherical Mercator (EPSG:3857).).

구글맵(Google map), BingMap, OpenStreetMap, 네이버 지도, 카카오 지도와 같은 다른 지도들도 모두 유사한 개념을 사용한다. 따라서 뷰를 비공식적이지만 사실상 모든 디지털 지도들이 사용하는 공통 개념이라고 생각할 수 있다.

디지털 지도의 가장 핵심적인 요소는 뷰(view)이며, 사용자와의 상호 작용을 용이하게 하기 위하여 사이드 패널(side panel)이 있는 것이 바람직하다. 도 20에서 뷰는 직사각형의 형상을 하고 있으며, 뷰에 보이는 실외 지도의 범위를 뷰 범위(view extent)라고 부른다. 뷰 범위는 뷰에 보이는 실외 지도의 경도의 최솟값과 최댓값, 위도의 최솟값과 최댓값으로 나타내거나, 아니면 대등하게 웹 메르카토르 도법에서의 동향거리의 최솟값과 최댓값, 북향거리의 최솟값과 최댓값 등으로 나타낼 수 있다.

본 발명에서는 뷰(view)를 편의상 지도 화면(map screen) 또는 간단히 화면(screen)이라고 지칭하기로 한다. 그리고 전체 지도 중 뷰 범위에 보이는 일부 지도를 지도 영역(map area)이라고 부르기로 한다. 그리고 지도 앱(map app)을 시작했을 때 맨 처음에 보이는 지도 화면을 초기 화면(initial screen)이라고 부르기로 한다.

지도 플랫폼(map platform)에서 지도(map)는 뷰(view)와 레이어(layers)와 타겟(target)을 가지는 자바스크립트 객체(JavaScript object)이다. 오픈레이어(openlayers)는 지도 객체(map object)를 다음과 같이 설명하고 있다(출처: https://openlayers.org/en/latest/apidoc/module-ol_Map-Map.html).

지도는 오픈레이어의 핵심 요소이다. 지도가 그려지기 위해서는 뷰와 하나 이상의 레이어와 타겟 컨테이너가 필요하다(The map is the core component of OpenLayers. For a map to render, a view, one or more layers, and a target container are needed). 여기서 타겟 컨테이너란 HTML 문서(HTML document)에서 지도가 부착되어지는 문서 요소(DOM element)를 지칭한다.

가장 간단한 지도 객체는 다음과 같이 주어질 수 있다.

var osmLayer = new ol.layer.Tile({

source: new ol.source.OSM()

});

var view = new ol.View({

center: [0, 0],

zoom: 1

});

var map = new ol.Map({

view: view,

layers: [osmLayer],

target: 'map'

});

여기서 뷰의 중심(view center)을 동향거리와 북향거리의 원점([0, 0])으로 하고, 줌은 1로 하였으며, HTML 문서에 map이라는 돔(DOM: Document Object Model) 요소(element)가 있어, 그 map 요소에 지도를 부착한다는 의미이다. 또, 지도에 보여질 맵 타일(map tile)은 오픈스트리트 맵(OSM, OpenStreetMap)을 사용한다.

인터넷으로 접속하는 디지털 지도는 지도의 줌 레벨(zoom level)에 따라서 뷰에 보여지는 내용이 달라진다. 일반적인 지도의 줌 레벨은 0에서 24 정도까지 변할 수 있다. 그리고 줌 레벨이 1씩 증가할 때 뷰에 보여지는 영역은 1/4로 줄어들고, 역으로 지도는 4배씩 확대되어 보여진다.

도 20에서 뷰의 중심에는 중심 마커(center marker)가 있다. 이 뷰 중심(view center)의 좌표가 (측지) 위도와 경도, 수학식 14로 주어지는 북향거리(N)와 수학식 15로 주어지는 동향거리(E) 등으로 사이드 패널(side panel) 또는 컨트롤 창(control pane)에 표시된다.

또, 도 20에서 뷰에 OK 벤처타운(OK Venture Town)이 보여지고 있다. 뷰의 중심이 이 건물 - 이하, 중앙의 건물(building at view center)이라고 지칭함 - 의 외곽선(outline) 안에 위치할 때, 좌측의 사이드 패널에는 이 건물의 이름(building name)이 표시되고 있으며, 이 건물이 3층 건물이므로 층을 선택할 수 있는 층 선택 메뉴(floor selector)가 나타난다.

도 21은 OpenLayers 문법으로 작성된 자바스크립트 코드(JavaScript code)의 일부로서, 지도 객체(map object)의 구성을 보여준다. 지도 객체의 레이어는 baseLayer, buildingLayer, buildingLabelLayer, floorplanLayer, spaceLabelLayer, unitAreaMarkLayer, locationMarkerLayer로 구성된다. 레이어는 먼저 선언하는 레이어가 먼저 그려지므로 baseLayer가 가장 밑에 있고, locationMarkerLayer가 가장 위에 있다. baseLayer는 OpenStreetMap에서 그림 파일들로 지도의 타일(tile)들을 받아서 실외 지도를 그리는 레이어이다. baseLayer는 래스터 레이어(raster layer)이고, 나머지는 모두 벡터 레이어(vector layer)이다.

locationMarkerLayer는 지도상에서 사용자의 위치나 나침반 등을 표시하기 위한 레이어이고, unitAreaMarkLayer는 단위 면적을 표시하기 위한 레이어이다.

baseLayer와 locationMarkerLayer와 unitAreaMarkLayer를 제외한 나머지 레이어들이 구조 레이어 그룹(structure layer group)을 형성한다. 이 중에서 buildingLayer는 건물의 외곽선(building outline)을 그리기 위한 레이어이고, floorplanLayer는 건물의 층별 평면도(floorplan per level) 중 어느 한 층의 평면도를 그리기 위한 레이어이다. buildingLabelLayer는 건물의 이름이나 홈페이지 주소 등 건물과 관련된 핵심 정보를 나타내기 위한 레이어이고, spaceLabelLayer는 층별 평면도에 보이는 개별 공간들(spaces)의 상호 등을 보여주기 위한 레이어이다. 예를 들어 각각의 방(room)이 하나의 공간이 될 수 있다.

도 21은 하나의 예시에 불과하지만, 가장 먼저 실외 지도를 표시하는 지도 레이어 그룹(map layer group)이 있고, 그 위에 벡터 레이어(vector layer)로 건물의 외곽선이나 평면도를 보여주기 위한 구조 레이어 그룹이 있다는 점이 중요하다. 도 21에서 지도 레이어 그룹은 단 하나의 레이어(즉, baseLayer)만 있는 레이어 그룹이지만, 일반적인 지도와 위성 지도를 함께 사용하는 예에서는 지도 레이어 그룹도 복수의 레이어를 갖게 된다. 또, 구조 레이어 그룹은 여러 개의 레이어로 구성될 수 있다. 이와 같이 여러 개의 레이어로 구성하는 이유는 구조적으로 프로그래밍을 하기 위해서이다.

이와 같이 종래 발명의 실시예는 디지털 지도(digital map)의 화면(view, map screen)에 실외 지도(outdoor map)와 건물(building)의 평면도(floorplan)를 포함하는 실내 지도(indoor map)를 통합적으로 표시하는 방법을 제공한다. 도 22는 종래 발명의 실시예에서 디지털 지도가 표시되는 전체 과정을 예시하는 순서도(flowchart)이다. 여기에는 실외 지도 서버(outdoor map server)를 유지하는 단계, 건물들의 외곽선 도면(building outline drawings)과 평면도(floorplans)를 건물별로 각각 개별 폴더(individual folder)들에 관리하는 건물 데이터 저장소(building data store)를 유지하는 단계, 건물들의 지도 설정 데이터(map setting data)를 관리하는 건물 데이터베이스(building database)를 유지하는 단계를 포함한다.

상기 건물 데이터베이스에 저장된 지도 설정 데이터는 각 건물의 고유식별번호(unique building identification number, primary ID, bldID)와 상기 개별 폴더에 이르는 전체 경로(full path)와 최저층(lowest floor)의 층수(minFloor)와 최고층(highest floor)의 층수(maxFloor)와 건물의 외곽선 표시 줌 레벨(zoomShowBld, zoom level for showing building outline)과 평면도 표시 줌 레벨(zoomShowFloor, zoom level for showing floorplan)과 북향거리 대응 정수(northing corresponding integer) I와 동향거리 대응 정수(easting corresponding integer) J를 포함한다.

사용자가 디지털 지도를 시작하면 초기 설정 값(initial map settings)으로 뷰에 실외 지도를 보여주는 단계와, 사용자의 줌(zoom), 팬(pan), 회전(rotate) 선택에 맞게 뷰를 갱신하는 단계를 포함한다. 뷰를 갱신하면 실외 지도가 갱신될 뿐만 아니라 그 안에 포함된 건물의 외곽선이나 평면도도 마찬가지로 줌, 팬, 회전된 상태로 보여진다.

디지털 지도의 사전 설정 데이터(preset data)에는 건물의 평면도를 표시하는 절대적인 줌 설정 값(preset zoom threshold value)이 있다. 예를 들어 대한민국전도를 보고 있을 때 대한민국 내 건물들의 평면도를 모두 표시한다는 것은 가능하지도 필요하지도 않기 때문이다. 따라서 줌이 설정 값 이상으로 일부 건물에 대하여는 평면도를 보여줄 필요성이 있는 줌 레벨(zoom level)을 예를 들어 15로 설정할 수 있다. 이와 같이 디지털 지도의 줌이 사전에 설정한 값 이상이면 건물 데이터베이스를 검색하여 지리적 위치가 뷰 범위(view extent)에 포함되는 건물들의 목록(list)을 작성하는 단계를 포함한다.

도 23은 뷰에 처음으로 평면도를 표시하는 평면도 표시 서브루틴을 예시하는 순서도이다. 뷰 범위 건물 목록 Bld_ID에 있는 건물의 숫자가 0보다 크면 for 루프(for loop)와 같은 순환 루프가 시작되며, for 루프는 목록에 있는 첫 번째 건물부터 시작한다(i = 0). 이 첫 번째 건물은 Bld_ID[0]이며, 마지막 건물은 Bld_ID[Bld_ID.length - 1]로 주어진다.

여기서 뷰 범위 건물 목록(Bld_ID)은 건물의 중심 좌표, 또는 건물의 전부나 일부가 뷰 안에 위치하고, 건물 데이터베이스에도 등록된 건물들의 목록이다. 그런데 어떤 건물은 너무 작아서 이 줌 레벨에서 표시하는 것이 부적절할 수 있다. 따라서 이 목록에 있는 건물들에 대하여 개별적으로 디지털 지도의 줌 레벨(zoom level)이 외곽선을 표시하는 줌 레벨(zoomShowBld)보다 큰 경우에만 건물 외곽선을 표시하게 된다. 또한, 뷰 범위 건물 목록에서 외곽선이 표시되어야 할 건물들의 목록 - 외곽선 표시 대상 건물 목록(bldIDsToShow)이라 지칭함 - 을 추출하여 관리한다. 이 건물, 즉 i번째 건물(ith building)이 외곽선 표시 대상 건물 목록에 있는 건물이면 이 건물의 외곽선 도면(building outline drawing)을 데이터 저장소(data store)에서 가져와서 건물 레이어(buildingLayer)에 추가한다.

실외 지도는 뷰에 보여주고자 하는 지리적 위치와 줌 레벨이 정해지면 지도에 보여질 타일들이 자동적으로 정해진다. 맵 타일(map tile)은 png 파일의 형태로 제작된 정사각형의 래스터 파일(raster file)을 사용하는 경우가 대부분이다. 그런데 실내 지도는 실외 지도 위에 중첩되어 보여져야 하고, 사용자가 다른 층을 선택하면 다른 실내 지도, 즉 다른 층의 평면도가 보여져야 하므로 실외 지도와 같은 타일 방식으로는 서비스를 하기 어렵다. 따라서 실내 지도는 실외 지도와 별개의 데이터로 관리되어야 하며, 데이터 저장소(data store)에 저장되었다가 필요시 불러와서 실외 지도 위에 중첩하여 표시할 수 있어야 한다.

이와 같이 데이터 저장소에 저장되었다가 웹 서버에 제공되기 위해서는 텍스트(text) 기반의 벡터 파일(vector file)로 실내 지도를 작성하는 것이 바람직하며, 이에 가장 적합한 파일 형식이 지오제이슨(GeoJSON)이다. 공식적인 홈페이지(https://geojson.org)에 의하면 GeoJSON은 다양한 지리적인 데이터 구조를 표현하기 위한 형식이다(GeoJSON is a format for encoding a variety of geographic data structures)^비특9.

위키피디아 한국어 사이트(https://ko.wikipedia.org/wiki/GeoJSON)에는 "GeoJSON(지오제이슨)은 위치정보를 갖는 점을 기반으로 체계적으로 지형을 표현하기 위해 설계된 개방형 공개 표준 형식이다. 이것은 JSON인 자바스그립트 오브젝트 노테이션(Object Notation)을 사용하는 파일 포맷이다."라고 해설되어 있다^비특10. 따라서 외곽선 도면과 평면도는 GeoJSON 형식으로 작성하는 것이 바람직하다.

건물의 외곽선(outline)은 폐곡선(closed curve)이나 다각형(polygon)으로 주어져야 한다. 그런데 GeoJSON 형식에서는 곡선을 허용하지 않으므로 실제로는 다각형으로만 주어져야 한다. 외곽선이 다각형으로 주어지면 뷰의 중심(view center)이 다각형의 안에 있는지 바깥에 있는지 판단할 수 있다.

다각형의 꼭지점을 구성하는 어느 한 점의 좌표는 [동향거리, 북향거리], 또는 [경도, 위도]의 형식으로 주어진다. 자바스크립트에서 대괄호(square brackets) []는 배열을 의미한다. 따라서 이 외곽선 도면을 빌딩 레이어(buildingLayer)에 추가하면 자동적으로 올바른 위치에 추가된다.

다음으로, 건물 외곽선 표시 대상 건물 목록에 있는 건물들에 대하여 디지털 지도의 줌 레벨이 건물의 이름 등을 포함하는 라벨(label)을 표시하는 줌 레벨(zoomShowLabel)보다 큰 경우에는 건물의 라벨을 건물 라벨 레이어(bldLabelLayer)에 추가한다.

그 다음으로 다시 외곽선 표시 대상 건물 목록에 있는 건물들에 대하여 디지털 지도의 줌 레벨이 건물들의 평면도 표시 줌 레벨(zoomShowFloor, zoom level for showing floorplan)보다 큰지 조사하고, 디지털 지도의 줌 레벨이 평면도 표시 줌 레벨보다 큰 건물들에 대하여는 다시 지면층(地面層, ground floor)이 있는 건물인지 확인한다. 이는 그 건물의 최저층(minFloor)이 0보다 작거나 같고, 최고층(maxFloor)이 0보다 크거나 같은지를 조사하여 알 수 있다.

다음으로, 이 두 가지 테스트를 모두 통과한 건물들의 목록 - 이하, 평면도 표시 대상 건물 목록이라 지칭함 - 을 작성하고, 이 목록에 있는 건물들에 대해서는 지면층의 평면도들을 데이터 저장소에서 가져와서 해당 건물들의 외곽선들에 부합되게 중첩하여 표시한다. 이 평면도들에 있는 점들의 위치도 모두 [동향거리, 북향거리], 또는 [경도, 위도]의 형식으로 주어지므로, 평면도 레이어(floorplanLayer)에 지면층의 평면도를 추가하면, 건물의 외곽선과 지면층의 평면도가 모두 실외 지도 상의 올바른 위치에 표시된다.

지금까지 설명한 내용은 디지털 지도를 시작하여 건물의 평면도가 처음으로 보이기까지의 순서도라고 할 수 있다. 이후 줌, 팬, 회전 작용이 또 발생하여 새로운 평면도를 추가하거나, 기존의 평면도를 이동시키거나 또는 기존의 평면도 중 일부를 제거하는 것과 같은 지도 갱신(map update) 과정은 상기한 과정을 반복할 수도 있다. 즉, 이미 작성한 뷰 범위 건물 목록과 외곽선 표시 대상 건물 목록과 평면도 표시 대상 건물 목록을 모두 0으로 초기화하고 뷰에 있는 모든 외곽선 도면과 평면도를 제거한 이후에, 뷰를 갱신하는 단계(update view)부터 다시 시작할 수도 있다.

그런데 사용자 상호작용이 일어날 때마다 건물 외곽선 도면이나 평면도를 모두 제거하고 새로 그리는 작업은 대단히 비효율적이다. 따라서 지도 갱신 서브루틴은 지금까지의 과정과 비슷하지만, 평면도 표시 서브루틴이 주로 차이가 나며, 뷰 범위 건물 목록(Bld_ID)과 외곽선 표시 대상 건물 목록 (bldIDsToShow)과 평면도 표시 대상 건물 목록(floorplanIDsToShow) 이외에 추가로 외곽선 표시 건물 목록(bldIDsInView)과 평면도 표시 건물 목록(floorplanIDsInView)을 따로따로 유지하고 갱신하는 알고리즘을 사용하면 더 효과적이다. 즉, 뷰가 변화되면 뷰 범위 건물 목록과 외곽선 표시 대상 건물 목록을 새로 작성한 이후에, 외곽선 표시 건물 목록과 비교하여 기존의 건물의 외곽선 도면을 삭제하거나 갱신하는 단계 및 새로운 건물의 외곽선 도면을 추가하는 단계를 포함하며, 평면도와 관련해서도 마찬가지의 단계를 거치게 된다.

이와 같은 기능을 수행하는 디지털 지도 시스템(digital map system)은 실외 지도 서버(outdoor map server)와, 건물들의 외곽선 도면(building outline drawing)과 평면도를 건물별로 각각 개별 폴더(individual folder)에 관리하는 데이터 저장소(data store)와, 건물들의 지도 설정 데이터(map setting data)를 관리하는 건물 데이터베이스(building database)와, 뷰(view)에 실외 지도(outdoor map)와 건물(building)의 평면도(floorplan)를 포함하는 실내 지도(indoor map)를 통합적으로 표시하기 위하여 일련의 단계들(series of stages)을 실행하는, 매체에 저장된 컴퓨터 프로그램을 포함한다.

상기 일련의 단계들은 디지털 지도를 초기 설정 값(initial map settings)으로 시작하여 뷰에 실외 지도를 보여주는 단계와, 사용자의 줌(zoom), 팬(pan), 회전(rotate) 선택에 맞게 뷰를 갱신하는 단계와, 디지털 지도의 줌(zoom)이 사전에 설정한 값(preset threshold zoom value) 이상이면 건물 데이터베이스를 검색하여 지리적인 좌표(geographic coordinates)가 뷰 범위(view extent)에 포함되는 뷰 범위 건물 목록을 작성하는 단계와, 뷰 범위 건물 목록에 있는 건물들의 숫자가 0보다 크면 평면도 표시 서브루틴(floorplan display subroutine)과 층 선택 서브루틴(floor selection subroutine)을 실행하는 단계를 포함한다.

[특 15]에 개시된 종래 발명의 좌표계에서 출원인의 사무실이 소재한 OK벤처타운의 도심(centroid)의 지리적인 좌표(geographic coordinates)는 측지 위도 36.32981409°와 경도 127.42671111°로 주어지며, 이로부터 수학식 14와 15를 이용하여 북향거리 N과 동향거리 E를 구해보면 각각 N = 14062970.577m와 E = 27570402.871m로 주어진다. 북향거리 N을 반올림한 북향거리 대응 정수(northing corresponding integer) I와 동향거리 대응 정수(easting corresponding integer) J는 각각 14062971과 27570403으로 주어진다. 이로부터 OK벤처타운의 건물 외곽선 도면(Bld.geojson)과 평면도(G.geojson, F1.geojson, F2.geojson)를 저장하는 폴더의 이름을 계산하면 N14062971E27570403으로 주어진다. 따라서 3층 건물인 OK벤처타운의 건물 파일은 다음과 같은 구조로 저장된다.

속성	폴더 경로	폴더 이름	파일명
건물 외곽선 파일	https://map.digitalearth.land/datastore	N14062971E27570403	Bld.geojson
1층 평면도	"	"	G.geojson
2층 평면도	"	"	F1.geojson
3층 평면도	"	"	F2.geojson

우선 데이터 저장소(data store)는 https://map.digitalearth.land/datastore에 위치한다. 이 안에 각각의 건물은 각자의 폴더를 가지고 있으며, OK벤처타운은 N14062971E27570403이라는 폴더 안에 존재한다. 3층 건물인 OK벤처타운은 1층, 2층, 3층의 평면도와 건물 외곽선 도면을 더하여 총 4개의 파일이 저장되어 있다. 이와 같은 파일 구조에서 도 22 내지 도 23에 도시한 알고리즘을 사용하여 효과적으로 실외 지도 위에 실내 지도를 표시할 수 있다.

종래 발명의 웹앱을 데스크톱 컴퓨터와 스마트폰에서 같이 사용하려고 할 때, 가장 먼저 해결하여야 하는 문제는 스크린 해상도(resolution)의 큰 차이에 대처하는 것이다. 또한, 데스크톱 컴퓨터와는 달리 스마트폰 사용자는 스마트폰을 세로로 세워서 사용하기도 하고(인물 사진 모드, portrait mode), 가로로 눕혀서 사용하기도 한다(풍경 사진 모드, landscape mode). 따라서 스마트폰의 경우에는 스마트폰의 방향(orientation)에도 대응을 하여야 한다.

이런 문제는 CSS3의 미디어 쿼리(media query) 또는 이를 이용하는 자바스크립트 라이브러리를 이용하여 해결할 수 있다. 미디어 쿼리를 이용하면 웹이 실행되는 클라이언트(client)의 스크린(screen) 크기를 알 수 있다. 실제로는 윈도우(window), 스크린(screen), 뷰포트(viewport) 등 다양한 화면(screen)의 정의가 있고, 그 크기도 다 다르다. 스크린의 경우에도 바깥 크기(outerWidth, outerHeight)와 안쪽 크기(innerWidth, innerHeight)가 따로 존재한다. 그러나 본 발명의 사상을 이해하기 위해서는 미디어 쿼리를 사용하여 데스크톱이나 스마트폰 화면의 크기와 방향을 알 수 있다는 사실만 알면 충분하다.

한편, 전문적인 자바스크립트 라이브러리(JavaScript library)를 이용하면 구체적인 클라이언트의 정체를 알 수 있다. 즉, 클라이언트가 아이폰 5인지, 아니면 삼성 갤럭시 22인지도 알 수 있다. 도 24는 동일한 핵심 코드(core code)를 사용하여 데스크톱 컴퓨터, 스마트폰 인물 사진 모드/풍경 사진 모드에 대응하는 방법을 예시하고 있다.

사용자가 데스크톱 컴퓨터나 스마트폰의 웹 브라우저로 해당 사이트(https://map.digitalearth.land)에 접속하면, 상기 인터넷 주소의 서버(server)에 존재하는 인덱스 페이지(index.html)가 실행된다. 인덱스 페이지는 미디어 쿼리 또는 자바스크립트 라이브러리를 사용하여 웹에 접속한 클라이언트의 종류(데스크톱 컴퓨터, 태블릿 PC, 스마트폰) 및 방향(screen mode, orientation)을 알아낸 후, 그에 맞는 랜딩 페이지(landing page)로 이송(redirect)한다. 즉, 클라이언트가 데스크톱 컴퓨터이면 indexDesktopLandscape.html 페이지가 실행되도록 하고, 세워진 스마트폰이면(인물 사진 모드) indexMobilePortrait.html 페이지를 연결하며, 누워진 스마트폰이면(풍경 사진 모드) indexMobileLandscape.html 페이지를 연결한다. indexDesktopLandscape.html과 indexMobilePortrait.html과 indexMobileLandscape.html 페이지에서 동작하는 자바스크립트 프로그램은 동일하거나 유사하지만, 인터넷 페이지의 UI(user intrface)가 각각 다르게 시작된다.

[특 1] Mohan Ganesalingam, Christopher Sheldrick, Jack Waley-Cohen, "Method and apparatus for identifying and communicating locations", 미국 등록특허 제9,883,333호, 등록일 2018년 1월 30일. [특 2] Richard D. Haney, "Location sharing and tracking using mobile phones or other wireless devices", 미국 등록 특허 제7,353,034호, 등록일 2008년 4월 1일. [특 3] Sami Sikila, "Positioning system and method", 미국 공개 특허 제2003/0149527호, 공개일 2003년 8월 7일. [특 4] Seung June Oh and Minah Oh, "Location-based text messaging", 미국 등록 특허 제7,742,774호, 등록일 2010년 6월 22일. [특 5] Marcel Mwa Van Os, Scott Herz, Mike Matas, "Location sharing", 미국 등록 특허 제8,369,867호, 등록일 2013년 2월 5일. [특 6] Marcel Mwa Van Os, Scott Herz, Mike Matas, "Location sharing", 미국 등록 특허 제10,368,199호, 등록일 2019년 7월 30일. [특 7] Marcel Mwa Van Os, Scott Herz, Mike Matas, "Location sharing", 미국 등록 특허 제10,841,739호, 등록일 2020년 11월 17일. [특 8] 김한석, 김성수, "이동통신망을 이용한 비상호출 처리장치와 그 방법", 대한민국 등록 특허 제10-0379946호, 등록일 2003년 3월 31일. [특 9] Ralph M. Toms, "System and method of simulating with respect to spheroid reference models using local surface coordinates", 미국 등록 특허 제7,428,476호, 등록일 2008년 9월 23일. [특 10] Ziji Wang, Jiefeng Sun, Dong Liu and Jiqing Zhang, "Method and device for sharing position", 미국 공개 특허 제2020/0026418호, 공개일 2020년 1월 23일. [특 11] Seth Jacob Pensack-Rinehart, Gavin Reaney, Yatin Chawathe, Nicholas Lee, Sascha Benjamin Brawer and Paul Messmer, "Providing indoor map data to a client computing device", 미국 공개 특허 제2015/0019625호, 공개일 2015년 1월 15일. [특 12] Zhou Bailiang and Jonah Jones, "Floor selection on an interactive digital map", 미국 등록 특허 제8,464,181호, 등록일 2013년 6월 11일. [특 13] Zhou Bailiang and Jonah Jones, "Floor selection on an interactive digital map", 미국 등록 특허 제9,323,420호, 등록일 2016년 4월 26일. [특 14] 김동환, 권연희, 최정아, 김형찬, "실내지도 데이터베이스, 지도 서비스 제공장치 및 방법, 개방형 API를 이용한 실내지도 제공장치, 그리고 실내지도 제작장치 및 방법", 대한민국 등록 특허 제10-1312294호, 등록일 2013년 9월 23일. [특 15] 권경일, "지리상의 위치를 특정하는 방법과 이를 이용하는 데이터베이스 및 데이터베이스의 데이터베이스", 대한민국 등록 특허 제10-2234723호, 등록일 2021년 3월 26일. [특 16] 권경일, "실내를 포함하는 지구상의 위치를 특정하는 방법과 이를 이용하는 데이터베이스", 대한민국 등록 특허 제10-2308960호, 등록일 2021년 9월 29일. [특 17] 권경일, "디지털 지도 기반의 온라인 플랫폼", 대한민국 등록 특허 제10-2344087호, 둥록일 2021년 12월 23일.

[비특 1] Wikipedia, "World Geodetic System". [비특 2] 이성곤, "물리탐사 실무자를 위한 측지 좌표계와 지도 투영의 이해", 지구물리와 물리탐사(Geophysics and Geophysical Exploration), vol. 19, no. 4, 2016, pp. 236 ~ 248. [비특 3] National Geospatial-intelligence Agency (NGA), "Web Mercator map projection", NGA_SIG_0011_1.0.0_WEBMERC (2014). [비특 4] Wikipedia, "Mercator projection". [비특 5] Wikipedia, "Web Mercator projection". [비특 6] Wikipedia, "Universal Transverse Mercator coordinate system". [비특 7] 위키백과(https://ko.wikipedia.org/wiki/), "국가지점번호" [비특 8] Wikipedia, "Google maps". [비특 9] IETF(Internet Engineering Task Force), "The GeoJSON Specification: RFC 7946". [비특 10] 위키백과, GeoJSON.

지도 앱에 보이는 실내·외의 장소를 다른 사람과 용이하게 공유할 수 있는 방법을 제공하고자 한다.

웹앱(web app)으로 실행되는 지도 앱(map app)에 보이는 실내·외의 장소(place)를 문자 메시지(text message)로 보내서 수신인(receiver)과 공유(share)할 수 있다. 문자 메시지 몸체(text message body)는 선택된 장소에 해당하는 지리적인 좌표(geographic coordinates)와 건물 아이디(building ID)와 층(floor)을 포함하는 지도 매개변수(map parameters)를 검색 문자열(search string)로 포함하는 URL(Uniform Resource Locator)을 포함한다.

실내·외의 장소를 통합하여 문자 메시지로 보내서 송신인과 수신인이 동일한 지도 화면을 공유할 수 있으며, 다른 사람과 만나거나, 실종자를 구조하거나, 긴급 구조 요청을 하는 등 다양한 분야에서 유용하게 사용할 수 있다.

도 1은 측지 위도와 지심 위도의 차이를 이해하기 위한 개념도.
도 2는 네이버 지도에서 마라도 남단으로 이동한 결과.
도 3은 구글 지도에서 마라도 남단으로 이동한 결과.
도 4는 도 3의 구글 지도의 주소창에 보이는 문자열을 구글의 크롬 브라우저에서 검색한 결과.
도 5는 메르카토르 도법의 개념도.
도 6은 메르카토르 도법으로 작성한 지도의 예.
도 7은 구면 메르카토르 도법을 이해하기 위한 개념도.
도 8은 UTM 좌표계로 그린 세계 지도의 예.
도 9는 UTM zone의 개념도.
도 10은 국가지점번호 안내판의 예.
도 11은 what3words 앱의 소개 화면의 일부.
도 12 내지 도 13은 what3words 앱의 실행 예.
도 14는 구글의 실내 지도를 소개하는 시작 페이지 화면.
도 15 내지 도 16은 구글의 매디슨 스퀘어 가든의 실내 지도에서 6K층과 지하 2층의 실내 지도를 확대한 모습.
도 17은 종래 발명에서 사용하는 좌표계의 개념도.
도 18은 종래 발명에서 층 정보의 개념을 예시하는 개념도.
도 19는 종래 발명의 디지털 지도 시스템의 구성을 보여주는 개념도.
도 20은 종래 발명에서 디지털 지도의 뷰와 중앙의 건물의 예를 보여주는 도면.
도 21은 종래 발명의 실시예에서 레이어의 구성을 예시하는 도면.
도 22는 종래 발명에서 지도 앱의 알고리즘을 보여주는 순서도.
도 23은 종래 발명의 실시예에서 평면도 표시 서브루틴의 순서도.
도 24는 미디어 쿼리를 이용하여 지도 앱의 랜딩 페이지(landing page)를 달리하는 과정을 예시하는 개념도.
도 25는 디지털 지도의 지도 화면의 중심에 계족산 장동산림욕장의 입구가 오도록 한 예.
도 26은 도 25에 보이는 컨트롤 창을 확대한 그림.
도 27은 본 발명의 지도 객체의 자바스크립트 코드.
도 28은 본 발명의 제1 실시예에서 기본 지도 매개변수와 시작 지도 매개변수를 정의하는 자바스크립트 코드.
도 29는 지도 앱을 실행하여 초기 화면이 표시되는 알고리즘을 예시하는 순서도.
도 30은 목표 지도 매개변수를 지정하는 자바스크립트 코드의 예.
도 31은 본 발명의 제1 실시예에서 지도 앱의 초기 화면을 보여주는 그림.
도 32는 시작 지도 매개변수를 저장하는 알고리즘의 순서도.
도 33은 지도 앱의 메뉴를 설명하는 도면.
도 34는 시작 지도 매개변수를 로컬 스토리지에 저장한 이후에 다시 지도 앱을 실행한 경우의 초기 화면.
도 35는 본 발명의 제2 실시예에서 송신인이 문자 메시지를 발신하는 단계의 알고리즘을 예시하는 순서도.
도 36은 '화면을 문자 메시지로 보내기' 버튼에 연결되어 있는 이벤트 리스너(event listener)의 예.
도 37 내지 도 39는 스마트폰에서 문자 메시지로 지도 화면을 보내는 실시예.
도 40은 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 알고리즘을 보여주는 순서도.
도 41은 URL에서 지도 매개변수를 추출하는 자바스크립트 코드의 예.
도 42는 본 발명의 제3 실시예에서 기기의 종류와 화면 모드에 따라서 랜딩 페이지를 달리하는 알고리즘을 보여주는 순서도.
도 43은 랜딩 페이지에서 디지털 지도의 초기 화면을 표시하는 알고리즘을 보여주는 순서도.
도 44는 본 발명의 제5 실시예에서 지도 앱의 화면에 실내 지도가 보이는 예.
도 45는 본 발명의 제5 실시예에서 지도 앱의 초기 화면을 표시하는 알고리즘을 보여주는 순서도.
도 46은 초기 화면에 실내 지도가 보이는 실시예에서 검색 범위를 예시하는 개념도.
도 47은 본 발명의 제5 실시예에서 실내 위치를 시작 장소로 등록하여 초기 화면에 표시되도록 한 예.
도 48 내지 도 50은 제5 실시예의 알고리즘이 실패하는 사례.
도 51은 제5 실시예의 알고리즘이 실패한 이유를 설명하기 위한 개념도.
도 52는 본 발명의 제6 실시예에서 시작 지도 매개변수를 저장하는 알고리즘을 보여주는 순서도.
도 53은 초기 화면에 표시된 장소가 목표 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계의 알고리즘을 보여주는 순서도.
도 54는 본 발명의 제7 실시예에서 실내·외의 장소를 문자 메시지로 보내는 알고리즘을 보여주는 순서도.
도 55는 URL에 포함된 검색 문자열에서 지도 매개변수를 추출하여 세션 스토리지에 저장하는 자바스크립트 코드의 예.
도 56은 지도 매개변수에서 지도 매개변수 객체를 생성하는 자바스크립트 코드의 예.
도 57은 지도 앱이 PWA로 스마트폰에 설치된 모습.
도 58은 본 발명의 지도 앱의 메뉴 버튼의 예.
도 59는 GPS 좌표를 문자 메시지로 보내는 메뉴를 실행하는 스마트폰 화면.
도 60 내지 도 61은 GPS 좌표를 문자 메시지로 보내는 알고리즘을 구현한 자바스크립트 코드의 일부.
도 62 내지 도 63은 GPS 좌표를 문자 메시지로 보낸 스마트폰 화면.
도 64는 본 발명의 제8 실시예에서 GPS 좌표를 문자 메시지로 보내는 알고리즘을 보여주는 순서도.
도 65는 문자 메시지를 수신하는 기기가 문자 메시지 서버인 전형적인 경우를 예시하는 개념도.
도 66은 본 발명의 제9 실시예에서 긴급 연락 정보를 등록하는 단계의 알고리즘을 보여주는 순서도.
도 67 내지 도 68은 긴급 연락 정보를 등록하는 스마트폰 화면의 예.
도 69는 본 발명의 제9 실시예에서 긴급 문자 메시지를 작성하는 자바스크립트 코드의 예.
도 70은 본 발명의 제9 실시예에서 발송된 긴급 문자 메시지의 예.
도 71은 본 발명의 제10 실시예에서 자동적으로 문자 메시지를 발송하는 단계의 알고리즘을 보여주는 순서도.

이하 도 25 내지 도 71을 이용하여 본 발명의 실시예들을 상세하게 설명하기로 한다.

장래 희망이 에드먼드 힐러리 경(Sir Edmund Hillary)과 같은 위대한 등반가인 소년이 최연소 에베레스트산 등정 기록을 세우겠다고 마음먹었다고 가정하자. 도 25는 디지털 지도의 뷰(view, map screen)의 중심에 대전시 대덕구에 위치한 계족산(鷄足山) 장동산림욕장의 입구가 오도록 한 예이다. 이 계족산이 에베레스트 산이라고 가정한다면, 그 소년은 이런 식으로 에베레스트 산의 지도를 수시로 들여다보며 연구하고 등정 계획을 세울 것이다.

도 25에 보이는 본 발명의 실시예의 디지털 지도는 웹앱(web app)으로 실행되며, 더욱 바람직하게는 프로그레시브 웹앱(PWA, Progressive Web App)으로 실행된다. 웹앱은 컨트롤 창(control pane)과 뷰를 가지고 있으며, 주소창(URL bar, address bar, location bar)을 가질 수 있다. 웹앱이라고 하더라도 주소창이 숨겨진 WebView를 사용할 수도 있으므로 웹앱에 주소창이 항상 노출되어 있는 것은 아니다.

뷰(view)는 지도가 보여지는 지도 화면(map screen)으로 사각형의 모양을 가진다. 본 발명에서는 뷰와 지도 화면, 또는 더 간단하게 화면(screen)을 같은 의미로 사용하기로 한다. 또 지도 화면에 보여지는 실외 지도를 지도 영역(map area)이라고 부르기로 한다.

컨트롤 창에는 (측지) 위도, 경도, 북향거리, 동향거리, 줌, 회전 등이 표시되고, 또 디지털 지도와 상호 작용할 수 있는 다양한 컨트롤 메뉴(control menu)를 가지고 있다. 도 26은 도 25의 컨트롤 창의 일부를 확대한 것이다. 컨트롤 창에는 수직 슬라이더(vertical slider)가 부착되어 있어서, 수직 슬라이더를 움직이면 컨트롤 창이 수직 방향으로 움직(scroll)이므로 다른 메뉴들이 나타나게 할 수 있다.

지도 화면(map screen)에 보여지는 실외 지도, 즉 지도 영역(map area)이 변경되면 컨트롤 창에 표시되는 위도와 경도, 북향거리, 동향거리, 줌, 회전 등의 값도 실시간으로 다시 계산되어 표시된다. 컨트롤 창에 보이는 위도와 경도 또는 이와 상호변환이 가능한 북향거리와 동향거리는 정확하게는 뷰의 중심(view center)에 해당하는 지점의 지리적 좌표(geographic coordinates)이다. 본 발명의 실시예의 지도 앱(map app)에는 사용자들이 뷰의 중심이 정확히 어디인지 알 수 있도록 중심 마커(center marker)가 뷰에 부착되어 있다. 예를 들어 패닝(panning)을 하여 뷰에 보이는 지도 영역이 바뀌더라도 중심 마커는 항상 뷰의 중심에 고정되어 있다.

가장 바람직한 북향거리와 동향거리는 수학식 18 내지 19와 같이 주어진다.

여기서 φ는 측지 위도이고, λ는 경도이며, R은 지구의 평균 반경인데, 그 값으로 6,378,137m를 사용할 수 있다. 또, N은 북향거리(northing)이며, E는 동향거리(easting)이다.

뷰에 보이는 실외 지도의 범위를 뷰 범위(view extent)라고 지칭한다. 뷰 범위는 지도 영역의 위도와 경도의 최솟값과 최댓값으로 특정할 수 있다. 그런데 이보다는 지도 영역의 중심의 위도와 경도의 쌍(pair), 또는 북향거리와 동향거리의 쌍에 더하여 줌(zoom)으로 특정하는 것이 더 일반적이다. 즉, 뷰 범위는 지도 영역의 중심의 지리적인 좌표와 줌으로 표시할 수도 있고, 지리적인 좌표의 최솟값과 최댓값들로 표시할 수도 있다. 또, 디지털 지도의 줌 대신에 지도의 해상도(resolution)를 특정할 수도 있다. 지도의 해상도란 지도 화면의 한 픽셀(pixel)이 얼마만한 지리적인 좌표의 간격에 대응하는지를 의미한다.

종이에 인쇄된 지도와는 다르게 스마트폰에서는 두 손가락을 이용하여 디지털 지도를 회전시킬 수 있고(pinch rotate), 도 25의 오른쪽 하단에 보이는 다이얼(dial)을 이용하여 지도를 회전시킬 수도 있다. 따라서 뷰에 보이는 실외 지도는 뷰의 중심의 지리적인 좌표(geographic coordinates), 줌(zoom), 회전(rotation)의 세가지 값을 모두 특정하면 완전하게 결정된다.

위도와 경도의 쌍, 또는 이와 상호변환이 가능한 북향거리와 동향거리의 쌍은 지구상에서의 수평 방향의 위치를 나타낸다. 위도와 경도, 또는 위도와 경도에 고도를 더한 좌표를 지리적인 좌표(geographic coordinates)라고 한다. 본 발명에서는 수평 방향의 위치를 나타내는 지리적인 좌표를 위치(location)라고 지칭하겠다. 지도 영역(map area)을 특정하려면 지도 영역의 중심의 지리적인 좌표(geographic coordinates), 즉 위치(location)와 줌(zoom)과 회전(rotation)을 특정하여야 한다. 위치는 경도와 측지 위도의 쌍(pair), 즉 [경도, 위도]로 주어지거나, 경도 및 위도의 쌍과 상호변환이 가능한 동향거리(easting)와 북향거리(northing)의 쌍, 즉 [동향거리, 북향거리]로 주어져야 한다. 대괄호([])는 자바스크립트에서 배열(array)을 나타낸다. 이들을 총합하여 지도 매개변수(map parameters)라고 지칭하겠다.

뷰에 보이는 실외 지도, 즉 지도 영역(map area)에 대응하는 지도 매개변수를 뷰 지도 매개변수(view map parameters)라고 부르기로 한다. 뷰 지도 매개변수는 뷰 위치(view location) viewLocation과 뷰 줌(view zoom) viewZoom과 뷰 회전(view rotation) viewRotation을 포함하며, 뷰 위치는 뷰 중심의 경도와 위도의 배열([경도, 위도]), 또는 동향거리와 북향거리의 배열([동향거리, 북향거리])로 주어진다.

지도 사업자는 사용자가 디지털 지도를 시작할 때 맨 처음에 어느 지역의 지도를 보여주도록 할 것인가를 결정하여야 한다. 가장 일반적인 방법은 현재 위치의 지도를 보여주는 것이다. 스마트폰에서 구글 지도나 네이버 지도를 시작하면 GPS 신호로부터 위치를 파악하여 현재 위치의 지도를 보여준다.

소년 등반가의 경우에는 디지털 지도를 시작할 때마다 도 25와 같은 화면이 보이도록 하고 싶을 것이다. 그러나 혼자서만 사용하는 디지털 지도가 아닌 이상, 도 21에서와 같이 지도의 시작 위치를 디지털 지도 프로그램 자체에 지정할 수는 없다.

사실 디지털 지도의 시작 위치를 개인화(personalization)하는 것은 보편적인 수요가 있다. 어떤 기업이 자사의 홈페이지에 회사 위치를 안내하려는 목적으로 지도를 삽입한다면, 그 홈페이지에서는 언제나 그 회사의 위치를 보여주고 싶을 것이다. 또는 주말마다 매번 새로운 산으로 등산을 가는 등산객은 일주일 단위로 지도의 시작 화면에 보이는 지도 영역(map area)을 바꾸고 싶을 것이다.

이 경우에 사용할 수 있는 한 방법은 로컬 스토리지(local storage)를 이용하는 것이다. 로컬 스토리지는 인터넷 브라우저(internet browser)가 반영구적으로 사용할 수 있는 메모리 공간(memory space)이라고 할 수 있다. 즉, 로컬 스토리지에 저장된 데이터는 일부러 해당 데이터를 지우기 전까지는 인터넷 브라우저를 지원하는 기기(device)에 존재한다. 기기의 일반적인 예는 PC나 스마트폰이 될 수 있다.

전술한 바와 같이 도 25에 보이는 디지털 지도를 그대로 재현하기 위해서는 지리적인 좌표와 줌과 회전이 모두 같아야 한다. 도 25에서와 같이 장동산림욕장의 입구가 지도 영역의 정중앙에 오려면, 위도와 경도가 각각 36.40658543°과 127.43884349°로 주어져야 한다. 또, 계족산 전체가 한눈에 들어오게 하려면 줌이 13.5 정도인 것이 적당하다. 그리고 장동산림욕장으로 들어가는 도로가 정면으로 보이게 하려면 지도를 270° 회전시켜야 한다.

도 27은 본 발명의 지도 객체(map object)의 자바스크립트 코드를 보여준다. 뷰 중심(view center)과 줌(zoom)을 직접 지정하는 대신에 목표 위치(goal location) goalLocation과 목표 줌(goal zoom) goalZoom이라는 매개 변수를 사용하여 간접적으로 지정한다. 목표 위치는 목표 경도(goal longitude) goalLon과 목표 위도(goal latitude) goalLat의 배열, 즉 [goalLon, goalLat]으로 주어진다. 또 지도를 회전시켜야 한다면 그 값은 목표 회전(goal rotation) goalRotation에 저장되어 있다. 목표 회전 goalRotation은 도(degree)의 단위로 설정하였지만, 오픈레이어(OpenLayers)는 라디안(radian)의 단위를 사용하므로 라디안으로 변환한 후에 그에 맞게 지도를 회전시킨다.

지도 앱이 시작될 때 보이는 지도 화면(map screen)을 초기 화면(initial screen)이라고 부를 수 있다. 초기 화면이란 사용자 상호작용(user interaction)을 통하여 뷰 중심의 지리적인 좌표나 줌, 회전 등이 변경되기 이전의 지도 화면을 말한다. 디지털 지도의 초기 화면은 지도 객체의 설정(setting)을 통하여 정해진다.

도 28은 본 발명의 제1 실시예에서 기본 지도 매개변수(default map parameters)와 시작 지도 매개변수(start map parameters)를 정의하는 자바스크립트 코드를 보여준다. 본 발명의 제1 실시예에서 지도 매개변수(map parameters)는 지리적인 좌표와 줌과 회전을 포함하는데, 지리적인 좌표는 간단히 경도 λ와 위도 φ의 쌍(pair), 또는 경도와 위도의 배열 [λ, φ]로 주어진다. 기본 지도 매개변수는 기본 위도(default latitude) default_latitude와 기본 경도(default longitude) default_longitude와 기본 줌(default zoom) default_zoom과 기본 회전(default rotation) default_rotation으로 구성되며, 프로그램에서 정의된 기본값(default values)을 가지고 있다. 도 28에서 기본 위치는 광화문 세종대왕 동상의 위치이며, 기본 줌은 17.0이고, 기본 회전은 0°이다.

한편, 시작 지도 매개변수(start map parameters)는 시작 위도(start latitude) start_latitude와 시작 경도(start longitude) start_longitude와 시작 줌(start zoom) start_zoom과 시작 회전(start rotation) start_rotation을 포함하며, 초기값(initial values)은 모두 '없음(null)'으로 되어 있다.

지도 앱의 시작 시에 이 기본 지도 매개변수가 목표 지도 매개변수로 지정(assign)된다. 따라서 도 27의 코드가 실행되면 기본 지도 매개변수에 부합하도록 초기 화면이 표시된다. 한편, 지도의 시작 화면, 즉 초기 화면에 보이는 지도 영역을 개인화(personalization)하려면 뷰 지도 매개변수를 시작 지도 매개변수(start map parameters)로 저장할 수 있다. 시작 지도 매개변수는 시작 위치(start location) start_location, 시작 줌(start zoom) start_zoom, 시작 회전(start rotation) start_rotation을 포함한다.

사용자가 지도 앱에서 '현재 화면을 시작 화면으로 저장(store current screen as start screen)'이라는 메뉴 버튼(menu button)을 누르면, 뷰 지도 매개변수를 시작 지도 매개변수로 로컬 스토리지(local storage)에 저장한다. 여기서 '뷰 지도 매개변수'란 스마트폰이나 컴퓨터와 같은 기기(device)가 있는 물리적인 장소의 지도 매개변수를 말하는 것이 아니라, 지도 앱의 뷰(view)에 보여지는 지도의 설정(setting)을 말한다. 예를 들어 대전시 '목척1길 21'에서 에베레스트 산의 지도를 보다가 '현재 화면을 시작 화면으로 저장' 버튼을 누르면 에베레스트 산의 지도 매개변수가 '시작 지도 매개변수'로 로컬 스토리지에 저장된다.

다음번에 지도 앱을 시작할 때, 지도 앱은 유효한 '시작 지도 매개변수'가 로컬 스토리지에 저장되어 있는지 확인한 후, 값이 저장되어 있으면 그 값들을 '목표 지도 매개변수(goal map parameters)'로 지정하여 디지털 지도의 시작 화면에 에베레스트 산이 보이도록 할 수 있다. 한편, 다음번에 디지털 지도를 시작할 때 '목척1길 21'이 보이도록 하고 싶다면, 지도 앱에서 지도 영역을 '목척1길 21'로 이동한 후 '현재 화면을 시작 화면으로 저장' 버튼을 누를 수도 있지만, 'GPS로 현재 위치 찾기(find current location using GPS)' 버튼을 먼저 눌러서 지도에 사용자의 위치가 보이도록 한 후, '현재 화면을 시작 화면으로 저장' 버튼을 누르면 더 편리하게 지정할 수 있다.

로컬 스토리지에 값을 저장하려면 자바스크립트 객체(JavaScript object)의 형식을 이용하여 키(key)와 값(value)의 쌍(pair)을 사용하여야 하는데, 키는 문자열(string)로 주어져야 한다. 따라서 start_latitude라는 키(key)에 36.0이라는 값(value)을 부여하여 로컬 스토리지에 저장하려면 window.localStorage.setItem("start_latitude", 36.0)이라는 자바스크립트(JavaScript) 명령을 실행하면 된다. 그리고 이 값을 가져오려면 window.localStorage.getItem("start_latitude")이라는 명령을 실행하면 된다. 그런데 이와 같이 얻어진 값은 실수(real number)가 아니라 문자열(string)로 주어진다. 따라서 이를 실수로 변환하는 과정이 필요하다. 이를 모두 고려하면 다음과 같은 명령을 실행하면 된다.

let start_latitude = parseFloat(window.localStorage.getItem("start_latitude"));

이와 같은 명령을 실행하면 start_latitude라는 변수에 36.0이라는 값이 저장된다. 만약 건물 고유 번호(building identification number)나 층수(floor number)와 같이 정수(integer)로 주어지는 값들을 가져오려면 parseFloat() 명령 대신에 parseInt() 명령을 실행하면 된다.

도 29는 시작 지도 매개변수를 저장한 이후에 디지털 지도를 실행하는 단계의 알고리즘을 보여주는 순서도이다. 사용자가 디지털 지도를 시작하면, 지도 앱은 로컬 스토리지에 저장된 시작 지도 매개변수가 있는지 확인한다. 저장된 시작 지도 매개변수가 있으면 시작 지도 매개변수를 가져와서 목표 지도 매개변수로 지정하고, 저장된 시작 지도 매개변수가 없으면 기본 지도 매개변수를 목표 지도 매개변수로 지정한다. 마지막으로 초기 화면의 지도 영역이 목표 지도 매개변수에 부합하도록 초기 화면을 표시한다.

도 30은 목표 지도 매개변수(goal map parameters)를 지정하는 자바스크립트 코드를 보여준다. start_latitude와 start_longitude라는 키(key)에 저장된 값이 모두 유효하다면(not null) 그 값들을 각각 goalLat과 goalLon으로 지정하고, start_zoom과 start_rotation이라는 키에 저장된 값도 각각 goalZoom과 goalRotation으로 지정한다. 두 값 중 어느 하나라도 유효하지 않다면(null), 기본 지도 매개변수를 목표 지도 매개변수로 지정한다. 결국, 로컬 스토리지에 유효한 시작 지도 매개변수가 저장되어 있으면 지도 앱이 시작 지도 매개변수로 시작하게 되며, 유효한 시작 지도 매개변수가 저장되어 있지 않으면 기본 지도 매개변수로 시작하게 된다.

도 31은 본 발명의 제1 실시예에서 디지털 지도의 초기 화면(initial screen)을 보여주는 그림이다. 현재는 저장된 시작 지도 매개변수가 없으므로 초기 화면에는 기본 지도 매개변수에 부합하는 광화문 광장이 보여지고 있다.

도 32는 시작 지도 매개변수(start map parameters)를 저장하는 알고리즘을 보여주는 순서도이다. 시작 지도 매개변수를 저장하는 단계는 사용자가 지도 앱과의 상호 작용을 통하여 지도 앱의 초기 화면에 보이게 할 지도 영역을 선택하는 단계에서 시작한다.

도 33은 웹앱(web app)으로 실행되는 지도 앱의 메인 화면(main screen)을 보여준다. 화면 왼쪽에는 컨트롤 창(control pane)이 있고, 오른쪽에는 뷰(view, map screen)가 있다. 뷰에 보이는 지도 영역(map area)은 뷰 지도 매개변수(view map parameters)로 특정된다. 뷰의 왼쪽 상단에는 줌을 증가시킬 수 있는 플러스(+) 버튼과 줌을 감소시킬 수 있는 마이너스(-) 버튼이 있다. 오른쪽 하단에는 지도를 회전시킬 수 있는 다이얼(dial)이 있다. 또 뷰에 보이는 지도에 마우스 커서(mouse cursor)를 가져간 뒤 마우스 왼쪽 버튼을 누르고 이동(drag)하면 지도 영역을 바꿀 수 있고, 마우스 휠(mouse wheel)을 돌려서 줌을 변경시킬 수도 있다. 이와 같은 방식으로 뷰에 보이는 지도 영역을 변경할 수 있다. 도 33에서 뷰 지도 매개변수(view map parameters)는 위도 36.40658543°, 경도 127.43884349°, 줌 17.0, 회전 277.0°이다.

사용자가 지도 앱과의 상호 작용을 통하여 지도 앱의 초기 화면에 보이게 할 지도 영역을 선택하는 단계를 완료하면, 선택된 지도 영역을 시작 지도 영역(start map area)으로 저장하는 메뉴를 실행한다. 도 33의 컨트롤 창에는 시작 지도 매개변수를 저장하는 메뉴 버튼(button for storing start map parameters)과 시작 지도 매개변수를 삭제하는 메뉴 버튼(button for erasing start map parameters)이 있다. 시작 지도 매개변수를 저장하는 메뉴 버튼의 이름은 '현재 화면을 시작 화면으로 저장'이라고 되어 있고, 시작 지도 매개변수를 삭제하는 메뉴 버튼의 이름은 '시작 화면 지우기'라고 표시되어 있다.

시작 지도 매개변수를 저장하는 메뉴 버튼을 누르면, 선택된 지도 영역에 해당하는 지도 매개변수, 즉 뷰 지도 매개변수가 로컬 스토리지에 시작 지도 매개변수로 저장된다. 도 34는 시작 지도 매개변수를 저장한 이후에 지도 앱을 다시 시작한 초기 화면을 보여준다. 뷰에 보이는 지도 영역이 도 33의 지도 영역과 동일한 것을 알 수 있다.

그런데 시작 지도 매개변수를 로컬 스토리지에 저장하는 대신에 앱 서버(app server)에 저장하는 방법도 가능하다. 이 경우에는 물론 PC나 스마트폰과 같은 기기(device)가 인터넷에 연결되어 있어야 하고, 둘째로 사용자 로그인(user login)이 되어 있어야 한다. 이 경우에 시작 지도 매개변수를 로컬 스토리지에 저장할 것인지 앱 서버에 저장할 것인지 택일할 수도 있고, 먼저 로컬 스토리지에 저장하고, 추가적으로 앱 서버에 저장할 수도 있다. 그러나 가장 바람직한 방법은 먼저 로컬 스토리지에 저장한 다음에 앱 서버(app server)에 사용자 로그인(user login)이 되어 있는지 확인한 후, 사용자 로그인이 되어 있으면 앱 서버에도 시작 지도 매개변수를 저장하는 방법이다.

이 경우에 지도 앱을 실행하는 단계에서 먼저 앱 서버에 로그인이 되어 있는지 확인한 후, 로그인이 되어 있으면 앱 서버에 시작 지도 매개변수가 저장되어 있는지 확인한다. 앱 서버에 시작 지도 매개변수가 저장되어 있으면 그 시작 지도 매개변수를 목표 지도 매개변수로 지정한다. 만약 앱 서버에 시작 지도 매개변수가 저장되어 있지 않으면, 로컬 스토리지에 시작 지도 매개변수가 저장되어 있는지 확인한다. 로컬 스토리지에 유효한 값이 저장되어 있다면 그 시작 지도 매개변수를 목표 지도 매개변수로 지정한다. 앱 서버와 로컬 스토리지에 모두 값이 저장되어 있지 않다면, 기본 지도 매개변수를 목표 지도 매개변수로 지정한다.

이와 같은 방법에 의하여 로컬 스토리지에 저장된 값이 지워졌다고 하더라도 앱 서버에 저장된 값을 이용하여 복원할 수 있다. 또, PC에서 시작 지도 매개변수를 저장했으면, 스마트폰에서도 변경된 시작 지도 매개변수로 지도 앱을 실행할 수 있다.

이와 같은 본 발명의 제1 실시예에 의하면 PC나 스마트폰으로 본 발명의 지도 서비스를 이용하는 사용자는 디지털 지도의 초기 화면에 보이는 지도 영역을 기기별로 개인화(personalization)할 수 있다.

소년 등반가가 주말에 장동산림욕장의 입구에서 친구와 만나서 같이 계족산 등반 훈련을 하기로 했다고 가정하자. 그렇다면, 약속 장소의 주소를 전화로 불러 주거나 문자 메시지로 보내줄 수도 있지만, 도 25에 보이는 디지털 지도를 직접 보내준다면 더 바람직할 것이다. 본 발명의 제2 실시예는 디지털 지도의 URL(Uniform Resource Locator)을 문자 메시지로 보내고, 수신인(receiver)이 수신된 문자 메시지를 선택하면 디지털 지도가 웹앱으로 시작되며, 지도 앱의 초기 화면에 송신인(sender)이 보낸 지도 영역이 보이도록 하는 방법에 관한 발명이다. 문자 메시지를 선택하는 행위는 마우스로 클릭(click)하거나 터치 모니터(touch monitor)에서 두드리는(tap) 행위를 모두 포함한다.

실시예 1의 발명이 사용자(user)의 기기에서 웹앱으로 실행되는 지도 앱의 초기 화면에 보이는 지도 영역을 개인화하는 방법이라면, 실시예 2의 발명은 문자 메시지를 수신한 수신인의 기기에서 웹앱으로 실행되는 지도 앱의 초기 화면에 보이는 지도 영역을 일회적으로 개인화하는 방법이다. 구체적으로 본 발명의 제2 실시예는 웹앱(web app)으로 실행되는 디지털 지도(digital map)의 지도 화면(map screen, view)에 보이는 지도 영역(map area)을 수신인과 공유(share)하기 위하여 문자 메시지(text message)를 보내는 방법에 관한 발명이다. 이 실시예는 송신인이 문자 메시지를 보내는 단계와, 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계로 구성된다.

도 35는 송신인이 문자 메시지를 보내는 단계의 알고리즘을 보여주는 순서도이다. 이 단계는 송신인이 지도 앱과의 상호 작용을 통하여 수신인의 기기(device)에서 웹앱으로 실행되는 지도 앱의 초기 화면에 보이게 할 지도 영역을 선택하는 단계에서 시작하며, 본 발명의 제1 실시예에서 지도 영역을 선택하는 단계와 동일하다.

지도 영역이 선택되면 송신인은 선택된 지도 영역을 문자 메시지로 보내는 메뉴를 실행한다. 지도 앱은 선택된 지도 영역에 해당하는 지리적인 좌표(geographic coordinates)와 줌(zoom)과 회전(rotation)을 포함하는 지도 매개변수(map parameters)를 검색 문자열(search string)로 포함하는 URL(Uniform Resource Locator)을 포함하는 문자 메시지 몸체(text message body)를 문자 메시지 창(text message window)에 작성한다. 문자 메시지의 작성이 완료되면 송신인이 수신인을 선택하고 문자 메시지를 발송한다.

도 36은 '화면을 문자 메시지로 보내기(send screen by text message)'라는 메뉴 버튼(btnSendScreenBySMS)에 연결되어 있는 이벤트 리스너(event listener)의 예를 보여주며, 그 구조는 다음과 같다.

btnSendScreenBySMS.addEventListener("click", function(){

....

}, false);

즉, 메뉴 버튼을 선택(click)하면 무명함수(無名函數, anonymous function)가 실행된다. 이 무명 함수의 내부에 있는 자바스크립트 코드는 지도 앱이 선택된 지도 영역에 해당하는 지도 매개변수를 SMS(Short Message Service, 단문 메시지 서비스)로 발송하는 소스 코드(source code)이다. 이와 같은 기능은 여러가지 방법으로 구현될 수 있으며, 도 36에 제시된 코드는 단지 하나의 예시일 뿐이다.

4행(line 4)에서 내용이 없는 URLSearchParams 객체 인스턴스(object instance)를 searchParams라는 이름으로 생성한다. 다음으로, 7행에서 뷰 중심(view center)의 북향거리(viewNorthing)를 북향거리(northing)라는 키(key)로 searchParams에 추가한다(append). 마찬가지로 뷰 중심의 동향거리(viewEasting)와 줌(viewZoom)과 회전(viewRotation)을 각각 동향거리(easting), 줌(zoom), 회전(rotation)이라는 키로 searchParams에 추가한다. 북향거리와 동향거리 대신에 위도와 경도를 사용해도 되지만, 거리의 단위로 표시하기 위하여 북향거리와 동향거리를 사용하였다.

이렇게 준비된 searchParams는 자바스크립트 객체(JavaScript object)이다. 이 자바스크립트 객체를 toString()이라는 메서드(method)를 사용해서 문자열(string)로 변환한다. 도 33에 보이는 지도 영역에 대하여 이렇게 변환된 문자열은 다음과 같이 주어진다.

northing=14071516.723&easting=27544298.950&zoom=17.0&rotation=277.0

여기에 포함된 앰퍼샌드(ampersand, &)는 '그리고(and)'를 뜻한다. 그런데 이 앰퍼샌드를 포함한 URL을 문자 메시지 몸체(text message body)에 추가하는 과정에서 문제가 발생할 수 있다. 구체적으로 어디에서 어디까지가 문자 메시지의 몸체인지 프로그램이 혼동할 수 있다. 이러한 문제를 회피하기 위하여 replace(/&/g, ':')라는 메서드를 사용하여 앰퍼샌드(&)를 모두 콜론(:)으로 변경한다. 많은 기호들 중에서 콜론을 선택한 이유는 순전히 이렇게 완성된 문자열이 보기에도 좋고 읽기에도 편하기 때문이다. 따라서 searchParams.toString().replace(/&/g, ':')라는 명령어는 다음과 같은 문자열을 반환한다.

northing=14071516.723:easting=27544298.950:zoom=17.0:rotation=277.0

여기에 window.location.origin라는 명령어로 웹앱의 주소(https://map.digitalearth.land)를 가져오고, 검색 문자열(search string)을 표시하는 물음표(?)를 추가하면 완성된 문자열 stringTextarea는 다음과 같이 주어진다.

stringTextarea = "https://map.digitalearth.land?northing=14071516.723:easting=27544298.950:zoom=17.0:rotation=277.0"

다음으로, 21행에서 문서(document)에 앵커 요소(anker element)를 linkSMS라는 이름으로 생성하고, 23행에서 문서에 자식 요소로 부착한다(appendChild). 25행에서 linkSMS의 href 속성으로 "sms:?body=" + stringTextarea를 지정한다. sms는 이 앵커 요소 linkSMS가 문자 메시지(text message)를 보내기 위한 요소라는 뜻이며, "body=" + stringTextarea는 이 문자 메시지의 메시지 몸체(message body)에 stringTextarea를 써넣으라는 뜻이다. 그리고 문자 메시지를 수신할 수신인(receiver)은 지정하지 않았는데, 이렇게 하면 스마트폰에서 수신인을 선택하라는 대화상자(prompt)가 나타난다.

인터넷 문서에서 가장 흔한 앵커 요소는 다른 웹 페이지(web page)로 연결되는 HTML 링크이다. 이 링크를 마우스(mouse)로 클릭(click)하거나 터치(touch)하면, 링크에 연결된 웹페이지로 이송(redirect)된다. 이와 같이 마우스 클릭이나 터치를 프로그램으로 대신할 수 있는 명령이 click()이다. 27행은 이렇게 생성된 앵커(linkSMS)를 프로그램적으로 클릭하여 문자 메시지(text message)를 발송한다.

도 37 내지 도 39는 스마트폰에서 문자 메시지로 지도 화면을 보내는 실시 예이다. 도 37은 발명자의 스마트폰에서 '화면을 문자 메시지로 보내기(send screen by text message)' 메뉴를 실행하는 화면이고, 도 38은 발명자 자신의 스마트폰으로 문자 메시지를 보낸 화면이며, 도 39는 수신된 문자 메시지를 선택(click)하여 지도 앱을 시작한 화면이다.

도 40은 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계의 알고리즘을 보여주는 순서도이다. 이 단계는 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 시작하는(launch) 단계, 지도 앱이 URL에 포함된 검색 문자열에서 지도 매개변수를 추출하는(parse) 단계, 지도 앱의 초기 화면에 보이는 지도 영역이 추출된 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계를 포함한다.

가장 일반적인 기기(device)가 스마트폰이므로, 수신인이 스마트폰에 수신된 문자 메시지를 선택하면 문자 메시지에 포함된 URL(https://map.digitalearth.land?northing=14071516.723:easting=27544298.950:zoom=17.0:rotation=277.0)에 포함된 지도 앱(https://map.digitalearth.land)가 웹앱으로 시작된다. 웹앱에서 시작할 웹 페이지가 명시적으로 지정되어 있지 않으면, 브라우저는 index.html 페이지나 index.php 페이지를 찾아서 실행하게 된다. 도 41은 index.html 페이지에 포함된 자바스크립트 코드이다.

URL이 "https://map.digitalearth.land?northing=14071516.723:easting=27544298.950:zoom=17.0:rotation=277.0"로 주어질 때, window.location.search는 물음표 이하의 문자열로 주어진다.

window.location.search = "?northing=14071516.723:easting=27544298.950:zoom=17.0:rotation=277.0"

여기서 지도 매개변수를 추출하는 방법도 여러가지로 구현할 수 있지만, 가장 간단한 방법은 다시 한번 URLSearchParams를 이용하는 것이다. 이를 위해서 문자 메시지 전송 과정에서 앰퍼샌드(&) 대신에 사용되었던 콜론(:)을 다시 앰퍼샌드로 치환하여야 한다. window.location.search.replace(/:/g, '&')라는 명령을 실행하면, 다음과 같이 콜론을 모두 앰퍼샌드로 치환한다.

window.location.search.replace(/:/g, '&') = "?northing=14071516.723&easting=27544298.950&zoom=17.0&rotation=277.0"

이렇게 치환된 문자열에서 searchParams라는 이름으로 URLSearchParams 객체를 생성한다. searchParams에서 get() 메서드를 사용하여 키(key)에 대응하는 값을 읽어온 뒤, 실수로 변환하면 지도 매개변수를 얻을 수 있다. 예를 들어 북향거리는 다음과 같이 얻을 수 있으며, 동향거리와 줌과 회전도 모두 마찬가지 방식으로 얻을 수 있다.

let northing = parseFloat(searchParams.get("northing"));

만약 지도 화면을 문자 메시지로 보내는 기기와 문자 메시지를 수신하는 기기가 같은 종류이고, 화면 모드(screen mode)도 동일하다면 이와 같은 코드로 충분하다. 그런데 PC에서 스마트폰으로 보내거나, 스마트폰에서 PC로 보내는 등 기기가 서로 동일하지 않을 수 있다. 또 스마트폰에서는 화면을 풍경 사진(landscape) 모드나 인물 사진(portrait) 모드로 사용할 수 있다. 이와 같은 경우에는 레이아웃(layout)이 다른 웹 페이지를 사용하는 것이 편리하다. 예를 들어 기기가 PC이면 랜딩 페이지(landing page)의 이름을 indexDesktopLandscape.html로 할 수 있다. 또, 기기가 스마트폰이면서 화면 모드가 인물 사진 모드이면 랜딩 페이지의 이름을 indexMobilePortrait.html로 할 수 있고, 풍경 사진 모드이면 랜딩 페이지의 이름을 indexMobileLandscape.html로 할 수 있다. 따라서 도 24에 예시한 바와 같이 인덱스 페이지(index.html)에서 기기의 종류와 화면 모드를 판단한 후, 적절한 랜딩 페이지로 이송(redirect)하는 과정이 필요하다.

그런데 HTML 문서(HTML document)에서는 다른 웹 페이지 간에 변수가 공유되지 않는다. 예를 들어 스마트폰에서 수신된 문자 메시지를 선택하여 인물 사진 모드로 지도 앱을 실행한다면, indexMobilePortrait.html 페이지가 실행되어야 하지만, index.html 페이지에서 추출된 지도 매개변수를 indexMobilePortrait.html 페이지에서는 볼 수 없다. 이와 같은 문제를 해결하기 위한 방법이 세션 스토리지(session storage)를 이용하는 것이다. 로컬 스토리지(local storage)와 세션 스토리지는 인터넷 표준에 정의된 것으로, 모든 인터넷 브라우저에서 사용할 수 있다.

로컬 스토리지는 기기의 하드웨어에 키(key)와 값(value)의 쌍(pair)으로 변수를 저장하며, 일부러 지우기 전까지는 계속 사용할 수 있는 저장 방법이다. 반면에 세션 스토리지는 인터넷 브라우저가 실행되고 있는 동안에만 임시적으로 사용할 수 있는 저장 방법인데, 웹 페이지 간에 변수를 전달하기 위하여 사용된다. 세션 스토리지에 저장된 변수는 인터넷 브라우저를 종료하는 순간 모두 사라진다. 그러나 로컬 스토리지에 변수를 저장하는 방법과 세션 스토리지에 변수를 저장하는 방법은 사실상 동일하다고 할 수 있다. 예를 들어 'northing'이라는 키에 northing이라는 변수의 값을 로컬 스토리지와 세션 스토리지에 저장하는 방법은 각각 다음과 같다.

window.localStorage.setItem('northing', northing);

window.sessionStorage.setItem('northing', northing);

또한, 저장된 값을 가져오는 방법은 각각 다음과 같다.

let northing = parseFloat(window.localStorage.get('northing'));

let northing = parseFloat(window.sessionStorage.get('northing'));

이와 같은 세션 스토리지를 사용하여 기기의 종류와 화면 모드에 대응하는 알고리즘이 도 42에 도시되어 있다. 수신인이 수신된 문자 메시지를 선택하면 문자 메시지에 포함된 URL로 지도 앱이 시작된다. 인덱스 페이지(index.html)에 포함된 자바스크립트 코드는 URL에 포함된 location 객체(location object)에서 검색 문자열(search string)을 가져온다. 검색 문자열은 window.location.search로 구할 수 있다. 검색 문자열에서 다시 지도 매개변수를 추출(parsing)한 뒤, 추출된 매개변수를 세션 스토리지(session storage)에 세션 변수(session variables)로 저장한다.

다음으로 지도 앱이 실행중인 기기의 종류(type)가 스마트폰인지 PC인지 판단하여, PC이면 PC용으로 만들어진 랜딩 페이지(landing page)인 indexDesktopLandscape.html로 시작한다. 기기의 종류가 스마트폰이면, 인물 사진 모드에서는 indexMobilePortrait.html로 시작할 수 있고, 풍경 사진 모드에서는 indexMobileLandscape.html로 시작할 수 있다.

기기의 종류와 화면 모드에 대응하는 랜딩 페이지를 시작한 이후에는 세션 스토리지에서 지도 매개변수를 가져오며, 인덱스 페이지(index.html)는 종료(close)한다. 마지막으로 초기 화면에 보이는 지도 영역이 지도 매개변수에 부합하도록 초기 화면을 표시한다.

웹앱으로 실행되는 지도 앱이 PWA이면 더 바람직하다는 사실, 지리적인 좌표를 경도와 측지 위도의 쌍으로 전송하는 대신에 경도와 측지 위도의 쌍과 상호변환이 가능한 동향거리와 북향거리의 쌍으로 보내는 것이 더 바람직하다는 사실 등은 실시예 1에서와 동일할 뿐만 아니라, 이후의 모든 실시예에서도 동일하다.

본 발명의 실시예 1은 지도 앱의 초기 화면을 개인화하는 방법에 관한 발명이고, 실시예 2 내지 3은 문자 메시지를 수신한 수신인의 기기에서 실행되는 지도 앱의 초기 화면을 일회적으로 개인화하는 방법에 관한 발명이다. 그러면 수신인이 지도 앱의 초기 화면을 개인화하였는데, 실시예 2 내지 3에서와 같은 문자 메시지를 받아서 선택했을 때 지도 앱의 초기 화면에 보이는 지도 영역을 어떻게 할 것인가의 문제가 있다.

도 43은 랜딩 페이지(landing page)에서 디지털 지도의 초기 화면을 표시하는 알고리즘을 보여주는 순서도이다. indexDesktopLandscape.html이나 indexMobilePortrait.html, indexMobileLandscape.html 등 랜딩 페이지가 결정되면, 지도 앱은 먼저 세션 스토리지에 유효한 지도 매개변수가 저장되어 있는지 확인한다. 유효한 지도 매개변수가 저장되어 있으면 세션 스토리지에서 지도 매개변수를 가져와서 이를 목표 지도 매개변수로 지정한다. 세션 스토리지에 유효한 지도 매개변수가 저장되어 있지 않으면, 이번에는 로컬 스토리지에 유효한 시작 지도 매개변수가 저장되어 있는지 확인한다. 유효한 시작 지도 매개변수가 저장되어 있으면, 로컬 스토리지에서 시작 지도 매개변수를 가져와서 목표 지도 매개변수로 지정한다. 로컬 스토리지에 저장된 시작 지도 매개변수도 없으면 기본 지도 매개변수를 목표 지도 매개변수로 지정한다. 마지막으로 디지털 지도의 초기 화면에 보이는 지도 영역이 목표 지도 매개변수에 부합하도록 초기 화면을 표시한다.

결과적으로 문자 메시지를 클릭하면, 문자 메시지의 URL에 포함된 검색 문자열에 부합하는 지도가 보여지고, 일반적인 방법으로 지도 앱을 시작하면 개인화된 초기 화면이 있으면 그 화면으로 시작하며, 개인화된 초기 화면이 없으면 기본 지도 화면으로 시작된다. 따라서 실시예 1의 발명과 실시예 2 내지 3의 발명이 동시에 구현될 수 있다.

[특 15] 내지 [특 17]에 개시된 종래 발명에 의하면 실외 지도 상의 올바른 위치에 실내 지도가 표시된다. 예를 들어 백화점이나 쇼핑몰의 실내 지도가 등록되어 있다면, 실내 지도 상의 각 상점의 위치에 상호(business name)가 표시되고, 그 상호를 선택하면 홈 페이지나 온라인 쇼핑몰이 연결되도록 할 수도 있다.

쇼핑몰에서 상점을 운영하는 상인이 상호에 온라인 쇼핑몰을 연결해 놓았다면, 디지털 지도를 시작할 때마다 온라인 쇼핑몰에서 새로운 주문이나 고객 후기 등이 있는지 확인하고 싶을 것이다. 따라서 이와 같은 경우에는 실내를 포함하여 디지털 지도의 시작 위치를 개인화할 필요성이 있다.

본 발명에서는 실외 지도 상에서의 위치와 실내 지도 상에서의 위치를 통합적으로 장소(place)라고 지칭하기로 한다. 장소는 경도와 측지 위도의 쌍이나 경도 및 측지 위도의 쌍과 상호변환이 가능한 동향거리와 북향거리의 쌍으로 주어지는 지리적인 좌표(geographic coordinates)와 건물 내에서의 층(floor)을 포함하는 개념이다. 디지털 지도의 줌과 회전은 장소의 개념에는 포함하지 않기로 한다. 즉, 본 발명의 제5 실시예는 지도 앱의 초기 화면에 보이는 실내·외의 장소를 개인화하기 위한 발명이다.

도 44는 출원인의 사무실이 있는 OK벤처타운 건물의 2층의 실내 지도를 보여준다. 이 장소가 지도 앱의 초기 화면에 보이도록 하려면 북향거리와 동향거리에 더하여 층(floor)을 지도 매개변수에 추가하여야 하며, 도 44의 지도 화면을 그대로 재현하려면 줌과 회전도 추가되어야 한다. 장소를 특정하는 지도 매개변수에 지리적인 좌표와 층만 포함되어 있다면, 지도 매개변수를 로컬 스토리지에 시작 지도 매개변수로 저장하는 과정에서 줌과 회전이 추가되며, 그 값은 기본 지도 매개변수에 포함된 줌과 회전의 값(예를 들어 zoom = 17 & rotation = 0)을 사용한다.

도 45는 이와 같이 층을 포함하는 시작 지도 매개변수를 가지는 디지털 지도의 초기 화면을 표시하는 알고리즘을 보여주는 순서도이다. 본 발명의 제1 실시예에서와 동일하게, 사용자가 디지털 지도를 시작하면 지도 앱은 로컬스토리지에 저장된 시작 지도 매개변수가 있는지 확인한다. 저장된 시작 지도 매개변수가 있으면 시작 지도 매개변수를 가져와서 목표 지도 매개변수로 지정하고, 저장된 시작 지도 매개변수가 없으면 기본 지도 매개변수를 목표 지도 매개변수로 지정한다. 마지막으로 초기 화면에 보이는 장소(place)가 목표 지도 매개변수에 부합하도록 초기 화면을 표시한다.

도 46은 실내를 포함하는 디지털 지도의 초기 화면에 보이는 장소, 즉 시작 장소(start place)를 개인화하는데 있어서 필요한 검색 범위(search area)를 설명하기 위한 개념도이다. 도 46에는 4채의 건물들의 외곽선이 표시되어 있다. 이 건물들은 그 건물들의 대표 지점(building center)이 뷰 범위(view extent)에 포함되는 건물들이다. 도 46에는 각 건물들의 대표 지점이 점(point)으로 표시되어 있다. 각 건물들의 대표 지점은 그 건물들의 외곽선을 나타내는 도형(geometry)의 도심(centroid)으로 정하는 것이 바람직하지만, 도형의 형상이 특이한 경우에는 도심과 별개로 건물 내의 한 점을 임의로 선택할 수 있다.

지도 앱의 초기 화면에 보이는 장소가 목표 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계는 다시 다음과 같은 여러 단계를 포함한다. 우선 목표 지도 매개변수로부터 뷰 범위를 결정하고 실외 지도를 표시한다. 그리고 뷰 범위(view extent)를 포함하는 검색 범위(search area)를 정한다. 검색 범위는 건물 데이터베이스에서 건물을 검색하는 지리적인 좌표의 범위이다. 검색 범위는 뷰 범위와 동일하게 할 수도 있지만, 뷰 범위보다 크게 하는 것이 바람직하다. 예를 들어 검색 범위는 뷰 범위와 중심이 일치하고, 모양은 같으며 면적은 2배로 할 수 있다.

검색 범위가 정해지면 건물 데이터베이스를 검색하여 건물의 대표 지점이 검색 범위에 포함되는 건물들의 목록(Bld_ID)을 작성한다. 이 목록에 포함된 건물들에 대하여 각 건물들의 외곽선 표시 줌 레벨(zoomShowBld)과 디지털 지도의 줌 레벨(viewZoom)을 비교하여 외곽선 표시 대상 건물 목록(bldIDsToShow)을 작성하고, 이 목록에 포함된 건물들의 외곽선 도면(building outline drawings)을 건물 데이터 저장소(building data store)에서 가져와서 실외 지도 상의 올바른 위치에 표시한다.

다음으로 외곽선 표시 대상 건물 목록(bldIDsToShow)에 있는 건물들에 대하여 평면도 표시 줌 레벨(zoomShowFloor)과 디지털 지도의 줌 레벨(viewZoom)을 비교하여 평면도 표시 대상 건물 목록(floorplanIDsToShow)을 작성한다. 평면도 표시 대상 건물 목록에 있는 건물들에 대하여 지면층(ground floor)이 있는 건물인지 확인하여, 지면층이 있는 건물들의 평면도를 건물 데이터 저장소에서 가져와서 실외 지도 상의 올바른 위치에 표시한다.

다음으로 뷰 중심(view center)이 건물의 외곽선 내에 위치하는 건물, 즉 중앙의 건물(building at view center)이 있는지 확인한다. 중앙의 건물이 있으면, 목표 지도 매개변수에 포함된 건물의 층(goalFloor)이 지면층인지 확인하고, 지면층이 아니면 중앙의 건물에 대하여 지면층의 평면도를 제거하고 해당 층의 평면도를 가져와서 실외 지도 상의 올바른 위치에 표시한다.

도 47은 이와 같은 알고리즘을 적용하여 디지털 지도의 초기 화면에 OK벤처타운 2층의 실내 지도가 보이게 한 예로, 도 44와 동일한 지도 화면이 초기 화면으로 보이는 것을 알 수 있다. 이와 같이 초기 화면에 실내 지도가 보이도록 하려면 여러 단계가 순차적으로 작동하여야 한다. 예를 들어 외곽선 표시 대상 건물 목록(bldIDsToShow)이 완성되기 이전에 평면도 표시 대상 건물 목록(floorplanIDsToShow)을 작성하면 안 된다. 건물 데이터베이스를 검색하거나, 건물 데이터 저장소에서 건물의 외곽선 도면이나 평면도를 가져와서 실외 지도 상의 올바른 위치에 표시하는 작업은 비동기적으로(asynchronously) 이루어진다. 그럼에도 불구하고 전술한 단계들은 사실상 동기적으로(synchronously) 작동하도록, 즉 전 단계가 끝난 다음에야 다음 단계가 시작되도록 프로그램이 작성되어야 한다.

도 48의 중앙에는 대전중앙로지하상가의 외곽선이 실외 지도 상의 올바른 위치에 표시되고 있으며, 오른쪽에는 대전역전지하상가의 외곽선이 일부 보이고 있다. 도 49는 이 대전중앙로지하상가의 오른쪽 회랑(回廊, corridor)을 디지털 지도의 시작 장소로 지정한 상태를 보여주며, 도 50은 디지털 지도의 초기 화면을 보여준다. 도 50에서 실외 지도는 지리적인 좌표와 줌과 회전이 모두 똑같이 재현되었는데, 실내 지도는 표시되지 않은 것을 알 수 있다.

도 51은 실시예 5의 알고리즘이 이 경우에 왜 실패하는지를 설명하기 위한 개념도이다. 대전중앙로지하상가는 약 490개의 상점들이 있는 비교적 큰 지하상가이다. 그런데 이 지하상가의 외곽선을 나타내는 도형의 도심(centroid)을 구해보면 이 지하상가의 외곽선 내에 위치하지도 않는다. 그러므로 이 지하상가의 대표 지점은 임의로 대전 중앙로 사거리의 중심과 일치하도록 하였다.

도 51에서 디지털 지도의 뷰 범위(view extent)는 지하상가의 오른쪽 회랑에 치우쳐 있다. 그런데 이 지하상가의 크기와 모양으로 인하여 이 지하상가의 대표 지점(building center)이 뷰 범위(view extent)는 물론이고, 검색 범위(search area)에도 포함되지 않는다. 따라서 목표 지도 매개변수에서 검색 범위가 정해진 다음에 건물 데이터베이스에서 검색하더라도 이 대전중앙로지하상가를 검색할 수 없다. 그러므로 도 50에서 실외 지도만 표시되고, 실내 지도는 표시되지 않은 것이다.

이와 같은 문제점을 해결하기 위한 가장 바람직한 방법은 층(floor)에 더하여 건물의 고유식별번호(unique building identification number), 즉 건물 아이디(building ID) bldID를 지도 매개변수에 포함시키는 것이다. 즉, 지도 매개변수는 지리적인 좌표와 건물 아이디와 층을 포함하며, 디지털 지도의 줌과 회전을 더 포함할 수 있다. 또, 장소의 개념은 지리적인 좌표와 건물 아이디와 층을 포함하는 것으로 한다.

이와 같은 본 발명의 제6 실시예는 웹앱(web app)으로 실행되는 디지털 지도(digital map)의 초기 화면(initial screen)에 보이는 실내·외의 장소(place)를 기기별로 개인화(personalization)하는 방법에 관한 발명으로 시작 지도 매개변수(start map parameters)를 저장하는 단계와 지도 앱을 실행하는 단계로 구성된다.

도 52는 본 발명의 제6 실시예에서 시작 지도 매개변수를 저장하는 알고리즘을 보여주는 순서도이다. 시작 지도 매개변수를 저장하는 단계는 사용자(user)가 지도 앱과의 상호 작용을 통하여 지도 앱의 초기 화면에 보이게 할 장소를 선택하는 단계, 사용자가 선택된 장소를 시작 장소(start place)로 등록하는 메뉴를 실행하는 단계, 지도 앱이 시작 장소에 해당하는 지리적인 좌표(geographic coordinates)와 건물 아이디(building ID) bldID와 층(floor)을 포함하는 지도 매개변수(map parameters)를 기기의 로컬 스토리지(local storage)에 시작 지도 매개변수로 저장하는 단계를 포함한다.

전술한 바와 같이 지도 앱의 초기 화면에 보이게 할 장소(place)를 특정하기 위하여 시작 지도 매개변수에 지리적인 좌표와 건물 아이디(bldID)와 건물 내 층(floor)을 포함시켜야 하고, 디지털 지도의 줌(zoom)과 회전(rotation)도 포함하는 것이 바람직하다. 건물 아이디와 층은 건물이 없는 실외에서는 널(null) 값을 대입하지 않고, 실외라는 사실을 프로그램에게 알려주기 위하여 특별한 숫자를 사용한다. 널 값을 사용하지 않는 이유는 로컬 스토리지에 시작 지도 매개변수를 저장할 때 실수나 정수로 값을 저장하기 위해서이다.

건물 아이디는 1 이상의 자연수(natural number)로 하는 것이 바람직하다. 즉, "bldID = 1,2,3,4,5..."와 같이 1부터 시작하여 순차적으로 번호를 부여하지만, 반드시 연속적인 숫자를 사용할 필요는 없다. 예를 들어 어떤 건물의 주인이 자기 건물의 건물 아이디로 행운의 번호인 777을 고집한다면 그대로 해도 되고, 마찬가지 이유로 4나 13번을 건물 아이디로 사용하지 않아도 된다. 또, 이산 수학(離散數學, discrete mathematics)의 특성상 건물 번호는 0번부터 시작하는 것이 맞지만, 건물 번호가 0번이라고 하면 사용자들에게 정서적인 혼란을 일으킬 수 있으므로 0 대신에 1부터 시작하도록 한다.

건물 아이디에 요구되는 유일한 조건은 모든 건물들의 아이디가 서로 다르다는 조건 하나이다. 따라서 SNS 사이트에 가입할 때 아이디를 정하듯이 건물 아이디를 영문과 숫자를 조합해서 사용할 수도 있다. 즉, 건물 아이디를 'BurjKhalifa0'이라고 하거나 'tallest_building_in_the_world_1'과 같이 지을 수도 있다.

그런데 건물 아이디를 이런 식으로 정하면 건물을 데이터베이스에서 검색하는 데 있어서 불필요하게 시간이 낭비된다. 또, 건물 아이디는 지도 앱에 사용자 로그인(user login)하기 위한 목적이 아니라, 건물 데이터베이스(building database)에 건물들을 등록하여 서로 구분하기 위한 목적이다. 그러므로 가장 단순하게 자연수로 건물 아이디를 정하고, 그 숫자는 시스템(system)이 순차적으로 추천을 해주되, 사용자는 추천된 숫자를 무시하고 자신이 선호하는 숫자를 사용할 수 있도록 하는 것이 바람직하다. 예를 들어 OK벤처타운의 건물 아이디는 1번이고, 대전중앙로지하상가의 건물 아이디는 101번, 대전역전지하상가의 건물 아이디는 102번이다.

모든 실재하는 건물들의 아이디가 1 이상의 자연수이므로, 실외와 같이 건물이 존재하지 않는 장소의 건물 아이디는 -1로 할 수 있다. 즉, 시작 지도 매개변수에 포함된 건물 아이디가 -1이라면, 건물이 없는 장소라는 것을 알 수 있다.

실내의 층은 정수로 주어진다. 실내에 있을 때 1층은 0, 2층은 1, 3층은 2, 지하 1층은 -1, 지하 2층은 -2와 같이 주어진다. 그리고 실외에 있을 때는 층이 0으로 주어진다. 층은 0이지만(floor = 0), 건물 아이디는 -1(bldID = -1)이라면, 건물 내의 1층이 아니라, 실외라는 것을 알 수 있다.

한편, 대전중앙로지하상가는 지면층이 없는 건물이다. 대전 중앙로 사거리에서 대전중앙로지하상가의 지하 1층(B1)을 선택하지 않으면, 디지털 지도에는 대전중앙로지하상가의 실내 지도가 표시되지 않고, 단지 건물의 외곽선만 표시된다. 이때의 층은 무한대(Infinity)로 표시할 수 있다. 무한대는 자바스크립트 문법에서 유효한 숫자(number)로 정의되어 있다. 따라서 건물 아이디가 1 이상의 자연수이고 층이 무한대라면, 그 지리적인 좌표에 건물은 있지만 사용자는 건물 내에 있지 않은 것으로 판단한다. 예를 들어 중앙로 사거리 한복판에 서있는 경우나, 건물의 옥상에 있거나, 낙하산을 타고 건물 위로 착지하려는 경우를 생각할 수 있다.

한편, 지도 앱을 실행하는 단계는 사용자가 지도 앱을 시작하는 단계, 지도 앱이 기기의 로컬 스토리지에 저장된 시작 지도 매개변수가 있는지 확인하는 단계, 저장된 시작 지도 매개변수가 있으면 시작 지도 매개변수를 목표 지도 매개변수(goal map parameters)로 지정하고, 저장된 시작 지도 매개변수가 없으면 기본 지도 매개변수(default map parameters)를 목표 지도 매개변수로 지정하는 단계, 초기 화면에 보이는 장소가 목표 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계를 포함한다.

도 53은 지도 앱의 초기 화면에 보이는 장소가 목표 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계의 알고리즘을 보여주는 순서도이다. 이 단계에서는 먼저, 목표 지도 매개변수에서 시작 지도 영역(start map area)을 결정하고, 뷰(view)에 실외 지도를 표시한다. 다음으로, 사전에 정해진 규칙에 따라서 시작 지도 영역으로부터 검색 범위를 정한다. 검색 범위가 정해지면, 건물의 대표 지점이 검색 범위 안에 위치하는 건물들을 건물 데이터베이스에서 검색하여 뷰 범위 건물 목록(Bld_ID)을 작성한다. 뷰 범위 건물 목록은 건물의 대표 지점이 검색 범위 안에 위치하는 건물들의 건물 아이디(bldID)의 배열(array)이다.

다음으로, 목표 지도 매개변수에 포함된 건물 아이디(goalBldID)가 유효한 건물 아이디인지 조사한다. goalBldID가 -1이면 유효하지 않은 건물 아이디이고, 1 이상의 자연수이면 유효한 건물 아이디이다. goalBldID가 유효한 건물 아이디이면, 이 건물 아이디가 뷰 범위 건물 목록(Bld_ID)에 포함되어 있는지 확인하고, 포함되어 있지 않다면 건물 데이터베이스에서 이 건물 아이디를 갖는 건물을 검색하여 뷰 범위 건물 목록에 추가한다.

다음으로, 뷰 범위 건물 목록으로부터 외곽선 표시 대상 건물 목록(bldIDsToShow)을 작성한다. 외곽선 표시 대상 건물은 뷰 범위 건물 목록에 있는 건물 중에서 외곽선을 표시하기 위한 줌 레벨(zoom level for showing building outline, zoomShowBld)이 디지털 지도의 줌 레벨보다 작은 건물들의 목록이다.

다음으로, 외곽선 표시 대상 건물 목록에 있는 건물들에 대하여 건물 데이터 스토어(building data store)에서 건물 외곽선 도면(building outline drawings)을 가져와서 실외 지도 상의 올바른 위치에 표시한다. 이후에는 실시예 5에서와 동일한 평면도 표시 단계가 수행된다. 이와 같은 방법을 사용하면 도 49에 보이는 장소도 시작 장소로 등록하여 오류없이 동작한다.

제1 내지 제6 실시예의 발명들에 사용된 기술을 사용하면 실외 지도나 실내 지도를 문자 메시지로 보내서 수신인과 공유할 수 있다. 즉, 본 발명의 제7 실시예는 지도 앱(map app)에 보이는 실내·외의 장소(place)를 문자 메시지(text message)로 보내서 수신인(receiver)과 공유(share)하는 방법에 관한 발명이며, 송신인이 문자 메시지를 보내는 단계와 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계로 구성된다.

도 54는 송신인이 문자 메시지를 보내는 단계의 알고리즘을 보여주는 순서도이며, 송신인이 지도 앱과의 상호 작용을 통하여 수신인의 기기에서 웹앱으로 실행되는 지도 앱의 초기 화면에 보이게 할 장소를 선택하는 단계, 송신인이 선택된 장소를 문자 메시지로 보내는 메뉴를 실행하는 단계, 지도 앱이 선택된 장소에 해당하는 지도 매개변수(map parameters)를 검색 문자열(search string)로 포함하는 URL(Uniform Resource Locator)을 포함하는 문자 메시지 몸체(text message body)를 작성하는 단계, 송신인이 수신인을 선택하고 문자 메시지를 발송하는 단계를 포함한다.

수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계는 수신인이 수신된 문자 메시지를 선택하여 웹앱으로 실행되는 지도 앱을 시작하는(launch) 단계, 지도 앱이 URL에 포함된 검색 문자열에서 지도 매개변수를 추출하는(parse) 단계, 지도 앱의 초기 화면에 보이는 장소가 추출된 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계를 포함한다.

선택된 장소에 해당하는 지도 매개변수는 지리적인 좌표(geographic coordinates)와 건물 아이디(building ID)와 층(floor)을 포함하며, 지도 영역(map area)의 줌(zoom)과 회전(rotation)도 포함하는 것이 바람직하다.

건물 아이디(building ID)는 중앙의 건물(building at view center)이 존재하는 경우에는 1 이상의 자연수(natural number)로 주어지고, 중앙의 건물이 존재하지 않는 경우에는 자연수가 아닌 숫자로 주어진다. 예를 들어 -1로 주어질 수 있다.

층(floor)은 중앙의 건물이 존재하지 않는 경우에는 0으로 주어지고, 중앙의 건물이 있고 실내 지도(indoor map)가 표시되는 경우에는 정수(integer)로 주어지며, 중앙의 건물이 존재하지만 실내 지도가 표시되지 않는 경우에는 정수가 아닌 숫자로 주어진다. 예를 들어 Infinity로 주어질 수 있다.

도 55는 URL에 포함된 검색 문자열(window.location.search)에서 지도 매개변수를 추출(parsing)하여 세션 스토리지에 저장하는 자바스크립트 코드이며, 인덱스 페이지(index.html)의 일부이다. 검색 문자열에서 콜론(":")을 모두 앰퍼샌드("&")로 바꾼 뒤, 이 검색 문자열에서 searchParams라는 이름으로 URLSearchParams 객체를 생성한다. 이 객체가 빈 객체("")가 아니라면, 세션 스토리지(window.sessionStorage)를 새로 생성한다. 다음으로, searchParams에서 북향거리(northing), 동향거리(easting), 위도(latitude), 경도(longitude), 줌(zoom), 회전(rotation), 건물 아이디(building ID), 층(floor)을 읽어와서(access and read) 각각 northing, easting, latitude, longitude, zoom, rotation, bldID, floor라는 변수에 저장한다. searchParams에 대응하는 값이 있다면 변수에는 실제 값이 저장되고, 대응되는 값이 없다면 변수는 값이 없는(null) 빈 변수가 된다.

마지막으로 이 8개의 변수로부터 sessionMapParameters라는 이름의 지도 매개변수 객체(mapParameters object)를 생성한 뒤 세션 스토리지에 저장한다. sessionMapParameters를 세션 스토리지에 저장하기 위해서는 먼저 문자열로 변환하여야 한다. 이후에는 기기의 종류와 화면 모드를 판단하여 대응하는 랜딩 페이지가 시작된다.

도 56은 지도 매개변수 객체를 생성하는 자바스크립트 코드이다. 지도 매개변수로 전달된 북향거리, 동향거리, 위도, 경도, 줌, 회전, 건물 아이디와 층은 각각 __northing, __easting, __latitude, __longitude, __zoom, __rotation, __bldID, __floor라는 이름을 가지는 내부 변수에 저장된다. 북향거리와 동향거리가 모두 유효한 값을 가지고 있다면(4행), 북향거리와 동향거리로부터 위도와 경도를 계산하여(6행, 8행) 위치 객체(location object)로 저장한다(10행). 만약 북향거리와 동향거리 중 어느 하나라도 유효한 값을 가지고 있지 않다면, 위도와 경도가 모두 유효한 값을 가지고 있는지 조사한다. 위도와 경도가 모두 유효한 값을 가지고 있다면 이들을 위치 객체로 저장한다(11행). 만약, 위도와 경도 중 어느 하나라도 유효한 값을 가지고 있지 않다면, 위치 객체는 널(null, 없음)로 설정한다(12행). 위치 객체가 널이 아니라면(14행), 줌, 회전, 건물 아이디, 층을 각각 조사하여 값이 있으면 그 값으로 저장하고, 값이 없으면 기본 값을 사용한다(16 ~ 26행).

지도 앱의 초기 화면에 보이는 장소가 추출된 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계는 추출된 지도 매개변수를 세션 스토리지(session storage)에 저장하는 단계, 미디어 쿼리(media query)를 이용하여 기기(device)의 종류(type)와 화면 방향(screen mode)을 결정하는 단계, 기기의 종류와 화면 방향에 맞는 랜딩 페이지(landing page)를 시작하는(launch) 단계, 랜딩 페이지에서 세션 스토리지에 저장된 지도 매개변수를 가져오는 단계, 세션 스토리지에서 가져온 지도 매개변수를 목표 지도 매개변수로 지정하는 단계, 목표 지도 매개변수에 부합하도록 지도 객체(map object)를 설정하는 단계를 포함한다.

이와 같은 방법에 의하여 URL에 포함된 검색 문자열에 북향거리와 동향거리가 포함되어 있거나, 위도와 경도가 포함되어 있다면 그 지리적인 좌표로 지도 앱이 시작된다. 만약 북향거리와 동향거리와 위도와 경도가 모두 포함되어 있다면 북향거리와 동향거리의 값을 사용한다. URL에 지리적인 좌표가 포함되어 있지 않다면, 로컬 스토리지에 저장된 시작 지도 매개변수로 지도 앱이 실행된다. 시작 지도 매개변수도 저장되어 있지 않다면 기본 지도 매개변수로 지도 앱이 실행된다.

건물 아이디와 층이 유효한 값이라면 실내 지도 상에서의 정확한 위치를 알려주며, 그렇지 않다면 실외라고 간주하여 디지털 지도의 초기 화면에 실외 지도만을 표시한다. 줌과 회전이 포함되어 있다면 송신인이 보낸 지도 화면이 수신인의 기기에서 그대로 재현이 되고, 그렇지 않다면 장소만 알려주게 된다.

스마트폰에서 웹앱으로 실행되는 지도 앱을 실행하여 화면에 보이는 장소를 문자 메시지로 보내기 위해서는 최소한 2가지의 외부 환경이 필요하다. 인터넷이 되어야 하고, 문자 메시지가 되어야 한다. 또, 주소가 없거나 위치를 짐작할 수 없는 낯선 곳에서 지리적인 좌표를 문자 메시지로 보내기 위해서는 GPS 센서가 작동해야 한다. GPS 센서는 인공위성으로부터 신호를 받아서 작동하므로 하늘이 보이는 장소에 있어야 하지만, 무선 인터넷이나 전화망과는 상관이 없다.

실내에서 지도 앱의 지도 화면(map screen)에 보이는 실내·외의 장소를 문자 메시지로 보낼 때와는 달리 실외에서는 무선 인터넷이 작동하지 않을 수 있다. 인터넷이 작동하지 않는다면 앱 서버(app server)나 실외 지도 서버(outdoor map server), 건물 데이터베이스(building database), 건물 데이터 스토어(building data store)에 연결할 수 없다. 따라서 웹앱으로 작성된 지도 앱을 이용할 수 없다.

그런데 전술한 바와 같이 비교적 최신 기술인 프로그레시브 웹앱(PWA, Progressive Web App)을 이용하면 인터넷이 안되는 장소에서도 앱(app)을 사용할 수 있다. 구글 크롬(Chrome)으로 PWA로 작성된 웹앱(예를 들어 https://map.digitalearth.land)에 접속하면 PC나 스마트폰에 설치할 수 있는 메뉴 버튼이 나타난다. 설치 버튼을 누르면 앱 서버에서 가져온 소스 파일들이 PC나 스마트폰에 저장되고, 바탕 화면에 아이콘도 나타난다. 도 57에서 스마트폰에 설치된 프로그레시브 웹앱(D.E.map)을 볼 수 있다. 구글 크롬(Chrome)이나 구글 지도, 네이버 지도, 카카오맵은 네이티브 앱(native app)이며, D.E.map(https://map.digitalearth.land)은 PWA이다. 도 57에서 볼 수 있는 바와 같이 네이티브 앱과 프로그레시브 웹앱을 육안으로 구분하기 힘들다.

바탕 화면에 보이는 PWA의 아이콘을 클릭하면 네이티브 앱과 마찬가지로 실행되며, 이미 가져온 파일들은 다시 가져오지 않고, 새로운 파일이 필요할 때만 앱서버에서 해당 파일을 가져오도록 할 수 있다. 매니페스트 파일(manifest.json)에 PC나 스마트폰에 저장할 파일들을 지정한다.

PWA로 작성된 앱이라면 무선 인터넷이 없어도 작동한다. 인터넷이 되는 장소에서 PWA로 된 앱을 실행하면 필요한 소스 파일이나 기타 자료(assets)를 앱 서버에서 가져와서 스마트폰에 저장한다. 다음에 인터넷이 안되는 장소에서 앱을 실행하면 스마트폰에 이미 저장되어 있는 소스를 활용하여 앱이 실행된다.

또, 인터넷이 안되는 곳에서는 실외 지도 서버에 접속할 수 없으므로 실외 지도조차 표시되지 않을 수도 있지만, 지도 앱에서 이미 방문한 적이 있는 지역이라면 해당 지역의 지도 타일(map tiles)도 스마트폰에 저장되어 있을 수 있다. 따라서 인터넷이 안되는 장소에서도 실외 지도가 보일 수 있다. 그리고 깊은 산속에서 조난을 당했더라도 거의 확실하게 GPS 센서는 작동한다. 그리고 무선 인터넷이 안되는 곳에서도 문자 메시지는 되는 경우가 많다. 문자 메시지는 전화 통화와 같은 망(network)을 이용하며, 무선 인터넷과는 별개의 망을 사용한다. 따라서 전화가 되는 지역에 있다면 자신이 조난당한 위치를 모호한 표현으로 구술하기보다는 지도 앱을 이용하여 정확한 지리적인 좌표를 문자 메시지로 보내어 신고할 수 있다. 본 발명의 제8 실시예는 인터넷이 안되고, 실외 지도조차 이용할 수 없는 환경에서 GPS 좌표를 문자 메시지로 보내기 위한 방법에 관한 발명이다.

도 58은 지도 앱의 다양한 메뉴(menu) 중의 일부를 보여주며, '화면을 문자 메시지로 보내기(send screen by text message)' 메뉴 버튼과 '화면의 인터넷 주소 복사하기(copy URL for the screen)' 메뉴 버튼과 'GPS 좌표를 문자 메시지로 보내기(send GPS coordinates by text message)' 메뉴 버튼과 '긴급 연락처 등록하기(register emergency contact information)' 메뉴 버튼과 '긴급 연락처로 문자 메시지 보내기(send emergency text message)' 메뉴 버튼을 볼 수 있다.

도 59는 PWA로 작성된 지도 앱을 실행한 초기 화면을 보여준다. 시험을 위하여 와이 파이(WiFi)와 데이터(data) 사용을 모두 차단하였지만 앱은 정상적으로 실행되는 것을 알 수 있다. 도 59에서는 'GPS 좌표를 문자 메시지로 보내기(send GPS coordinates by text message)' 메뉴 버튼을 선택하였다. 이 메뉴 버튼은 btnSendGPSCoordsBySMS라는 이름을 가지고 있다.

도 60 내지 도 61은 GPS 좌표를 문자 메시지로 보내는 알고리즘을 구현한 자바스크립트 코드의 일부를 보여준다. 도 60에서 'GPS 좌표를 문자 메시지로 보내기' 메뉴 버튼(btnSendGPSCoordsBySMS)에 이벤트 리스너(event listener)가 연결되어 있는 것을 알 수 있다. 메뉴 버튼을 선택(click, tap)하면, 지오로케이션 API(Geolocation API)를 지원하는지 확인한 후, 지원이 되면 GPS 센서로부터 현재 위치를 한번 읽어오는 API를 호출한다.

지오로케이션 API는 인터넷 표준으로 정의되어 있으며, getCurrentPosition(success, error, options)는 GPS 센서를 동작시켜 한번만 좌표를 읽어오는 API이다. 이 API가 성공적으로 수행되었다면 success 함수가 호출되며, 실패하면 error 함수가 호출된다. 옵션(options)은 이 API를 어떻게 호출할지를 정의한다.

도 60에서 옵션(GPSPositionOptions)은 높은 수준의 정밀도로 위치 정보를 가져오고(enableHighAccuracy: true), 브라우저가 현재 위치를 계산하는데 무한정 기다릴 수 있으며(timeout: Infinity), 얻어진 정보는 100ms 이내에서 재사용 가능하다(maximumAge: 100)는 의미이다. 또, 성공적으로 위치 정보를 가져왔으면 sendGPSCoordsBySMS 함수를 실행하고, 실패했으면 onGPSPositionError 함수를 실행한다.

도 61은 sendGPSCoordsBySMS 함수의 소스 코드를 보여준다. 이 함수가 호출되면 _position이라는 내부 이름을 가지는 위치 객체(position object)가 전달된다. 위치 객체는 타임스탬프 객체(timestamp object)와 좌표 객체(coords object)를 가진다. 좌표 객체는 위도(latitude), 경도(longitude), 고도(altitude), 위·경도에 대한 정확도(accuracy), 고도에 대한 정확도(altitudeAccuracy), 기기(device)의 이동 방향(heading), 기기의 이동 속도(speed)라는 속성들(attributes)을 가진다. 따라서 위치 객체로부터 위도와 경도로 구성되는 지리적인 좌표를 얻으려면 다음과 같은 두 줄의 코드가 필요하다.

let GPSLat = _position.coords.latitude;

let GPSLon = _position.coords.longitude;

위치 객체(position object)에서 위도(GPSLat)와 경도(GPSLon)를 읽어온 뒤, 이로부터 북향거리(GPSNorthing)와 동향거리(GPSEasting)를 계산한다. 인터넷이 안되면 지도 영역(map area)이 표시되지 않으므로 줌이나 회전 등의 지도 매개변수의 값은 무의미하다. 따라서 북향거리와 동향거리만을 사용하여 검색 문자열을 작성한다. 그런데 계산된 북향거리와 동향거리는 소수점 이하의 자릿수가 여럿인 실수로 주어지므로, 소수점 이하를 반올림한 값으로 검색 문자열을 작성한다. GPS 센서의 오차는 5m 이상이므로, 소수점 이하의 자릿수는 무의미하기 때문이다. 도 61에서 appHOME은 웹앱의 주소(https://map.digitalearth.land)이다. 나머지 코드는 실시예 7에서와 같다.

도 62는 발명자가 수신인을 자기 자신으로 하여 문자 메시지를 보낸 스마트폰 화면을 보여준다. 한편, 도 63은 다시 와이 파이(WiFi)를 켜고 문자 메시지를 선택하여 지도 앱을 실행한 화면을 보여준다. 와이 파이를 켠 이유는 검색 문자열에 포함된 지리적인 좌표에 해당하는 지도 타일(map tiles)을 가져와야 하기 때문이다.

이와 같이 본 발명의 제8 실시예의 발명은 GPS 좌표를 문자 메시지(text message)로 보내서 수신인(receiver)과 공유(share)하는 방법에 관한 발명이며, 송신인이 문자 메시지를 보내는 단계와 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계로 구성된다.

도 64는 송신인이 문자 메시지를 보내는 단계의 알고리즘을 보여주는 순서도이며, 송신인이 지도 앱을 시작하는 단계, 송신인이 GPS 좌표를 문자 메시지로 보내는 메뉴를 실행하는 단계, 지도 앱이 지오로케이션 API(Geolocation API)를 호출하여 위치 객체(position object)를 획득하는 단계, 지도 앱이 획득된 위치 객체로부터 지리적인 좌표를 읽어오는 단계, 지도 앱이 지리적인 좌표를 검색 문자열(search string)로 포함하는 URL(Uniform Resource Locator)을 포함하는 문자 메시지 몸체(text message body)를 작성하는 단계, 송신인이 수신인을 선택하여 문자 메시지를 발송하는 단계를 포함한다.

수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계는 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 시작하는(launch) 단계, 지도 앱이 URL에 포함된 검색 문자열에서 지리적인 좌표를 추출하는(parse) 단계, 지도 앱의 초기 화면에 보이는 지도 영역(map area)이 지리적인 좌표(geographic coordinates)에 부합하도록 초기 화면을 표시하는 단계를 포함한다.

지도 앱의 초기 화면에 보이는 지도 영역이 지리적인 좌표에 부합하도록 초기 화면을 표시하는 단계는 추출(parsing)된 지리적인 좌표에 줌과 회전의 기본값을 추가한 지도 매개변수(map parameters)를 세션 스토리지(session storage)에 저장하는 단계, 미디어 쿼리(media query)를 이용하여 기기(device)의 종류(type)와 화면 방향(screen mode)을 결정하는 단계, 기기의 종류와 화면 방향에 맞는 랜딩 페이지(landing page)를 시작하는(launch) 단계, 랜딩 페이지에서 세션 스토리지에 저장된 지도 매개변수를 가져오는 단계, 세션 스토리지에서 가져온 지도 매개변수를 목표 지도 매개변수로 지정하는 단계, 목표 지도 매개변수에 부합하도록 지도 객체(map object)를 설정하는 단계를 포함한다.

도 65에 예시한 바와 같이 문자 메시지로 GPS 좌표를 보내는 상황은 아마도 경찰청, 소방청, 외교부 등에 다급히 도움을 요청하는 상황일 것이다. 이 경우에는 문자 메시지를 수신하는 수신인은 개인이 아니라 콜센터(call center) 등이 될 가능성이 크다. 콜센터에서는 스마트폰으로 전화나 문자 메시지를 받지 않을 것이다. 이 경우에 기기(device)는 SMS 센터(SMS center) 또는 SMS 게이트웨이(SMS gateway)에 연결된 PC, 즉 문자 메시지 서버(text message server)가 될 것이다.

여성이나 어린이가 어둡고 인적이 드문 밤거리를 걷다 보면 범죄의 위험에 노출되기 쉽다. 그래서 우범지역에는 인공지능 CCTV와 비상벨을 설치하여 긴급한 순간에 비상벨을 눌러서 도움을 요청하거나, 아니면 "도와주세요"와 같은 구조 요청 신호를 인공지능 SW로 인식하여 자동으로 119와 같은 구조 센터로 연결시키기도 한다. 하지만, 범죄는 우범지역에서만 일어나는 것이 아니라 언제 어디서나 일어날 수 있고, 특히 해외를 여행하다가 위험에 노출되는 경우에는 이와 같은 방법으로는 전혀 대처할 수 없다. 그리고 급박한 순간에는 전화를 걸어서 구조 요청을 하기도 어려울 수 있다.

이와 같은 다양한 상황에 대처하기 위하여 스마트폰에서 버튼 하나만 누르면 즉시 구조 요청 신호가 보내질 수 있다면 바람직할 것이다. 본 발명의 제9 실시예는 문자 메시지(text message)로 사전에 설정된 수신인(receiver)과 GPS 좌표를 공유(share)하는 방법에 관한 발명이며, 송신인이 긴급 연락 정보(emergency contact information)를 등록하는 단계와 문자 메시지를 보내는 단계 및 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계로 구성된다.

도 66은 송신인이 긴급 연락 정보를 등록하는 단계의 알고리즘을 보여주는 순서도이다. 이 단계는 송신인이 지도 앱을 시작하는 단계, 송신인이 긴급 연락 정보를 등록하는 메뉴를 실행하여 긴급 문자 메시지(emergency text message)를 수신할 긴급 연락 전화번호(emergency contact telephone number)를 포함하는 긴급 연락 정보를 입력하는 단계, 지도 앱이 긴급 연락 정보를 기기의 로컬 스토리지에 저장하는 단계를 포함한다. 도 58에 보이는 '긴급 연락처 등록하기(register emergency contact information)' 메뉴 버튼을 선택하면 긴급 연락 정보를 등록하는 화면이 나타난다.

도 67은 긴급 연락 정보를 등록하는 스마트폰 화면의 예이며, 도 68은 긴급 연락 전화번호로 발명자 자신의 스마트폰 전화번호를 입력한 화면을 보여준다. 여기서 사용자 이름(user name)과 긴급 연락 전화번호(phone no. to send emergency text message)는 반드시 입력하여야 하는 필드(field)이며, 나머지는 선택적으로 입력할 수 있는 필드이다. 긴급 연락 정보를 입력하고 저장(save) 버튼을 누르면 사용자 이름과 긴급 연락 전화번호를 포함하는 긴급 연락 정보를 스마트폰의 로컬 스토리지(local storage)에 저장한다.

송신인이 문자 메시지를 보내는 단계는 송신인이 지도 앱을 시작하는 단계, 송신인이 GPS 좌표를 문자 메시지로 보내는 메뉴를 실행하는 단계, 지도 앱이 지오로케이션 API(Geolocation API)를 호출하여 위치 객체(position object)를 획득하는 단계, 지도 앱이 위치 객체로부터 지리적인 좌표(geographic coordinates)를 읽어오는 단계, 지도 앱이 지리적인 좌표를 검색 문자열(search string)로 포함하는 URL(Uniform Resource Locator)을 포함하는 문자 메시지 몸체(text message body)를 작성하는 단계, 지도 앱이 사전에 등록된 긴급 연락 전화번호로 문자 메시지를 발송하는 단계를 포함한다. 송신인이 도 58에 보이는 '긴급 연락처로 문자 메시지 보내기(send emergency text message)' 메뉴 버튼을 선택하면 긴급 문자 메시지를 보낼 수 있다.

도 69는 긴급 문자 메시지를 작성하여 발송하는 자바스크립트 코드를 보여준다. 3행에서 로컬 스토리지에 저장된 사용자 이름(userName)을 가져오며, 5행과 7행에서는 미리 작성된 메시지(message)와 긴급 문자 메시지를 보낼 전화번호(phone)를 가져온다. 9행과 11행에서는 위치 객체(position object) _position에서 위도(GPSLat)와 경도(GPSLon)를 읽어오고, 13행과 15행에서는 위도와 경도로부터 북향거리(GPSNorthing)와 동향거리(GPSEasting)를 계산한다. 18행 내지 19행에서는 문자 메시지 몸체(text message body)를 작성한다. 이 문자 메시지 몸체에는 지리적인 좌표(GPSNorthing, GPSEasting)를 검색 문자열(search string)로 포함하는 URL과 사용자 이름(userName) 및 사전에 작성된 메시지(message)가 포함된다. 21행에서 linkSMS라는 이름으로 앵커(angker) 요소를 생성하고, 23행에서 문서(document)에 부착하며, 25행에서 문자 메시지를 보낼 수 있도록 linkSMS의 href 속성을 작성한 후, 27행에서 이 linkSMS를 프로그램적으로 클릭(click)하여 문자 메시지를 발송한다.

도 70은 이와 같은 방법으로 발송된 긴급 문자 메시지를 보여준다. 이 문자 메시지에는 구조 대상자의 최소한의 인적 사항과 상황에 맞게 미리 작성된 메시지 및 구조 대상자의 위치를 지도상에서 확인할 수 있는 인터넷 링크가 포함되어 있다.

수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계는 수신인이 수신된 문자 메시지에 포함된 URL을 선택하여 웹앱으로 실행되는 지도 앱을 시작하는 단계, 지도 앱이 URL에 포함된 검색 문자열에서 지리적인 좌표(geographic coordinates)를 추출(parsing)하는 단계, 지도 앱의 초기 화면에 보이는 지도 영역(map area)이 지리적인 좌표에 부합하도록 초기 화면을 표시하는 단계를 포함한다.

본 발명의 제9 실시예의 발명을 이용하면 위급 상황에서 최소한의 노력으로 신속하게 구조 요청을 할 수 있다. 예를 들어 지도 앱을 시작하고, '긴급 연락처로 문자 메시지 보내기(send emergency text message)' 버튼을 클릭하고, 문자 메시지 창에서 확인(confirm) 버튼을 누르는 것만으로 구조 요청을 할 수 있다. 또, 북극이나 남극, 사하라 사막과 같이 지구상 어디에 있더라도 전화만 되는 지역에 있다면 이 지도 앱을 이용하여 구조 요청을 할 수 있으며, 무선 인터넷이 필요하지 않다.

긴급 연락 정보를 등록하는 단계에서는 스마트폰 소지자, 즉 구조 대상자의 이름, 구조 대상자의 신원 확인을 위한 주민등록번호나 여권번호와 같은 개인 식별 번호, 구조 당국의 전화번호, 구조 단계에서 구조 당국이 필요한 정보를 얻을 수 있는 가족이나 지인의 이름과 전화번호, 그리고 필요한 경우 구조 당국에서 구조 대상자의 개인 정보를 조회하는 것에 동의하는지 여부 등을 등록할 수 있다.

긴급 문자 메시지를 보낼 구조 당국은 119, 경찰청, 소방청, 각국 대사관 등 상황에 따라 다를 수 있다. 예를 들어 공부를 하고 늦은 밤에 귀가하는 여고생은 거주 지역의 경찰서의 전화번호를 등록해 놓으면 좋을 것이다. 오로라를 구경하러 핀란드에 가는 여행자는 핀란드에 있는 한국 대사관의 전화번호를 미리 등록하고 가면 좋을 것이다. 또, 긴급 연락 정보를 기기의 로컬 스토리지에 저장하는 이외에 앱 서버에도 저장하면 만일의 사태에 더 유연하게 대처할 수 있을 것이다.

때로는 지도 앱을 시작하여(launch) 메뉴 버튼을 누르는 간단한 동작도 할 수 없는 경우가 있다. 예를 들어 절벽을 등반하다가 실족하여 산 아래로 떨어지는 경우, 길을 걷다가 갑자기 교통사고를 당하는 경우 등이다. 또한, 노인이나 환자들이 낙상 사고를 당하는 경우도 마찬가지이다.

이와 같은 경우에는 지도 앱이 자동적으로 구조 요청 신호를 보낼 수 있다면, 구조 대상자가 직접 구조 요청 신호를 보낼 수 없는 경우에 도움이 될 것이다. 이와 같은 일을 가능하게 하기 위한 가장 적절한 방법은 앱이 백그라운드(background)에서 실행되게 하는 것이다. 예를 들어 아이폰(iPhone)의 시리(Siri)가 한 예이다. 마이크로소프트 윈도우(Microsoft Window)에서도 앱이 백그라운드에서 실행되도록 설정할 수 있다. 즉, 지도 앱을 일부러 시작하지 않더라도 스마트폰이 켜있는 상태에서 지도 앱이 최소한의 스마트폰 자원을 소모하면서 대기하고 있다가, 구조 요청 신호를 발송할 조건이 충족되면 자동적으로 구조 요청 신호를 사전에 등록된 구조 기관이나 지인에게 보낼 수 있을 것이다.

본 발명의 제10 실시예는 자동적으로 발송되는 문자 메시지(text message)로 사전에 설정된 수신인(receiver)과 GPS 좌표를 공유(share)하는 방법에 관한 방법이며, 사용자가 긴급 연락 정보(emergency contact information)를 등록하는 단계와 지도 앱이 자동적으로 문자 메시지를 보내는 단계 및 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계로 구성된다.

사용자가 긴급 연락 정보를 등록하는 단계는 사용자가 지도 앱을 시작하는 단계, 사용자가 긴급 연락 정보를 등록하는 메뉴를 실행하여 긴급 문자 메시지(emergency text message)를 수신할 긴급 연락 전화번호(emergency contact telephone number)를 포함하는 긴급 연락 정보를 입력하는 단계, 지도 앱이 긴급 연락 정보를 기기의 로컬 스토리지에 저장하는 단계를 포함하며, 실시예 9에서 긴급 연락 정보를 등록하는 단계와 사실상 동일하다.

다만, 제10 실시예에서는 지도 앱이 긴급 문자 메시지를 발송하는 조건을 개인화할 수 있다면 바람직할 것이다. 예를 들어 본인의 목소리로 "도와주세요"라고 외치는 경우에 긴급 문자 메시지가 발송되도록 한다든지, 바탕 화면의 앱 아이콘을 3초 이내에 3번을 두드리면(tap) 긴급 문자 메시지가 발송되도록 한다든지 하는 시나리오를 생각할 수 있다. 기본적으로 설정되는 조건으로는 스마트폰에 일정 이상의 충격이 가해진다든지, 일정 이상의 굉음이 발생하는 경우 등을 생각할 수 있다. 긴급 문자 메시지가 발송되는 조건은 이 중에 택일을 해야만 하는 것이 아니라, 하나 이상을 선택할 수 있도록 하는 것이 바람직할 것이다.

도 71은 본 발명의 제10 실시예에서 자동적으로 문자 메시지를 발송하는 단계의 알고리즘을 보여주는 순서도이다. 지도 앱이 자동적으로 문자 메시지를 보내는 단계는 지도 앱이 백그라운드(background)에서 실행되며 자동적으로 긴급 문자 메시지를 발송할 조건이 충족되는지 모니터링(monitoring)하는 단계, 자동적으로 긴급 문자 메시지를 발송할 조건이 충족되면 지도 앱이 지오로케이션 API(Geolocation API)를 호출하여 위치 객체(position object)를 획득하는 단계, 지도 앱이 위치 객체로부터 지리적인 좌표(geographic coordinates)를 읽어오는 단계, 지도 앱이 지리적인 좌표를 검색 문자열(search string)로 포함하는 URL(Uniform Resource Locator)을 포함하는 문자 메시지 몸체(text message body)를 작성하는 단계, 지도 앱이 사전에 등록된 긴급 연락 전화번호로 문자 메시지를 발송하는 단계를 포함한다.

수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계는 수신인이 수신된 문자 메시지를 선택하여 웹앱으로 실행되는 지도 앱을 시작하는 단계, 지도 앱이 URL에 포함된 검색 문자열에서 지리적인 좌표를 추출하는(parse) 단계, 지도 앱의 초기 화면에 보이는 지도 영역(map area)이 지리적인 좌표에 부합하도록 초기 화면을 표시하는 단계를 포함한다.

주소나 지리적인 좌표를 불러주는 대신에 간단한 방법으로 수신인에게 문자 메시지를 보내서 디지털 지도로 위치를 공유할 수 있다. 이는 방문객에게 찾아올 위치를 알려주거나, 배달원에게 배송지를 알려주는데 사용할 수도 있고, 119, 경찰청, 소방청 등이 구조·탐색 작전(search & rescue mission)을 하는데 사용할 수도 있다.

N: 북향거리
E: 동향거리
φ: 측지 위도
λ: 경도
R: 지구의 평균 반경

Claims (49)

1. 웹앱(web app)으로 실행되는 지도 앱(map app)의 초기 화면(initial screen)에 보이는 지도 영역(map area)을 기기(device)별로 개인화(personalization)하는 방법에 있어서,
   시작 지도 매개변수(start map parameters)를 저장하는 단계와 지도 앱을 실행하는 단계로 구성되되,
   시작 지도 매개변수를 저장하는 단계는;
   사용자(user)가 지도 앱과의 상호 작용을 통하여 지도 앱의 초기 화면에 보이게 할 지도 영역을 선택하는 단계,
   선택된 지도 영역을 시작 지도 영역(start map area)으로 등록하는 메뉴를 실행하는 단계,
   지도 앱이 시작 지도 영역에 해당하는 지리적인 좌표(geographic coordinates)와 줌(zoom)과 회전(rotation)을 포함하는 지도 매개변수(map parameters)를 기기의 로컬 스토리지(local storage)에 시작 지도 매개변수로 저장하는 단계를 포함하고,
   지도 앱을 실행하는 단계는;
   사용자가 지도 앱을 시작하는 단계,
   지도 앱이 기기의 로컬 스토리지에 저장된 시작 지도 매개변수가 있는지 확인하는 단계,
   저장된 시작 지도 매개변수가 있으면 시작 지도 매개변수를 목표 지도 매개변수(goal map parameters)로 지정하고, 저장된 시작 지도 매개변수가 없으면 기본 지도 매개변수(default map parameters)를 목표 지도 매개변수로 지정하는 단계,
   지도 앱의 초기 화면에 보이는 지도 영역이 목표 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계를 포함하는 것을 특징으로 하는,
   웹앱으로 실행되는 지도 앱의 초기 화면에 보이는 지도 영역을 기기별로 개인화하는 방법.
   
2. 제1항에 있어서,
   시작 지도 영역에 해당하는 지리적인 좌표는 경도(longitude)와 측지 위도(geodetic latitude)의 쌍(pair)으로 주어지는 것을 특징으로 하는,
   웹앱으로 실행되는 지도 앱의 초기 화면에 보이는 지도 영역을 기기별로 개인화하는 방법.
   
3. 제1항에 있어서,
   시작 지도 영역에 해당하는 지리적인 좌표는 경도(longitude) 및 측지 위도(geodetic latitude)의 쌍(pair)과 상호변환이 가능한 동향거리(easting)와 북향거리(northing)의 쌍으로 주어지는 것을 특징으로 하는,
   웹앱으로 실행되는 지도 앱의 초기 화면에 보이는 지도 영역을 기기별로 개인화하는 방법.
   
4. 제3항에 있어서,
   북향거리(northing) N은 다음과 같이 주어지되,
   

   

   
   여기서 R은 지구의 평균 반경이고, φ는 측지 위도이며,
   동향거리(easting) E는 다음과 같이 주어지되,
   

   

   
   여기서 λ는 경도인 것을 특징으로 하는,
   웹앱으로 실행되는 지도 앱의 초기 화면에 보이는 지도 영역을 기기별로 개인화하는 방법.
   
5. 제1항에 있어서,
   시작 지도 매개변수를 저장하는 단계는;
   앱 서버(app server)에 사용자 로그인(user login)이 되어 있는지 확인하는 단계,
   사용자 로그인이 되어 있으면 시작 지도 매개변수를 앱 서버에 저장하는 단계를 포함하고,
   지도 앱을 실행하는 단계는;
   앱 서버에 사용자 로그인이 되어 있는지 확인하는 단계,
   사용자 로그인이 되어 있으면 앱 서버에 저장된 시작 지도 매개변수가 있는지 확인하는 단계,
   앱 서버에 저장된 시작 지도 매개변수가 있으면 앱 서버에 저장된 시작 지도 매개변수를 우선적으로 목표 지도 매개변수로 지정하는 단계를 포함하는 것을 특징으로 하는,
   웹앱으로 실행되는 지도 앱의 초기 화면에 보이는 지도 영역을 기기별로 개인화하는 방법.
   
6. 웹앱(web app)으로 실행되는 지도 앱(map app)에 보이는 지도 영역(map area)을 문자 메시지(text message)로 보내서 수신인(receiver)과 공유(share)하는 방법에 있어서,
   송신인(sender)이 문자 메시지를 보내는 단계와 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계로 구성되되,
   송신인이 문자 메시지를 보내는 단계는;
   송신인이 지도 앱과의 상호 작용을 통하여 수신인의 기기(device)에서 웹앱으로 실행되는 지도 앱의 초기 화면에 보이게 할 지도 영역을 선택하는 단계,
   송신인이 선택된 지도 영역을 문자 메시지로 보내는 메뉴를 실행하는 단계,
   지도 앱이 선택된 지도 영역에 해당하는 지리적인 좌표(geographic coordinates)와 줌(zoom)과 회전(rotation)을 포함하는 지도 매개변수(map parameters)를 검색 문자열(search string)로 포함하는 URL(Uniform Resource Locator)을 포함하는 문자 메시지 몸체(text message body)를 작성하는 단계,
   송신인이 수신인을 선택하여 문자 메시지를 발송하는 단계를 포함하고,
   수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계는;
   수신인이 수신된 문자 메시지를 선택하여 지도 앱을 시작(launch)하는 단계,
   지도 앱이 URL에 포함된 검색 문자열에서 지도 매개변수를 추출하는(parse) 단계,
   지도 앱의 초기 화면에 보이는 지도 영역이 추출된 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계를 포함하되,
   지도 앱의 초기 화면에 보이는 지도 영역이 추출된 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계는;
   추출된 지도 매개변수를 세션 스토리지(session storage)에 저장하는 단계,
   미디어 쿼리(media query)를 이용하여 기기(device)의 종류(type)와 화면 방향(screen mode)을 결정하는 단계,
   기기의 종류와 화면 방향에 맞는 랜딩 페이지(landing page)를 시작하는(launch) 단계,
   랜딩 페이지에서 세션 스토리지에 저장된 지도 매개변수를 가져오는 단계,
   세션 스토리지에서 가져온 지도 매개변수를 목표 지도 매개변수로 저장하는 단계,
   목표 지도 매개변수에 부합하도록 지도 객체(map object)를 설정하는 단계를 포함하는 것을 특징으로 하는,
   웹앱으로 실행되는 지도 앱에 보이는 지도 영역을 문자 메시지로 보내서 수신인과 공유하는 방법.
   
7. 제6항에 있어서,
   선택된 지도 영역에 해당하는 지리적인 좌표는 경도(longitude)와 측지 위도(geodetic latitude)의 쌍으로 주어지는 것을 특징으로 하는,
   웹앱으로 실행되는 지도 앱에 보이는 지도 영역을 문자 메시지로 보내서 수신인과 공유하는 방법.
   
8. 제6항에 있어서,
   선택된 지도 영역에 해당하는 지리적인 좌표는 경도(longitude) 및 측지 위도(geodetic latitude)의 쌍과 상호변환이 가능한 동향거리(easting)와 북향거리(northing)의 쌍으로 주어지는 것을 특징으로 하는,
   웹앱으로 실행되는 지도 앱에 보이는 지도 영역을 문자 메시지로 보내서 수신인과 공유하는 방법.
   
9. 제8항에 있어서,
   북향거리(northing) N은 다음과 같이 주어지되,
   

   

   
   여기서 R은 지구의 평균 반경이고, φ는 측지 위도이며,
   동향거리(easting) E는 다음과 같이 주어지되,
   

   

   
   여기서 λ는 경도인 것을 특징으로 하는,
   웹앱으로 실행되는 지도 앱에 보이는 지도 영역을 문자 메시지로 보내서 수신인과 공유하는 방법.
   
10. 제6항에 있어서,
    지도 앱은 프로그레시브 웹앱(PWA, Progressive Web App)인 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 지도 영역을 문자 메시지로 보내서 수신인과 공유하는 방법.
    
11. 삭제
12. 웹앱(web app)으로 실행되는 지도 앱(map app)에 보이는 실내·외의 장소(place)를 기기(device)별로 개인화(personalization)하는 방법에 있어서,
    시작 지도 매개변수(start map parameters)를 저장하는 단계와 지도 앱을 실행하는 단계로 구성되되,
    시작 지도 매개변수를 저장하는 단계는;
    사용자(user)가 지도 앱과의 상호 작용을 통하여 지도 앱의 초기 화면에 보이게 할 장소를 선택하는 단계,
    사용자가 선택된 장소를 시작 장소(start place)로 등록하는 메뉴를 실행하는 단계,
    지도 앱이 시작 장소에 해당하는 지도 매개변수(map parameters)를 기기의 로컬 스토리지(local storage)에 시작 지도 매개변수로 저장하는 단계를 포함하고,
    지도 앱을 실행하는 단계는;
    사용자가 지도 앱을 시작하는 단계,
    지도 앱이 기기의 로컬 스토리지에 저장된 시작 지도 매개변수가 있는지 확인하는 단계,
    저장된 시작 지도 매개변수가 있으면 시작 지도 매개변수를 목표 지도 매개변수(goal map parameters)로 지정하고, 저장된 시작 지도 매개변수가 없으면 기본 지도 매개변수(default map parameters)를 목표 지도 매개변수로 지정하는 단계,
    초기 화면에 보이는 장소가 목표 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계를 포함하는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 기기별로 개인화하는 방법.
    
13. 제12항에 있어서,
    시작 장소에 해당하는 지도 매개변수(map parameters)는 지리적인 좌표(geographic coordinates)와 건물 아이디(building ID)와 층(floor)을 포함하는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 기기별로 개인화하는 방법.
    
14. 제13항에 있어서,
    시작 장소에 해당하는 지도 매개변수는 지도 앱의 초기 화면에 보이게 할 지도 영역(map area)의 줌(zoom)과 회전(rotation)을 포함하는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 기기별로 개인화하는 방법.
    
15. 제13항에 있어서,
    지리적인 좌표(geographic coordinates)는 경도(longitude)와 측지 위도(geodetic latitude)의 쌍(pair)이나 경도 및 측지 위도의 쌍과 상호변환되는 동향거리(easting)와 북향거리(northing)의 쌍 중 어느 하나로 주어지는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 기기별로 개인화하는 방법.
    
16. 제15항에 있어서,
    북향거리(northing) N은 다음과 같이 주어지되,
    

    

    
    여기서 R은 지구의 평균 반경이고, φ는 측지 위도이며,
    동향거리(easting) E는 다음과 같이 주어지되,
    

    

    
    여기서 λ는 경도인 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 기기별로 개인화하는 방법.
    
17. 웹앱(web app)으로 실행되는 지도 앱(map app)에 보이는 실내·외의 장소(place)를 문자 메시지(text message)로 보내서 수신인(receiver)과 공유(share)하는 방법에 있어서,
    송신인(sender)이 문자 메시지를 보내는 단계와 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계로 구성되되,
    송신인이 문자 메시지를 보내는 단계는;
    송신인이 지도 앱을 시작하는 단계,
    송신인이 지도 앱과의 상호 작용을 통하여 수신인의 기기(device)에서 웹앱으로 실행되는 지도 앱의 초기 화면에 보이게 할 장소(place)를 선택하는 단계,
    송신인이 선택된 장소를 문자 메시지로 보내는 메뉴를 실행하는 단계,
    지도 앱이 선택된 장소에 해당하는 지도 매개변수(map parameters)를 검색 문자열(search string)로 포함하는 URL(Uniform Resource Locator)을 포함하는 문자 메시지 몸체(text message body)를 작성하는 단계,
    송신인이 수신인을 선택하여 문자 메시지를 발송하는 단계를 포함하고,
    수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계는;
    수신인이 수신된 문자 메시지를 선택하여 지도 앱을 시작(launch)하는 단계,
    지도 앱이 URL에 포함된 검색 문자열에서 지도 매개변수를 추출하는(parse) 단계,
    지도 앱의 초기 화면에 보이는 장소가 추출된 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계를 포함하는 것을 특징으로 하되,
    선택된 장소에 해당하는 지도 매개변수는 지리적인 좌표(geographic coordinates)와 건물 아이디(building ID)와 층(floor)을 포함하는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 문자 메시지로 보내서 수신인과 공유하는 방법.
    
18. 제17항에 있어서,
    지도 앱의 지도 화면(map screen)에 중심 마커(center marker)를 구비하는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 문자 메시지로 보내서 수신인과 공유하는 방법.
    
19. 삭제
20. 제17항에 있어서,
    선택된 장소에 해당하는 지도 매개변수는 지도 앱의 초기 화면에 보이게 할 지도 영역(map area)의 줌(zoom)과 회전(rotation)을 포함하는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 문자 메시지로 보내서 수신인과 공유하는 방법.
    
21. 제17항에 있어서,
    지리적인 좌표는 경도(longitude)와 측지 위도(geodetic latitude)의 쌍으로 주어지는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 문자 메시지로 보내서 수신인과 공유하는 방법.
    
22. 제17항에 있어서,
    지리적인 좌표는 경도(longitude) 및 측지 위도(geodetic latitude)의 쌍과 상호변환이 가능한 동향거리(easting)와 북향거리(northing)의 쌍으로 주어지는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 문자 메시지로 보내서 수신인과 공유하는 방법.
    
23. 제22항에 있어서,
    북향거리(northing) N은 다음과 같이 주어지되,
    

    

    
    여기서 R은 지구의 평균 반경이고, φ는 측지 위도이며,
    동향거리(easting) E는 다음과 같이 주어지되,
    

    

    
    여기서 λ는 경도인 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 문자 메시지로 보내서 수신인과 공유하는 방법.
    
24. 제17항에 있어서,
    건물 아이디(building ID)는 뷰의 중심(view center)이 건물의 외곽선 안에 위치하는 건물 - 이하, 중앙의 건물(building at view center)이라 지칭함 - 이 존재하는 경우에는 자연수(natural number)로 주어지고,
    중앙의 건물이 존재하지 않는 경우에는 자연수가 아닌 수(number)로 주어지는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 문자 메시지로 보내서 수신인과 공유하는 방법.
    
25. 제17항에 있어서,
    층(floor)은 뷰의 중심(view center)이 건물의 외곽선 안에 위치하는 건물 - 이하, 중앙의 건물(building at view center)이라 지칭함 - 이 존재하지 않는 경우에는 0으로 주어지고,
    중앙의 건물이 있고 실내 지도(indoor map)가 표시된 경우에는 정수(integer)로 주어지며,
    중앙의 건물이 존재하지만 실내 지도가 표시되지 않는 경우에는 정수가 아닌 수(number)로 주어지는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 문자 메시지로 보내서 수신인과 공유하는 방법.
    
26. 제17항에 있어서,
    지도 앱은 프로그레시브 웹앱(PWA, Progressive Web App)인 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 문자 메시지로 보내서 수신인과 공유하는 방법.
    
27. 제17항에 있어서,
    지도 앱의 초기 화면에 보이는 장소가 추출된 지도 매개변수에 부합하도록 초기 화면을 표시하는 단계는,
    추출된 지도 매개변수를 세션 스토리지(session storage)에 저장하는 단계,
    미디어 쿼리(media query)를 이용하여 기기(device)의 종류(type)와 화면 방향(screen mode)을 결정하는 단계,
    기기의 종류와 화면 방향에 맞는 랜딩 페이지(landing page)를 시작(launch)하는 단계,
    랜딩 페이지에서 세션 스토리지에 저장된 지도 매개변수를 가져오는 단계,
    세션 스토리지에서 가져온 지도 매개변수를 목표 지도 매개변수로 지정하는 단계,
    목표 지도 매개변수에 부합하도록 지도 객체(map object)를 설정하는 단계를 포함하는 것을 특징으로 하는,
    웹앱으로 실행되는 지도 앱에 보이는 실내·외의 장소를 문자 메시지로 보내서 수신인과 공유하는 방법.
    
28. 문자 메시지(text message)로 GPS 좌표를 공유(share)하는 방법에 있어서,
    송신인이 문자 메시지를 보내는 단계와 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계로 구성되되,
    송신인이 문자 메시지를 보내는 단계는;
    송신인이 지도 앱을 시작하는 단계,
    송신인이 GPS 좌표를 문자 메시지로 보내는 메뉴를 실행하는 단계,
    지도 앱이 지오로케이션 API(Geolocation API)를 호출하여 위치 객체(position object)를 획득하는 단계,
    지도 앱이 위치 객체로부터 지리적인 좌표(geographic coordinates)를 읽어오는 단계,
    지도 앱이 지리적인 좌표를 검색 문자열(search string)로 포함하는 URL(Uniform Resource Locator)을 포함하는 문자 메시지 몸체(text message body)를 작성하는 단계,
    송신인이 수신인을 선택하여 문자 메시지를 발송하는 단계를 포함하고,
    수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계는;
    수신인이 수신된 문자 메시지를 선택하여 웹앱으로 실행되는 지도 앱을 시작하는(launch) 단계,
    지도 앱이 URL에 포함된 검색 문자열에서 지리적인 좌표를 추출하는(parse) 단계,
    지도 앱의 초기 화면에 보이는 지도 영역(map area)이 지리적인 좌표에 부합하도록 초기 화면을 표시하는 단계를 포함하는 것을 특징으로 하되,
    지도 앱의 초기 화면에 보이는 지도 영역이 지리적인 좌표에 부합하도록 초기 화면을 표시하는 단계는;
    지리적인 좌표에 줌과 회전의 기본값을 추가한 지도 매개변수를 세션 스토리지(session storage)에 저장하는 단계,
    랜딩 페이지에서 세션 스토리지에 저장된 지도 매개변수를 가져오는 단계,
    세션 스토리지에서 가져온 지도 매개변수를 목표 지도 매개변수로 저장하는 단계,
    목표 지도 매개변수에 부합하도록 지도 객체(map object)를 설정하는 단계를 포함하는 것을 특징으로 하는,
    문자 메시지로 GPS 좌표를 공유하는 방법.
    
29. 제28항에 있어서,
    지리적인 좌표는 경도(longitude)와 측지 위도(geodetic latitude)의 쌍으로 주어지는 것을 특징으로 하는,
    문자 메시지로 GPS 좌표를 공유하는 방법.
    
30. 제28항에 있어서,
    지리적인 좌표는 경도(longitude) 및 측지 위도(geodetic latitude)의 쌍과 상호변환이 가능한 동향거리(easting)와 북향거리(northing)의 쌍으로 주어지는 것을 특징으로 하는,
    문자 메시지로 GPS 좌표를 공유하는 방법.
    
31. 제30항에 있어서,
    북향거리(northing) N은 다음과 같이 주어지되,
    

    

    
    여기서 R은 지구의 평균 반경이고, φ는 측지 위도이며,
    동향거리(easting) E는 다음과 같이 주어지되,
    

    

    
    여기서 λ는 경도인 것을 특징으로 하는,
    문자 메시지로 GPS 좌표를 공유하는 방법.
    
32. 제28항에 있어서,
    지도 앱은 프로그레시브 웹앱(PWA, Progressive Web App)인 것을 특징으로 하는,
    문자 메시지로 GPS 좌표를 공유하는 방법.
    
33. 제28항에 있어서,
    지도 앱의 초기 화면에 보이는 지도 영역이 지리적인 좌표에 부합하도록 초기 화면을 표시하는 단계는;
    미디어 쿼리(media query)를 이용하여 기기(device)의 종류(type)와 화면 방향(screen mode)을 결정하는 단계,
    기기의 종류와 화면 방향에 맞는 랜딩 페이지(landing page)를 시작하는(launch) 단계를 포함하는 것을 특징으로 하는,
    문자 메시지로 GPS 좌표를 공유하는 방법.
    
34. 제28항에 있어서,
    기기(device)는 스마트폰(smart phone)과 문자 메시지 서버(text message server) 중 어느 하나인 것을 특징으로 하는,
    문자 메시지로 GPS 좌표를 공유하는 방법.
    
35. 문자 메시지(text message)로 사전에 등록된 수신인(receiver)과 GPS 좌표를 공유(share)하는 방법에 있어서,
    송신인이 긴급 연락 정보(emergency contact information)를 등록하는 단계와 송신인이 문자 메시지를 보내는 단계 및 수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계로 구성되되,
    송신인이 긴급 연락 정보를 등록하는 단계는;
    송신인이 지도 앱을 시작하는 단계,
    송신인이 긴급 연락 정보를 등록하는 메뉴를 실행하여 긴급 문자 메시지(emergency text message)를 수신할 긴급 연락 전화번호(emergency contact telephone number)를 포함하는 긴급 연락 정보를 입력하는 단계,
    지도 앱이 긴급 연락 정보를 기기(device)의 로컬 스토리지에 저장하는 단계를 포함하고,
    송신인이 문자 메시지를 보내는 단계는;
    송신인이 지도 앱을 시작하는 단계,
    송신인이 GPS 좌표를 문자 메시지로 보내는 메뉴를 실행하는 단계,
    지도 앱이 지오로케이션 API(Geolocation API)를 호출하여 위치 객체(position object)를 획득하는 단계,
    지도 앱이 위치 객체로부터 지리적인 좌표(geographic coordinates)를 읽어오는 단계,
    지도 앱이 지리적인 좌표를 검색 문자열(search string)로 포함하는 URL(Uniform Resource Locator)을 포함하는 문자 메시지 몸체(text message body)를 작성하는 단계,
    지도 앱이 사전에 등록된 긴급 연락 전화번호로 문자 메시지를 발송하는 단계를 포함하고,
    수신인이 수신된 문자 메시지를 선택하여 지도 앱을 실행하는 단계는;
    수신인이 수신된 문자 메시지를 선택하여 웹앱으로 실행되는 지도 앱을 시작하는(launch) 단계,
    지도 앱이 URL에 포함된 검색 문자열에서 지리적인 좌표를 추출하는(parse) 단계,
    지도 앱의 초기 화면에 보이는 지도 영역(map area)이 지리적인 좌표에 부합하도록 초기 화면을 표시하는 단계를 포함하되,
    지도 앱의 초기 화면에 보이는 지도 영역이 지리적인 좌표에 부합하도록 초기 화면을 표시하는 단계는;
    지리적인 좌표에 줌과 회전의 기본값을 추가한 지도 매개변수를 세션 스토리지(session storage)에 저장하는 단계,
    랜딩 페이지에서 세션 스토리지에 저장된 지도 매개변수를 가져오는 단계,
    세션 스토리지에서 가져온 지도 매개변수를 목표 지도 매개변수로 지정하는 단계,
    목표 지도 매개변수에 부합하도록 지도 객체(map object)를 설정하는 단계를 포함하는 것을 특징으로 하는,
    문자 메시지로 사전에 등록된 수신인과 GPS 좌표를 공유하는 방법.
    
36. 제35항에 있어서,
    지리적인 좌표는 경도(longitude)와 측지 위도(geodetic latitude)의 쌍으로 주어지는 것을 특징으로 하는,
    문자 메시지로 사전에 등록된 수신인과 GPS 좌표를 공유하는 방법.
    
37. 제35항에 있어서,
    지리적인 좌표는 경도(longitude) 및 측지 위도(geodetic latitude)의 쌍과 상호변환이 가능한 동향거리(easting)와 북향거리(northing)의 쌍으로 주어지는 것을 특징으로 하는,
    문자 메시지로 사전에 등록된 수신인과 GPS 좌표를 공유하는 방법.
    
38. 제37항에 있어서,
    북향거리(northing) N은 다음과 같이 주어지되,
    

    

    
    여기서 R은 지구의 평균 반경이고, φ는 측지 위도이며,
    동향거리(easting) E는 다음과 같이 주어지되,
    

    

    
    여기서 λ는 경도인 것을 특징으로 하는,
    문자 메시지로 사전에 등록된 수신인과 GPS 좌표를 공유하는 방법.
    
39. 제35항에 있어서,
    지도 앱은 프로그레시브 웹앱(PWA, Progressive Web App)인 것을 특징으로 하는,
    문자 메시지로 사전에 등록된 수신인과 GPS 좌표를 공유하는 방법.
    
40. 제35항에 있어서,
    지도 앱의 초기 화면에 보이는 지도 영역이 지리적인 좌표에 부합하도록 초기 화면을 표시하는 단계는;
    미디어 쿼리(media query)를 이용하여 기기(device)의 종류(type)와 화면 방향(screen mode)을 결정하는 단계,
    기기의 종류와 화면 방향에 맞는 랜딩 페이지(landing page)를 시작하는(launch) 단계를 포함하는 것을 특징으로 하는,
    문자 메시지로 사전에 등록된 수신인과 GPS 좌표를 공유하는 방법.
    
41. 제35항에 있어서,
    기기(device)는 스마트폰(smart phone)과 문자 메시지 서버(text message server) 중 어느 하나인 것을 특징으로 하는,
    문자 메시지로 사전에 등록된 수신인과 GPS 좌표를 공유하는 방법.
    
42. 제35항에 있어서,
    긴급 연락 정보는 구조 대상자의 이름, 구조 대상자의 신원 확인을 위한 개인 식별 번호, 구조 당국의 전화번호, 구조 당국이 필요한 정보를 얻을 수 있는 가족이나 지인의 이름과 전화번호, 구조 당국에서 구조 대상자의 개인 정보를 조회하는 것에 동의하는지의 여부들 중 어느 하나 이상을 포함하는 것을 특징으로 하는,
    문자 메시지로 사전에 등록된 수신인과 GPS 좌표를 공유하는 방법.
    
43. 삭제
44. 삭제
45. 삭제
46. 삭제
47. 삭제
48. 삭제
49. 삭제

Images