KR20090051094A

KR20090051094A - 맵 정정 데이터를 구성하는 방법 및 장치

Info

Publication number: KR20090051094A
Application number: KR1020097005199A
Authority: KR
Inventors: 피터르 헤일런; 로리 존스
Original assignee: 톰톰 인터내셔날 비.브이.
Priority date: 2006-08-15
Filing date: 2007-08-15
Publication date: 2009-05-20
Also published as: KR20090041430A; CN101517371A; RU2009109234A; AU2007286429A1; JP2010500584A; RU2009109239A; CN101517365A; CN101517366A; GB2440958A; JP2010500586A; RU2482540C2; RU2009109231A; CN103090877A; TW200817933A; JP2010500589A; JP2017016135A; TW200829875A; TW200823431A; RU2009109237A; GB0616211D0

Abstract

맵 정정 데이터를 구성하는(organize) 방법 및 장치가 설명된다. 장치는 맵 정정 데이터를 수신하는 수단, 상기 맵 정정 데이터를 확인하는(validate) 수단, 상기 맵 정정 데이터를 적어도 하나의 카테고리로 분류하는(categorize) 수단, 및 맵 정정 데이터를 저장하는 수단을 포함한다.

Description

맵 정정 데이터를 구성하는 방법 및 장치{A method of and an apparatus for organizing map correction data}

본 발명은 내비게이션 디바이스들에서 사용하기 위한 향상된 맵 데이터를 생성하는 방법에 관한 것이다. 내비게이션 디바이스들은 GPS 기반의 PND(personal navigation device)들을 포함한다.

전자 내비게이션 디바이스들, 예컨대 TomTom International BV의 GO^TM와 같은 GPS 기반 개인 내비게이션 디바이스들을 위한 맵 데이터는, Tele Atlas NV와 같은 전문적인 맵 공급자(vendor)로부터 나온다. 이 맵 데이터는, 전형적으로 GPS 시스템으로부터 위치 데이터를 사용하는, 경로 안내 알고리즘(route guidance algorithm)들이 사용하기 위해 특별히 설계된다. 예를 들어, 도로들은 선들 - 즉 벡터들 (예: 시작점, 끝점, 도로 방향으로, 전체 도로는 각각이 시작점/끝점 방향 파라미터들에 의해 고유하게 정의되는 몇백 개의 이러한 부분들로 구성된다)로서 묘사될 수 있다. 그때 맵은 이러한 도로 벡터들, 각 벡터와 연관된 데이터(속도 제한; 진행 방향 등)와 POI(point of interest)들, 도로 이름들, 공원 경계, 강 경계 등과 같은 다른 지리적 특징(feature)들로 이루어지고, 이것들 모두는 벡터로 정의 된다. 모든 맵 특징(map feature)들(예: 도로 벡터, POI 등)은 전형적으로 GPS 좌표 시스템과 대응되는 또는 그것에 관련된 좌표 시스템에서 정의되어, GPS 시스템을 통해 결정되어진 디바이스 위치를 맵에서 보여지고 목적지로 계획된 최적의 경로에 대한 관련 도로 상에 위치시키는 것을 가능하게 한다.

이 맵 데이터베이스를 구성하기 위해, Tele Atlas는, 영국의 도로들에 대한 군사 측량(Ordnance Survey)과 같은 다양한 소스들로부터 기초적 도로 정보로 시작한다. Tele Atlas는 또한, 도로들 상에서 운행하는 차량들과 다른 맵들을 조사하는 직원들, 및 항공 사진들로 이루어진 큰 전용 팀을 가지고 있어서 그 데이터를 업데이트하고 조사한다. 이 데이터는 Tele Atlas 맵 데이터베이스의 핵심을 구성한다. 이 맵 데이터베이스는 지리적기준(geo-refenced) 데이터로써 계속적으로 증대되어지고 있다. 그런 이후에 그 데이터는 검사되고 TomTom과 같은 디바이스 제조업체에게 연간 4회 공고되었다.

이들 맵들을 업데이트하고 확인하고 검증하는데 들어가는 방대한 자료 (resource)들에도 불구하고, 어떤 지리적 지역들에 대한 데이터는 1년 또는 그 이상 지난 것일 수도 있다.

상기에서 기술된 계속되고 있는 향상들에 더하여, 최종유저(end-user)들은 Tele Atlas의 웹 사이트를 사용하여 Tele Atlas에 대해 맵 오류(map error)들을 직접 보고할 수 있다. TomTom과 같은 디바이스 제조자들은 또한 이러한 방식으로 그들 유저들로부터의 맵 오류 보고들을 포착하고 전송한다. 이들 오류 보고들은 일반적으로 단지 자유형식 텍스트 포맷이어서, 그 오류가 실제로 의미하는 것 및 그것 들이 관련된 어느 정확한 위치를 파악하는데 상당한 노력을 들여야 한다. 일단 진짜 오류로서 검증된다면, 적절한 정정이 확인(validate)되고 그리고 나서 차후의 맵 릴리즈(release)에 포함된다. 결국 그 정정은 최초로 알려진 후 1년 또는 그 이상 지나 최종유저 디바이스에서 발견되거나 또는, 어떤 경우들에 있어서는, 전혀 발견되지 않을 수 있다.

또한, GPS 위성 내비게이션 디바이스를 사용하여 계획되고 완성된 여행의 '자취'(trace)를 저장하는 것이 알려져 있다 (예를 들어, 미국 프린스톤(Princeton)에 있는 ALK Technologies에 의해 제공된 'GPS track submission' 기능을 참조). 이 자취는, 지오코딩된(geo-coded) 데이터를 사용하여, 차량이 얻은 완전한 경로에 관한 기록이다. 그때 유저는 이 자취 데이터를 그 디바이스 공급자에게 다시 보낼 수 있고; 그 후에 이 자취 데이터는 맵 데이터베이스의 정확성 및 완전성을 향상시키는데 사용된다. 예를 들면, 도로 또는 분기점(turning)에 관한 정확한 위치는 디바이스에 의해 사용되는 맵 상에서 정확하게 포착되지 않을 수도 있고; 그 도로 또는 분기점에 가는 사람을 위한 취합된(aggregated) 트랙(track)들이 더 정확한 위치가 결정되는 것을 가능하게 할 것이며; 그 디바이스 공급자에 의한 차후의 맵 릴리즈들은 정정을 포함할 수 있다.

또한, 종종 '위키맵들'(wikimaps)로 불리는 협력적 맵핑 프로젝트(mapping project)들에 관하여 언급할 수도 있다. 그러나 위키맵들은 우리가 정의하는 것으로서의 '맵 데이터' - 즉, 목적지로의 도로 시스템 상에 경로를 작성하는 경로 안내 알고리즘들에 적합한 맵 데이터 - 를 생성하지 않는다.

본 발명은 내비게이션 디바이스들에서 사용하기 위한 향상된 맵 데이터를 생성하는 방법이고, 상기 방법은 다음의 단계들을 포함한다:

a) 경로(route) 안내(guidance) 알고리즘에 적합한, 맵 데이터를, 전자(electronic) 내비게이션 디바이스상에 디스플레이하는 단계;

b) 상기 디바이스의 최종-유저(end-user)가 맵 오류에 대한 정정(correction)을, 상기 디바이스에 직접 입력하는 단계:

c) 상기 디바이스는, 상기 정정을 외부에서 처리하지 않고 상기 정정을 사용할 수 있는 단계를 포함한다.

따라서, 최종유저가 웹 링크(web link)를 통해 맵 공급자에게 오류들을 보고하는 것, 그래서 그 맵 공급자가 그 오류를 확인하고, 그 맵들을 업데이트하며 그 업데이트를 공급하는 것을 기다리는 것 - 완성하기 위해 수 개월 및 때때로 수 년이 걸릴 수도 있는 하나의 사이클 - 에 한정되어지는 것이 더 이상 필요하지 않다. 대신에, 내비게이션 디바이스가 외부 처리(processing) - 예: 맵 공급자에 의한 확인 - 없이 그 정정을 사용할 수 있다. 디바이스에 의한 정정의 이용은, 상대적인 용어로, '즉각적'(immediate)이다. '즉각적'이라는 용어는 즉시로서가 아니라 단순히 그 정정이 입력된 후에 '곧'을 의미하는 것으로서 해석되어야 할 것이다. 유저가 그 정정이 사용되어야 하는지를 검증하고, 그 디바이스를 켜고 그리고 나서 끄는 것 등과 같은 개입 단계들이 있을 수 있다.

구현에 있어서, 유저들이 그들의 디바이스 상에 저장된 맵 데이터에 수정을 하는 것을 허용하는 내비게이션 디바이스가 있다. 그 내비게이션 디바이스는 TomTom International BV의 GO 시리즈 디바이스와 같은 경로 안내 능력을 가진 휴대용 독립형 GPS 내비게이션 디바이스, 또는 휴대폰 또는 PDA와 같은 임의의 다른 종류의 휴대용 정보 디바이스일 수 있다. 그러나 동등하게, 그것은 차량에 통합된 디바이스, 또는 내비게이션 소프트웨어(이 용어는, 실제로 동적인 경로 안내가 아니고 대신에 단순히 맵핑 - 유저가 어디에 있는지 - 을 전달하는 맵핑 소프트웨어를 포함한다. 또한, 그 내비게이션 소프트웨어는 클라이언트 디바이스 상에서 국부적으로 실행되거나 또는 클라이언트 디바이스로부터 떨어진 원격의 서버 상에서 실행될 수 있다)를 실행시키는 고정된 데스크탑(desktop) PC(랩탑(laptop) 포함)와 같은 컴퓨팅 디바이스일 수 있다. 그때 PC는 경로 안내 성능을 가진 휴대용 내비게이션 디바이스와 도킹(docking)될 수 있고 그 휴대용 내비게이션 디바이스에 정정들을 전송할 수 있다.

이러한 내비게이션 디바이스의 전형적인 특징들은 다음과 같다:

· 유저가 디지털로 저장된 맵에 대한 정정들을 생성할 수 있게 해 주는 유저 인터페이스;

· 유저가 경로 계산들에서 맵 오류들을 포함하거나 배제할 수 있게 해 주는 유저 인터페이스;

· 유저가 디지털 맵 상에 유저의 정정된 맵 데이터를 볼 수 있게 해 주는 유저 인터페이스;

· 정정된 맵 데이터를, 청각적 마킹, 텍스트(textual) 마킹, 또는 다른 유형의 시각적 마킹으로 디스플레이하는 유저 인터페이스;

· 유저가 하나 이상의 운송 유형들과 맵 정정들을 연관시킬 수 있게 해 주는 정정 카테고리들의 집합;

· 예컨대 콘텐트 취합 서비스(content aggregation service)를 거쳐, 다른 유저들과 맵 정정들을 공유할 수 있는 성능. 공유된 맵들은 그것들이 다운로드되자마자 (예컨대 경로 계획 알고리즘 또는 맵 디스플레이 엔진(map display engine)에 의해) 사용하기에 유효하다.

본 발명의 제2 측면은 자동화된 맵 정정 제안(suggestion) 방법이다: 이 방법에서, 내비게이션 디바이스는 운전자 행동에 관련된 통계 데이터를 수집하고 분석하며, 전형적으로 일정 문턱값 기준들(threshold criteria)이 부합될 때, 유저에게 맵 정정들을 제안한다. 예를 들면, 만약 유저가 그 디바이스가 아래로 경로를 계획했던 도로로 들어가지 않았다면, 그것은 실제 도로가 '출입 금지' 표시를 가지고 있지만, 그 디바이스 상에 저장된 맵이 최신이 아니기 때문일 수도 있다. 그러면 그 디바이스는 '미안하지만, 그 맵은 부정확하였습니까?'와 같은 메시지를 그 메시지에 의해 디스플레이된 '예' 및 '아니오' 버튼들과 함께 자동적으로 디스플레이할 수 있다. 만약 유저가 '예'를 누르면, 그러면 그 디바이스는 유저가 그 디바이스 상에 저장된 맵에 대한 정정들을 생성할 수 있게 해 주도록 유저 인터페이스를 디스플레이할 수도 있다. 그리고 나서 유저는 '출입 금지' 도로로서 그 도로를 마킹(marking)함으로써 그 맵을 정정할 수 있다. 그 정정은 그 내비게이션 디바이스 상에서 실행되는 경로 계획 알고리즘들에 관해 즉각적으로 이용가능하다.

제3 측면은 맵 정정 분석 방법이다: 이 방법에서, 시스템은 다음 중 하나 이상을 사용하여 맵 정정들을 분석한다:

· 정정의 "유효성"(validity)을 얻기 위해 유저 정정들에 관한 분석 및 취합;

· 단일의 유저로부터의 정정들의 "신뢰성"(trustworthiness)을 얻기 위해 그 단일의 유저에 의해 공급되는 정정들에 관한 분석;

· "금지된"(banned) 워드들(예: 거리 이름들에서의 허사(expletive)들)을 제거하기 위해 모든 스트링 데이터(string data)에 관한 키워드 분석;

· 맵 정정이 동일한 영역에 관한 다른 맵들(다른 공급자들로부터의 맵들 및 같은 공급자로부터의 맵의 새 버전들 양자 모두 해당)에 적용되어야 하는지 여부를 결정하기 위해 정정들에 관한 분석.

본 발명은 첨부된 도면들을 참조하여 기술될 것이다.

도 1은 내비게이션 디바이스에 의해 디스플레이되는 주요 오류 보고를 위한 스크린이다.

도 2는 유저들이 포착하고 보고하기를 바라는 오류 유형을 유저들이 정의할 수 있게 해주는 화면을 보여주는 도면이다.

도 3은 본 발명을 구현하는 내비게이션 디바이스로부터의 스크린 샷(screen shot)으로, 그 스크린 샷은 디스플레이의 하단부를 따라 실행되는 평면도 및 상태 바(status bar)를 보여준다.

도 4는 3-D 도를 구현하는 내비게이션 디바이스로부터의 스크린 샷이다.

도 5는 내비게이션 메뉴를 보여주고 있는 내비게이션 디바이스로부터의 스크린 샷이다.

도 6a 및 도 6b는 내비게이션 디바이스의 사시도들이다.

도 7은 내비게이션 디바이스의 시스템 구조에 관한 도식적인 도면이다.

도 8은 내비게이션 디바이스에서의 컴포넌트들에 관한 블록도이고; 그리고

도 9는 도 8의 내비게이션 디바이스에서의 전기적 하위 부품들에 관한 다이어그램이다.

본 발명은 Map Share^TM로 불리는 구현을 참조하여 기술될 것이다. Map Share™는 유저들이 TomTom International B.V사의 GO 개인 내비게이션 디바이스들을 사용하여 맵 오류들을 정정하고 또한 공유하고 보고할 수 있게 해 줄 것이다. 유저는 내비게이션 디바이스 내에 정정(또는 맵 정정(fix))을 입력한다. 그 뒤 맵 정정은 도로, 주요지점(POI) 기타 등등을 라우팅하고 디스플레이하는데 디바이스에 의해 사용되는 맵 데이터를 보완하기 위해 디바이스에 국부적으로 적용된다. 맵 정정은 바로 이용가능하다. 그 맵 정정은 다수의 방식들로 그 디바이스에 의해 TomTom 서버로 보고될 수 있다: 그 디바이스는 일체형 통신 성능(예: 그 서버로 데이터를 보낼 수 있는 무선 셀룰러 시스템)을 가질 수도 있거나, 데이터를 그 서버로 송신할 휴대 전화에 근거리 무선 링크를 통해 그 데이터를 송신할 수도 있거나, 그 서버와 통신할 수 있는 인터넷 연결 PC와 도킹할 수도 있으며, 또는 그 자체가 그 인터넷 연결 PC일 수도 있다. 그때 그 서버는 모든 유저들로부터 모든 정정들을 취합하고, 정정들의 유효성을 확인하고, 그리고 그 정정들을 다른 유저드에게 배포하며, 그리고 하나 이상의 맵 공급자들과 그 정정들을 공유할 수 있다.

완전히 구현되어질 때, 이 피드백(feedback)은 TomTom 제품들에서 맵 데이터를 업데이트하는 주된 메커니즘으로서 맵 공급자 업데이트들을 대체할 수 있다.

Map Share에 관한 하나의 구현 영역은 사용하기 쉽게(friendly), 디바이스상 도구(on-device tool)들을 제공하는 것으로, 여기서 그 디바이스상 도구들은 그 유저로 하여금:

· 그들 맵 상의 거리 통행금지하고(block) 거리 통행금지해제하도록(un-block)

· 그들 맵 상의 거리들의 교통 방향을 수정하도록

· 그들 맵 상의 거리 이름들을 추가하고 수정하도록

· 그들 맵 상의 도로들의 속도 제한들을 수정하도록

할 수 있게 해 주는 것이다.

따라서, 그 정정들은 경로지정 계산 알고리즘들이 어떻게 작동되는지에 직접 영향을 끼친다 - 즉, 정정들은 목적지로의 경로를 계산할 때 사용된다. Map Share는 또한 유저로 하여금:

· 그 맵에 과속 감시 카메라(safety camera) 위치들을 추가하도록

· 다른 유저들과 맵 정정들을 공유하도록

· 다른 유저들로부터 맵 정정들을 다운로드하도록

· 많은 오류들에 대한 맵 오류 보고들을 생성하도록

할 수 있게 해 준다.

디바이스상의 정정들에 더하여, 모든 상기의 정정 유형들에 대한 같은 정정 특징들이, 예를 들어 정정들을 저장하기 위하여, 그 디바이스에 연결할 수 있는 데스크탑 컴퓨터 애플리케이션을 사용하여 이용가능하게 될 수 있다.

디바이스상의 특징들에 더하여, 현존하는 TomTom 맵 오류 보고 도구에 대한 향상들이 가능하고, 여기서 그 도구는 웹 기반이다:

· 맵 오류 보고는 톰톰 지원 웹사이트(TomTom Support Website) 내에서 발견하기에 더 용이하게 될 것임

· 맵 오류 보고 도구들은 TomTomHome 애플리케이션에 추가될 것임

· 유저들은 그들이 보고하였던 맵 오류들에 대한 피드백을 수신할 것임

· TomTom은 그것의 맵 공급자, 예를 들어 TeleAtlas에게 그것들을 보내기 전에 오류들을 미리 우선순위화할 수 있을 것임.

이전에 설명한 바와 같이, Map Share 구현에서의 중요한 특징들은:

· 맵 정정들, 오류 보고 등을 그 디바이스 상에서 하는 것

· 일정한 정정들이 즉각적인 효과를 나타내게 만드는 것(예: 유저-정의 기준들을 부합하면임)

· 유저들이 다른 유저들과 정정들을 교환할 수 있게 해 주는 것이다.

GO 내비게이션 디바이스에 관하여, 이것은 도 1a에 보여지는 바와 같이, 'Make changes to the map'인 메뉴 항목을 디스플레이하는 디바이스에 의해 구현될 수 있다. 이 아이템을 선택한 결과는 아래에서 논의된다. 먼저 기술될 2개의 추가적인 메뉴 항목들이 있다.

첫 번째로, 'Exchange Changes'인 메뉴 항목은 유저로 하여금, 유저 자신의 변화들에 관한 업로드를 개시하고 다른 사람들의 변경들을 그 디바이스에 다운로드할 수 있게 해준다. 업로드는 GO 디바이스가 도킹되어진 인터넷 연결 PC를 거쳐 또는 블루투스(Bluetooth) 네트워크를 통해 GO 디바이스에 연결하는 GPRS 무선 링크를 가진 휴대 전화를 거칠 수 있다.

두 번째로, 'Preferences About changes'인 메뉴 항목은 어느 변경들을 허용할지를 결정한다. 이 항목을 선택함으로써 그 디바이스로 하여금, 허용할 적용가능한 유형의 변경들을 유저가 표시할 수 있는 체크 박스들과 함께, 메뉴 스크린을 디스플레이하게 할 수 있다.

어떤 변경들이 허용되어야 하는지는 다음과 같을 수 있다:

[x] 당신의 독자적인 변경

[x] 최근의 변경

[ ] 지난 해의 변경 / 다른 맵들 상에서 이루어진 것

[x] 한 번 이상 보고된 경우만

[x] 신뢰되는 소스들로부터인 나온 경우만

2635개 중 1365개의 이용가능 변경들이 허용됨.

만일 유저가 'Make changes to map' 아이콘을 그것을 터치함으로써 선택한다 면, 그것은, 그 맵을 변경할 즉효(INSTANT-EFFECT) 옵션들과 이에 더하여 오류를 보고(REPORT)할 옵션(만약 그 오류가 자동(self-action)으로써 커버되지 않는 경우)을 제공하는 서브메뉴로 유저를 이끈다. 이것들은, 도 1b에서 보여지는 바와 같이, 다음을 포함한다:

· Add/change street name(거리명 추가 변경): 만약 유저가 이것을 선택하면, 그때는 그 디바이스는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 디바이스가 정상 내비게이션 모드에 있다면 디스플레이될) 거리들의 이름들에 관한 리스트를 디스플레이할 수 있다; 유저는 이름을 바꿀 거리를 선택할 수 있고 그리고 나서 화면상의 키보드(on-screen keyboard)를 통해 새로운 이름을 기입할 수 있다.

· Block Street(거리 통행금지): 만약 유저가 이것을 선택하면, 그때는 그 디바이스는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 디바이스가 정상 내비게이션 모드에 있다면 디스플레이될) 거리명들의 리스트를 디스플레이할 수 있다; 유저는 통행금지될 거리를 선택할 수 있다.

· Change traffic direction(교통 방향 변경)(미도시): 만약 유저가 이것을 선택하면, 그때는 그 디바이스는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 디바이스가 정상 내비게이션 모드에 있다면 디스플레이될) 거리명들에 관한 리스트를 교통 방향과 함께 디스플레이할 수 있다; 유저는 교통 방향이 변경되어질 거리를 선택할 수 있다.

· Change speed limit(속도 제한 변경): 만약 유저가 이것을 선택하면, 그 때는 그 디바이스는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 디바이스가 정상 내비게이션 모드에 있다면 디스플레이될) 거리명들에 관한 리스트를, 적용가능한 속도 제한들과 함께, 디스플레이할 수 있다; 유저는 속도 제한이 변경되어질 거리를 선택하고 그리고 나서 메뉴로부터 적절한 새로운 속도 제한을 선택할 수 있다.

· Un-block street(거리 통행금지 해제): 만약 유저가 이것을 선택하면, 그때는 그 디바이스는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 디바이스가 정상 내비게이션 모드에 있다면 디스플레이될) 통행금지된 거리명들에 관한 리스트를 디스플레이할 수 있다; 유저는 통행금지해제할 거리를 선택할 수 있다.

게다가, 'Edit/delete POI'(POI 편집/삭제) 아이콘을 선택하여 다음 사항들을 위한 그래픽 옵션들을 가진 더 아래의 하위메뉴에 도달하는 것이 가능하다:

- Rename a POI: POI 개명(rename)

- Move a POI: POI 이동

- Add a POI to a category: 카테고리에 POI 추가

- Delete a POI: POI 삭제

- Re-categorize a POI: POI 재분류.

각각의 경우에, 그 디바이스는, 예를 들어, 현재 그 맵에 의해 디스플레이되고 있는 (또는 만약 그 디바이스가 정상 내비게이션 모드에 있다면 디스플레이될) POI들의 이름들에 관한 리스트를 디스플레이할 수 있다; 유저는 관련 POI를 선택하 고 그리고 나서 그 POI를 편집하거나 삭제할 수 있다. 이들 POI들은 전형적으로 맵 공급자에 의해 공급된 것들이지만, 유저에 의해 다운로드된 POI들을 포함할 수 있다(예컨대 과속 감시 카메라).

추가적인 메뉴 항목은 'Report other error'(다른 오류를 보고)하는 것이다. 이것은 보고될 불편사항(complaint)들, 빠진 도로들 등을 허용한다. 전형적인 기능들은 유저로 하여금 위치를 고르고, 전형적인 문제들의 리스트에서 선택할 수 있게 하고 유저로 하여금 자유형식(free) 텍스트 설명 등을 추가할 수 있게 해 주는 것이다.

- 다른 특징들

· 유저들은 그들 맵에 대한 "사적"(private) 정정들 및 또한 취합을 위하여 TomTom에 보내지는 "공유"(shared) 정정들을 생성할 수 있다.

· 각 맵 정정은 독립적으로 저장된다

· 모든 맵 정정들은 OTA 배포를 위해 고도로 압축가능하다.

· 모든 맵 정정들은, 경쟁사들이 TomTom 디바이스들 상에 이루어진 정정들을 사용하여 그들 자신의 맵들을 정정할 수 없음을 확실히 하기 위하여 고도의(HIGHLY) 보안(그 포맷을 수동으로 역설계하는(reverse engineering)하는 것이 가능하지 않도록 함)을 갖춘다.

· 수정들은 맵에 독립적인 형태로 저장된다.

˚ 맵 정정들은 맵 업그레이드 동안 유지보존된다.

˚ 맵 정정들은 서로 다른 공급자들로부터의 맵들에 적용될 수 있다.

· 만약 정정에 관련된 지역이 맵 데이터의 새 릴리즈에서 변경되었다면 맵 정정들은 자동적으로 삭제될 수 있다(이 경우에서 우리는 맵 오류가 맵 공급자에 의해 정정되어졌다는 것을 가정하기 때문)

· 맵 정정들은 유저의 맵 데이터를 영구히 수정하지 않는다.

· 유저들은 어떤 종류의 변경들을 그들이 사용할지를 결정할 수 있다(예: "나의 변경들만을 사용" 또는 "나의 변경들 및 TomTom으로부터의 변경들을 사용" 또는 "선택된 언어로된 변경 사용")

· TomTom은 각각의 릴리즈된 맵 버전에 대한 맵 정정 데이터베이스들을 유지한다 (주의: 새 맵들을 가진 유저들은 더 오래된 맵들 상에서 보고된 수정들을 받을 수 있지만, 오래된 맵들의 유저들은 더 새로운 맵들 상에서 보고된 수정들을 수신할 수 없을 것이다).

· TomTom은 맵 정정들 및 보고들이 수집되어지고 다른 유저들과 공유될 수 있도록 취합 시스템(aggregation system)을 생성한다.

· TomTom은 맵 정정들 및 보고들의 유효성 또는 신용가능성이 평가될 수 있도록 "신뢰"(trust) 시스템을 생성한다. 정기적으로 좋은 오류들을 보고하는 유저들은 "신뢰받는"(trusted) 자들로 될 수도 있고, 그들의 수정들은 확인(validation)할 필요 없이 모든 유저들에게 제공된다. 이들 유저들은 또한 다른 유저들에 의해 제출된 수정들을 확인하도록 요구받을 수도 있다.

· TomTom은 유저들에 의해 보내진 수정들을 보증한다(endorse) (일단 수정들이 확인되었을 경우).

도 2는 본 발명을 구현하는 내비게이션 디바이스에 탑재되는 핵심 소프트웨어 모듈들을 도식적으로 보여주고 있다. 디스플레이(21)는 기존의 방식으로 유저가 목적지 주소를 입력하는 터치 스크린 디스플레이이다. 그 주소 데이터 입력은 UI 모듈(22)에 의해 다루어지고 내비게이션/경로 계획 모듈(23)로 송신된다. GPS 모듈(24)로부터 GPS 피드(feed)를 얻는 경로 계획 모듈(23)은 그 디바이스가 가지고 있던 (또는 그렇지 않으면 Tele Atlas와 같은 맵 공급자로부터 공급된) 암호화되고, 압축된 맵 데이터로부터 맵 데이터를 사용하여 경로를 계획한다. 그때 본 발명은 다음과 같이 구현된다: 유저는 필요하면, 도 1a 및 도 1b에 의해 예시하고 있는 바와 같이, 터치 스크린 상호작용을 활용하고, 큰 그래픽 아이콘들을 터치하여, 맵 정정을 디스플레이(21)에 입력한다. UI 모듈(22)은 그 맵 정정을 포착하고 그것을 맵 정정 저장소(26)로 보낸다. 맵 정정이 맵 정정 저장소(26)에 있게 되자마자, 그것은 경로 계획 모듈(22) 및 UI 모듈(22)에 대해 이용가능하게 된다. 만약 그 맵 정정이, 운행되어지는 현재의 경로도 재계획할 것을 필요로 한다면, 그때 그것은 자동적으로 일어날 것이다 (만약 그 유저가 그 옵션을 설정한 경우). 예를 들면, 그 디바이스는 유저가 거리로 진입할(turn) 것을 필요로 하는 경로를 계획할 수도 있다: 그 분기점(turning)에 도달할 때, 유저는 그것이 최근에 '출입 금지' 거리로 되었음을 발견한다. 유저는 적절한 맵 정정을 입력할 수 있다: 그때 그 출입 금지 거리를 고려하여 새로운 경로가 즉각적으로 계획되고 적절한 경로 안내가 주어진다. 마찬가지로, 만약 유저가 다른 목적지로의 완전히 새로운 경로를 계획한다면, 그 새로운 경로도 또한 그 맵 정정을 고려할 것이다. 만약 그 맵 정정이 어떻게 그 맵이 나타나야할지(예를 들면, 도로를 개명, 새로운 POI를 보여주는 것, 예컨대 과속 감시 카메라)에 작용하여야 한다면, 그때는 그 새로운 모습이 즉각적으로 존재할 것이다. 정정에 관한 자동적인 이용은 의무적인 것은 아니고; 어떤 유저들은 맵 정정들을 배제하는 경로 계산 등을 선호할 수도 있다.

부록 1은 본 발명을 구현할 수 있는 전형적인 디바이스를 묘사한다. 부록 2는 Map Share에 대한 고수준의 요구조건들이다.

- 부록 1

본 발명은 GO로 불리는 TomTom B.V.사의 통합 내비게이션 디바이스로 구현될 수 있다. GO는 Navigator(또는 Navcore)로 불리는 내비게이션 소프트웨어를 탑재하고 내부 GPS 수신기를 가진다; Naviator 소프트웨어는 또한 컴팩(Compaq) iPaq과 같은 터치 스크린(즉 스타일러스(stylus)로 제어되는) 방식의 포켓(Pocket) PC 전원의 PDA 디바이스 상에서 실행될 수 있다. 그러면 그것은 그 PDA가 GPS 수신기와 결합될 때 GPS 기반 내비게이션 시스템을 제공한다. 결합된 PDA 및 GPS 수신기 시스템은 차량내 내비게이션 시스템으로서 사용되도록 설계된다.

본 발명은 또한 임의의 다른 구성의 내비게이션 디바이스, 예컨대 일체형 GPS 수신기/컴퓨터/디스플레이를 가진 디바이스, 또는 비차량에서 사용하기 위해(예: 보행자들을 위해) 설계되거나 차와 다른 운송수단들(예: 항공기)을 위해 설계된 디바이스로 구현될 수도 있다. 그 내비게이션 디바이스는 임의의 종류의 위치 감지 기술을 구현할 수 있고 GPS에 제한되지는 않는다; 따라서 그것은 다른 종류의 European Galileo 시스템과 같은 GNSS(global navigation satellite system)를 사용하여 구현될 수 있다. 동등하게, 그것은 위성 기반 위치/속도 시스템들에 제한되지 않지만, 그라운드기반 비콘(ground-based beacon)들이나 그 디바이스가 그 디바이스의 지리적 위치를 결정하는 것을 가능하게 하는 임의의 다른 종류의 시스템을 사용하여 배치될 수 있다.

Navigator 소프트웨어는, PDA 상에서 실행될 때, 도 3의 정상 내비게이션 모드 스크린이 디스플레이되게 하는 내비게이션 디바이스를 결과적으로 도출한다. 이 뷰는 텍스트, 기호, 음성 안내 및 이동 맵(moving map)의 조합을 사용하여 구동 명령들을 제공한다. 본질적인 유저 인터페이스 요소들은 다음과 같다: 2-D 맵(1)은 화면의 대부분을 차지한다. 그 맵은 유저의 차 및 그것의 인접한 주변을 보여주고, 차가 이동하고 있는 방향이 항상 "위쪽"이 되는 식으로 회전된다. 스크린의 하부 1/4에 상태바가 걸쳐 있다. 그 디바이스 자체적으로 기존의 GPS 위치 발견을 사용하여 결정한 것으로서의 그 디바이스의 현재 위치 및 그것의 방위(orientation)(그것의 진행 방향으로부터 추론됨)가 화살표(3)에 의해 묘사된다. 그 디바이스에 의해 계산된 경로(디바이스 메모리 내 맵 데이터베이스에 저장된 맵 데이터에 적용되는 것으로서 디바이스 메모리에 저장된 경로 계산 알고리즘들을 이용)는 진행 방향을 부여하는 화살표들로 중첩된 어두운 길(4)로서 보여진다. 어두운 길(4) 위에, 모든 주요 동작(action)들(예: 회전 코너, 교차로, 로터리 등)이 길(4)에 그려진 화살표들(5)로써 도식적으로 묘사된다. 상태 바(2)는 또한 그것의 좌측에 다음 액션(여기서는, 우회전)을 묘사하는 개략도(6)를 포함한다. 상태 바(2)는 또한 그 디 바이스에 의해 계산된 전체 경로에 관한 데이터베이스(즉 취해질 경로를 정의하는 모든 도로들 및 관련 동작들의 리스트)로부터 추출되어진 다음 동작에 대한 거리(즉 우회전 - 여기서 거리는 220 미터)를 보여준다. 상태 바(2)는 또한 현재 도로명 (8), 도착까지의 추정 시간(9)(여기서는 2분 40초), 실제 추정되는 도착 시간(10)(오전 11시 36분) 및 목적지까지의 거리(11)(1.4km)를 보여준다. GPS 신호 강도는 모바일 전화 양식의 신호 강도 표시자(12)로 보여진다. 도 4에서 보여지는 바와 같이, 3-D 맵 뷰(map view)도 또한 가능하다.

만약 유저가 스크린(13)을 터치하면, 그때 내비게이션 화면의 주 메뉴(미도시)가 디스플레이된다; 이 메뉴로부터, Navigator 애플리케이션 내의 다른 핵심 내비게이션 기능들이 개시되거나 제어될 수 있다. 핵심 내비게이션 기능들이, 자체적으로 매우 쉽게 호출된 메뉴 화면(예: 맵 디스플레이에서 메뉴 스크린까지 한 단계 떨어져 있음)으로부터, 선택될 수 있게 하는 것은, 유저 상호작용을 크게 단순화시키고 그것을 더 빠르고 더 용이하게 한다.

유저에 의해 터치될 것을 필요로 하는 터치 존(touch zone) 영역은 대부분의 스타일러스 기반 터치 스크린 시스템들에서보다 훨씬 더 크다. 그것은, 특별한 정밀함을 갖추지 않은 하나의 손가락에 의해 확실하게 선택될 만큼 충분히 크게 설계된다; 즉, 차량을 제어할 때 운전자의 현실 상태조건들과 유사하게 하기 위해 그렇게 설계된다; 운전자는 작은 제어 아이콘들을 가진 고도로 상세한 화면을 볼 시간이 별로 없을 것이고, 그들 작은 제어 아이콘들 중 하나를 정확하게 누를 시간은 더 없을 것이다. 따라서, 주어진 소프트 키(soft key)(또는 스크린(13)의 중심에서 와 같은, 숨겨진 소프트 키)와 연관된 매우 큰 터치 스크린 영역을 사용하는 것은 이 구현의 사려 깊은 설계 특징이다. 다른 스타일러스 기반 애플리케이션들과 달리, 이 설계 특징은, 운전자가 실제로 운전하고 있는 동안 운전자가 필요로 할 것 같은 핵심 기능들을 선택하도록 Navigator의 도처에 일관되게 배치된다. 따라서, 유저에게 스크린상의 아이콘들(예: 예를 들어 목적지 주소를 기입하기 위한 가상 키보드(virtual keyboard)의 키들 또는 제어 아이콘들)을 선택할 기회가 주어질 때마다, 그때 그 아이콘들/키들의 설계는 단순하게 유지되고 연관된 터치 스크린 존들은 각각의 아이콘/키가 명백하게 손가락으로 선택될 수 있는 크기로 확정된다. 실제로, 연관된 터치 스크린 존은 최소한 0.7 cm² 정도(order)일 것이고 전형적으로 평방지대일 것이다. 정상 내비게이션 모드에서, 그 디바이스는 맵을 디스플레이한다. 그 후에 스크린 중심(또는 다른 구현에서는 스크린의 임의의 부분) 근처에서 그 맵(즉, 터치 감지 디스플레이)을 한 번(또는 다른 구현에서는 두 번) 터치하는 것은, 다양한 내비게이션 기능들, 예컨대 대체 경로를 계산하고 그리고 다음 도로 부분을 회피하도록 그 경로를 재계산하거나(방해물 또는 심한 교통혼잡과 마주칠 때 유용함), 특정한, 열거된 도로들을 회피하도록 그 경로를 재계산하는 옵션에 대응되는 큰 아이콘들을 가진 내비게이션 메뉴(도 5 참조)를 직접적으로(즉, 아래로 다음 레벨) 혹은 간접적으로(즉 아래로 둘 이상의 레벨) 호출할 것이다.

그 디바이스의 실제 물리적 구조는 메모리 아키텍처(architecture)의 관점에서 볼 때 기존의 엠베디드 디바이스와는 근본적으로 다르다 (아래에서 시스템 아키 텍쳐 섹션 참조). 그러나 높은 수준으로 그것은 유사하다: 메모리는 경로 계산 알고리즘들, 맵 데이터베이스 및 유저 인터페이스 소프트웨어를 저장하고; 마이크로프로세서는 유저 입력(예: 출발 및 목적지 주소들을 입력하기 위한 디바이스 터치 스크린 및 모든 다른 제어 입력들을 사용)을 해석하고 프로세싱하며 그 경로 계산 알고리즘들을 탑재하여 최적의 경로를 계산한다. '최적'이라는 것은 최단 시간 또는 최단 거리나 또는 어떤 다른 유저관련 인자들과 같은 기준들을 가리킬 수도 있다.

더 구체적으로, 유저는 가상 키보드를 사용하여 PDA 상에서 실행되는 Navigator 소프트웨어에 보통의 방식으로 그 유저의 출발 위치와 요구되는 목적지를 입력한다. 그리고 나서 유저는 진행 경로가 계산되는 방식을 선택한다: 다양한 모드들이 제공되는데, 예컨대 매우 빠르게 그 경로를 계산하지만, 그 경로가 가장 짧지 않을 수도 있는 '빠름' 모드, 모든 가능한 경로들을 조사하고 최단거리를 밝혀내지만, 계산하는 것 등을 위해 더 오래 걸리는 '완전' 모드 등이 제공된다. 다른 옵션들도 가능한데, 여기서 유저는, 눈에 띄게 아름다운 경치들로서 마킹된 최고의 POI(point of interest)를 통과하거나 또는 어린이들에게 가능한 관심대상인 최고의 POI들을 통과하는, 경치가 아름다운 경로를 정의하거나 가장 적은 수의 교차점(junction)들을 이용하는 등의 경로를 정의할 수 있다.

도로들은 자체적으로, 선들 - 즉 벡터들(예: 이는 시작점, 종점, 도로 방향으로서, 여기서 완전한 도로는 수백 개의 이러한 부분들로 이루어지고, 그 각각은 시작점/종점 방향 파라미터들에 의해 고유하게 정의됨)로서, PDA 상에서 실행되는 Navigator의 일부인 (또는 그와 달리 그것에 의해 액세스되는) 맵 데이터베이스에서 그려진다. 그때 맵은 이러한 도로 벡터들과, 추가적으로 POI들, 도로 이름들, 공원 경계, 강 경계 등과 같은 다른 지리적 특징들의 집합으로, 이들 모두는 벡터로 정의된다. 모든 맵 특징들(예: 도로 벡터들, POI들 등)은 GPS 좌표 시스템에 대응되는 또는 그에 관련되는 좌표 시스템에서 정의되어, GPS 시스템을 통하여 결정된 디바이스의 위치를 맵에서 보이는 관련 도로 상에 위치시키는 것을 가능하게 한다.

도로 계산은 Navigator 소프트웨어의 부분인 복잡한 알고리즘들을 이용한다. 그 알고리즘들은 많은 잠재적인 상이한 경로들을 점수기록하도록(score) 적용된다. 그 후에 Navigator 소프트웨어는, 경치가 아름다운 경로, 역사 박물관들이 있지만 과속 감시 카메라는 없는, 완전 모드 스캔(scan)과 같은 유저 정의 기준들(또는 디바이스 디폴트(default)들)과 대비하여 그것들을 평가한다. 그러면 그 정의된 기준들을 가장 잘 부합시키는 경로는 PDA 내 프로세서에 의해 계산되고 그 후에 도로 이름들, 벡터 종점들에서 행해질 동작들(예: 100미터 후에 거리 x로 왼쪽으로 회전하라는 것과 같이, 그 경로의 각 도로를 따른 기결정된 거리들에 대응됨), 및 벡터들의 시퀀스로서 RAM 내 데이터베이스에 저장된다.

도 6a 및 도 6b는 내비게이션 디바이스의 실제 구현에 관한 사시도들이다. 그 내비게이션 디바이스는 디스플레이, 내부 GPS 수신기, 마이크로프로세서, 전원장치(power supply) 및 메모리 시스템들을 포함하는 유닛이다. 그 디바이스는 거치대(arm)에 위치하게 되고, 그 거치대는 큰 흡착기(suction cup)를 사용하여 차의 대시보드(dashboard)에 자체적으로 고정된다.

- 시스템 아키텍처

대용량 마스크 ROM(mask ROM) 또는 플래쉬(Flash) 디바이스로부터 적소에서 모든 OS 및 애플리케이션 코드를 실행하는 기존의 엠베디드 디바이스들과 대조적으로, 본 발명의 구현에서는 새로운 메모리 아키텍처를 사용한다. 도 7은 그 디바이스를 도식적으로 묘사하고 있다. 그 디바이스 - 전체로서 51로 표시됨 - 는 마이크로프로세서(56), 전원 소스(57), 디스플레이 및 관련 드라이버들(58)과 같은 기존의 항목들을 포함한다. 또한, 그것은 SD 카드 리더(53)를 포함한다; SD 카드(52)는 안쪽에 넣어져 있는 것으로 나타나 있다. 디바이스(51)는 내부 DRAM(54) 및 XIP 플래쉬(55)를 구비하고 있다.

따라서, 그 디바이스는 다음과 같은 메모리에 관한 3가지 상이한 형태들을 이용한다:

1. 소량의 내부 XIP(eXecute In Place) 플래쉬 ROM(55). 이것은 PC의 BIOS ROM과 유사하고 단지 독점적인 부트 로더(boot loader), (UID 및 제조 데이터를 위한) E² 에뮬레이션(emulation) 및 스플래쉬 스크린 비트 맵(splash screen bit map)들만을 포함할 것이다. 이것은 256 KB 크기일 것으로 추정되고 느린 8비트 폭의 SRAM 인터페이스에 접해 있을 것이다.

2. 메인 시스템 RAM(또는 DRAM) 메모리(54)로, 이것은 PC의 메인 메모 리(RAM)와 유사하다. 이것은 OS 및 애플리케이션들을 위한 비디오 RAM 및 워크스페이스(workspace)를 제공할 뿐만 아니라 모든 메인 코드가 실행되는 곳일 것이다. 주의: 어떠한 영속적인 유저 데이터도 (PC처럼) 메인 시스템 RAM에 저장되지 않을 것으로, 즉 어떠한 "램 드라이브"(Ram drive)도 없을 것이다. 이 RAM은 오직 32비트 100MHz 동기식 고속 버스(high-speed bus)에만 연결될 것이다.

3. 비휘발성 저장소로, 이는 PC의 하드 디스크와 유사하다. 이것은 분리형 NAND 플래쉬 기반 SD 카드들(52)로서 구현된다. 이들 디바이스들은 XIP를 지원하지 않는다. 모든 OS, 애플리케이션, 세팅(setting) 파일들 및 맵 데이터는 SD 카드들 상에 영구히 저장될 것이다.

부팅 시에 독점적 부트 로더(55)는 공급된 SD 카드(52)를 유저가 삽입하도록 자극한다(prompt). 이것이 행해진 때, 그 디바이스는 SD 카드(52)로부터 특정 시스템 파일을 RAM(54)에 복사할 것이다. 이 파일은 운영 시스템(Operating System) 및 내비게이션 애플리케이션을 포함할 것이다. 일단 이것이 완료되면 애플리케이션으로 제어가 넘어갈 것이다. 그러면 그 애플리케이션이 시작되어 비휘발성 데이터, 예로서 SD 카드(52)로부터의 맵들을 액세스한다.

그 디바이스가 그 후에 꺼지도록 스위치될 때, RAM(54) 콘텐츠는 유지보존되고 그래서 이 부팅 절차는 단지 처음 그 디바이스를 사용할 때만 일어난다.

- GO 제품 사양

- 서설

GO는 독립형의 완전히 통합된 개인 내비게이션 디바이스이다. 그것은 차량에 대한 어떠한 연결에 대해서도 독립적으로 작동할 것이다.

- 타깃 시장

GO는 일반적인 개인 내비게이션 시장에 초점을 맞추도록 의도된 것이다. 특히 그것은 "얼리 어답터"(early adopter) 시장을 넘어 개인 내비게이션을 위한 시장을 확장하기 위해 계획된 것이다. 이와같이 그것은 완전한 독립형 솔루션이다; 그것은 인터넷 연결 또는 PC나 PDA에 대한 액세스를 필요로 하지 않는다. 완전성 및 사용의 용이성에 중점이 두어질 것이다.

비록 GO가 완전한 개인 내비게이션 솔루션임에도 불구하고, 그것은 주로 차량에서 사용되는 경우를 위해 의도된다. 주요 타깃 시장은 비즈니스나 아니면 취미(오락)를 위해 차량을 운전하는 자 누구든지이다.

성공적으로 이 시장을 다루기 위하여 GO는 다음의 최고 수준의 요구조건들을 만족시켜야 한다:

1. 수용가능한 기준 소매 가격(price point) - 제품 특징들 및 비용 간의 적절한 타협

2. 단순성 - GO의 설치 및 작동은 단순하고 직관적일 것, 모든 주요 기능들은 제품 메뉴얼에 의지하지 않으면서 PC 지식이 없는 평균적인 유저에 의해 이루어져야 함.

3. 유연성(flexibility) - 모든 맵 데이터 및 운영 프로그램들은 메모리 카드들 내 플러그 상에서 공급될 것. 그 디바이스는 서로 다른 지역들을 커버하도록 용이하게 확장될 수 있음.

4. 신뢰성(reliability) - 비록 차내 내비게이션 시스템들이 안전을 보장하는 결정적인 컴포넌트들로 고려되지 않음에도 불구하고 유저들은 GO에 의존하게 될 것이다. 그것은 모든 관련 자동차 환경 표준들대로 만들어질 것이다. 게다가 그것은 짧은 GPS 커버리지 불능(outage)을 견딜 것이다.

- 채널들

· 소비자 전자제품 소매 아웃렛들

· 자동차 악세서리 아웃렛들

· 전문 자동차 액세서리 정비 공장들

- 제품 요약

GO는 차량내 개인 내비게이션 디바이스이다. 그것은, 말하자면, 범용 목적보다는 오히려 특정 기능을 위한 전자제품으로서 계획된다. 그것은 소비자 판매후의 자동차 시장을 위해 계획된다. 그것은 최종 유저에 의해 사용하고 설치하기 단순할 것이지만, 전문적인 맞춤 킷(fitting kit)이 선택적으로 공급될 것이다.

주요한 특징들은 다음과 같다:

· 표준 상품의 포켓PC 2002 컴포넌트들을 기초로 함

· 가로형(landscape orientation)으로 설치된 표준 포켓PC 3.5인치 1/4VGA 반투과성(transflective) TFT LCD 디스플레이

· ROM없는(ROMless) 소프트-부트(soft-boot) 메모리 아키텍처

· 고도로 집적된 ARM9 200MHz CPU

· 애플리케이션 및 맵 데이터 저장을 위한 SD 카드 메모리 슬롯

· 통합된 GPS 수신기 및 안테나

· 단순한 추측 항법(dead reckoning)을 위한 통합된 2개 축 가속도계

· 유닛의 기부(base) 상에서 도킹 커넥터(docking connector)를 통해 만들어진 외부 GPS 안테나 연결들, 전원, 오디오 및 디버그(debug)

· 어떠한 GUI 층도 가지지 않은 엠베디드 리눅스 OS, 애플리케이션이 그 자신의 UI를 제공함

· 손가락으로 사용하기에 최적화된 매우 단순한 터치 스크린 UI

· 음성 지시를 위한 고품질의 통합 스피커

· 최소한 5시간의 연속 작동을 부여하는 내부의 충전가능한 리튬-이온 배터리.

- 운영 시스템

GO는 엠베디드 리눅스의 커스터마이징된 버전을 사용할 것이다. 이것은 플래쉬 메모리에 있는 커스텀(custom) 부트-로더 프로그램에 의해 SD 카드로부터 로딩될 것이다.

- 하드 버튼( hard button )들

GO는 단지 하나의 하드 버튼인 전원 버튼을 가질 것이다. 그것은 GO를 켜거나 끄기 위해 한 번 눌러진다. UI는 모든 다른 동작들이 펜(pen) 기반 UI를 통해 용이하게 액세스가능하도록 설계될 것이다.

또한 숨겨진 하드 리셋 버튼도 있을 것이다.

- 아키텍처

GO 아키텍처는 모바일 컴퓨팅 디바이스들을 위해 설계된 고도로 집적된 단일 칩 프로세서에 기초한다. 이 디바이스는 산업 표준인 ARM920T 프로세서로부터 약 200 MIP의 성능을 전달한다. 그것은 또한 GPS 기저대역(base-band)을 제외하고 요구되는 모든 주변기기들을 포함한다. 이들 주변기기들은 DRAM 콘트롤러, 타이머/카운터들, UART들, SD 인터페이스 및 LCD 콘트롤러를 포함한다.

이 아키텍처의 주요 요소들은 다음과 같다:

· 200MHz로 실행되는 마이크로프로세서

· 저전력 자가 리프레쉬(refresh)를 갖는 32MB 또는 64MB의 고속 동기식 DRAM (SDRAM); 32비트 폭 100MHz 버스 상에 2개 디바이스들로서 구성됨

· OS를 포함하는 모든 비휘발성 저장소를 위한 SD 카드 인터페이스 (RAM 드라이브는 아님)

· 256KB의 NOR 플래쉬에 저장된 원래상태의(native) (저장내용 없는(bare metal)) 부트 로더. 이 플래쉬 디바이스는 고유한 제품 ID 및 제조 데이터와 같은 보호 데이터를 저장하기 위해 쓰기 금지된 부트 섹터(boot sector)를 포함할 것이다.

· 도킹 커넥터에 연결된 디버그 UART(RS232 3V 레벨)

· PC 접속을 위한 USB 클라이언트

· 통합된 GPS 수신기

· 통합된 2개 축 가속도계

· PDA 및 모바일 전화 접속을 위한 선택적인 통합 블루투스 트랜시버

· I²S 코덱 및 증폭기를 통한 고품질 오디오

도 8은 GO 블록도이다.

- 전력 관리

GO는 통합된 리튬-이온 2200 mAH 충전가능 배터리로부터 전력을 공급받을 것이다. 이 배터리는 충전될 수 있고, 그 디바이스는 외부에서 공급되는 +5V 전원으로부터 (그 배터리가 어떠한 충전도 포함하고 있지 않을지라도) 전력을 공급받는다. 이 외부 +5V 전원은 도킹 커넥터 또는 DC 잭 소켓을 통해 공급된다.

+5V 공급은 차량의 주 공급 레일(rail)로부터 또는 외부에서의 간선 어댑터(mains adapter)로부터 생성될 것이다. 그 디바이스는 단일 버튼에 의해 켜지고 꺼질 것이다. 그 디바이스가 꺼질 때 DRAM 콘텐츠는 자가-리프레쉬하는 RAM을 둠으로써 유지보존될 것이어서, 켜지도록 스위치될 때에는 GO는 그것이 꺼지도록 스위치되었던 데에서부터 재개할 것이다(resume). 또한 도킹 커넥터를 통해 이용가능한 웨이크업(wake-up) 신호가 있을 것이고, 이것은 차량 점화장치가 켜지도록 스위치될 때 GO를 자동으로 켜지게 스위치하는데 사용될 수 있다.

또한 작은 숨겨진 리셋 스위치도 있을 것이다.

- 시스템 메모리 아키텍처

대용량 마스크 ROM 또는 플래쉬 디바이스로부터 적소에서 모든 OS 및 애플리케이션 코드를 실행하는 기존의 엠베디드 디바이스들과 대조적으로, GO는 PC에 훨 씬 더 가까운 새로운 메모리 아키텍처에 기반할 것이다.

이것은 다음과 같은 메모리에 관한 3가지 형태들로 이루어질 것이다:

4. 소량의 XIP(eXecute In Place) 플래쉬 ROM. 이것은 PC의 BIOS ROM과 유사하고 단지 독점적인 부트 로더, (UID 및 제조 데이터를 위한) E² 에뮬레이션 및 스플래쉬 스크린 비트 맵들만을 포함할 것이다. 이것은 256 KB 크기일 것으로 추정되고 느린 8비트 폭의 SRAM 인터페이스에 접해 있을 것이다.

5. 메인 시스템 메모리로, 이것은 PC의 메인 메모리(RAM)와 유사하다. 이것은 OS 및 애플리케이션들을 위한 비디오 RAM 및 워크스페이스를 제공할 뿐만 아니라 모든 메인 코드가 실행되는 곳일 것이다. 주의: 어떠한 영속적인 유저 데이터도 (PC처럼) 메인 시스템 RAM에 저장되지 않을 것으로, 즉 어떠한 "램 드라이브"도 없을 것이다. 이 RAM은 오직 32비트 100MHz 동기식 고속 버스에만 연결될 것이다. GO는 128 MB (32비트 폭) 및 64MB 32비트 폭과 32MB (16비트 폭)의 16비트 폭 256/512Mbit SDRAM의 허용 메모리 구성들을 위한 2개의 위치(site)들을 포함할 것이다.

6. 비휘발성 저장소로, 이는 PC의 하드 디스크와 유사하다. 이것은 분리형 NAND 플래쉬 기반 SD 카드들로서 구현된다. 이들 디바이스들은 XIP를 지원하지 않는다. 모든 OS, 애플리케이션, 세팅 파일들 및 맵 데이터는 SD 카드들 상에 영구히 저장될 것이다.

- 오디오

52 mm 직경의 스피커가 GO 내에 수용되어 양질의 음성 지시를 부여한다. 이것은 내부 증폭기 및 오디오 코덱에 의해 작동될 것이다. 오디오 라인 아웃(line out)도 또한 도킹 커넥터 상에 존재할 것이다.

- SD 메모리 슬롯

GO는 하나의 표준 SD 카드 소켓을 포함할 것이다. 이들은 시스템 소프트웨어를 로딩하기 위해 그리고 맵 데이터를 액세스하기 위해 사용된다.

- 디스플레이

GO는 반투과성 3.5인치 TFT 백라이트(backlit) 디스플레이를 이용할 것이다. 그것은 포켓PC PDA에 의해 사용되는 '표준' 1/4VGA 디스플레이일 것이다. 그것은 또한 터치 패널(touch panel) 및 밝은 CCFL 백라이트를 포함할 것이다.

- 전력 공급

- 전력 공급 - AC 어댑터 소켓

4.75V 내지 5.25V (5.00V +/- 5%) @ 2A

- 전력 공급 - 도킹 커넥터

4.75V 내지 5.25V (5.00V +/- 5%) @ 2A

- 변형예들

GO에 관한 다음 변형예들을 결집하고 테스트하는 것이 가능하여야 할 것이다:

- 표준 (블루투스 미탑재, 32 Mbyte RAM )

표준 변형예에서 블루투스 기능이 탑재되지 않아서, 32 Mbyte RAM이 적합하 다.

- 블루투스 옵션 (미래의 변형예 )

비록 BOM 비용을 최소화하기 위하여 표준 변형예에서 블루투스가 탑재되지 않지만 이 제품 설계는 블루투스를 포함하여야 할 것이다. 그 설계는 블루투스 기능이 작동하고 있을 때 모든 다른 기능들(GPS RF 성능 포함)이 저하됨이 없이 작동함을 보증하여야 할 것이다.

- 64 Mbyte RAM 옵션 (미래의 변형예 )

이 제품 설계는 32Mbyte 대신에 64Mbyte RAM에 적합시키는 것이 가능함을 보증하여야 할 것이다.

- 하위부품들(subassemblies)

GO는 도 9에서 보이는 바와 같이 다음의 전기적 하위부품들로 이루어져 있다.

- RF 케이블

RF 케이블은 외부 GPS 안테나(이는 RF 도킹 커넥터를 거쳐 GO에 연결됨)로부터의 RF 신호를 GPS 모듈이 위치해 있는 RF PCB로 피드한다.

- 외부 커넥터들

- 도킹 커넥터들

2개의 도킹 커넥터들은 외부의 도킹 스테이션(Docking Station)들에 대한 인터페이스를 제공한다.

- 도킹 커넥터 #1의 핀아웃( pinout )

Pin	Signal	Dir	Type	설명
1	GND	-	-	신호 및 전력 GND
2	GND	-	-	신호 및 전력 GND
3	DOCKSNS1	I/P	PU	도킹 스테이션 의미(Sense) [0,1] - 이들 신호들은 장치 내 풀업(pull-up) 저항기들에 연결된다. 도킹 스테이션은 도킹 스테이션의 존재 및 유형을 나타내기 위해 이들 신호들 중 어느 하나 또는 양자 모두를 GND로 이끈다(pull).
4	DOCKSNS0	I/P	PU
5	AUDIOL	O/P		차 오디오 시스템에 연결할 오디오 라인 출력들(왼쪽(Left) 및 오른쪽(Right))
6	AUDIOR	O/P		차 오디오 시스템에 연결할 오디오 라인 출력들(왼쪽(Left) 및 오른쪽(Right))
7	MUTE	O/P	O/D	장치는 그 장치가 음성 명령을 제기하고 있는 동안 차 오디오 시스템이 그 차 오디오 시스템 자체를 뮤팅(muting)하도록 신호하기 위해 이 라인을 GND로 이끈다.
8	IGNITION	I/P	PD	점화 의미
9	DOCKPWR	I/P	PWR	장치에 전력을 공급하고 동시에 배터리를 충전하기 위해 도킹 스테이션으로부터의 +5V 전력
10	DOCKPWR	I/P	PWR	장치에 전력을 공급하고 동시에 배터리를 충전하기 위해 도킹 스테이션으로부터의 +5V 전력

여기서 PWR은 전력 연결(Power connection)을, PU는 그 장치 내 풀업 저항기(Pull-Up resistor), O/D는 개방-드레인 출력(Open-Drain output), 그리고 PD는 그 장치 내 풀다운 저항기(Pull-Down resistor)를 의미한다.

- 도킹 커넥터 #2의 핀아웃

Pin	Signal	Dir	Type	설명
1	TXD	O/P	UART	3V 로직 레벨 UART 신호들
2	RXD	I/P	UART
3	RTS	O/P	UART
4	CTS	I/P	UART
5	GND	-	PWR
6	nTRST	I/P	JTAG	테스트 및 설정(configuration)을 위한 CPU JTAG 신호들
7	TMS	I/P	JTAG
8	TCK	I/P	JTAG
9	TDI	I/P	JTAG
10	TDO	O/P	JTAG

- RF 도킹 커넥터

RF 도킹 커넥터는 도킹 스테이션을 경유하여 외부의 활성화 GPS 안테나를 연결하는 것을 가능하게 해 준다.

- AC 어댑터 소켓

AC 어댑터 소켓은 전력이 저비용의 AC 어댑터 또는 CLA(Cigarette Lighter Adapter)로부터 공급되는 것을 가능하게 해 준다.

- USB 커넥터

USB 커넥터는 표준의 미니 USB 케이블로 PC에 연결하는 것을 가능하게 해 준다.

- SD 카드 소켓

고진동 적용에 적합한 하드 로킹(hard locking) SD 카드 소켓은 SDIO, SD 메모리 및 MMC 카드들을 지원한다.

(비록 GO가 SDIO에 대한 하드웨어 지원을 제공하지만, 소프트웨어 지원은 제품 도입 시에 이용가능하지 않을 것이다)

- 프로세서

프로세서는 약 200Mhz에서 작동하는 ARM920T 기반 SOC(System on chip)이다.

- RAM

GO는 RAM에 관하여 다음의 명세에 적합될 것이다:

유형	저전력 리프레쉬를 가지는 SDRAM ("모바일" SDRAM)
총 메모리	32 Mbyte (표준) 또는 64 Mbyte (미래 옵션)
버스 폭(Bus width)	32비트
최소 속도	100Mhz
최대 자가 리프레쉬 전류	디바이스당 500μA
설정	2×16비트 폭 CSP 사이트들

- 플래쉬 메모리

GO는 다음을 포함할 최소 256kbyte의 16비트 폭 플래쉬 메모리로 적합될 것이다:

· SD 카드로부터 O/S의 로딩을 할 수 있게 하는 부트 로더 코드

· 공장에서 세팅된 읽기전용으로 보호되는 제조 파라미터들(예: 제조일) 및 고유 ID (E2PROM 에뮬레이션)

· 유저 특정 세팅들(user specific settings) (E2PROM 에뮬레이션)

다음의 디바이스들이 가격 및 이용가능성에 따라 사용될 수 있다:

- GPS 내부 안테나

GPS 내부 안테나는 RF PCB에 직접 달린다.

- GPS 외부 (활성화) 안테나 스위칭

외부 안테나가 RF 도킹 커넥터를 통해 연결될 때, GPS 안테나 소스는 자동적으로 외부 안테나로 스위칭된다.

- 가속도계

고체 상태 가속도계는 속도 및 방향 변경에 관한 정보를 제공하기 위해 프로세서에 직접 연결된다.

- 보조 기능들

- 점화 동기화

점화 웨이크업

도킹 스테이션 IGNITION 신호 상의 상승 에지(rising edge)는 장치를 웨이크업할 것이다. IGNITION 신호는 12V 또는 24V 차량 배터리에 연결될 수도 있다.

점화 상태 모니터링

도킹 스테이션 IGNITION 신호의 상태가 탐지되고 그리고 그 점화(ignition) 신호가 로우(low)가 될 때 소프트웨어가 장치를 끄게 할 수 있게 하기 위해 GPIO 핀으로 피드된다.

- 표준 주변기기들

다음의 주변디바이스들이 GO에 관하여 표준으로서 포함될 것이다.

·단순한 도킹 슈(shoe). GO를 설치하고 DC 잭을 통해 충전하는 것을 가능하게 해 줌. 어떠한 다른 연결도 그 단순 잭에 포함되지 않음.

· DC 잭 소켓 또는 단순 도킹 슈를 통해 GO에 연결하고 있는 담배 라이터 전원 케이블

· PC 접속을 위한 미니 USB 케이블

· DC 잭 소켓으로의 연결을 위한 보편적인 간선 어댑터(universal mains adapter).

- 선택적 주변기기들

다음의 선택적인 주변디바이스들이 GO의 응용프로그램 시작 시간에 또는 그 후에 이용가능할 것이다.

·활성화 안테나 킷. 이는 적합한 케이블 및 GPS RF 커넥터를 가진 도킹 슈 및 GPS 활성화 안테나를 포함. 외부 안테나가 요구될 때 자가 설치를 위한 것.

·전문적인 차량 도킹 킷. 단지 전문적인 설치에 적합하기 위한 것임. 차량 인터페이스 박스(interface box)를 거쳐 차량 전원(supply), 오디오 시스템 및 활동 안테나에 대한 직접 연결을 허용.

- 부록 2

Map Share 고수준 요구조건들(0.40)

- 서론

TomTom은 소비자들에게 이용가능한 가장 정확한 맵 데이터를 제공하려고 노력한다. 현재, 맵 업데이트들이 TomTom 맵 공급자들에 의해 이루어지고 있고, TomTom은 Tele Atlas로 보고 툴을 거쳐 어떤 맵들에서의 오류들을 피드백할 수 있다. 이 상황은 맵 오류가 정정되기 전에 몇몇 맵 개정들을 행할 수도 있고, TomTom 오류 보고들의 결과로서 이루어지는 모든 정정들도 또한 경쟁자들과 공유되기 때문에 이상적인 것과는 거리가 멀다. TomTom이 스케줄대로 맵 업데이트들을 제공하기 위해서, 새로운 맵 오류 보고 및 정정 시스템이 요구된다. 이들 개선점들은 Map Share 프로젝트를 통해 전해질 것이다.

1.1 범위

여기서는 Map Share 프로젝트의 고수준 요구조건들을 설명하고 있다.

2 고수준 요구조건들

이 섹션은 Map Share의 고수준 요구조건들을 설명하고 있다.

2.1 유저 요구조건들

이 섹션은 Map Share를 위한 유저 요구조건들을 설명하고 있다.

2.1.1 맵 정정들

어떤 맵 오류들은 유저에 의해 즉각적으로 정정될 수 있다. 이 섹션은 맵 정정들에 관련된 유저 요구조건들을 설명하고 있다.

2.1.1.1 디바이스상 맵 정정들

유저는 그들의 NavCore 디바이스 상에서 맵 정정을 행할 수 있어야 할 것이다.

2.1.1.2 TomTom Home 맵 정정들

유저는 TomTom Home 애플리케이션의 Navigator 제어 안에서 맵 정정을 행할 수 있어야 할 것이다.

2.1.2 맵 정정 유형들

이 섹션은 행해질 수 있는 맵 정정의 유형들에 관련된 유저 요구조건들을 기술하고 있다.

2.1.2.1 안전 카메라 추가

유저는 맵 상에 안전 카메라들의 위치들을 추가할 수 있어야 할 것이다.

주의: 이러한 식으로 안전 카메라들을 보고하는 것은 이미 가능한 것이지만, 그 구현은 보고 절차를 단순화하기 위해 조정되어야 하고, 그것을 다른 맵 정정들과 일관성 있게 만들어주고 유저들이 즉각적으로 보고했던 안전 카메라들을 유저들로 하여금 볼 수 있게 해 준다.

2.1.2.2 도로를 통행금지시킴

유저는 맵 상의 도로들을 통행금지할 수 있어야 할 것이다.

2.1.2.3 도로를 통행금지해제시킴

유저는 맵 상의 도로들을 통행금지해제할 수 있어야 할 것이다.

2.1.2.4 교통 방향 수정

유저는 맵 상에 도로들의 교통 방향 속성들을 수정할 수 있어야 할 것이다.

구체적으로 유저는 다음을 할 수 있어야 할 것이다:

· 양방향 도로를 단방향 도로로 변경 (어느 한쪽 방향으로)

· 단방향 도로를 양방향 도로로 변경

· 단방향 도로의 방향을 그와 다른 방향으로 변경.

2.1.2.5 도로 추가

유저는 맵 상에 도로(하나 이상의 노드들로 이루어짐)를 추가할 수 있어야 할 것이다.

2.1.2.6 도로 연결

유저는 맵 상에 2개의 점들을 연결하여 새로운 링크를 새로운 도로로서 정의할 수 있어야 할 것이다.

2.1.2.7 거리명 추가

유저는 거리명들을 맵 상의 이름없는 거리들에 추가할 수 있어야 할 것이다.

2.1.2.8 거리명 수정

유저는 맵 상의 도로명들을 수정할 수 있어야 할 것이다.

2.1.2.9 속도 제한 수정

유저는 맵 상에서 도로들의 최대 속도를 수정할 수 있어야 할 것이다.

2.1.3 디바이스상 정정들의 이용가능성

일단 맵 정정들이 NavCore 디바이스 상에 존재한다면, 그것들은 유저에게 이용가능하게 되어야 한다. 이 섹션은 디바이스상 정정들의 이용가능성에 관련된 유 저 요구조건들을 설명하고 있다.

2.1.3.1 사적 정정들의 이용가능성

유저는 사적 정정들이 기록되자마자 그 사적 정정들을 사용할 수 있어야 할 것이다.

2.1.3.2 공적 정정들의 이용가능성

유저는 공적 정정들이 디바이스로 다운로드되자마자 그 공적 정정들을 사용할 수 있어야 할 것이다.

2.1.4 맵 정정들의 사용

어떤 맵 정정들이 다른 TomTom 소유자들에 의해 이루어졌을 수도 있기 때문에, 유저는 경로들을 계산시 어느 정정들을 사용할 것인지를 선택할 수 있어야 한다. 이 섹션은 유저 디바이스 상의 맵 정정들의 사용에 관련된 유저 요구조건들을 설명하고 있다.

2.1.4.1 안전 카메라 경고

유저는 사적 및/또는 공적 피보고 안전 카메라들에 대한 경고들을 수시할지 여부를 선택할 수 있어야 할 것이다.

2.1.4.2 사적 맵 정정 사용

유저는 그들이 정정을 포함한 경로를 계획할 때에는 어느 때라도 그들의 사적 맵 정정들을 사용하거나 무시할 수 있어야 할 것이다.

2.1.4.3 공적 맵 정정 사용

유저는 그들이 정정을 포함한 경로를 계획할 때에는 어느 때라도 그들의 공 적 맵 정정들을 사용하거나 무시할 수 있어야 할 것이다.

2.1.4.4 자동적인 맵 정정 사용

유저는 하나 이상의 카테고리들로부터의 사적 및/또는 공적 정정들이 자동적으로 경로 계산 내에 포함되도록 그들 디바이스를 설정할 수 있어야 할 것이다. 유저는 그들이 정정들을 사용하고 있음을 알고 있어야 할 것이다.

2.1.4.5 경로 재계산

유저는 맵 정정들을 포함하거나 또는 배제하도록 경로들을 재계산할 수 있어야 할 것이다.

2.1.4.6 맵 정정 제거

유저는 그들 디바이스로부터 맵 정정을 편집하거나 제거할 수 있어야 할 것이다.

2.1.5 맵 오류 보고

어떤 맵 오류들은 스케일(scale)에 있어서 너무 복잡하거나 또는 커서 디바이스 그 자체 상에서 정정을 행할 수 없다. 우리(또는 우리의 맵 공급자들)가 정정 활동을 할 수 있기 위해, 이들 오류들은 TomTom에 보고될 필요가 있다. 이 섹션은 맵 오류 보고에 관련된 유저 요구조건들을 설명하고 있다.

2.1.5.1 디바이스상 맵 오류 보고

유저는 그들 디바이스 상에서 맵 오류 보고들을 생성하고 이것들을 TomTom PLUS 서버에 업로드할 수 있어야 할 것이다.

주의: 유저는 운전하는 동안 맵 오류 보고들을 생성할 수 없어야 할 것이다.

주의: 디바이스 상에서 오류 보고들을 생성시 기정의된 오류 유형들의 리스트를 유저들에게 제공하는 것이 수용될 것이다.

2.1.5.2 TomTom Home 맵 오류 보고

유저는 TomTom Home의 Navigator 제어 내에서 맵 오류 보고들을 생성하고 이것들을 TomTom PLUS 서버에 업로드할 수 있어야 할 것이다.

주의: 유저는 맵 오류 보고를 생성하기 위해 TomTom 소비자로서 등록하여야 하는 것은 아니어야 할 것이다.

2.1.5.3 TomTom Home 에 디바이스상 오류 보고들의 가져오기( importing )

유저는 그들 디바이스 상에서 포착된 맵 오류 보고들을 TomTom Home 애플리케이션으로 가져오기할 수 있어야 할 것이다. 유저는 이들 보고들을 편집하여 그 후에 그것들을 TomTom PLUS 서버에 업로드할 수 있어야 할 것이다.

2.1.5.4 맵 오류 보고 피드백

유저는 그들의 맵 오류 보고들에 관하여 피드백이 주어져야 할 것이다.

2.1.6 자동적인 맵 오류 식별

어떤 환경들에서는 TomTom 디바이스가 그 제품의 사용에 기초하여, 유저에게 정정들을 제안하는 것이 가능하다. 이 섹션은 맵 오류들의 자동적인 식별에 관련된 유저 요구조건들을 설명하고 있다.

2.1.6.1 자동적인 도로 통행금지 제안

유저는 여러 차례 경로 계획들 내 그들이 피하기를 선택하는 도로들을 통행금지하도록 자극되어야(prompted) 할 것이다.

2.1.6.2 자동적인 도로 생성 제안

유저는 여러 차례 그들이 도로로서 마킹되지 않은 맵 구역을 지나며 운전한다면 그 맵 상에서 도로를 추가하도록 자극되어야 할 것이다.

2.1.6.3 자동적인 도로명 제안

유저는 여러 차례 그들이 이러한 도로에 대한 경로들을 계획한다면 그 맵 상에서 이름없는 도로들에 이름을 덧붙이도록 자극되어야 할 것이다.

2.1.6.4 자동적인 속도 제한 수정 제안

유저는 여러 차례 그들이 맵 데이터에서 지정된 것과 상당히 다른 속도로 도로를 따라 운전한다면 그 도로의 속도 제한을 수정하도록 자극되어야 할 것이다.

2.1.7 맵 정정 공유

Map Share의 유저들은 다른 TomTom 소유자들과 그들의 정정들을 공유하기를 희망한다. 이 섹션은 다른 TomTom 소유자들과 맵 정정들을 공유할 수 있는 유저 능력에 관련된 유저 요구조건들을 설명하고 있다.

2.1.7.1 사적 맵 정정들

유저는 그들의 개인적인 사용만을 위한 정정들을 생성할 수 있어야 할 것이다. 이들 정정들은 TomTom PLUS 서버에 송신되어서는 안될 것이다.

2.1.7.2 공적 맵 정정들

유저는 다른 TomTom 소유자들과 공유되는 정정들을 생성할 수 있어야 할 것이다. 이들 정정들은 TomTom PLUS 서버에 업로드되어 다른 Map Share 유저들에게 이용가능해져야 할 것이다.

2.1.7.3 공적 맵 정정 커뮤니티 분류

유저는 적용가능한 유저 커뮤니티에 따라 그들의 공적 맵 정정들을 분류할 수 있어야 할 것이다. 다음의 커뮤니티 카테고리들이 이용가능하게 되어야 할 것이다:

· 모든 유저들

· 모든 자동차 운전자들

· 대형 수송차 운전자들

· 오토바이 운전자들

· 제한 속도 차량 운전자들

· 보행자들

· 자전거들

2.1.7.4 신뢰받는 유저 지위

유저는, 그들이 업로드한 맵 정정들의 수와 질에 기초하여, "신뢰받는 유저" 지위를 획득할 수 있어야 할 것이다.

2.1.7.5 맵 정정 정보

유저는 그들이 사용하고 있는 맵 데이터의 더 새로운 버전에서 정정되었던 맵 정정을 보고하려고 시도하는지를 알아야 할 것이다. 유저는 또한 그들이 업데이트된 맵을 어떻게 구입할 수 있을지를 알아야 할 것이다.

2.1. 8 맵 정정 검색

공적 맵 정정들을 사용하기 위해 유저는 TomTom PLUS 서버로부터 그것들을 검색하여야 한다. 이 섹션은 맵 정정 검색에 관련된 유저 요구조건들을 설명하고 있다.

2.1.8.1 공적 맵 정정 검색

유저는 TomTom PLUS 서버로부터 그들의 디바이스로, 그리고 TomTom Home 애플리케이션으로 공적 맵 정정들을 다운로드할 수 있어야 할 것이다.

2.1.8.2 공적 맵 정정 컴퓨니티 카테고리 검색

유저는 하나 이상의 커뮤니티 카테고리들로부터 공적 맵 정정들을 다운로드할 수 있어야 할 것이다.

주의: 공적 정정 커뮤니티 카테고리들은 섹션 2.1.7.3에 정의되어 있다.

2.1.8.3 공적 맵 정정 소스 카테고리 검색

유저는 하나 이상의 커뮤니티 소스 카테고리들로부터 공적 맵 정정들을 다운로드할 수 있어야 할 것이다.

주의: 공적 정정 소스 카테고리들은 섹션 2.2.1.5에 정의되어 있다.

2.1.8.4 공적 맵 정정 공급자 카테고리 검색

유저는 하나 이상의 맵 공급자 소스 카테고리들로부터 공적 맵 정정들을 다운로드할 수 있어야 할 것이다. 공급자 카테고리는 각각의 TomTom 맵 공급자에 대해 제공되어야 할 것이다.

2.1.8.5 공적 맵 정정 위치 카테고리 검색

유저는 하나 이상의 위치 카테고리들로부터 공적 맵 정정들을 다운로드할 수 있어야 할 것이다.

주의: 다음의 카테고리들이 이용가능할 것이다:

· 모든 맵들

· 디바이스 상의 모든 맵들

· 디바이스 상에 현재 로딩된 맵

2.2 기술적 제약( Technical Constraint )들

Map Share 내 어떤 특징들은 유저 요구조건들을 다루고 TomTom의 이익을 보호하기 위해 특정 방법으로 구현되어야 한다. 이 섹션은 Map Share의 V1 범위에 두어진 모든 알려진 기술적 제약들을 설명하고 있다.

2.2.1 공적 맵 정정 관리

유저들로 하여금 공적 맵 정정들에 관련된 결정들을 알게 해 주기 위해, Map Share는 이들 정정들을 관리하여야 한다. 이 섹션은 맵 정정 분류에 관련된 제약들을 설명하고 있다.

2.2.1.1 맵 정정 취합

TomTom은 TomTom PLUS 서버에 송신된 모든 공적 맵 정정들을 취합해야 할 것이다.

2.2.1.2 맵 정정 분석

공적 맵 정정들은 그들의 소스, 적용성(applicability) 및 신뢰성과 같은 그들의 유효성(validity)을 평가하기 위해 분석되어야 할 것이다.

2.2.1.3 맵 정정 배포

TomTom은 요청 시에 Map Share 유저들에게 모든 공적 맵 정정들을 배포하여 야 할 것이다.

2.2.1.4 맵 정정 제거

TomTom은 유저들에게 공급되는 각각의 맵에 대한 각 맵 정정의 적용성을 평가하여야 할 것이다. 만약 맵 정정이 주어진 맵에 대하여 적용가능하지 않은 것으로 확인되면 그때는 그것은 취합된 맵 정정들로부터 제거되어 이 맵의 유저들에게 배포되지 않아야 할 것이다.

2.2.1.5 맵 정정 소스 카테고리들

TomTom PLUS 서버 상에 보유된 맵 정정들은, 정정의 소스에 관한 상대적 신뢰성에 관해 유저가 알 수 있도록, 소스에 따라 분류되어야 할 것이다.

2.2.1.5.1 TomTom 승인( Endorsement )

TomTom은 특정 맵 정정들을 승인할 수 있어야 할 것이고 이것들은 특정 카테고리에서 유저에게 표현되어야 할 것이다.

2.2.1.5.2 단순 유저 보고들

단일 유저에 의해 보고되었던 맵 정정들은 특정 카테고리에서 다른 유저들에게 표현되어야 할 것이다.

2.2.1.5.3 다수 유저 보고들

한 명 이상의 유저에 의해 보고되었던 맵 정정들은 특정 카테고리들에서 다른 유저들에게 표현되어야 할 것이다. 구체적으로, 다음의 카테고리들이 표현되어야 할 것이다:

· 2-5명 유저 보고들

· 5명 이상의 유저 보고들.

2.2.1.5.4 신뢰받는 유저 보고들

신뢰받는 유저들에 의해 보고되었던 맵 정정들은 특정 카테고리에서 다른 유저들에게 표현되어야 할 것이다.

2.2.1.5.5 커뮤니티 승인

Map Share 유저들은 다른 TomTom 소유자들에 의해 만들어진 맵 정정들을 승인할 수 있어야 할 것이고 이들 승인들의 증거(징표)가 유저에게 표현되어야 할 것이다.

2.2.2 데이터 포맷

Map Share로부터 경쟁적인 이득을 얻기(그리고 유지하기) 위해서, 맵 정정 데이터는 구조화된, 재사용가능한 그리고 안전한 방식으로 보유되는 것이 필수적이다. 이 섹션은 보안에 관련된 제약들을 설명하고 있다.

2.2.2.1 고유한 식별

각 맵 정정은 고유하게 식별되어야 할 것이다.

2.2.2.2 타임 스탬프( Time Stamp )

디바이스 상에서 포착된 각 맵 정정은 그것이 입력되었던 그리고/또는 보고되었던 시간으로 타임 스탬프되어야 할 것이다.

2.2.2.3 모듈성( Modularity )

각 맵 정정은 그것이 모든 다른 맵 정정들과 무관하게 맵에 적용될 수 있게 해주는 형태로 저장되어야 할 것이다 (즉 NavCore는 정정이 맵에 적용되고 유저에 게 표현되어야 할지 여부를 정정별로 결정할 수 있어야 할 것이다).

2.2.2.4 비영속적 수정

맵 정정들은 유저의 맵 데이터에 대해 영속적인 수정을 하지 않아야 할 것이다.

2.2.2.5 데이터 압축

맵 정정들은 무선 네트워크들을 거쳐 빠르고 저렴한 배포를 가능하게 해 주도록 고도로 압축가능하여야 할 것이다.

2.2.2.6 데이터 암호화

맵 정정들은 데이터 포맷이 역설계되는 것이 가능하지 않도록 고도로 암호화되어야 할 것이다.

2.2.2.7 데이터 보전( Data Integrity )

맵 정정들은 그것들이 맵 업그레이드 프로세스를 거치면서 계속 유지되는 방식으로 저장되어야 할 것이다.

2.2.2.8 미래 맵 버전 호환성

맵 정정들은, 더 오래된 맵 버전들 상에서 이루어진 정정들이 최근의 버전에 적용될 수 있도록, 미래 맵 버전들과 호환성이 있어야 할 것이다.

2.2.2.9 과거 맵 버전 비호환성

맵 정정들은 과거 맵 버전들과 호환성이 있지 않아야 할 것이다. 과거 맵 버전에 관해 현재 맵 버전 상에서 이루어진 맵 정정을 적용시키는 것이 가능하지 않아야 할 것이다.

2.2.2.10 맵 공급자 독립성

맵 정정들은, 맵 정정들이 서로 다른 공급자들로부터의 맵들에 적용될 수 있도록, 맵 공급자에 관해 독립적이어야 할 것이다.

2.2.2.11 Tele Atlas API 호환성

맵 정정들은, TomTom이 그렇게 하기를 희망하면 Tele Atlas에게 정확히 포맷화된 보고들을 송신할 수 있도록, Tele Atlas 맵 보고 API와 호환성 있는 포맷으로 저장되어야 할 것이다.

2.2.3 디바이스상 맵 정정 핸들링

맵 정정이 유저의 디바이스 상에서 정확하게 핸들링됨을 보증하기 위해, 일정한 규칙들이 적용되어야 한다. 이 섹션은 디바이스상 맵 정정 핸들링에 관련된 제약들을 설명하고 있다.

2.2.3.1 자동적인 맵 정정 생략

과거 맵 버전들 상에서 생성된 맵 정정들은 그것들이 유저 디바이스 상에서 현재 로딩된 맵에 적용가능한지 여부를 알기 위해 조사되어야 할 것이다. 적용가능하지 않은 맵 정정들은 경로 계산 내에서 사용되어서는 안될 것이다.

2.2.4 맵 오류 보고 관리

더 효과적인 방식으로 맵 오류 보고들을 관리하기 위해, TomTom은 오류 보고들을 취합하고 우선순위화하는 방법을 구현하여야 한다. 이 섹션은 맵 오류 보고 관리에 관련된 제약들을 설명하고 있다.

2.2.4.1 맵 오류 보고 포맷

모든 맵 오류 보고들은 Tele Atlas 맵 오류 보고 API와 호환성 있는 포맷으로 생성되어야 할 것이다.

2.2.4.2 맵 오류 보고 취합

TomTom은 유저 디바이스들, TomTom Home 및 TomTom 웹사이트로부터 모든 맵 오류 보고들을 취합해야 할 것이다.

2.2.4.3 맵 오류 보고 우선순위화

TomTom은 모든 맵 오류 보고들을 평가하고, 가장 심각한 오류들이 명백하게 강조ㄴ(highlight)되도록, 이것들에 대해 우선순위를 할당하여야 할 것이다. TomTom 맵 공급자들에게 오류 보고들을 제출시 이들 우선순위들은 그 TomTom 맵 공급자들에 대해 송수신되어야 할 것이다.

2.2.4.4 Tele Atlas API 호환성

맵 오류 보고들은, TomTom이 그렇게 하기를 희망하면 Tele Atlas에게 정확하게 포맷화된 보고들을 송신할 수 있도록, Tele Atlas 맵 보고 API와 호환성 있는 포맷으로 저장되어야 할 것이다.

3 생략

이 섹션은 Map Share의 V1 범위(scope)로부터 생략되었던 고수준 요구조건들을 설명하고 있다.

3.1 유저 요구조건들

이 섹션은 Map Share에 대한 생략된 유저 요구조건들을 설명하고 있다.

3.1.1 맵 정정 유형들

이 섹션은 Map Share의 V1 범위로부터 생략되었던 맵 정정 유형들을 설명하고 있다.

3.1.1.1 도시명/ 장소명 수정

유저는 맵 상에 도시명들(및 다른 장소명들)을 수정할 수 있어야 할 것이다.

3.1.1.2 운송 유형에 대한 도로 통행금지

유저는 하나 이상의 운송 유형들에 대하여 도로로의 진입로를 통행금지할 수 있어야 할 것이다. 구체적으로 유저는 다음의 운송 유형들에 대하여 통로를 통행금지할 수 있어야 할 것이다:

· 모든 자동차들

· 보행자들

· 대형 수송차들

· 자전거들.

3.1.1.3 운송 유형에 대한 도로 통행금지해제

유저는 하나 이상의 운송 유형들에 대하여 도로의 진입로를 통행금지해제할 수 있어야 할 것이다. 구체적으로 유저는 다음의 전송 유형들에 대하여 통로를 통행금지해제할 수 있어야 할 것이다:

· 모든 자동차들

· 보행자들

· 대형 수송차들

· 자전거들.

3.1.1.4 도로 클래스 수정

유저는 맵 상에 도로들의 "클래스"를 수정할 수 있어야 할 것이다.

주의: 도로 클래스들은 도로들의 속성들을 정의하기 위해 사용되고 경로 계산 내에서 사용된다.

3.1.1.5 회전 제한 추가

유저는 맵 상의 도로들에 회전 제한들을 추가할 수 있어야 할 것이다.

3.1.1.6 회전 제한 제거

유저는 맵 상의 도로들에 적용되는 회전 제한들을 제거할 수 있어야 할 것이다.

3.1.1.7 번지( House Number ) 추가

유저는 맵 상의 도로들에 번지들(단일 번호 또는 범위 중 어느 한 쪽)을 추가할 수 있어야 할 것이다.

3.1.1.8 번지 수정

유저는 맵 상의 도로들에 적용된 번지들(단일 번호 또는 범위 중 어느 한 쪽)의 위치를 수정할 수 있어야 할 것이다.

3.1.1.9 평균 속도 수정

유저는 맵 상의 도로들의 평균 속도를 수정할 수 있어야 할 것이다.

3.1.1.10 도로에 통행세( Toll ) 추가

유저는 유료 도로로서 맵 상의 도로를 마킹할 수 있어야 할 것이다.

3.1.1.11 도로에서 통행세 제거

유저는 맵 상의 도로들로부터 통행세의 존재를 제거할 수 있어야 할 것이다.

3.1.1.12 교통표지 추가

유저는 맵 상의 도로들에 교통표지 정보를 추가할 수 있어야 할 것이다.

3.1.1.13 교통표지 수정

유저는 맵 상의 도로들과 연관된 교통표지 정보의 속성들을 수정할 수 있어야 할 것이다.

3.1.1.14 교통표지 제거

유저는 맵 상의 도로들과 연관된 교통표지 정보를 제거할 수 있어야 할 것이다.

3.1.1.15 POI 위치 수정

유저는 맵 상에 POI의 위치를 수정할 수 있어야 할 것이다.

3.1.1.16 POI 이름 수정

유저는 맵 상에 POI의 이름들을 수정할 수 있어야 할 것이다.

3.1.1.17 POI 카테고리 수정

유저는 맵 상에 POI의 카테고리를 수정할 수 있어야 할 것이다.

3.3.1.18 POI 제거

유저는 맵으로부터 POI를 제거할 수 있어야 할 것이다.

3.1.1.19 고속도로 출구 번호 수정

유저는 맵 상의 고속도로들의 출구 번호들을 수정할 수 있어야 할 것이다.

3.1.1.20 우편번호 수정

유저는 맵 상의 도로와 연관된 우편번호를 수정할 수 있어야 할 것이다.

3.1.1.21 도로 높이 제한 추가

유저는 맵 상의 도로들에 도로 높이 제한들을 추가할 수 있어야 할 것이다.

3.1.1.22 도로폭 제한 추가

유저는 맵 상의 도로들에 도로폭 제한들을 추가할 수 있어야 할 것이다.

3.1.1.23 도로 중량 제한 추가

유저는 맵 상의 도로들에 도로 중량 제한들을 추가할 수 있어야 할 것이다.

3.1.2 맵 오류 보고

어떤 맵 오류들은 스케일에 있어 너무 복잡하거나 너무 커서 디바이스 그 자체 상에서 정정을 수행할 수 없다. 우리 (또는 우리의 맵 공급자들)가 정정 활동을 취할 수 있기 위해, 이들 오류들은 TomTom에 보고될 필요가 있다. 이 섹션은 맵 오류 보고에 관련된 유저 요구조건들을 설명하고 있다.

3.1.2.1 TomTom 웹사이트 맵 오류 보고

유저는 TomTom Support Website(TomTom 지원 웹사이트) 내에 맵 오류 보고들을 생성하고 이것들을 TomTom PLUS 서버에 업로드할 수 있어야 할 것이다.

· 유저들은 맵 오류 보고를 생성하기 위해 TomTom 소비자로서 등록할 필요가 있어야 하는 것은 아니다.

· 그래픽 유저 인터페이스는 맵 오류 위치들을 더 용이하게 선택할 수 있게 해 주도록 이용가능하게 되어야 할 것이다.

· 그들 보고의 상태에 관하여 피드백이 유저에게 주어져야 할 것이다.

3.2 기술적 제약들

Map Share 내 어떤 특징들은 유저 요구조건들을 다루고 TomTom의 이익을 보호하기 위해 특정 방식으로 구현되어야 한다. 이 섹션은 Map Share의 V1 범위로부터 생략되었던 모든 알려진 기술적 제약들을 설명하고 있다.

3.2.1 맵 오류 보고

이 섹션은 Map Share의 V1 범위로부터 생략되었던 맵 오류 보고에 관련된 모든 알려진 기술적 제약들을 설명하고 있다.

3.2.1.1 Tele Atlas로의 맵 오류 보고

TomTom은 Tele Atlas 맵 오류 보고 API를 구현하고 이것을 Tele Atlas로의 모든 보고들을 위한 보고 메커니즘으로서 사용하여야 할 것이다.

Claims

맵 정정 데이터를 구성하는(organize) 방법으로서,

- 맵 정정 데이터를 수신하는 단계,

- 상기 맵 정정 데이터를 확인하는(validate) 단계,

- 상기 맵 정정 데이터를 적어도 하나의 카테고리로 분류하는(categorize) 단계, 및

- 상기 맵 정정 데이터를 저장하는 단계를 포함하는, 방법.
제1항에 있어서,

상기 수신하는 단계는, 상기 맵 정정 데이터를 무선 데이터 연결을 통해 수신하는 단계를 더 포함하는, 방법.
제1항 또는 제2항에 있어서,

상기 수신하는 단계는, 상기 맵 정정 데이터를 인터넷을 통해 수신하는 단계를 포함하는, 방법.
제1항 내지 제3항 중 어느 한 항에 있어서,

상기 확인하는 단계는, 악성(malicious) 워드를 탐색하는 단계, 중복 정정을 체크하는 단계, 충돌(conflicting) 정정을 체크하는 단계, 및 정정을 소스와 연관 시키는 단계 중 적어도 하나를 더 포함하는, 방법.
제1항 내지 제4항 중 어느 한 항에 있어서,

상기 적어도 하나의 카테고리는, 커뮤니티 분류(categorization), 정정 유형 분류, 소스 분류, 위치 분류, 언어 분류, 유효성(validity) 분류, 중요도 분류, POI(point of interest) 카테고리 분류, 우선권(priority) 분류, 맵 제공자 분류 중 적어도 하나를 포함하는, 방법.
제1항 내지 제5항 중 어느 한 항에 있어서,

상기 맵 정정 데이터를 저장하는 단계는, 상기 맵 정정 데이터를 원격 서버에 저장하는 단계를 포함하는, 방법.
맵 정정 데이터를 구성하는(organize) 장치로서,

- 맵 정정 데이터를 수신하는 수단,

- 상기 맵 정정 데이터를 확인하는(validate) 수단,

- 상기 맵 정정 데이터를 적어도 하나의 카테고리로 분류하는(categorize) 수단, 및

- 상기 맵 정정 데이터를 저장하는 수단을 포함하는, 장치.
제7항에 있어서,

상기 맵 정정 데이터를 무선 데이터 연결을 통해 수신하는 수단을 더 포함하는, 장치.
제7항 또는 제8항에 있어서,

상기 맵 정정 데이터를 인터넷을 통해 수신하는 수단을 포함하는, 장치.
제7항 내지 제9항 중 어느 한 항에 있어서,

악성(malicious) 워드를 탐색하는 단계, 중복 정정을 체크하는 단계, 충돌(conflicting) 정정을 체크하는 단계, 및 정정을 소스와 연관시키는 단계 중 적어도 하나에 의해 상기 맵 정정 데이터를 확인하는 수단을 더 포함하는,장치.
제7항 내지 제10항 중 어느 한 항에 있어서,

상기 적어도 하나의 카테고리는, 커뮤니티 분류(categorization), 정정 유형 분류, 소스 분류, 위치 분류, 언어 분류, 유효성(validity) 분류, 중요도 분류, POI 카테고리 분류, 우선권(priority) 분류, 맵 제공자 분류 중 적어도 하나를 포함하는, 장치.
제7항 내지 제11항 중 어느 한 항에 있어서,

상기 맵 정정 데이터를 서버에 저장하는 수단을 더 포함하는, 장치.