KR20090015908A

KR20090015908A - 지역성 인덱스 및 지역성을 인덱싱하기 위한 방법

Info

Publication number: KR20090015908A
Application number: KR1020087026849A
Authority: KR
Inventors: 마이클 게일리
Original assignee: 텔레 아틀라스 노스 아메리카, 인크.
Priority date: 2006-05-12
Filing date: 2007-05-11
Publication date: 2009-02-12
Also published as: WO2007134249A2; AU2007249239A1; EP2021912A2; BRPI0709707A2; WO2007134249A3; US20070276845A1; JP2009537049A; EP2021912A4; CA2650558A1; CN101432687A; RU2008148959A

Abstract

전자 지도 및 데이터베이스와 함께 이용되기 위하여 지역성 인덱스가 제공된다. 지리적 데이터베이스 내의 각 지리적 특징이 다양한 지역성 명칭 소스로부터의 지역성 명칭과 관련된다. 지역성 명칭의 콘텍스트-민감성 토큰화, 정규화, 최적화 동작이, 의미상 상이한 명칭은 보존하면서 중복 및 변형된 지역성 명칭을 제거한다. 지역성 명칭 테이블은 각 지역성 명칭의 파싱된 표현 및 다른 관련 정보를 포함하고, 인덱싱을 위한 주된 토큰이 식별된다. 메인 소스 마스크가 해당 방법에서 이용되는 각 지역성 명칭 소스에 대해 비트를 할당함으로써 생성된다. 한 지역성에 관련된 각 지리적 특징에 대하여 개별 소스 마스크가 저장되고, 해당 지역성이 발견된 각 소스에 대하여 비트가 설정된다. 각 지리적 특징과 관련된 지역성 명칭들이, 주어진 어플리케이션 내의 용법의 유력성의 순서로서 지리적 특징의 테이블 내에 인덱싱된다.

Description

지역성 인덱스 및 지역성을 인덱싱하기 위한 방법{Locality indexes and method for indexing localities}

우선권 주장

본 특허출원은, 2006년 5월 12일 마이클 게일리히(Michael Geilich)에 의하여 출원된 미국 특허출원번호 제 11/433,104호 명칭 "지역성 인덱스 및 지역성을 인덱싱하기 위한 방법(Locality indexes and method for indexing localities"을 가지는 특허출원(Attorney Docket 번호. TELA-07767US0)에 대한 우선권을 주장한다.

본 발명은 지리적 데이터베이스를 위한 지역성의 인덱스에 관련되며, 특히, 지역성 명칭 및 해당 지역성 내에 포함된 관련 지리적 특징들을 인덱싱하기 위하여 이용되는 지리적 데이터베이스 내의 데이터 구조에 관련된다.

최근에, 소비자들에게는 그들로 하여금 디지털 지도 상의 특정 거리 주소를 찾아가도록 허용하는 다양한 장치 및 시스템이 제공되어 왔다. 이러한 장치 및 시스템은 운전자로 하여금 거리 및 도로 상에서 네비게이션할 수 있도록 허용하는 차량-내 네비게이션 시스템, 개인 휴대용 단말기("PDA")와 같은 휴대용 핸드헬드 장치, 동일한 기능을 수행할 수 있는 개인 네비게이션 장치 및 셀룰러 전화기, 및 사 용자가 원하는 지점을 표시하는 지도를 생성할 수 있는 인터넷 어플리케이션들의 형태를 가진다. 이러한 장치 및 시스템의 다른 타입 및 다른 타입들의 공통 측면은 지리적 특징을 가지는 지리적 데이터베이스 및 사용자 입력에 응답하여 이러한 지리적 데이터베이스에 액세스하고 이를 조작하기 위한 소프트웨어이다. 본질적으로, 이러한 장치 및 시스템 모두에서, 사용자는 목표 지점에 접근할 수 있고, 결과적으로 반환되는 결과가 원하는 지점의 위치가 될 것이다.

전형적으로, 사용자는 레스토랑, 도시 중앙(city center) 또는 금문교와 같은 목적지 랜드마크와 같은 것의 주소 및 영업장 명칭을 입력하게 되고, 그러면 요청된 위치 또는 특징의 위치가 반환된다. 이러한 위치는 맵 디스플레이 상에 표시되거나, 또는 해당 위치로의 운전 방향을 연산 및 디스플레이 하는데 이용되거나, 또는 다른 방식으로 이용될 수 있다.

전형적으로, 어플리케이션들은 원하는 지리적 특징이 위치된 지역성(지방(지(地方), 국부성, 지방성, locality)을 검색하는 탑-다운 검색 방법을 이용하고, 해당 지역성 내에서 해당 지리적 특징을 검색한다. 지역성에서 발견될 수 있는 지리적 특징의 예에는 번지, 랜드마크와 비즈니스 지점 등이 있다. 또한, 어플리케이션들은 특정 기준에 정합하는 모든 지리적 특징들을 검색하고, 이후에 정합된 지리적 특징들이 위치된 지역성의 목록으로부터 원하는 지리적 특징을 선택하는 바텀-업 검색 방법도 이용할 수 있다.

현재, 지리적 데이터베이스에는 지역성 인덱스가 공급되지 않거나 또는 지리적 데이터베이스는 지역성 내의 지리적 특징을 검색하는 동안에 제한된 기능성을 가지는 지역성 인덱스를 가진다. 지역성 인덱스는 사용자에게 디스플레이할 지역성 명칭 및 관련 정보를 선택하는데 이용될 수 있다. 예를 들어, 지역성이란 주(미국) 내의 도시 또는 타운, 프로빈스(province)(캐나다의 경우), 카운티, 또는 다른 주된 지리적 특징들일 수 있다. 현재 지역성 인덱스를 가지는 지리적 데이터베이스에 대하여, 인덱스는 기본적으로 명칭 소스에 의해 정렬되고 소스들 사이에서 명칭이 중복되는 지역성 명칭들의 목록이다. 지역성 명칭은 행정적, 우편 행정, 및 회화 소스(colloquial source)와 같은 다수의 지역성 명칭 소스 내에서 발견될 수 있다. 본 명세서에서 "지역성 명칭(locality name)"이라는 용어는 지역성 설명으로서 이용될 수 있는 모든 데이터를 말하는 것으로 이해된다. 전술된 바와 같은 소스들 이외에도, 우편 코드 자체가 지역성 명칭으로서 이용될 수 있다. 또한 전화 교환 번호가 몇몇 나라에서는 지역성을 표시할 수 있고, 지역성 명칭으로서 이용될 수 있다. 독일에서는, 번호판 접두어(prefix)가 지역성을 나타내고, 지역성 명칭으로서 이용될 수 있다. 이하, 지리적 데이터베이스에 지역성 인덱스가 제공되는지 여부에 무관하게 종래 기술에 의한 지리적 데이터베이스에 대해서 설명한다.

현재, 다양한 지역성 명칭 소스로부터의 지역성 정보로 채워진 지리적 데이터베이스는, 해당 지역성 명칭이 복수 개의 지역성 명칭 소스에서 발견될 경우 지역성에 대한 중복 엔트리를 포함하게 될 것이다. 장치 또는 시스템의 제조자 또는 어플리케이션 개발자들은 중복 지역성을 명칭의 고유 집합에 통합시키지 않거나 또는 스펠링, 구두점, 약어, 또는 중복된 것들 사이의 차이점과 같은, 지역성 명칭 소스들에 대한 중복된 것들의 표현식의 차이점에 기인하여 불완전 통합을 수행한다. 그러므로, 사용자가 어느 지역성에 대하여 지리적 데이터베이스 어플리케이션에 질의하면, 사용자의 장치 또는 시스템은, 해당 지역성 명칭이 다중 지역성 명칭 소스에서 발견된다면 동일한 지역성 명칭을 여러 번 나열할 수 있다. 이것은, 사용자의 시스템 또는 장치 스크린 상에 디스플레이된 동일하거나 거의 동일한 지역성 명칭 중 하나를 선택해야 하는 사용자에게는 혼동스러운 일이다. 다른 문제점은, 사용자가 실제의 중복 지역성 및 동일하거나 상이하게 변형된 불일치 지역성(disjoint localities)을 구별할 수 없는 경우에, 지역성 명칭의 목록 내에 존재한다. 다중 지역성 명칭 소스로부터 중복된 지역성 명칭이 발견되는 문제점은 제한된 메모리를 가지는 몇 개의 네비게이션 장치에서는 더욱 커진다. 예를 들어, 어떤 장치는 지리적 특징 당 오직 두 개의 지역성 명칭만을 유지할 수 있다. 두 개 이상의 지역성 명칭과 관련된 지리적 특징에 대하여, 장치 내에서 이용할 지역성 명칭을 두 개 선택하는 것은 차선의 선택인데 그 이유는 중복되지만 불일치하는 지역성 및 더 유력한(prevalent) 지역성 명칭을 가지는 지역성들이 해당 선택 과정에서 누락될 수 있기 때문이다. 누락되는 중복 불일치(중복되지만 일치하지 않는) 지역성은, 사용자로 하여금 목록 내에서 피상적으로 고유해 보이는 성질 때문에 부정확한 지역성을 선택하도록 야기할 수 있다. 지리적 인덱스를 가지는 지리적 데이터베이스에 대하여, 중복 지역성을 통합하지 못하면 그 크기에 있어서 적합하지 않은, 특히 메모리가 제한된 네비게이션 장치에 대하여 적합하지 않은 지역성 인덱스를 생성하게 된다.

현재, 정확히 동일한 지리적 특징을 공유하는 동일하거나 다소 변형된 명칭을 가지는 지역성들에 대하여, 중복 명칭 엔트리는 종래의 지역성 인덱스로부터 제거되지 않는다. 적어도 하나의 지리적 특징을 공유하는 동일하거나 다소 변형된 명칭을 가지는 지역성에 대하여, 명칭 엔트리는 종래의 지역성 인덱스에서는 단일 엔트리로 통합되지 않는다. 다양한 지역성 명칭 소스로부터의 지역성 정보로 가득찬 지리적 데이터베이스는, 만일 상이한 소스 중 적어도 두 개가 해당 지역성에 대하여 다소 변형된 명칭들을 가진다면, 해당 지역성에 대한 다소 상이한 명칭을 포함할 수 있다. 예를 들면, Ho-Ho Kus, New Jersey는 상이한 소스에서는 다소 상이한 명칭, 즉, Ho-Ho Kus, Ho Ho Kus 또는 Ho-Ho-Kus(Hohokus)와 같이 알려질 수 있다. 종래 기술의 지역성 인덱스에 대하여, 다소 변형된 지역성 명칭을 가지는 지리적 데이터베이스 엔트리를 제거하지 못하면, 그 크기에 있어서 적합하지 않은, 특히 메모리가 제한된 네비게이션 장치에 대하여 적합하지 않은 지역성 인덱스를 생성하게 되고 이러한 다소 상이한 지역성 명칭을 구별하고자 시도하는 사용자에게는 혼란을 초래하게 된다. 중복 명명되지만 불일치하는 지역성에 대하여, 종래 기술은 현재 해당 지역성이 위치한 카운티와 같은 추가 정보를 디스플레이함으로써 지역성을 구별한다. 이러한 지역성에 대하여, 지역성과 함께 추가적 정보로서 디스플레이되는, 인접하고 널리 알려지며 유력한 도시들이 사용자에게 더 유용한데, 그 이유는 미국에서는 카운티 명보다는 도시 명칭 및 위치가 더욱 식별되기 쉽기 때문이다.

도 1은 통상의 사용법(common usage)의 경우 일관되게 처리되지 않는 지역성 정의의 예를 도시하는 도면을 예시한다. 지역성 정의(locality definition)의 예들은 "우편 장소(postal place)"와 "카운티 서브디비전(county subdivision)"이다. 도 1에서, 통상의 사용법의 경우, Allston이 Boston의 일부라고 간주된다. Allston은 postal place이고 Boston이 카운티 서브디비전이다. 도 1에서, 우편 장소: Allston이 카운티 서브디비전: Boston 내에 포함되는 것으로 도시된다. 반면에, Manhattan은 New York City의 일부인 것으로 간주되지만, Manhattan은 카운티 서브디비전이고, New York City는 Postal Place이기도 하고 통합 장소(Incorporated Place)이기도 하다. 도 1에서, County Subdivision: Manhattan이 Postal Place: New York City 내에 포함되는 것으로 도시된다. 이러한 상충 현상은 통상의 사용법 및 공식 지역성 정의 사이의 차이점을 예시한다.

더 나아가, 통상의 사용법에서 일관되기 처리되지 않는 지역성 정의의 다른 예에서, New York가 주 내의 특정 지리적 특징들이 통상의 사용법의 경우 SoHo, Manhattan, 및 New York City 라고 알려진 부분적으로 중첩되는 지역성 내에 포함된다. 전술된 바와 같이, New York City는 Postal Place 지역성 명칭 소스 내에서 발견될 수 있고, Manhattan은 Incorporated Place 지역성 명칭 소스 내에서 발견될 수 있다. 반면에, SoHo는 지역성 명칭 소스에서 발견될 수 없고, 구어에 의하여 알려진다. SoHo는 공식 지역성 정의에만 기반하는 지역성 인덱스에서는 발견되지 않을 것이다.

더 나아가, 현재의 지리적 데이터베이스 지역성 인덱스들은 우선 순위에 의하여, 또는 통상의 사용법을 위한 그들의 중요성에 따라서 정렬되지 않는다. 더 나아가, 지리적 데이터베이스 내의 각 지리적 특징에 대하여, 지리적 특징과 관련된 지역성들이 해당 지리적 특징에 대하여 우선 순위가 부여되지 않는다. 각 지리적 특징에 대해서 오직 두 개의 지역성 명칭들만(지역성에 우선 순위를 부여하지 않고)을 저장할 수 있는 제한 메모리 장치에서, 어플리케이션 개발자는 두 개 이상의 지역성과 관련된 지리적 특징에 대하여 두 개의 지역성 명칭을 선택하여야 한다. 바람직하게는, 지리적 특징과 관련된 최고의 우선 순위의 지역성 또는 통상의 사용법의 경우에 가장 널리 알려지거나 가장 유력한 지역성들이 사용자 장치에 디스플레이될 것이다. 지역성의 목록을 사용자에게 제공할 때, 지리적 특징과 관련된 최고 우선 순위의 명칭들이 이용되어야 하는데, 그 이유는 그들이 가장 식별되기 쉬울 것이기 때문이다.

더 나아가, 지역성 명칭의, 명칭 "South Hadley" 내의 "Hadley"와 같은 가장 중요한 명칭 성분 또는 주된 토큰(primary token)이 몇 개의 현재 지리적 데이터베이스 지역성 인덱스에서는 식별되지 않는다. 현재 상업적으로 구입 가능한 몇 가지 네비게이션 어플리케이션이 Massachusetts 내의 도시 Hadley를 검색하면, Hadley가 검색되지만, South Hadley는 검색되지 않는다. South Hadley를 찾으려면, 사용자는 "S"로 시작하여야 하고, "South"로 시작하는 많은 선택 사항들을 정렬해야 한다.

중복된 지역성 명칭 및 다소 변형된 명칭으로 알려진 지역성들이 동일한 지역성을 표현하는 경우에, 그리고 이러한 경우에만, 중복 지역성 명칭 및 다소 변형된 명칭으로 알려진 지역성들이 통합되어, 특히 메모리가 제한된 장치에 대해서는 사용자가 동일하거나 다소 변형된 명칭의 목록을 통하여 선택하여야 하는 혼동을 제거하도록 하는 방식으로 지리적 데이터베이스 지역성 인덱스가 필요하다. 이러한 지역성 인덱스는 또한 그렇지 않으면 부적합한 인덱스의 크기를 감소시키기 위하여도 필요하다. 중복 및 변형된 명칭을 가지는 지역성을 통합시키면, 의미론적으로 상이한 지역성 명칭들만을 보존할 필요성만이 존재한다. 불일치 지역성을 나타내는 중복 지역성 명칭들이 구분되도록 하는 방식으로 지역성 인덱스가 구현될 필요가 있다. 그렇지 않으면, 사용자는 동일한 명칭을 가지는 두 가지 상이한 지점을 구별할 방법이 없다. 더 나아가, 통상의 사용법에서 일관적으로 처리되지 않은 공식 지역성 정의가 설명되도록 하는 방식으로, 및 이러한 인덱스가 이와 같은 공식 지역성 정의에 기반하도록 하는 방식으로 구현될 필요가 있다. 다중 지역성과 관련된 각 지리적 특징에 대한 지역성 우선 순위에 의하여 정렬되는 지역성 인덱스가 필요하다. 우선 순위에 의하여 정렬하면 가장 중요한 명칭으로 하여금 제한된 메모리 어플리케이션 내에 포함되도록 선택되도록 허용하고, 사용자에게 제공될 최적 명칭을 식별한다. 최종적으로, 소정 지역성에 대한 가장 중요한 명칭 성분이 해당 인덱스의 일부이고 해당 명칭 성분에 대한 탐색이 모든 관련 지역성에 대한 확장된 목록을 반환하도록 보장하는 방식으로 지역성 인덱스가 구현될 필요가 있다.

일반적으로 기술된 지역성 인덱스는 전자전자 데이터베이스는 물론 인덱스를 생성하기 위한 방법 및 시스템과 함께 이용되도록 제공된다.

다양한 지역성 명칭 소스로부터의 지역성 명칭들은 지리적 데이터베이스 내의 각 지리적 특징에 대한 지리적 특징들과 관련된다. 지역성 명칭의 콘텍스트-민감성 토큰화, 정규화, 최적화 및 정합이, 의미적으로 상이한 명칭은 보존하면서 중복 및 변형된 지역성 명칭의 제거 및 통합을 허용한다. 중복 지역성 명칭들이 동일한 지역성을 표시하는 경우에, 그리고 이러한 경우에만 중복 지역성 명칭들은 제거되어, 그렇지 않은 경우에는 사용자가 동일 또는 유사한 명칭들의 목록에서 선택하여야 하는 사용자의 혼돈을 줄여준다. 다소 변형된 명칭으로 알려진 지역성에 대한 지리적 데이터베이스 엔트리들은, 이러한 지역성들이 적어도 하나의 공통 지리적 특징을 공유할 경우에는 단일 엔트리로 통합된다. 중복 또는 다소 변형된 지역성 명칭들을 가지는 불일치 지역성들은, 이들이 상이한 지역성을 표시할 경우에, 또한 그러한 경우에만 이들에게 인접 지역성의 명칭을 이용하여 보조(adorn)함으로써, 그렇지 않았을 경우에 동일한 명칭 또는 사용자에게 덜 의미 있는 방식으로 구분되는 명칭의 목록에서 선택하여야 하는 사용자의 혼돈을 감소시키거나, 예를 들어 위치가 일반적으로 사용자에게 알려진 카운티 명칭을 이용하여 보조함으로써 감소시킨다.

지역성 명칭 테이블이 생성되고 해당 지역성의 전체 명칭, 인덱싱을 위한 지역성의 주된 토큰 및 보조어, 도시 센터 정보 및 지역성의 크기와 같은 다른 관련 정보를 포함한다. 메인 소스 마스크는 이러한 방법에서 이용되는 각 지역성 명칭 소스에 대해 비트를 할당함으로써 생성된다. 특징 지역성 우선 순위 테이블 내의 각 지리적 특징에 대해서, 개별 소스 마스크가 해당 지리적 특징과 관련된 각 지역성에 대하여 저장되며, 여기서 지역성에 발견될 수 있는 각 소스에 대해서 한 비트가 설정된다. 이러한 테이블에 지역성 명칭 테이블로의 링크들 및 지리적 특징과 관련된 각 지역성에 대한 우선 순위가 존재한다. 또한 특징 지역성 테이블은 특징 찾기 테이블로의 링크를 포함하고, 이것은 각 지리적 특징에 대한 관련된 지리적 특징 정보를 포함한다.

각 지리적 특징에 대한 지역성 명칭들이 우선 순위의 순서로 인덱싱된다. 바람직한 실시예에서, 지리적 특징과 관련된 가장 높은 우선 순위를 가지는 지역성은 선호된 우편 명칭 소스(postal name source) 내에서 발견되는 것이고, 잔여 지역성들의 우선 순위는 각 지역성 소스 마스크 내에 설정된 비트의 개수에 의하여 결정된다. 이러한 인덱스에서, 제1 지역성이 통상의 사용법에서 더 널리 알려지거나 더 유력한 경우에 제1 지역성이 제2 지역성보다 더 높은 우선 순위를 가진다.

우선 순위를 이용하여 정렬하면 선택된 가장 중요한 명칭들이 제한된 메모리의 어플리케이션 내에 포함되도록 허용되고, 가장 최적 명칭이 식별되어 바텀-업 검색에서 사용자에게 제공된다. 그러므로 중복 또는 다소 변형된 지역성 명칭을 포함할 수 있는 지역성 인덱스의 부적절한 크기가 감소된다. 더 나아가, 지역성 인덱스는 통상의 사용법에서 일관적으로 처리되지 않는 지역성 정의들을 고려하는데, 그 이유는 이 인덱스가 이러한 공식 지역성 정의에 기반하지 않기 때문이다. 최종적으로, 토큰화 단계로부터의 지역성에 대한 가장 중요한 명칭 성분이 해당 인덱스의 일부로서 해당 명칭 성분에 대한 검색이 모든 관련 지역성의 확장된 목록을 반환하도록 보장한다.

도 1은 통상의 사용법에서 일관적으로 다뤄지지 않는 지역성 정의의 예들을 도시하는 도면이다.

도 2는 미국 행정 구역들의 계층성을 도시하는 도면이다.

도 3은 "Boston, Massachusetts"와 같은 지역성 내의 상이한 네 개의 지역성 내에 위치한 "Adams Street"와 같은 동일한 명칭을 가지는 주소들을 구별할 필요성을 예시한다.

도 4는 다중 타입의 지역성 명칭 소스를 이용함으로써 구분될 수 있는, "Brentwood, California"와 같은 동일한 명칭의 인접 지역 및 공식 지역성들의 일 예를 도시한다.

도 5는 "Quechee, Vermont"와 같이 광범위한 지역성 인덱스 내에 포함될 필요성이 있는, 공식 소스 내에 목록화될 수 있지만 명확하게 규정된 경계를 가지지 않는 작은 마을의 일 예를 도시한다.

도 6은 New York City 내의 "Greenwich Village"와 같이 광범위한 지역성 인덱스 내에 포함될 필요성이 있는 비공식 지역성 명칭들인 인접지역의 일 예를 도시한다.

도 7은 New York City의 borough of Queens 내의 "Forest Hills"와 같이, 광범위한 지역성 인덱스 내에 포함될 필요성이 있는 borough 지역 내에 위치한 마을의 일 예를 도시한다.

도 8a 및 8b는 지역성들을 지리적 데이터베이스 내의 지리적 특징들로 링크 하고, 지역성 명칭들을 토큰화하고, 정규화하며, 최적화하고, 정합하며, 우선 순위에 의하여 정렬된 지역성의 인덱스를 생성하는 프로세스 흐름도의 일 실시예를 도시하는 도면이다.

도 9는 알려지지 않은 지역성 명칭과 관련된 거리의 지역성 명칭을 결정하기 위하여 이용되는 페이스 보팅(face voting)의 일 예를 도시한다.

도 10은 미국 및 캐나다에 대한 지역성 명칭 소스 마스크의 두 가지 예들을 도시한다.

도 11은 지역성 명칭들의 정합을 통하여 지역성 명칭 집합을 감소시키기 위한 알고리즘의 일 실시예를 도시한다.

도 12는 주어진 지리적 특징에 대한 지역성 명칭의 우선 순위를 결정하기 위한 알고리즘의 일 실시예를 도시한다.

도 13은 특징 지역성 우선 순위 테이블(Feature Locality Priority table), 지역성 명칭 테이블(Locality Name table) 및 특징 찾기 테이블(Find Feature table)을 포함하는 지역성 인덱스 파일의 일 실시예를 도시한다.

도 14는 인접 도시가 잘못하여 설정되었을 경우에 비일관성을 조정할 수 있는 네비게이션 어플리케이션에 대한 일 예를 도시한다.

도 15는 본 발명의 실시예들과 함께 이용될 수 있는 예시적인 시스템의 블록도를 도시한다.

더욱 바람직한 지역성 인덱스를 생성하기 위하여, 지역성 명칭들의 완전한 목록이 우선 다양한 지역성 명칭 소스로부터 명칭을 수집함에 의하여 생성되어야 한다. 이러한 소스들에는 다른 것들도 있지만, 행정, 우편 및 구어에 의한 지역성 명칭 소스들이 포함된다. 모든 개수 및 타입의 소스로부터의 지역성 명칭을 이용함으로써 국제적 데이터에 대한 범용 스키마(universal schema)가 설정된다. 이러한 특징이 없으면 오직 고정된 개수의 소스만이 이용될 수 있으며, 예를 들어 우편 또는 행정 명칭 소스만이 이용될 수 있는데, 그 결과 중요한 명칭을 누락시키고 상이한 나라에서 이용될 수 있는 소스들의 타입을 제한할 수 있다.

이 명세서에서 이용되는 용어들이 미국에 한정되기는 하지만, 실시예에서는 동일한 기술적 사상이 명칭을 수정하기만 하면 국제적으로 적용될 수 있다. 외국 지역성 명칭 소스 등가물의 예들에는 영국의 Ordnance Survey and Royal Mail 및 캐나다의 Stats Can and Canada Post가 포함된다.

실시예에서, 지역성 명칭 소스들의 주어진 집합에 대하여, 각 지역성 명칭 소스로부터 지역성 명칭들의 목록이 획득된다. 실시예에서, 소스들은 예를 들어 하나 또는 그 이상의 선택된 주(states), 영역(territories), 프로빈스(province), 또는 구역(district) 내의 지역성을 포함하는 것들이다. 바람직한 실시예에서, 소스들은 미국 내의 지역성을 포함하는 것들이다. 예를 들어, 미국에서는 지역성 명칭들의 소스는 다음을 포함할 수 있는데, 이에 한정되는 것은 아니다.

1. 연방 정보 처리 표준 55(Federal Information Processing Standards 55, FIPS55). USGS(United States Geological Survey) TIGER 데이터베이스의 이러한 성분이 공용 도메인(http://geonames.usgs.gov/fips55.html)에서 발견된다. FIPS55는 정부에 의하여 정의된 행정 지역성에 대한 지역성 구조체(locality structure)를 설명하는 표준 소스인데, 예를 들어 명칭이 부여된 인구 밀접 지역, 주된 카운티 디비전, 및 미국, 푸에르토리코 및 다른 근접 영역들의 다른 지점들에 대한 코드를 포함한다.

2. 미국 우편 서비스(United States Postal Service, USPS) 도시/주 파일(City/State file). 이 파일은 USPS ZIP+4 프로덕트의 성분이다. 도시 및 주 명칭이 주소 범위 또는 ZIP 코드 레벨에서 발견된다. 5 자리 ZIP 코드 및 네 자리 확장자(ZIP+4) 가 인덱스 내의 지역성 명칭으로서 처리되고, USPS City State File 내의 명칭의 적합한 집합을 가리킨다. 일반적으로는 각 지점에 대해 오직 하나의 바람직한 우편 지역성 명칭이 존재하는 반면에, 우편 서비스는 또한 동일한 지점에 대한 모든 개수의 허용 가능한 및 비-허용 가능한 우편 지역성 명칭들을 포함할 수도 있다. "바람직한" 우편 지역성 명칭은 어드레싱 메일에서 이용되기 위하여 USPS가 추천하는 명칭이다. "허용 가능한(permissible)" 우편 지역성 명칭은 메일 배달을 위하여 USPS가 인증하고 허용한 별명(alias name)이다. "비-허용가능한" 우편 지역성 명칭은 USPS 가 우편 배달을 위하여 허용하지 않은 것이다. 실시예에서, 지역성 인덱스는 각 지리적 특징에 대하여 바람직하고 허용가능한 우편 지역성 명칭들 모두를 포함할 것이다.

3. 미국 지리학 보고서(United States Geological Survey, USGS)에 의하여 제공된 지리적 명칭 정보 시스템(Geographic Names Information System, GNIS). 이것은 미국 내의 지역성 명칭들의 공용 도메인 데이터베이스이고, 50개의 주 및 영역(territories)을 포함한다. GNIS는 도시 명칭, 그들의 센터 지점, 그들의 인구, 및 유사한 정보를 목록화한다.

4. 도시 센터(City Center)에 대한 관심 지역(Point of Interest, POI).

5. USPS 우체국에 대한 POI.

6. 미국 센서스국(United States Census Bureau)의 토폴로지적으로 집적된 지리적 인코딩 및 참조 시스템(Topologically Integrated Geographic Encoding and Referencing system, TIGER) 엔티티 "P"(TIGER 내의 통합 지점들)에 대한 레코드 타입 C.

7. 엔티티 "M"(TIGER 내의 카운티 서브디비전)에 대한 TIGER 레코드 타입 C.

한 주 내에 전체적으로 포함되는 지역성 명칭들은 인덱싱 목적을 위하여 해당 주와 관련될 수 있다. 한 주, 즉, 미국의 특정 zip code 내에 전체적으로 포함되지 않는 지역성들은 그들의 포함하는 주들에 대하여 다중 인덱싱될 수 있다. 도 2는 미국 행정 구역의 계층성을 도시하는 도면이다. 이러한 행정 구역들은 도면의 중앙에, Nation, Regions, Divisions, States 및 Counties라고 표시된 그룹 내에 전체적으로 포함된다. 이러한 도면은, County 서브디비전이 카운티 내에 포함된다는 것을 도시한다. 도 2의 "Places"로서 표시되는 행정 지역들은 주 내에 전체적으로 표시된다. 행정 지역은 카운티 또는 카운티 서브디비전 경계를 가로지를 수 있다. 대도시 영역(Metropolitan Areas), 도시 영역(Urban Areas) 및 심지어 ZIP 코드도 역시 주 경계를 가로지를 수 있고, 따라서 도 2에 도시된 바와 같이 오직 Nation 내에만 전체적으로 포함된다.

도 1은 미국 내의 지역성들이, 다중 지역성 소스로부터의 명칭들을 처리하기 위한 규칙들의 고정된 집합만을 이용해서는 네비게이션 어플리케이션에 대하여 자동으로 유용하게 모델링될 수 없다는 것을 나타내는 예시적인 도면이다. 우편 지역(Postal places) 및 카운티 서브디비전(county subdivisions)이 공식 소스(official sources) 내에서 발견된다. 도 1에서, Massachusetts에서, Allston의 우편 지역은 Boston의 카운티 서브디비전 내에 전체적으로 포함된다. 하지만, New York에서는, Manhattan의 카운티 서브디비전은 New York City의 우편 지역 내에 전체적으로 포함된다. 그러므로, 카운티 서브디비전 지역성 명칭 소스가 특정 카운티 서브디비전 내의 우편 지역을 결정하는데 반드시 이용될 수가 없다. 유사하게, 우편 지역 지역성 명칭 소스는 특정 우편 지역 내의 카운티 서브디비전을 결정하는데 반드시 이용될 수 없다. 상이한 소스로부터의 지역성 명칭들의 통상의 사용법은 지지에 따라 변동한다. 이러한 변동이, 다중 소스로부터의 지역성 명칭을 인덱싱할 때에는 반드시 고려되어야 한다.

실시예에서, 다음과 같은 사용 케이스는 지리적 데이터베이스로 액세스하는 소프트웨어 어플리케이션 또는 장치의 사용자에 의하여 이용되는데, 이것은 다중 소스로부터의 지역성 명칭을 이용하여 인덱스를 구성하는 장점을 예시한다. 만일 오직 하나의 명칭만이 이용된다면, 중요한 명칭들은 누락된다. 우편 명칭, 행정 명칭, 및 심지어 구어 명칭(colloquial names) 모두가 중요하다.

인덱스 내에 우편 명칭 소스가 없으면:

Enter state-> Vermont

Enter city-> Quechee

City not found: Quechee

인덱스 내에 우편 명칭 소스가 있으면:

Enter state-> Vermont

Enter city-> Quechee

Found-> Quechee

인덱스 내에 행정 명칭 소스가 없으면:

Enter state->New York

Enter city->Manhattan

City not found: "Manhattan"

인덱스 내에 행정 명칭 소스가 있으면:

Enter state->New York

Enter city->Manhattan

Found: "Manhattan"

실시예에서, 후속하는 네 가지 사용예들은 다중 지역성 명칭 소스로부터의 지역성 명칭들을 콤파일하는 다른 장점은, 한 지역성 내의 모호한 거리 주소들을 구별할 수 있는 것이라는 점을 나타낸다. 미국 내의 도시는 도시의 상이한 부분에 위치한 중복된 거리 주소를 가질 수 있다. 이러한 현상은 특히 Boston 및 Massachusetts와 같은 대도시에서는 특히 그러하다. 전술된 바와 같이, Boston은 행정 지역성 명칭 소스 FIPS55 내의 카운티 서브디비전으로서 발견될 수 있다. 실 시예에서, 이러한 네 가지 사용예 중 제1 사용예는, 특정 도시 주소가 한 도시 내에 고요한 전형적이고 문제점이 발생하지 않는 케이스를 도시하는데, 여기에는 도시가 대도시이더라도 네비게이션 목적에는 문제점이 존재하지 않는다. 이러한 일 예는 Boston 내의 Newbury Street이 있다. 이 거리 명칭은 10 블록 길이만큼 길고, Boston 내의 다른 어느 지역과도 중복되지 않는다.

인덱스 내에 행정 명칭 소스가 있으면:

Enter state -> Massachusetts

Enter City -> Boston

Enter Street -> Newbury Street // 집 번호와 무관하게 고유함

이때, 정밀 목적지(precise destination)는 사용자로부터 다른 입력을 대기하는데, 예를 들어 특정 거리 번호, 최근접 교차로, 또는 최근접 블록 등의 입력을 대기한다. 이러한 입력이 제공되면 목적지는 사용자를 위하여 지도 상에 정확히 표시된다.

Enter Street Number->173

Found: "173 Newbury Street, Boston, Massachusetts"

실시예에서, 네 가지 사용예 중 제2 사용예는, 거리 명칭이 한 도시 내에서 중복되지만, 집 번호(house number)가 해당 목적지를 고유하게 만드는 경우에 발생한다. 대도시 내의 서너 개의 소도시를 관통하는 긴 거리가 이러한 예시 중 하나이다. 예를 들어, Commonwealth Avenue는 Boston을 관통하고 이와 더불어 Boston 내의 작은 도시인 Allston 및 Chestnut Hill을 관통한다. 전술된 바와 같이, Boston은 행정 지역성 명칭 소스 내에서 발견되는 카운티 서브디비전이다. Allston 및 Chestnut Hill은 각각 우편 코드 02134 및 02467을 가지고 우편 지역성 명칭 소스 내에서 발견될 수 있는 도시들이다.

인덱스 내에 행정 명칭 소스가 없으면:

Enter state->Massachusetts

Enter city->Boston

Enter street->Commonwealth Avenue

Enter street number->2000

Street number not found: "2000"

Boston이 미국 우편 서비스에 따르면 우편 코드 02467에 대한 적합한 우편 명칭이 아니기 때문에, 비록 Chestnut Hill이 Boston 내의 소도시이지만 "2000 Commonwealth Ave, Chestnut Hill, Massachusetts 02467"이 Boston에 대한 위의 예에서는 발견되지 않는다.

인덱스 내에 행정 및 우편 명칭 소스 모두를 가지고 있으면:

Enter state->Massachusetts

Enter city->Boston

Enter street->Commonwealth Avenue

여기서, Commonwealth Avenue는 Boston, Allston 및 Chestnut Hill을 관통하는 것을 알 수 있다. 정밀 목적지는 특정 거리 번호, 최근접 교차로 또는 최근접 블록과 같은 추가 입력을 사용자로부터 대기한다. 이러한 입력이 제공되면, 목적 지는 사용자를 위하여 지도 상에 정확히 표시된다.

Enter street number->2000

Found: "2000 Commonwealth Avenue, Chestnut Hill, Massachusetts"

실시예에서, 네 가지 경우 중 세 번째 경우는 도 3에 도시되고, 이것은 제2 사용예와 유사하지만, 네 개의 상이한 Adams Street Boston 내의 네 군데 상이한 지역에서 발견될 수 있다는 점이 상이하다. 도 3은 Boston, Massachusetts와 같은 지역성 내의 상이한 네 개의 지역성 내에 위치한 동일한 명칭 예를 들어 "Adams Street"를 가지는 주소들을 구별하여야 하는 필요성을 예시한다.

인덱스 내에 우편 명칭 소스가 없으면:

Enter state -> Massachusetts

Enter city -> Boston

Enter street -> Adams Street

Please choose from ->

Adams St., Boston // 어플리케이션이 Boston 내에서

Adams St., Boston // 네 개의 상이한 Adams Street를

Adams St., Boston // 발견하고 사용자는 이 4가지 선택 사항을

Adams St., Boston // 구별할 수 없음

인덱스 내에 우편 명칭 소스가 있으면:

Enter state -> Massachusetts

Enter city -> Boston

Enter street -> Adams Street

Please choose from ->

Adams St., Charlestown

Adams St., Hyde Park

Adams St., Roxbury

Adams St., Dorchester

Enter street number -> // 사용자는 계속하여 거리 번호를 입력

이러한 사용예에서, 어플리케이션은 사용자로부터의 추가적 정보를 요청하기 이전에 각 사용자 엔트리를 처리한다. 다른 실시예에서는, "인덱스 내에 우편 명칭 소스가 있으면"의 경우에, 사용자는 이러한 세 개의 엔트리를 어플리케이션이 처리하기 이전에 Boston 이라는 도시를 입력하고, Adams Street이라는 거리를 입력하며, 거리 번호를 입력한다. 소도시 Charlestown, Hyde Park, Roxbury 및 Dorchester에서 거리 번호가 중복되지 않는다고 가정하면, 이러한 네 개의 소도시 중 하나에 대해서 거리 명칭 및 번호가 발견될 것이며, 사용자에게 디스플레이된 맵 상에 정확히 표시될 것이다.

실시예에서, 네 가지 사용예 중 제4 사용예는 심지어 "2 Adams St"와 같은 거리 번호마저도 한 도시 내의 동일한 명칭을 가지는 개별 거리 상에서 중복되는 경우를 도시한다. 이러한 경우에, 적합한 유일한 응답은 사용자에게 중복 사항이 표시된 소도시의 목록을 제공함으로써 고유 목적지를 유도하도록 하는 것이다. 그러므로, 전술된 제3 사용예로부터의 실시예를 이용하면 다음을 얻는다:

인덱스 내에 행정 및 우편 명칭 소스가 있으면:

Enter state->Massachusetts

Enter city->Boston

Enter street->Adams Street

Enter street number->2

Please choose from->

2 Adams Street, Charlestown

2 Adams Street, Hyde Park

2 Adams Street, Roxbury

2 Adams Street, Dorchester

실시예에서, 도 4에 도시된 다른 사용예에서 공식 지역성 및 "Brentwood, California"와 같은 동일한 명칭을 가지는 인접 지역(neighborhood)이 지역성 명칭 소스의 다중 타입을 이용하여 구별될 수 있다. Brentwood, California는 San Francisco에 인접한 공식 행정 구역이기도 하고, 또한 허용 가능하지만 바람직하지는 않는 우편 명칭인 Los Angeles의 잘 알려지지만 비공식적인 인접 지역이기도 하다. 도 4는 California 내의 두 개의 Brentwood 지역성들을 도시한다. 두 개의 위치는 네비게이션 목적으로 유력한 주소들을 포함하며, 바람직한 네비게이션 어플리케이션은 이들을 사용자를 위하여 구별할 것이다.

Enter state->California

Enter city->Brentwood

Please choose from->

Brentwood (city near San Francisco)

Brentwood (neighborhood of Los Angeles)

이와 같이 동일한 사용예를 이용하면, 다른 실시예에서, 사용자가 어플리케이션이 사용자 엔트리를 처리하기 이전에 주, 도시 및 거리 명칭을 입력한다면, 어플리케이션은 정확한 Brentwood를 결정할 수 있다. 예를 들어 다음과 같다.

Enter state->California

Enter city->Brentwood

Enter street name->Concord Avenue

Enter street number->767

Found: "767 Concord Avenue, Brentwood (city near San Francisco), California"

실시예에서, 도 5에 도시된 바와 같은 다른 사용예에서, 공식 소스 내에 목록화될 수 있지만, "Quechee, Vermont"와 같은 명확한 경계를 가지지 않는 작은 마을들이 광범위한 지역성 인덱스 내에 포함될 필요가 있다. Quechee, Vermont 라는 마을은 유명한 소규모 관광 목적지 도시이다. Simon Pierce Glassblowing이 광고면(Yellow Page)에서 1760 Quechee Main Street, Quechee, Vermont 05059라고 검색될 수 있다. 그러나, Quechee는 행정 지역성이 아니고, 또한 미국 우편 서비스가 이 주소를 식별하는 것도 아니다. ZIP 코드 05059는 거리 주소를 거의 가지지 않는 "Post Office Box only" ZIP 코드이다. 그러므로, Quechee Main Street이 Quechee 내의 거리에서는 식별되지 않는다. Quechee의 중심을 감싸는 영역이 White River Junction 및 Hartford라고 알려진다. 도 5는 하나의 가능한 구획된 마을 경계를 가지는 Quechee의 장래 지도를 예시한다. 바람직한 네비게이션 어플리케이션은 이들이 광고면 디렉토리 내에 출판될 때에, 주소가 적법한 우편 주소인지 통합된 지역인지 여부를 식별할 필요가 있다.

Enter state->Vermont

Enter city->Quechee

Enter street->Quechee Main Street

Enter number->1760

Found: "1760 Quechee Main Street, White River Junction, Vermont"

불행하게도, Quechee 지역성 명칭은 거리 주소에는 첨부될 수 없는데, 그 이유는 Quechee의 경계가 알려지지 않기 때문이다. 대신에 White River Junction 이 해당 거리 주소에 대한 지정된 지역성이다. 이러한 선택은 우편 주소에 따르는 것이다. 네비게이션 어플리케이션은, 자신이 원하는 지점을 후술되는 바와 같이 생성된 지역성 인덱스를 이용하여 발견하였다는 것을 결정할 수 있다. 비록 Quechee 가 "1760 Quechee Main Street"에 대한 지역성이 아니지만, 지역성 인덱스는 Quechee를 확장시켜 White River Junction, Vermont 내에서 해당 거리를 찾을 수 있다. 네비게이션 어플리케이션은 정합된 지역성이 사용자 입력과 다르면 사용자의 확인을 요청할 수 있다. 비록 오직 하나의 거리가 발견되었다고 하더라도 이것은 오직 가능한 매치일 뿐이고, 네비게이션 어플리케이션의 사용자가 이것을 수락 하거나 거부할 수 있는 것이다. 맵 개선(map enhancement)이 Quechee의 경계를 추가함으로써 장래에는 정확한 답변이 가능할 수 있도록 이루어질 수 있다. 이러한 경우에, "1760 Quechee Main Street"이 위치할 수 있는 지역성의 명칭이 사실상 Quechee가 될 것이다.

실시예에서, 도 6에 도시된 바와 같은 장래의 사용예에서, New York City의 "Greenwich Village"와 같은 비공식(unofficial) 지역성 명칭인 인접 지역들이 광범위한 지역성 인덱스에 포함될 필요가 있다. 네비게이션을 위하여 중요하지만 어느 행정 또는 우편 소스에서 공개되지 않은 다양한 지역성 명칭들이 미국에 존재한다. 이러한 명칭의 일 클래스가 유명한 인접 지역(famous neighborhood)이다. 그 예에는 New York City 내의 Greenwich Village 및 SoHo 및 San Francisco의 Haight-Ashbury이다. 이러한 곳은 거리 세그먼트, 주소, 상업 지역(business) 및 다른 관심 지역을 포함할 만큼 충분히 넓다. 바람직한 네비게이션 어플리케이션은 이들이 공식적 행정 또는 우편 명칭이던 아니던 간에 관계없이 그들 내부에서 잘 알려진 지역 및 거리 주소를 찾아낼 기능을 포함할 것이다.

다양한 소스로부터의 명칭이 없으면:

Enter state->New York

Enter city->Greenwich Village

City not found: "Greenwich Village"

다양한 소스로부터의 명칭이 있으면:

Enter state -> New York

Enter city -> Greenwich Village // 우편 또는 행정 명칭 모두 아님

Enter street -> // 사용자는 거리 명칭을 입력하여 계속함

이러한 사용예에서, 다양한 소스로부터의 명칭을 이용하면, 확장된 지도는 Greenwich Village라는 경계를 포함할 수 있다. 도 6은 Greenwich Village가 Greenwich 거리 및 Broadway 사이의 Spring 및 14번가에 의하여 경계되는 Manhattan 지역으로서 정의될 수 있음을 도시한다. 이러한 정보와 함께 맵을 이용하면, 다음의 대화가 계속될 것이다.

Enter street->Carmine Street

Enter street number->13

Found: "13 Carmine Street, Greenwich Village, New York"

도 7에 도시된 장래 사용예와 같은 실시예에서, New York City의 Queens의 borough 내의 "Forest Hills"와 같이 borough 내에 위치한 마을들이 광범위한 지역성 인덱스 내에 포함될 필요가 있다. 상이한 소스로부터의 지역성 명칭들이 New York City의 borough들 중 어느 것에 거리 명칭이 위치할 수 있는지를 결정하는데 이용될 수 있다. New York 시티는 다섯 개의 borough를 가지고 있다. 이들 중 하나 Queens를 제외한 모든 것들이 지역성 명칭만으로 대표된다. 그러나, Queens에서는, 수십 개의 포함된 지역성들이 발견된다. Queens 내의 주소를 검색하는 동안에, 사용자는 해당 주소가 위치한 Queens 내의 지역성을 알 필요가 없다. 후술되는 지역성 인덱스는, 어느 주소가 오직 하나의 마을에 고유하게 포함될 경우에는 어떤 마을이 해당 주소를 포함하는지 결정할 수 있다.

Enter State-> New York

Enter city-> Queens

Enter street->70^th Road

Enter street number->10700

Found: "10700 70^th Road, Forest Hills, N.Y.

이러한 사용예에서, 지역성 인덱스는 Queens 내에 위치한 명칭들에 대한 요청만을 처리할 수 있다.

Enter state->New York

Enter city->Forest Hills

Enter street->70^th Rd.

Enter street number->10700

Found: "10700 70^th Road, Forest Hills, N.Y."

도 8a 및 8b는 지역성들을 지리적 데이터베이스 내의 지리적 특징들로 링크하고, 지역성 명칭들을 토큰화하고, 정규화하며, 최적화하고 정합하며, 우선 순위에 의하여 정렬된 지역성의 인덱스를 생성하는 프로세스 흐름도의 일 실시예를 도시하는 도면이다. 실시예에서, 어느 지역성 내에서 발견될 수 있는 지리적 특징의 예들은 거리(street), 거리 세그먼트, 거리 세그먼트 에지, 블록 페이스(block face), 랜드마크, 주립 공원(state park), 고속도로, 택배 센터(parcel center), 페리 노선(ferry line), 버스 노선(bus route), 택배 센터, 비즈니스 지역 및 주거 지역을 포함하지만 이에 한정되는 것은 아니다. 거리 세그먼트는 거리의 일부이거나, 주소 범위이거나, 또는 단일 주소일 수 있다. 거리 세그먼트 에지(edge)는 거리 세그먼트의 한쪽 거리이다. 블록 페이스는 도시 블록을 구성하는 네 개의 페이스 중 하나이다.

전술된 것으로부터의 지역성 명칭 소스들의 주어진 집합에 대하여 및 주어진 독점적 지리적 데이터베이스에 대하여, 프로세스는 단계 805부터 개시된다. 만일 다른 지역성 명칭이 단계 810에서 처리되도록 존재하면, 단계 815에서 프로세스는 만일 소스가 지리적 데이터베이스 내의 지리적 특징과 일치하는 지리적 특징들을 포함한다면 맵 정합 동작이 수행될 수 있는지 결정한다. 만일 단계 815에서 해당 소스에 대한 맵 정합 동작이 가능하다는 것이 알려지면, 단계 820에서 맵 정합 동작은 지역성 명칭 소스로부터의 지역성 명칭들을 해당 지리적 데이터베이스 내의 지리적 특징과 직접적으로 관련시킨다. 직접적 관련화 동작은 융합(conflation) 동작 또는 속성 정합 동작을 통하여 자동적으로 수행되거나, 또는 관찰을 통하여 수동으로 수행될 수 있다. 직접 관련 동작은 전형적으로 속성을 지리적 데이터베이스와 공유하는 지역성 명칭 소스들에 대해서 이용된다. 바람직한 일 실시예에서, 해당 지역성 명칭 소스가 지상의 그 위치 및 범위를 표시하는 자신에게 첨부된 공간 정보를 가지는 경우에는 융합 동작이 이용될 수 있다. 직접 관련화 동작은 지역성 명칭 소스로부터의 지역성을 공간적으로 지리적 데이터베이스 상에 중첩시키고, 지역성을 해당 지역성의 경계 내에 발생된 모든 지리적 데이터베이스 특징으 로 할당함으로써 이루어진다. 속성 정합 동작은 공통 속성을 소스 및 지리적 데이터베이스 사이에 정합시킴으로써 수행되며, 이를 통하여 직접 관련화 동작이 이루어지도록 할 수 있다. 정합될 수 있는 속성들은 스트링 또는 숫자에 의하여 표시될 수 있는 것들이다. 간접적 관련화 동작이 전형적으로 다른 소스에 대해서 이용된다.

실시예에서, 지역성 명칭 소스가 지리적 데이터베이스와 속성을 공유하는 단계 820에서, 지리적 데이터베이스 내의 지리적 특징으로의 직접 관련화 동작이 해당 소스 내의 속성들을 맵 또는 지리적 데이터베이스 내의 동일한 속성에 반하여 정합시킴으로써 수행될 수 있다. 예를 들어, 주소 속성을 지역성 소스 및 지리적 데이터베이스 사이에서 정합시키기 위하여 범위-정합(range-matching) 동작이 이용될 수 있다. 범위 정합 동작은 TIGER, 및 USPS City Place Names 디렉토리를 포함한 거리 세부 사항과 관련된 지역성 명칭을 가지는 모든 소스를 이용하여 수행될 수 있다. County Subdivision (엔티티 "M") 및 Incorporated Place (엔티티 "P") 코드들이 정합된 TIGER 지리적 특징들로부터 관심 대상인 맵 또는 데이터베이스 내의 지리적 특징 상에 직접적으로 전파된다. 범위 정합 동작은 거 명칭, 집 번호의 범위, 및 TIGER로부터의 지역성을 취득하고 이러한 아이템들을 관심 대상인 독점적 지리적 데이터베이스 내의 상응하는 거리 세그먼트로 정합하고자 시도한다. TIGER에서, 거리 블록의 각 측면은 주소 범위를 가지는 것뿐만 아니라 해당 지점의 엔티티 타입 P(incorporated place name), 해당 지점의 엔티티 타입 M(county subdivision name), 주 코드(state code), 블록 코드, 트랙트 코드(tract code) 및 Minor Civil Division(MCD)을 나타내는 태그를 가진다. 정합되는 범위들이 정보를 TIGER로부터 해당 지리적 데이터베이스로 전달하는 것을 가능하게 한다. 범위 정합은 거리 세그먼트의 정확한 매치이거나, 접촉하거나 정확하게 정렬된 거리 세그먼트이거나 또는 부분적으로 중첩되는 거리 세그먼트일 수 있다.

USPS City/State 파일이 지역성 명칭 소스인 단계 820에서, 소스 USPS ZIP+4 카탈로그로부터의 배달가능한 주소 범위들은 맵 또는 데이터베이스에 대하여 지오코딩된다(geocoded). 실시예에서, 소스로부터의 ZIP 코드가 스스로 지역성 명칭인 것으로 처리된다. 이 소스로부터의 ZIP 코드들 역시 City/State 파일 내의 지역성 명칭들의 적합한 집합을 지시한다. 각각의 성공적인 정합에 대해서 5자리 ZIP 코드 및 ZIP+4로부터의 하나의 4자리 plus4 코드가 지역성 명칭으로서 처리되고 상응하는 지리적 특징 상에 전파된다.

단계 825에서, 지역성 명칭 소스로 정합되지 않았던 지리적 데이터베이스 내의 지리적 특징에 대하여, 해당 지리적 특징들을 해당 지리적 데이터베이스 내의 다른 특징들과 정합시키고, 이를 통하여 해당 정합된 특징으로부터 지역성 지정(assignment)을 물려받도록 하기 위하여 페이스 보팅(face voting)이 이용된다. 도 9는 알려지지 않은 지역성 명칭과 관련된 지리적 데이터베이스 내의 도시 블록 페이스에 대한 명칭을 결정하기 위하여 이용되는 페이스 보팅의 일 예를 예시한다. 실시예에서, TIGER 명칭 소스에 대한 담당 영역 내의 홀(hole) 또는 비정합 지리적 특징들은 "페이스 보팅"의 프로세스를 통하여 제거된다. 미지의 도시 명칭과 관련된 블록 페이스를 가지는 도시 블록에 대하여, 페이스 보팅은, 해당 블록 페이스를 둘러싸는 블록 페이스들 또는 주어진 블록 페이스에 연결되는 블록 페이스에 상응하는 도시 명칭에 기반하여 해당 블록 페이스의 도시 명칭을 결정한다. 도 9는 주어진 블록 페이스에 대하여 페이스 보팅 동작에서 이용되는 블록 페이스들이 주어진 블록에 인접한 두 개의 블록 페이스 및 주어진 블록 반대편의 하나의 블록 페이스인, 도시 블록에 대한 페이스 보팅을 예시한다. 도 9의 블록 페이스들은 각각 거리 세그먼트의 일면인 지리적 특징인 것으로 간주될 수 있다. 인접한 및 반대편 블록 페이스들이 실시예에서 검사되고, 할당되지 않은 페이스가 위치한 주된 지역성이 다른 인접 및 반대편의 페이스들 중에서 다수 보트(majority vote)인 것으로 결정된다. 이러한 프로세스는 County Subdivision 및 Incorporated Place 코드 및 그들의 관련된 명칭을, 인접한 및 반대편의 코딩된 지리적 특징(실시예에서는 블록 페이스임)으로부터의 모든 코딩되지 않은 지리적 특징으로 전파한다.

예를 들어, 도 9에서, Center Street의 블록 거리 세그먼트의 북쪽 측은 미지의 도시 명칭과 관련되는데, 그 이유는 이것이 해당 지역성 명칭 소스 내의 모든 지역성과 관련되지 않는 지리적 특징이기 때문이다. 그러나, 다른 블록 페이스에서, 또는 First Street 일 블록 거리 세그먼트의 East 측, Main Street 일 블록 거리 세그먼트의 South 측 및 Second Street 일 블록 거리 세그먼트의 West 측들이 "Boston"과 관련되는 것이 발견된다. 해당 블록에 대한 이러한 세 개의 거리 세그먼트들 중 세 개가 Boston과 관련되기 때문에, 해당 페이스 보트는 3 중 3이고, Center Street이 Boston과 관련될 것이다. 만일 이러한 세 개의 거리 세그먼트들 중 두 개가 특정 도시와 관련된다면, 페이스 보트는 2/3이 되고, Center Street 이 또한 해당 특정 도시와 관련될 것이다. 동률인 경우에는, 세 개의 거리 세그먼트들이 각각 상이한 도시와 관련되는데, 이 경우에는 페이스 보트가 1/3이 된다. 이 경우에는 주된 보트가 존재하지 않으므로, Center Street은 자신에게 근접한 주변 거리들 중 하나의 도시와 관련되고, 이 경우 이것은 First Street 또는 Second Street 이 된다.

실시예에서, 도시 블록 페이스가 아닌, 거리 세그먼트 측면 또는 도로 에지와 같은 다른 지리적 특징들에 대해서 페이스 보팅이 이용될 수 있다. 실시예에서, 페이스 보팅이 미지의 도시명과 관련된 거리 세그먼트 이외의 다른 두개 또는 그 이상의 거리 세그먼트 측면에 대해서 이용될 수 있다. 실시예에서, 페이스 보팅이 두 개 또는 그 이상의 블록 페이스들이 미지의 도시명과 관련된 경우에도 이용될 수 있다. 이러한 경우에, 주된 보트는 잔여 블록 페이스들로부터 획득되고, 다수 보트 또는 동률이 발견되고 전술된 바와 같이 처리된다. 실시예에서, 페이스 보팅이 블록 페이스들을 도시 또는 타운이 아닌 다른 지역성 명칭과 관련하는데 이용될 수 있다. 예를 들어, USPS City/State 파일 내의 지역성 명칭들은 5자리 ZIP 코드 및 ZIP+4 파일로부터의 하나의 4-자리 빌딩 코드(building code)이다.

페이스 보팅의 다른 실시예들은 다수 보트 대신에 가중치 보트 또는 선형 길이 보트를 포함한다. 가중치 보트(weighted vote)를 이용하는 실시예에서, 어느 지역성과 관련되지 않은 블록 페이스에 인접한 특정 블록 페이스들에게 선호도(preference)가 주어지거나, 또는 보팅 프로세스에서 더 많은 가중치가 부여된다. 가중된(weighted) 보팅은 인접 블록 페이스 할당의 신뢰도를 측정하는 모든 가중치 성분(weighting component)을 가질 수 있다. 예를 들어, 주된 도로거나 넓은 지역에 위치된 블록 페이스에 선호도가 부여될 수 있다. 블록 페이스의 길이가 이와 같은 가중치 기법의 다른 예이다. 선형 길이 보트를 이용하는 실시예에서, 지역성과 관련되지 않은 주어진 블록 페이스에 대하여, 해당 주어진 블록 페이스에 인접한 블록 페이스들과 관련된 알려진 각각의 지역성에 대하여, 블록 페이스들의 전체 길이가 얻어져서 인접 블록 페이스들과 관련된 어떤 지역성이 가장 긴 전체 선형 길이를 가지는 블록 페이스를 가지는 지가 결정된다. 그러면, 그 결과로서 얻어지는 지역성에 지역성과 관련되지 않은 블록 페이스가 제공된다.

도 8a에서, 만일 단계 815에서 소스가 지리적 데이터베이스와 아무런 속성도 공유하지 않기 때문에 맵 정합 동작이 가능하지 않으면, 단계 855에서 실시예에서 소스-공통 명칭 정합(cross-source name matching)이 채택된다. 크로스-소싱이란 해당 소스(또는 제1 소스) 내의 지역성 명칭을 이미 지리적 데이터베이스 내의 지리적 특징과 직접적으로 관련된 다른 소스의 지역성 명칭들과 간접적으로 관련시키는 동작이다. 단계 855에서, 지리적 데이터베이스 내의 지리적 특징과 이미 직접적으로 관련된 제2 소스가 제1 소스에 정합되는 지역성 명칭을 가지는 것이 발견되기 때문에 소스-공통 명칭 정합이 가능하면, 단계 860에서 제1 소스가 제2 소스로 정합된다. 단계 865에서, 제1 소스 내의 각 지역성 명칭은 제2 소스로부터의 지리적 특징으로의 관련성을 상속받고, 따라서 특정 지리적 특징에 간접적으로 관련된다. 실시예에서, 이어진 지리적 특징들의 예시에는 거리 세그먼트 측면, 블록 페이스 및 페리(도선) 노선 등이 있다. 실시예에서, FIPS55 데이터는 소스-공통 명 칭 정합 동작을 위한 유용한 명칭 소스이다. 예를 들어, 인구 밀집 지역(Populated Places) 소스에 대한 GNIS 지역성이 주 및 카운티 내의 FIPS55 소스 내의 지역성 명칭들에 대해서 정합된다. 정합이 이루어지면, GNIS 명칭은 그들의 정합된 FIPS55 명칭으로부터 거리 세그먼트 측면으로의 관련성을 상속받는다. 단계 865로부터, 프로세스는 후술되는 바와 같이 단계 830으로 진행한다. 만일 단계 855에서 소스-공통 정합 동작이 해당 소스에 대해서 가능하지 않으면, 해당 소스는 이러한 프로세스에는 이용될 수 없고, 프로세스는 단계 810에서 다른 지역성 소스를 선택하기 위하여 되돌아간다.

실시예에서, 다양한 지역성 명칭 소스로부터 얻어진 지역성 명칭들은 토큰화되고, 정규화되며, 최적화되고 및/또는 정합되고, 통합되며, 또는 보조어가 부착되어 중복 및 다소 변형된 지역성 명칭이 제거된다. 바람직한 실시예에서는 토큰화, 정규화, 최적화, 정합, 통합, 또는 보조어 부착(adorning) 동작의 모든 단계들이 수행된다. 이러한 프로세스는 두 개 또는 그 이상의 유사한 명칭을 가지는 각 지역성에 대한 지역성 명칭의 개수를 감소시키는 반면에, 의미론적으로 상이한 지역성 명칭들을 여전히 유지한다. 이러한 단계들은 다양한 소스의 명칭 인코딩 기법에 차이점을 부여한다. 다양한 소스로부터의 유사한 지역성 명칭들의 일 예는 Ho-Ho-Kus, New jersey인데, 이것은 다양한 지역성 명칭 소스 내에서 다음과 같이 발견된다.

TIGER Record Type C: Ho-Ho-Kus Twnshp

USPS City State: HO HO KUS Township

POI Center of Settlement: HO-HO-KUS

FIPS55-3: Ho-Ho-Kus (Hohokus)

GNIS: Ho-Ho-Kus

도 8a의 단계 825 및 865로부터, 프로세스는 단계 830으로 진행한다. 단계 830에서, 실시예에서 명칭-정합 프로세스, 토큰화, 또는 파싱(parsing)의 제1 부분이 지역성 명칭을 약 10 개의 토큰 또는 성분으로 분리할 수 있다. 지역성 명칭들의 토큰화하기 위하여 다양한 기법이 이용될 수 있다. 이러한 단계의 목적은 지역성 명칭의 중요 성분 또는 중요부 또는 명칭 "body"를 인덱싱 목적을 위해 분리해 내는 것이다. 접두어 및 접미어와 같은 다른 성분들 각각이 개별 성분일 수 있다. 그러면, 지역성 명칭이 인덱스 내에서 토큰으로써 표현되고, 이에 의하여 어플리케이션 개발자로 하여금 해당 명칭의 중요부에 대한 인덱싱을 하도록 허용한다. 예를 들어, 이에 의하여 Amherst 및 South Amherst 모두가 원할 경우 "A" 밑에 인덱스될 것이다. 실시예에서 중복된 것들을 제거하면 말단 사용자로 하여금 제한된 메모리 어플리케이션 내에서 더 많은 명칭에 접근하도록 허용하고, 동일한 명칭을 여러번 보게 되는 사용자 혼돈을 방지한다.

앞에 목록화된 바와 같은 두 개의 지역성 명칭 소스들 중 제1 소스로부터의 Ho-Ho-Kus, New Jersey에 대한 지역성 명칭들을 토큰화하는 예는 다음과 같은 보디(body) 및 접두어 토큰을 생성한다.

Body: Ho-Ho-Kus, Suffix: Twnshp

Body: HO HO KUS, Suffix: Township

토큰화는 고유 명칭을 정의하는 성분들을 격리시키고 관련성(association)에 의하여 정합 프로세스에서 무시될 수 있는 토큰을 격리시키는데 유용하다. 거의 모든 말단 사용자는 ""Rutland" 가 "Rutland Township"과 정합되기를 기대하는데, 즉, "Township"이라는 용어는 중요하지 않은 것으로 되기를 기대한다. 동시에, 거의 모든 말단 사용자는 "Boston"이 "South Boston"과 정합되지 않기를 바라는데, 즉, "South"이라는 용어는 중요한 것으로 되기를 바란다. 토큰화를 수행하는 다른 이유는, 명칭의 중요부가 인덱스될 것이기 때문에 소프트웨어 어플리케이션의 개발자에게 지역성 명칭을 말단 사용자에게 제공하는데 있어서 탄력성을 제공하는 것이다. 예를 들어, "Hollywood" 및 "West Hollywood"를 토큰화함으로써, 이들 둘 모두는 "Hollywood"에 대하여 맵 검색을 입력한 말단 사용자에게 선택 가능한 대상으로서 제공될 것이다. 이러한 현상은 이들 둘 모두의 "body" 토큰이 "Hollywood"일 것이기 때문에 발생하는데, 즉, West Hollywood는 Body: Hollywood, Prefix: West로 토큰화되고, Hollywood는 Body: Hollywood로 토큰화될 것이기 때문이다.

다른 실시예에서, 토큰화는 컨텍스트에 민감한 약어들의 정확한 확장 표현을 결정하는데 도움을 준다. 예를 들어, 지역성 접두어 토큰 "St."은 거의 "Saint"를 의미하지만, 지역성 접미어 토큰 "St."는 거의 "State"를 가리키게 된다.

다음에 토큰의 다른 타입 및 이러한 토큰의 예들이 나열된다.

PreDirection - 선행 방향(direction) ("North" Adams)

PreType - 선행 타입(leading type) ("Lake" Isabella)

Prefix - 선행하지만 방향 또는 타입이 아니다("Old" Orchard Beach))

PreName - 보디 이전의 비-타입 워드(lake "of the" woods)

Body - 인덱스 목적을 위해 이용되는 주요부(Lake "Isabella")

PostType - 후행 타입(Imperial "Beach")

PostDirection - 후행 방향 토큰(Leisure Village "West")

Suffix - 후행하지만 방향 또는 타입이 아님(Manchester "By The Sea"))

Division - 지역성의 분배를 규정하는 숫자 식별자(Meredosia "1")

Adornment - 지역성 명칭의 위치를 명확하게 하기 위한 카운티 명칭과 같은 괄호 안에 있거나 보조적인 정보(Middletown "(Bethlehem)")

도 8a의 단계 835에서, 토큰화 단계로부터의 토큰화의 정규화 동작은 일반적으로 실시예들에서 다음 프로세스 중 하나 또는 그 이상을 포함한다: 약자의 펼치기, 구두점을 줄이거나 제거하기, 일관된 대소문자를 이용하기 및 내장 공백 제거하기. 실시예에서, 방향에 대한 및 타입에 대한 표준 약어들이 확장된다. 예를 들어, 방향 약어 "N."은 "North"로 확장된다. 타입 약자에 대해서는, "Mt."가 "Mount"로 확장되고 "AFB"는 "Air Force Base"로 확장된다. 상이한 소스 내에 발견되는 명칭들이 상이하게 표시될 수 있다고 가정하면, 정합 동작에서 약어를 적합하게 정규화하는 것은 중요하다. 실시예에서, 내장 공백 및 구두점 들이 제거된다. 실시예에서, 해당 지역성 명칭 토큰에 대하여 일관된 대문자 또는 소문자 중 하나를 이용하여 대소문자가 정규화될 수 있다. 대소문자는 또한 실시예에서 각 토큰의 첫 번째 문자만을 대문자화함으로써 정규화될 수 있다. 더 나아가, 대소문자 차이점은 어느 실시예에서는 정규화 프로세스 대신에 정합 프로세스에서 교정될 수 있다. 바람직한 실시예에서, 대소문자는 일관된 대문자로 정규화된다. Ho-Ho-Kus, New jersey 예시를 이용하면, 토큰을 정규화하면 다음 결과를 얻는다.

Body: HOHOKUS, Suffix: TOWNSHIP

후속하는 사용예는 지역성 인덱스 내에 저장될 수 있는 특징들을 토큰화 및 정규화하는 장점을 예시하는데, 이들의 생성이 후술된다. 인덱스 내에 이러한 특징을 적용하지 않으면, 변형된 약어들이 상이한 도시명으로서 나타나게 된다. 이러한 특징들이 인덱스 내에 적용되면, 약어들이 공통 형태로 만들어지므로, 어플리케이션 개발자로 하여금 목록을 단일 정확한 엔트리로 줄일 수 있도록 허용한다. 비록 토큰의 대문자화 동작이 정합을 용이하게 하기 위하여 일관된 대문자로 정규화되었지만, 토큰들은 전형적으로는 각 토큰의 첫 번째 문자만이 대문자화된 상태로 사용자에게 제공된다.

인덱스 내의 토큰화 및 정규화된 지역성 명칭이 없으면:

Enter city->Randolph

Please choose from->

Randolph Hghts

Randolph Heights

Randolph Hts.

인덱스 내의 토큰화 및 정규화된 지역성 명칭이 있으면:

Enter city->Randolph

You chose: Randolph Heights

다음의 사용예는 지역성 명칭 내의 방향 토큰들을 토큰화 및 정규화하는 장점을 예시한다. 방향 토큰을 식별함으로써, 지역성 명칭은 방향이 아니라 그들의 보디에 의하여 인덱스될 수 있다. 방향이 정규화된 이후에, 어플리케이션 개발자는 정규화된 토큰만 점검하면 되고 이러한 토큰의 다른 모든 약어들을 점검할 필요가 없다.

인덱스 내의 토큰화 및 정규화된 지역성 명칭이 없으면:

Enter city->Boston

Found: Boston

Enter city->South B

Please choose from->

South Bath

South Barrister

South Barnstable

South Boston

Enter city->S. Boston

City not found: "S. Boston"

Enter city->South Boston

Found: "South Boston"

인덱스 내의 토큰화 및 정규화된 지역성 명칭이 있으면:

Enter city->Boston

Please choose from->

Boston

South Boston

도 8a의 단계 840에서, 정규화 단계로부터 두 개 또는 그 이상의 유사한 지역성 명칭을 최적화하는 동작은, 일반적으로 실시예들에서 각 유사한 지역성 명칭을 해당 지역성 내에 포함된 지리적 특징과 관련시킨다. 지리적 특징들의 예들은 거리, 거리 세그먼트, 랜드마크, 주 공원, 고속도로, 상업 지역 및 주거 지역을 포함한다. Ho-Ho-Kus, New jersey 예시에서, 최적화 동작을 수행하면 HoHoKus 및 for HOHOKUS 모두에 대하여 동일한 지리적 특징을 발견할 것이다.

도 8a의 단계 845에서, 메인 소스 마스크에서는 소스 마스크의 다음 비트가 소스에 할당된다. 실시예에서, 이러한 마스크는 카운티 내에서 유일하다. 다른 실시예에서, 마스크는 모든 지역적 영역(주 또는 대륙)에 대해 고유할 수 있다. 도 10은 미국 및 캐나다에 대한 지역성 명칭 소스 마스크의 두 가지 예를 도시한다. 실시예에서, 소스 마스크 내의 각 비트 위치는 단일 지역성 명칭 소스를 나타낸다. 이러한 마스크는 하나 또는 그 이상의 행정, 우편 또는 다른 지역성 명칭 소스를 포함할 수 있다. 이러한 마스크는 한 나라에서 고유하고, 지역성 명칭 소스의 우선 순위를 암시하지 않는다. 열 "Decimal Bit Value" 내의 각 비트 값에 대하여, 열 "Locality Name Source" 내의 지역성 명칭 소스가 해당 비트 값에 할당된다. 인덱싱 목적을 위하여, 지역성 소스 마스크는 상이한 종류의 지역성 명칭이 말단 어플리케이션에 최적으로 정합되도록 하는 탄력성을 허용한다. 실시예에서, "Trump"라고 표시된 마스크 내의 소스가 인덱싱 목적을 위하여 이러한 소스에서 발견되는 지역성 명칭에게 최고의 우선 순위를 부여하도록 이용될 수 있다. 이러한 소스 내의 각 지역성 명칭에 대하여, 개별 소스 마스크가 역시 생성될 수 있어서, 지역성 명칭이 나타나는 소스를 표시한다.

단계 850에서, 소스 내의 각 지역성 명칭에 대한 소스 마스크 내의 후속 비트 위치가 이 소스로 설정된다. 다중 소스에서 발견되는 명칭들이 그들의 나타나는 각 소스에 대한 마스크 내에서 설정되는 비트를 가질 것이다. 예를 들어, "Boston"이라는 명칭은 동시에 카운티 서브디비전 명칭이고, 행정 위치 및 복수 개의 ZIP 코드에 대한 바람직한 우편 명칭이다. 다중 소스에서 나타나지 않는 명칭들은 그들의 소스에 상응하는 그들의 마스크 내에 설정된 단일 비트만을 가지게 될 것이다. 이러한 프로세스는 단계 810으로 되돌아가 존재할 경우 후속하는 지역성 명칭 소스를 처리한다.

만일 도 8a의 단계 810에서 처리할 잔여 지역성 소스가 존재하지 않으면, 프로세스는 도 8b의 단계 868로 진행한다. 단계 868에서, 모든 이용 가능한 소스로부터의 최적화된 명칭들이 정합된다. 사용가능한 소스들은 그들에 대해 단계 815의 맵 정합 동작이 가능한 소스들이며 도 8a의 단계 855에서의 다른 소스 정합 동작이 가능한 소스들이다. 정합 동작은 정규화된 토큰들을 전체 명칭으로 연접(concatenate)하고 이들을 비교하여, 실시예에서 그들이 정합되는 것으로 간주될 수 있는지 결정한다. 실시예에서, 지역성 명칭 케이스 또는 대소문자 차이의 정규 화 동작이 전술된 바와 같은 정규화 단계 대신에 이러한 명칭 정합 단계에서 수행될 수 있다. 실시예에서, 대소문자를 구별하는 정합 로직이 정합 단계에서 이용될 수 있다. 미국 내의 각 주에 대해서, 지정된 소스로부터의 모든 지역성 명칭들이 실시예 내에서 정합된다.

명칭 정합 동작을 위하여 다수의 상이한 알고리즘들이 이용될 수 있다. 명칭-정합 기법의 예들에는 콘텍스트-민감 정합, 음성학적 정합 및 사운덱스(Soundex)가 포함된다. 콘텍스트-민감(Context-sensitive) 정합은 명칭들의 문자열 정합이거나 명칭의 스펠링 정합이다. 이러한 타입의 정합 동작은 어떤 토큰들이 정합되는지에 대한 정보를 이용하여 수행되며, 이러한 정보는 특정 규칙을 허용한다. 예를 들어, 보디 토큰에서, 바람직한 콘텍스트-민감성 정합 알고리즘은 "John F. Kennedy" 및 "John Fitzgerald Kennedy"를 정합시킬 수 있다. 매우 바람직한 콘텍스트-민감성 정합 알고리즘은 "MLK" 및 "Martin Luther King"을 정합시킬 수 있다. 음성학적 정합(Phonetic matching)은 반면에 단어의 스펠링이 아니라 단어의 사운드를 정합한다. 예를 들어 "fish" 및 "phish"는 음성학적으로는 정합된다. 다양한 언어에서 명칭 정합 동작을 수행하기 위하여, 상이한 음성학적 정합 알고리즘이 이용될 수 있다. Soundex는 명칭을 그들이 영어로 발음되었을 경우의 음향에 따라서 인덱싱하기 위한 음향학적 알고리즘이다. 기초적 목적은 동일한 발음을 가지는 명칭들이 동일한 문자열로 인코딩되도록 함으로써, 스펠링에 다소 차이가 있더라도 명칭들이 정합되도록 하는 것이다. 음성학적 알고리즘에 관련된 더 상세한 정보는 출원 번호 No. 11/377,764호, 출원일 2006년 3월 16일, 명칭 "Geographic Feature Name Reduction Using Phonetic Algorithms", 및 발명자 Jesse Sheridan인 문서에서 발견될 수 있다.

실시예에서, 두 개의 전체 명칭이 정합되도록 하기 위해서는, 문자열들이 정확하게 일치해야 한다. 만일 전체 명칭이 정합되지 않으면, 실시예들에서는 보디 토큰의 정합이 시도된다. 보디 토큰들은 정합되어야 하고 방향 및 타입 토큰들이 또한 성공적인 토큰 정합을 위하여 정합되어야 한다. 그러므로, 토큰의 정합 동작이 하나 또는 그 이상의 선행 토큰으로부터 개시되지 않을 수 있고, 한 토큰이 다른 토큰의 선행 하부문자열(leading substring)이 되어야 한다. 그러므로, 정합하는 토큰들이 또한 특정 토큰들을 무시해야 한다. 실시예에서, 두 개의 정합되는 명칭들 사이에서 사소한 스펠링 변동이 허용될 수 있다. 실시예에서, 명칭 정합이 잘못된 정합을 방지하기 위하여 매우 보수적인 방식으로 구현된다. 따라서:

"North Boston"은 "South Boston"과 정합되지 않는다.

"South Boston"은 "Boston"과 정합되지 않는다.

"Township of Rutland"는 "Rutland Township"과 정합되지 않는다.

도 8b의 870에서, 단계 868에서 발견되는 모든 정합된 지역성 명칭들의 집합들이 처리된다. 정합된 지역성 명칭들의 각 집합은 중복 또는 다소 변형된 명칭을 가지는 지역성들이다. 단계 870에서, 만일 정합된 지역성 명칭들의 다른 집합이 존재하면, 프로세스는 정합된 명칭들이 중첩된 지형(overlapping geometry)을 표시하는지 단계 872에서 결정한다. 단계 872에서, 정합된 명칭은 지역성이 중첩되거나 또는 그들이 서로 단지 인접할 뿐일 지라도, 그들이 최적화 단계 840에서 결정 된 적어도 하나의 공통 지리적 특징을 공유하는 한 중첩하는 지형을 표시한다.

도 8b의 단계 872에서 정합된 명칭이 중첩된 지형을 나타낸다면, 만일 단계 873에서 중첩되는 지형이 정확하다면, 단계 874에서 하나를 제외한 중첩 명칭들이 지리적 데이터베이스 내의 해당 지역성 인덱스 엔트리로부터 제거된다. 만일 하나의 지역성 명칭과 관련된 모든 지리적 특징들이 서로 동일하면, 이러한 지역성 명칭들은 순수한 중복물들이고 하나를 제외한 모두가 제거된다. 지역성 명칭들은 해당 명칭이 동일한 지역성을 나타낼 때 그리고 그러한 경우에만 제거된다. 이러한 단계는 중복 지역성을 제거하고 지역성 명칭 집합을 감소시킨다. 많은 중복 엔트리를 포함하는 지역성 인덱스에 대하여, 이러한 기법은 인덱싱의 양 및 인덱스에 의하여 요구되는 저장 공간을 현저하게 감소시킬 것이다. Ho-Ho-Kus, New jersey 예의 경우에, 각 명칭에 대하여 상호 연접된 정규화된 토큰들은 모두 "HOHOKUS TOWNSHIP"이다. 이러한 두 개의 지역성 명칭들이 최적화 단계로부터 공통된 모든 지리적 특징을 가지는 것으로 결정될 것이기 때문에, 이러한 지역성 명칭들은 순수한 중복물들이고 하나가 제거된다. 그러면, 프로세스는 다시 단계 870으로 돌아가서 정합된 지역성 명칭들의 다른 집합이 존재하는지 결정한다.

도 8b의 단계 873에서 중첩 지형이 정확하지 않거나, 또는 지역성이 다른 지역성, 일반적으로는 다소 상이한 명칭을 가지는 지역성과 적어도 하나이지만 전체가 아닌 지리적 특징들을 공유하면, 이러한 지역성들은 단계 875에서 동일한 지역성인 것으로 간주되어 통합된다. 예를 들어, Vermont 내의 "Randolph" 및 "Randolph Center"는 두 개의 개별 도시지만 상호 중첩되는 도시이다. 이러한 두 도시가 중첩하기 때문에, 이들은 적어도 하나의 공통 지리적 특징을 공유하고, 이들은 동일한 지역성인 것으로 간주되어 통합된다.

실시예에서, 지역성 명칭의 통합 동작은 중첩하는 지역성들이 비-중첩 특징들을 가지지 않아서 상호 구분될 수 없는 경우에만 발생한다. 예를 들어, 만일 Randolph 및 Randolph Center 모두가 중첩되는 거리 명칭이 없는 Main Street을 가진다면, 두 도시들은 통합될 수 있다. 하지만, 예를 들어 만일 두 도시 모두가 "2 Main Street"을 가진다면, 이들은 통합될 수 없다.

후속하는 사용예는 중첩하는 지형을 가지는 다중 소스로부터 중복 지역성 명칭들 중 하나를 제외하고 모두 제거하는 효과를 예시한다. 이러한 특징이 없다면, 지역성 명칭은 사용자에게 제공된 선택 사항에서 중복 표시된다.

중복 제거 기능이 없으면:

Enter city->Hanover

Please choose from->

Hanover (County subdivision)

Hanover (Administrative place)

Hanover (03755)

중복 제거가 수행된 이후에는:

Enter city->Hanover

Found: "Hanover"

후속하는 사용예도 역시 다소 상이한 명칭을 가지는 지역성들의 통합의 장점 을 예시한다. 통합 기능이 없으면, 사용자는 원하는 목적지가 위치한 지역성 내에 다소 상이한 명칭 중 어느 것이 위치되는지를 알 수 없다. 통합을 통하여, 사용자는 명칭을 구분할 필요가 없다. 예를 들어, 지역성 "Randolph", "Randolph Center" 및 "Randolph Township"은 중첩되고, 따라서 이들은 단일 명칭 "Randolph"로 표시되는 공통 영역으로 통합된다.

통합 기능이 없으면:

Enter city->Randolph

Enter street->Main Street

Please choose from->

Main Street, Randolph

Main Street, Randolph Center

Main Street, Randolph Township

통합 기능이 있으면,

Enter city->Randolph

Enter street->Main Street

Found: "Main Street, Randolph"

도 8b의 단계 876에서, 정합된 명칭들로부터의 모든 특징들의 연합(union)이 통합된 명칭으로 지정된다. 예를 들어, FIPS55에서, Boston의 카운티 서브디비전이 특정 지리(geography)을 정의한다. Boston의 행정 위치(Administrative Place)는 중첩되지만 반드시 동일하지는 않는 다른 지리를 정의한다. Boston의 우편 위 치(postal place)는 미국의 우편이 배달될 수 있는 거리를 담당하는 지리의 제3 집합을 정의한다. 이러한 상이한 특징들의 연합을 생성하면 Boston과 관련된 특징들의 완전한 집합을 형성한다. 이러한 Boston에 관련된 명칭들 각각에 관련된 지리적 특징들의 연합은 이러한 소스들 각각을 포함하는 지리적 특징들의 집합을 포함한다. 예를 들어, 만일 말단 사용자에게 Adams St.이 관심 대상이라면, 비록 Adams St.이 우편 위치 Boston의 일부는 아니라도, Adams St.이 해당 사용자에 대하여 발견될 것인데, 그 이유는 이것이 다양한 지역성 명칭 소스로부터의 정합 지역성 명칭들로부터의 지리적 특징들의 연합에 기인하여 Boston의 카운티 서브디비전의 일부이기 때문이다. 그러므로, 고유 지역성 명칭들의 목록이 얻어지는데, 여기서 비트들은 각 명칭이 발견된 소스에 상응하는 소스 마스크 내에서 설정되고, 각 명칭이 적용되는 모든 지리적 특징들의 연합이 얻어진다. 그러면, 프로세스는 단계 870으로 돌아가 정합되는 지리적 명칭의 다른 집합이 존재하는지 결정한다.

도 11은 지역성 명칭들의 정합을 통하여 지역성 명칭 집합을 감소시키기 위한 알고리즘을 도시한다. 지역성 명칭 소스 내의 각 지역성 명칭 A에 대하여, 또한 명칭 A와 정합하는 다른 모든 소스 내의 각 명칭 B에 대하여, B와 관련되며 이미 A로 할당되지 않은 모든 세그먼트 거리를 A로 할당한다. 이것이 전술된 도 8b의 단계 876이다. 이미 소스 마스크 A 내에 포함되지 않은 소스 마스크 B 내에 어떤 비트를 포함시키고, B를 삭제한다.

도 8b의 단계 872에서, 만일 정합된 명칭이 중첩된 지형을 나타내지 않으면, 정합된 명칭들에는 보조어가 추가되어 단계 878에서 이들이 유일하도록 한다. 중 첩된 지형을 나타내지 않는 정합된 명칭들은 물리적으로 불일치하는 중복된 또는 다소 변형된 명칭을 가지는 지역성들이다. 실시예에서, 이와 같이 물리적으로 불일치하는 지역성들은 미국 내의 한 주 내에 위치한 도시들이다. 많은 주들이 동일 또는 다소 상이한 명칭을 가지는 다중 도시를 포함한다. 일반적으로, 중복 명칭을 가지는 이러한 지역성들은 한 주 내의 상이한 카운티 내에 존재한다. 그러므로, 이러한 중복 명칭들은 보조어(예를 들어 해당 지역성이 위치한 카운티 명칭)를 사용자에게 제공함으로써 사용자에 의하여 식별될 수 있다. 지역성의 보조어는 전형적으로는 괄호 내에 표시되거나 또는 지역성 명칭 이후에 인용부호 내에 표시된다. 그러나, 카운티 명칭 또는 다른 경계 보조어(border adornment)들은 비-지역 사용자(non-local users)에게는 식별될 수 없을 수 있다. 그 대신에, 중복 명칭을 가지는 각 지역성에 인접한 대도시이며 쉽게 식별가능한 도시의 명칭은 사용자에게 더 나은 정보를 제공할 것이다. 그러므로, 단계 878에서 개별 도시 보조어가 단계 872로부터의 명칭들 각각에 대한 지역성 인덱스 내에 저장된다. 이러한 타입의 보조어를 생성하는데 관련된 더 상세한 정보가 출원 번호 No. 11/345,877호, 출원일 2006년 2월 1일, 명칭 "Method for Differentiating Duplicate or Similarly Named Disjoint Localities within a State or other Principle Geographic Unit of Interest", 출원인 Michael Geilich인 문헌에서 발견될 수 있다. 그러면, 이러한 프로세스는 다시 단계 870으로 되돌아가 정합된 지역성 명칭들의 다른 집합이 존재하는지 결정한다.

후속하는 사용예는 중복되거나 다소 변형된 명칭을 가지는 불일치 지역성들 에 대한 보조어를 도시한다.

카운티 명칭으로 보조어 추가(Adorning):

Enter state->PA

Enter city->Bethel

Please choose from->

Bethel (Berks)

Bethel (Allegheny)

Bethel (Lancaster)

Bethel (Mercer)

Bethel (Sullivan)

Bethel (Wayne)

크고, 인접하여, 쉽게 식별되는 도시 명칭으로 보조어 추가:

Enter state->PA

Enter city->Bethel

Please choose from->

Bethel (Fredericksburg)

Bethel (Pittsburgh)

Bethel (Lancaster)

Bethel (Youngstown)

Bethel (Willamsport)

Bethel (Scranton)

이러한 사용예에서, 어플리케이션은 사용자로부터 다른 정보를 요청하기 이전에 각 사용자 엔트리를 처리한다. 다른 실시예에서, "크고, 인접하여, 쉽게 식별되는 도시명칭으로 보조어 추가"하기 위하여, 만일 사용자가 주, 도시 및 거리 명칭을 어플리케이션이 이러한 사용자 엔트리를 처리하기 이전에 입력하면, 거리 주소가 오직 하나의 선택물에서만 발견될 때 고유 목적지가 결정될 수 있다. 예를 들어:

크고, 인접하여, 쉽게 식별되는 도시 명칭으로 보조어 추가:

Enter state->PA

Enter city->Bethel

Enter street name->Main Street

Found: "Main Street, Bethel (Fredericksburg)"

만일 단계 870에서 정합된 지역성 명칭들의 다른 집합이 존재하지 않으면, 도 8b의 단계 880에서 인덱스가 생성된다. 이러한 인덱스는 우선 지리적 특징에 의하여 정렬된다. 각각의 지리적 특징에 대하여, 해당 지리적 특징을 포함하는 지역성들이 우선 순위에 의하여 인덱싱된다. 인덱스 내의 지역성 명칭들은 우선 순위에 의하여 정렬되어, 어플리케이션 개발자들로 하여금 모든 지리적 특징에 대해 가장 유력한 명칭을 선택하는 기능을 해당 어플리케이션으로 프로그램하도록 허용한다. 이를 통하여 말단 사용자에게 예를 들어 제한된 메모리 환경에서 선택할 가장 유력한 명칭을 제공한다. 각 지리적 특징에 대하여 오직 두 개의 지역성 명칭 들만을 저장할 수 있는 제한된 메모리 장치에 대하여, 어플리케이션 개발자들은 지역성 인덱스를 이용하여 두개 이상의 지역성과 관련된 지리적 특징에 대하여 사용자에게 가장 높은 우선 순위를 가지는 지역성을 선택하도록 할 수 있다. 이와 유사하게, 바텀-업 검색 어플리케이션에 대해서, 어플리케이션은 주소 또는 지리적 특징을 사용자로부터 요청하고, 지역성의 목록을 사용자에게 제공하는데, 이들 중에서 사용자가 선택한다. 지역성의 목록을 제공할 때, 해당 주소와 관련된 가장 높은 우선 순위를 가지는 명칭들이 이용될 수 있다.

실시예에서, 어느 지리적 특징과 관련된 지역성들의 우선 순위는 의도된 어플리케이션에 대한 통상의 사용법 내의 각 지역성 명칭의 유력성(prevalence)에 기반한다. 실시예에서, 통상의 사용법에 기반한 우선 순위 부여 동작이, 지역성 명칭으로 하여금 상이한 사용자에게 상이하게 정렬되도록 허용한다. 통상의 사용법에서의 "New York City" "Manhattan" 및 "SoHo"와 같은 중첩 지역성의 예에서, 해당 지역을 잘 알고 있는 지역 사용자는 세 개의 지역성들 중 더 구체적인 것인 "SoHo"을 이용할 가능성이 높다. 만일 어떤 어플리케이션이 이러한 지역 사용자(local user)를 고려하여 의도된 것이면, 가장 높은 우선 순위를 가지는 지역성 명칭은 해당 지역성 명칭이 발견될 수 있는 최소 개수의 소스를 가지는 것일 가능성이 높다. 그러므로, 가장 높은 것부터 낮은 것으로 우선 순위를 정렬하면, "SoHo", "Manhattan" 및 "New York City"가 될 것이다.

그러나, New York City 내의 중첩 지역성의 동일한 예를 이용하면, 통상의 사용법에서 해당 지역을 잘 모르는 비-지역 사용자의 경우에는, 이들은 아마도 더 잘 알려지고 쉽게 구별되는 지역성을 이용할 가능성이 높다. 만일 어느 어플리케이션이 이러한 비-지역 사용자에 대하여 의도된다면, 가장 높은 우선 순위를 가지는 지역성 명칭은 아마도 해당 지역성 명칭이 발견될 수 있는 가장 많은 개수의 소스를 가지는 것일 것이다. 그러므로, 우선 순위를 가장 높은 것부터 가장 낮은 순으로 배열하면, "New York City", "Manhattan" 및 "SoHo"가 될 것이다.

실시예에서, 어플리케이션 내의 우선 순위를 결정하기 위한 알고리즘들은 사용자에 대한 상이한 통상의 사용법을 만족시키기 위하여 상이하게 적용될 수 있다. 예를 들어, 대도시와 같은 지역성 내에서 네비게이팅 하는 지역 사용자에 대하여, 사용자는 지역 사용자의 통상의 사용법에 기반한 지역성 명칭의 우선 순위를 원할 수 있다. 그러나, 동일한 사용자가 멀리서부터 동일한 대도시로 네비게이션하는 동안에, 이 사용자는 비-지역 사용자에 대한 통상의 사용법에 기반한 상이한 우선 순위를 원할 수 있다. 그러나, 사용자가 대도시에 도달하고 해당 도시로의 경계를 통과하면, 사용자는 지역 사용자의 우선 순위로 다시 돌아가는 우선 순위를 원할 수 있다.

다수의 상이한 우선 순위 부여 기법이 가능하다. 바람직한 실시예에서, 지리적 특징과 관련된 가장 높은 우선 순위를 가지는 지역성은 바람직한 우편 명칭 소스 내에서 발견되는 것이고, 그리고 잔여 지역성들의 우선 순위는 개별 지역성 소스 마스크 내에 설정된 비트의 개수에 의하여 결정된다. 실시예에서, 제1 지역성이 통상의 사용법에서 더 널리 알려지거나 더 유력하다면, 제1 지역성은 제2 지역성보다 더 높은 우선 순위를 가진다. 실시예에서, 지역성 명칭의 우선 순위는 해당 명칭이 발견될 수 있는 소스의 개수에 의하여 결정된다. 가장 높은 우선 순위를 가지는 지리적 특징에 대한 지역성 명칭은 가장 많은 개수의 소스 내에서 발견되는 지역성 명칭이고, 따라서, 이것은 자신의 소스 마스크 내에 설정된 가장 많은 비트를 가진다. 지리적 특징에 대한 지역성 명칭들의 우선 순위는 높은 것보다 낮은 것 순서이다.

실시예에서, 어플리케이션 개는 또한 소스 마스크를 이용하여, 다른 것들에 비하여 특정 지역성 명칭 소스를 더 선호함에 의한 이러한 기초적 우선 순위 기법을 무시할 수 있다. 다른 실시예에서는, 우선 순위는 가장 큰 물리적 지역성 크기 또는 가장 큰 지역성 인구에 대하여 정의될 수 있다. 다른 실시예에서, 우선 순위는 어느 지역성 내의 예를 들어 거리 세그먼트와 같은 지리적 특징들의 가장 큰 개수로서 정의될 수 있다. 또한, 우선 순위는 해당 지역성 내에 위치한 주요 지리적 특징들의 가장 큰 개수의 관점에서 정의될 수 있는데, 이것은 다른 실시예에서 해당 지역성 내에 위치한 지리적 특징들의 크기와는 반대인 것이다. 주요 지리적 특징의 일 예시는 중요한 고속도로이다. 실시예에서, 우선 순위는 지역성 소스 마스크를 이용하여 정의되어 다른 소스에 비하여 특정 지역성 명칭 소스의 선호를 결정할 수 있다. 실시예에서, 어플리케이션 개발자는 도 10의 "Trump"라고 표시된 지역성 소스들로부터의 지역성 명칭들을 최고-우선 순위 명칭으로서 이용할 수 있다.

지역성 우선 순위가 동률을 이루는 실시예에서, 주된 정렬은 전술된 기법들 중 하나를 이용하여 수행되고, 필요한 경우에는 전술된 기법들 중 하나에 기반한 제2 정렬 방법에 의하여 수행된다. 바람직한 실시예에서, 각 지역성이 발견될 수 있는 가장 높은 것부터 낮은 것으로 소스의 개수에 대하여 주된 정렬이 수행된다. 예를 들어, 제2 정렬은 지리적 특징들의 개수 또는 거리 세그먼트의 개수에 기반하고, 각 지역성 내에 포함된 가장 높은 것부터 낮은 것 순으로 수행된다.

도 12는 주어진 지리적 특징에 대한 지역성 명칭의 우선 순위를 결정하기 위한 알고리즘의 일 실시예를 도시한다. 지리적 데이터베이스 내의 각 거리 세그먼트 측면(street segment side) S에 대하여, S가 할당되는 모든 지역성 명칭들 A를 찾는다. 각 A에 대하여, 그 소스 마스크 내에 가장 많은 비트가 설정된 명칭 A를 찾는다. A를 이 거리 세그먼트 측면 S에 대한 인덱스 내의 다음으로 높은 우선 순위 명칭에 할당한다.

도 8b의 프로세스가 단계 890에서 종료한다.

도 13은 특징 지역성 우선 순위 테이블(Feature Locality Priority table), 지역성 명칭 테이블(Locality Name table) 및 특징 찾기 테이블(Find Feature table)을 포함하는 지역성 인덱스 파일의 일 실시예를 도시한다. 이러한 테이블은 최종적으로는 데이터베이스에 저장된다. 도 13의 특징 지역성 우선 순위 테이블의 실시예에서, 지역성을 각 지리적 특징에 대한 우선 순위에 의하여 목록화한다. 실시예에서, 테이블 내의 각 지리적 특징은 특징 ID 번호인 FF_ID와 관련된다. 특징 ID 번호는 순차적일 수 있지만 반드시 순차적이어야 하는 것은 아니다. 특징 ID 번호는 또한 특징 찾기 테이블로의 링크이다. 실시예에서, 네트워크 내의 각 지리적 특징과 관련된 각 지역성은 지역성 ID 번호인 NAME_ID와도 역시 관련된다. 지역성 ID 번호는 순차적일 수 있지만 반드시 순차적이어야 하는 것은 아니다. PRIORITY 필드는 지리적 특징과 관련된 지역성 명칭의 유력성을 나타낸다. 전술된 바와 같이, 각 지리적 특징과 관련된 지역성 명칭에 우선 순위를 부여하기 위하여 다수의 우선 순위 기법이 존재한다. PRIORITY는 가장 높은 우선 순위로서 "1"부터 시작하는 순차적 번호이다. 이 테이블은 또한 전술된 바와 같이, 이러한 지역성에 대한 지역성 명칭 소스 마스크 LOC_MASK를 포함한다.

지역성 인덱스의 다양한 포맷은 모든 개수의 테이블 엔트리로 하여금 특징 지역성 우선 순위 테이블 내의 각 지리적 특징에 대해 포함되도록 허용한다. 이것은 우편 명칭에 대하여 특히 북미에서 매우 중요하다. 각 위치에 대해 오직 하나의 우편 지역성 명칭이 일반적으로 존재하는 반면에, 우편 서비스는 동일한 위치에 대한 모든 개수의 허용가능한 우편 지역성 명칭을 가진다. 지역성 인덱스는 각 지리적 특징에 대한 모든 바람직하고 허용가능한 우편 명칭을 포함한다.

실시예에서, 도 13의 지역성 명칭 테이블은 지역성 ID 번호 NAME_ID를 통하여 특징 지역성 우선 순위 테이블과 링크된다. 이 테이블은 또한 실시예에서는 혼합된 대소문자를 이용한 해당 지역성의 전체 명칭인 FULL_NAME을 포함한다. 실시예에서, FIPS55에 표시된 바와 같은 전체 지역성 명칭들이 해당 테이블 내의 전체 지역성 명칭들의 최종 인코딩을 위하여 이용된다. 그러나, 전체 지역성 명칭을 표시하기 위한 다른 소스들도 역시 이용될 수 있다. 테이블의 NAME_KEY 필드는 인덱싱 목적을 위한 지역성 명칭의 중요부분이다. 실시예에서, NAME_KEY가 지역성 명칭의 전술된 토큰화 및 정규화로부터 발견된다. 이를 통하여, 예를 들어 "Hollywood" 및 "West Hollywood"가 모두 "H" 하에 인덱스되도록 허용하는데, 그 이유는 이들 둘 모두의 메인 보디 토큰이 "Hollywood"이기 때문이다. ADORNMENT 필드는 크고 용이하게 식별되는 위치의 지역성 명칭 또는 해당 인덱스 근처의 도시의 지역성 명칭을 포함하는 지역성 명칭 테이블 내의 다른 엔트리를 가리키는 포인터이다. 실시예에서, ADORNMENT는 해당 지역성이 주와 같이 도시의 주된 서브디비전 내의 모호한 지역성일 경우에만 저장된다. 실시예에서, 보조어가 사용자의 장치 또는 시스템 상의 목록 내의 중복 지역성들을 구별하기 위하여 이용된다.

NAME_LC 필드는 지역성 명칭의 언어에 대한 3문자 코드이다. 실시예에서, NAME_LC는 각 지역성 명칭에 대해서 설정되어 다중언어 국가를 지원하기 위하여 해당 명칭의 원래 언어(native language)를 표시한다. 실시예에서, NAME_LC는 모든 개수의 문자일 수 있다. LOC_SIZE는 이러한 지역성 명칭과 관련된 지리적 특징의 개수의 카운트를 표시하고 어플리케이션 개발자들에 의하여 특징 지역성 우선 순위 테이블 내에 제공된 기본 PRIORITY 기법을 무효화할 수 있다. COUNTRY는 나라 코드이고, 해당 지역성이 위치한 나라의 3문자 약어이다. 실시예에서, COUNTRY는 ISO 3166-1과 같은 표준 나라 코드일 수 있는데, 이것은 국제 표준 기구(International Organization for Standardization)에 의하여 최초로 발행된 ISO 3166 표준의 일부이다. 실시예에서, COUNTRY는 모든 개수의 문자일 수 있다. CENTER_ID는 해당 지역성에 대한 지리적 데이터베이스 내의 다른 지점에서 발견되는 도시 중심지점 특징(city center point feature)으로의 링크이다. 실시예에서, 이러한 도시 중심 지점 특징들은 지역성 중심점의 위도 및 경도 좌표이고, 또한 해당 도시 중심에 상응하는 거리 세그먼트이다. 도시 중심은 특정 거리 주소가 요청 되지 않거나 발견될 수 없는 경우에 사용자에게 지역성 내의 지점을 제공한다.

실시예에서, 도 13의 지역성 명칭 테이블은 지역성에 대한 다수의 다른 유용한 타입의 정보를 포함할 수 있다. 예를 들어, 문자-음성 어플리케이션에 대하여 지역성 명칭 테이블 내에 음소(phoneme)를 포함시키는 것이 유용할 것인데, 이 경우에 음소는 동등하기 인지되는 음성 음향 또는 부호 요소의 집합이다. 지역성 명칭 테이블 내에 저장될 수 있는 상이한 타입의 정보의 다른 예들은 지역성의 시청의 사전 및 지역성의 경찰국의 전화 번호 들이다.

실시예에서, 도 13의 특징 찾기 테이블은 각 지리적 특징에 대한 정보를 포함한다. FF_ID는 지리적 특징 정보를 특징 지역성 우선 순위 테이블로 링크시키는데 이용되는 특징 ID 번호이다. FEAT_TYPE은 지리적 특징의 타입인데, 즉, "R"은 도로 특징이고, "F"는 페리 노선 특징이다. FEAT_ID는 해당 특징에 대한 지리적 데이터베이스 내의 정보로의 링크인데, 즉, 거리 명칭 및 주소 범위 같은 것이다. FEAT_ID는 또한 간접 링키지(linkage) 또는 관심 지점(POI)과 같은 지리적 데이터베이스로 링크된 다른 콘텐츠를 제공한다. SIDE는 지리적 특징의 일 측면이고, 예를 들어 거리 에지(street edge)이다. SIDE는 우측에 대해서 "R"을 가지고, 좌측에 대해서 "L"을 가지며, 양측 모두에 대해서 "B"를 가지고, "적용 불가능(not applicable)"에 대해서는 "null"을 가진다.

실시예에서, 지역성 인덱스는 국제적 포맷을 포함하는 다중 포맷에서 제공되어, 독점적 지리적 데이터베이스들과의 용이한 통합을 허용한다. 지역성 인덱스가 모든 나라로부터의 데이터를 수용하도록 제공된다. 포맷이 일반화되는 동안에, 콘 텐츠는 맞춤(tailored)되어 각 나라에 적합한 특정 지역성 소스 및 타입을 포함한다. 독점적 어플리케이션은 각 지역성 명칭에 대한 정확한 발음을 제공한다.

지역성 인덱스 테이블 용법에 대한 실시예에서, 주소를 찾는 탑-다운 방식의 구현예에서 지역성이 우선 결정되고, 그 이후에 정확한 지리적 특징이 해당 지역성 내에서 발견된다. 네비게이션 어플리케이션이 우선 명칭 정합을 수행하여 지역성 명칭 테이블 내에서 원하는 지역성 명칭을 찾는다. 이러한 지역성이 발견되면, 특징 지역성 우선 순위 테이블이 선택된 지역성의 NAME_ID를 이용하여 검색되어, 해당 지역성 내에 포함되는 지리적 특징들을 결정한다. 이러한 특징들의 FF_ID들이 특징 찾기 테이블로의 인덱스로서 이용되어, 거리 세그먼트의 경우에 거리 명칭 및 주소 범위와 같은 특정 특징을 찾는데 이용되는 이러한 특징에 대한 정보를 검색하는데, 그러면 정합이 수행되어 원하는 특정 지리적 특징을 선택한다. 예를 들어, [Enter City->Boston]이다. "Boston"은 지역성 명칭 테이블 내의 명칭들과 정합되어 "Boston"의 NAME_ID를 반환한다. [Enter Street->Adams]의 경우를 본다. 특징 지역성 우선 순위 테이블 이 그 NAME_ID가 "Boston"의 NAME_ID인 FFID의 목록을 검색한다. 특징 찾기 테이블이 지리적 데이터베이스 내의 "Adams"를 지시하는 FEAT_ID에 대해서 검색된다. 후속하여, 사용자로부터 원하는 집 번호가 요청될 수 있으며, 지리적 데이터베이스 내의 요청된 집 번호를 포함하는 주소 범위를 가리키는 FEAT_ID에 대해서 특징 찾기 테이블이 검색된다. 특징 찾기 테이블은 지리적 데이터베이스 내의 이러한 특징에 대한 위도 및 경도 포인트를 가리키는 FEAT_ID에 대해서 검색되어, 예를 들어 네비게이션 어플리케이션 또는 장치 상에 이러한 장치 의 위치를 사용자에게 디스플레이할 수 있을 수 있다. 성능을 향상시키기 위하여, 지역성 인덱스는 흔히 사전 콤파일되어 이러한 간접 참조(indirect references)들 중 많은 것들을 제거할 것이다.

지역성 인덱스 용법에 대한 실시예에서, 주소 검색의 바텀-업 구현에서, 우선 목표 지리적 특징의 목록이 선택되고, 그리고 원하는 지역성이 해당 명칭에 의한 특징을 포함하는 모든 지역성들의 목록으로부터 결정함에 의하여 선택된다. 네비게이션 어플리케이션이 우선 정합을 수행하여 지리적 특징들의 목록을 특징 검색 테이블 내에서 발견한다. 그러면 특징 검색 테이블로부터 상응하는 FF_ID들이 특징 지역성 우선 순위 테이블로의 인덱스로서 이용된다. 그러면 이러한 FF_ID에 대한 우선 순위 테이블 내의 엔트리들이, 지역성 명칭 테이블 내의 그 명칭이 원하는 지역성과 정합되는 NAME_ID에 대해 스캐닝될 수 있다. 만일 어플리케이션 개발자들이 지역성 선택 사항들을 사용자에게 제공하고자 한다면, 어플리케이션은 우선 순위 순서로 지역성 NAME_ID들을 고려하여야 하고, 고려 대상인 FF_ID 들에 대하여 고유한 가장 높은 우선 순위를 가지는 지역성 명칭을 선택한다. 그러면 이러한 명칭들이 사용자에게 제공되어 사용자가 선택할 수 있다. 탑-다운 경우에서와 같이, 지역성 인덱스들도 흔히 사전 컴파일되어 테이블들 간의 많은 간접 참조들을 제거한다.

실시예들에서, 지역성 인덱스가 관심 영역 및 랜드마크와 같은 명칭이 부여된 위치를 검색하기 위하여 이용될 수 있다. 이러한 지역들의 목록이 우선 독점적 지역성 데이터로부터의 거리 세그먼트와 관련된다. 그러면, 어플리케이션은 원하 는 관심 영역 또는 랜드마크를 정합시켜 해당 거리 세그먼트를 검색한다. 그러면, 어플리케이션은 정확한 지역성을 결정하기 위하여 거리 세그먼트를 이용한 전술된 주소를 검색하기 위한 구현예를 이용한다.

실시예에서, 지역성 인덱스가 도시 중심을 찾기 위해 이용될 수 있다. 어플리케이션은 지역성 명칭 테이블 내의 FULL_NAME 및 NAME_KEY를 이용하여 원하는 지역성을 명칭 정합시켜 테이블 내에서 정확한 엔트리를 검색할 것이다. 정확한 엔트리가 검색되면, CENTER_ID 필드가 지리적 데이터베이스 내의 상응하는 독점적 지역성 중심 정보(즉 위도 및 경도 좌표 또는 도시 중심에 상응하는 거리 세그먼트)를 검색하는데 이용된다.

실시예에서, 지역성 인덱스가 지역성을 중복 명칭을 가지지만 구별되는 지리인 지역성을 명확하게 구별하기 위하여 이용될 수 있다. 어플리케이션은 지역성 명칭 테이블 내의 FULL_NAME 및 NAME_KEY를 이용하여 명칭 정합 동작을 수행하여 테이블 내에서 정확한 엔트리를 검색한다. 예를 들어, 만일 지역성이 "Brentwood, California"라면, 두 개의 일치하는 것들이 도 4에 도시된 바와 같이 발견될 것이다. 그러면, 지역성 명칭 테이블로부터의 ADORNMENT가 각 Brentwood 지역성에 대하여 이용될 수 있는데, 예를 들어, "Los Angeles" 및 "San Francisco" 보조어들이 이용될 수 있다. 이러한 것들이 사에게 "Brentwood (Los Angeles)" 및 "Brentwood (San Francisco)" 라고 디스플레이되고 이로부터 사용자가 선택할 수 있다.

실시예에서, 지역성 인덱스가 주소 특징들 내의 모호성을 해결하기 위하여 이용될 수 있다. 예를 들어, 도 3의 "2 Adams Street" 예에서, 어플리케이션은 각 특징에 대하여 PRIORITY에 의하여 정렬된 다중 지역성 명칭들을 이용할 것이며, 이를 통하여 Boston, Massachusetts의 지역성 내에서 발견된 네 개의 "2 Adams Street" 주소들을 구별한다. 우선 어플리케이션이 특징 찾기 테이블의 FEAT_ID 필드를 이용하여 지리적 데이터베이스 내의 중복 주소들에 상응하는 거리 세그먼트를 찾을 것이다. 그러면, 어플리케이션은 상응하는 FF_ID를 특징 찾기 테이블 내에서 발견할 것이다. 그러면, FF_ID가 특징 지역성 우선 순위 테이블로의 인덱스로서 이용된다. 지역성들은 고유한 NAME_ID 가 각 FF_ID 엔트리에 대하여 발견될 때까지 PRIORITY를 이용하여 높은 것부터 낮은 우선 순위 순서로 검색된다. NAME_ID는 지역성 명칭 테이블로의 인덱스로서 이용되어 각 중복된 주소에 대한 고유 지역성 명칭인 FULL_NAME을 검색한다. "2 Adams Street"에 대한 예시에서, 고유한 지역성 명칭들이 Charlestown, Hyde Park, Roxbury 및 Dorchester, Boston, Massachusetts의 모든 서브-지역성들에서 발견될 것이다.

실시예에서, 지역성 인덱스가 탑-다운 어플리케이션 내에서 요청된 특징에 대한 인접 영역을 검색하는데 이용될 수 있다. 몇 가지 경우에서, 원하는 특징이 사용자에 의하여 특정된 지역성 내에서 발견되지 않을 수 있고, 네비게이션 어플리케이션이 이러한 검색 결과를 인접한 지역성 또는 더 큰 지역성을 포함하는 것으로 확장하려고 원할 수 있다. 우선 어플리케이션은 원하는 지역성의 명칭을 지역성 명칭 테이블 내에서 정합시키고, 상응하는 NAME_ID를 검색한다. 이러한 지역성 NAME_ID를 가지는 특징 지역성 우선 순위 테이블 내에서는 요청된 특징에 상응하는 FF_ID가 존재하지 않다고 결정한 이후에, 어플리케이션은 이러한 NAME_ID를 포함하 지 않는 특징 지역성 우선 순위 테이블 내에서 하나 또는 그 이상의 FF_ID를 검색할 것이다. 더 높거나 낮은 우선 순위를 가지는 우선 순위 체인이 특징 지역성 우선 순위 테이블 내의 이러한 FF_ID에 대하여 후속함으로써 이러한 FF_ID에 상응하는 다른 NAME_ID를 검색할 수 있다. 요청된 주소가 이러한 다르고 관련된 지역성 중 하나에 존재하는지 여부를 결정하기 위하여 특징 찾기 테이블을 참조할 수 있다.

실시예에서, 다음의 사용예는 지역성 인덱스의 특징에 우선 순위를 부여하는 것의 장점을 예시한다. 우선 순위를 부여하지 않으면, 사용자에게 질의할 때 가장 인식가능한 명칭을 어떻게 이용할지가 어플리케이션 개발자에게는 명확하지 않다. 몇 가지 지역에서, 우편 명칭이 가장 공통적이다. 다른 지역에서, 행정 명칭들이 잘 공지된다. 우선 순위 특징을 가지면, 가장 공통인 명칭이 선택될 수 있다.

우선 순위 부여 동작이 없으면:

Enter street->Broadway

Please choose from->

Broadway (Charlestown, MA)

Broadway (Manhattan, NY)

우선 순위 부여 동작이 있으면:

Enter street->Broadway

Please choose from->

Broadway (Boston, MA)

Broadway (New York, NY)

도 14에 예시된 사용예의 실시예에서, 네비게이션 어플리케이션은 인접 도시가 잘못 특정될 경우에 비일관성을 보상할 수 있다. 시카고와 같은 대도시들은 일반적으로 교외(suburb)에 의하여 둘러싸여있다. 교외 지역들은 개별적이고 그들은 각자의 행정 구조를 가진다. 특히, 그들의 지역성 명칭들은 흔히 상이하다. 사용자는 이러한 교외 지역에 대해서는 알지 못할 수 있고, 오직 큰 중심 도시만 생각할 수 있다. 일 예가 도 14에 도시된 바와 같은 시카고의 북부의 교외에서 발견된다. 사용자가 Lincolnwood 내의 "Bryn Mawr Country Club"을 찾고자 하지만 오직 그 지역을 Chicago라고만 알고 있다고 가정한다. 만일 사용자가 해당 거리 주소가 "6600 North Crawford Ave."라는 것을 안다면, 입력은 다음과 같이 진행할 것이다.

Enter state->Illinois

Enter city->Chicago

Enter street->North Crawford Avenue

네비게이션 어플리케이션이 여기서 비일관성에 주의할 것이다. 어플리케이션은 우선 NAME_ID가 Chicago를 가리키는 특징 지역성 우선 순위 테이블 내의 모든 FF_ID를 검색할 것이다. 어플리케이션은 "North Crawford Avenue" 가 Chicago 내에서는 존재하지 않는다는 것에 주의할 것이다. 어플리케이션은 FF_ID가 "North Crawford Avenue"를 가리키는 특징 지역성 우선 순위 테이블 내의 모든 FF_ID를 검색할 것이다. 어플리케이션은 "North Crawford Avenue"를 Lincolnwood의 Chicago 근교에서 발견할 것이다. 만일 어플리케이션이 "North Crawford Avenue"를 수 개 의 지역성에서 발견하면, 어플리케이션은 특징 지역성 우선 순위 테이블 내의 PRIORITY를 이용하여 이러한 FF_ID에 대한 가장 높은 지역성 명칭을 이용할 것이다. 어플리케이션은 "South Crawford Avenue"가 Chicago 내에 존재한다는 것에 주의할 수 있다. 그러면 어플리케이션은 거리 번호를 요청한다.

Enter street number->6600

Found: "6600 North Crawford Avenue, Lincolnwood, Illinois"

이러한 예에서, 만일 정확한 거리 번호가 두 지역 모두에서 발견되었다면, 어플리케이션은 사용자에게 선택 사항을 제공할 수 있으며, 이것은 "6600 South Crawford Avenue, Chicago" 또는 "6600 North Crawford Avenue, Lincolnwood"이다. 거리 번호 "6600"이 Chicago 내의 "South Crawford Avenue" 상에서는 발견되지 않으므로, 이러한 주소 선택은 사용자에게 디스플레이되지 않는다. 비록 "North Crawford Avenue"에 대하여 발견된 거리 번호 "6600"이 Lincolnwood 내에 위치하고 Chicago 내에 위치하지 않으면, 어플리케이션은 이것이 사용자가 요청하고자 하는 주소라고 간주할 수 있다.

다른 사용예의 실시예에서, 어플리케이션은 거리에 대한 또는 도시에 대한 사용자의 입력 중 하나가 일관적이지 않고 고쳐져야 하는지를 처리하기 위하여 제공될 수 있다. 이러한 웹사이트 상의 Chandler Music Hall에 대한 주소는 ""71-73 Main Street, Randolph, Vermont"이다. 도시 Randolph 내에서, Main Street는 "North Main Street" 및 "South Main Street"으로 분리된다. "Main Street"은 역시 Randolph Center의 인접 도시에도 존재한다. 말단 사용자에 대하여, 만일 도시 가 정말 Main Street이라면, Hall은 반드시 Randolph Center이어야 한다. 만일 Hall 이 Randolph 내에 있다면, 이것은 North Main Street 또는 South Main Street에 위치한다. Hall은 실제로는 Randolph 내에 존재하고, 71 North Main Street에 존재한다. 만일 말단 사용자가 탑-다운 어플리케이션 내에서 웹사이트 주소를 이용하고 있었다면, 이 사용자는 정확하게 Randolph로부터 North 또는 South Main Street로 유도될 수 있지만, 어플리케이션은 사용자에게 결정하도록 요청하는데 그 이유는 거리 번호 71이 두 거리 모두에 존재하기 때문이다. 만일 사용자가 웹사이트 주소를 바텀-업 어플리케이션에서 이용하고 있었다면, 사용자는 Main Street 로부터 Randolph Center로 잘못 유도될 수 있다. 실시예에서, 네비게이션 어플리케이션이 이러한 종류의 상황을 다루는 한 가지 방법은 모든 선택 사항들을 사용자에게 제공하는 것이다.

Enter state->Vermont

Enter city->Randolph

Enter street->Main Street

Enter street number->71

Please choose from->

71 North Main Street, Randolph

71 South Main Street, Randolph

71 Main Street, Randolph Center

실시예에서, 본 발명의 하나 또는 그 이상의 단계들은 자동으로 수행된다. 자동 특징이 적절한 소프트웨어를 이용하여 구현된다. 자동 특징은 지역성 인덱스가 생성되는 효율 및 속력에 현저한 증가가 이루어지도록 한다.

본 발명의 실시예들은 수정을 거쳐서 비-네비게이션 어플리케이션 및 장치에 적용될 수 있다. 예를 들어, 공간적 광고면 어플리케이션에서, 소정 지점으로부터의 거리에 의하여 정렬된 특정 타입을 가지는 모든 상업들을 검색하는 것이 바람직하다. 실시예에서, 이러한 타입의 어플리케이션의 지역성을 인덱싱하는 것은 광고면 디렉토리 내의 발생 빈도에 기반한 우선 순위 기법을 이용할 수 있다.

도 15는 본 발명의 실시예들과 함께 이용될 수 있는 예시적 시스템(900)의 블록도를 도시한다. 비록 이 도면이 구성 요소들이 논리적으로 분리된 것으로 도시하지만, 이러한 것은 오직 예시적인 목적으로 제공될 뿐이다. 도면에 표시된 성분들이 통합되거나 개별 소프트웨어, 펌웨어 및/또는 하드웨어 성분들로 분할될 수 있다는 것이 당업자에게는 명백할 것이다. 더 나아가, 어떻게 이들이 통합되거나 분할되느냐에 무관하게 이러한 성분들이 동일한 연산 장치/시스템 상에서 실행될 수 있고 또는 하나 또는 그 이상의 네트워크 또는 다른 적합한 통신 수단에 의하여 연결된 상이한 연산 장치/시스템을 통하여 배포될 수 있다는 점이 역시 당업자에게는 명백할 것이다.

도 15에 도시된 바와 같이, 시스템(900)은 전형적으로 하나 또는 그 이상의 메모리(912), 하나 또는 그 이상의 프로세서(914) 및 하나 또는 그 이상의 저장 장치 또는 어느 종류의 저장소(916)를 포함할 수 있는 연산 장치(910)를 포함한다. 시스템(900)은 또한, 그래픽 사용자 인터페이스 또는 GUI(920)를 포함하는 디스플 레이 장치(918)를 포함할 수 있으며, 이를 이용하여 시스템은 맵 및 다른 정보를 사용자에게 디스플레이할 수 있다. 사용자는 연산 장치를 이용하여 예를 들어 소정 지역성이 맵 상에 디스플레이되도록 요청하거나 또는 드라이빙 방향이 맵 상의 루트(route) 및/또는 텍스트 방향으로서 디스플레이되도록 요청한다. GUI(920)는 "Washington, New jersey" 및 그들의 보조어인 "Easton" 및 "Hammonton"에 대한 한 쌍의 중복 지역성들의 일 예를 디스플레이한다. 사용자는 이러한 중복 지역성들 중 하나가 GUI(920) 상에 디스플레이되도록 선택할 것이다.

지리적 데이터베이스(930)가 연산 장치 또는 시스템(910)으로의 외부 저장소로서 도시되거나, 반면에 몇 가지 경우에서는 지리적 데이터베이스(930)는 저장소(916)와 동일한 저장 장치일 수 있다. 실시예에서, 지역성 명칭 엔트리들이 지리적 데이터베이스(930) 내의 중복 및 변형된 지역성(932)들에 대하여 통합된다. 실시예에서, 지리적 데이터베이스(930)는 지역성 소스(934)의 메인 소스 마스크를 포함한다. 실시예에서, 특징 지역성 우선 순위, 지역성 명칭 및 특징 찾기 테이블을 포함하는 지역성 인덱스(936) 지리적 데이터베이스(930) 내에 저장된다.

독점적 지리적 데이터베이스 생성 소프트웨어(940)는 실제-세상 지역성 소스 및 정의(960)들을 이용하여 중복 및 변형된 지역성 명칭 엔트리(932)를 통합 및/또는 보조하고(adorn), 지역성 소스(934)의 메인 소스 마스크를 생성하며, 지역성 인덱스(936)를 생성할 수 있다. 실제 세상의 지역성 소스 및 정의의 예들은 도 2에 대한 설명 내에서 사전 설명된 바와 같다. 지리적 데이터베이스(930)로부터의 정보가 지리적 데이터베이스-어플리케이션 변환기 및 장치 어플리케이션 소프트웨 어(950)에 의하여 이용되고, 이것은 최종적으로는 연산 장치(910)의 사용자에 의하여 이용된다. 지리적 데이터베이스-어플리케이션 변환기 및 장치 어플리케이션 소프트웨어(950)는 사용자의 연산 장치(910)로부터 이격된 것으로 도시되지만 사용자의 연산 장치(910) 상에 상주할 수도 있다.

인덱스 상에서 또는 네비게이션 장치 상에서 사용자에 의하여 이용되는 바와 같은 지리적 데이터베이스-어플리케이션 변환기 및 장치 어플리케이션 소프트웨어(950)의 예에 대하여, 사용자는 소정 지역성이 맵 상에 디스플레이되도록 선택할 수 있다. 또는, 만일 사용자가 드라이빙 방향을 요청하면, 예를 들어, 이러한 지역성은 시작하거나 도착하는 지역성일 수 있다.

실시예에서, 사용자에게 질의하는 소프트웨어 어플리케이션의 타입은 드릴-다운(drill-down) 어플리케이션(탑-다운 또는 바텀-업) 일 수 있다. 드릴 다운 접근법은 제한된 메모리를 가지는 자동차 기반 네비게이션 시스템에서 유용하다. 제한된 메모리 장치에 대하여 유용한 실시예에서, 어플리케이션 개발자들은 장치 내에 우선 순위에 있어서 높게 랭크되는 지역성 명칭들만을 포함시킬 수 있다. 탑-다운 어플리케이션은 우선 사용자로 하여금 주된 지리적 특징을 입력하도록 요청하는데, 예를 들어 주 또는 구역(province)을 입력하도록 요청한다. 그러면, 어플리케이션은 사용자로 하여금 주된 지리적 특징 내에 위치한 도시 또는 타운과 같은 지역성을 입력하도록 요청한다. 그러면, 어플리케이션은 사용자로 하여금 거리의 명칭을 지역성 내에 입력하도록 요청한다. 최종적으로, 어플리케이션은 사용자로 하여금 거리 번호를 입력하도록 요청한다. 거의 모든 경우에, 이러한 질의의 결과 어플리케이션에 의하여 이용될 모호하지 않은 지리적 데이터베이스 특징을 확정하게 되는데, 예를 들어 이러한 지역성을 디스플레이 장치(918)의 GUI(920) 상에서 사용자에게 디스플레이한다. 바텀-업 어플리케이션은 우선 사용자로 하여금 집 번호 및 거리 번호를 입력하도록 요청한다. 그러면, 어플리케이션은 이러한 주소가 발견될 수 있는 모든 지역성들을 디스플레이한다. 최종적으로, 어플리케이션은 사용자로 하여금 원하는 지역성의 명칭을 선택하거나 입력하도록 요청한다. 또한, 바텀-업 방법도 역시 명확한 지리적 데이터베이스 특징을 규정하게 되는데, 이것은 이후에 어플리케이션에 의하여 이용될 수 있다.

실시예에서, 어플리케이션 소프트웨어는 드릴-다운 어플리케이션 내의 지리적 데이터베이스 인덱스를 이용할 수 있으며, 이것은 말단 사용자로 하여금 일반적으로 주어진 주 내에서 부분 또는 전체의 지역성 명칭을 입력하도록 허용한다. 실시예에서, 어플리케이션은 사용자의 입력에 정합되는 명칭을 말단 사용자에게 제공하고, 사용자는 최적의 옵션을 선택한다. 토큰화된 명칭 보디(name bodies)에 대하여 정합시키면, 어플리케이션은 "Hollywood"의 첫 번째 문자들 중 어떤 것이 말단 사용자에 의하여 입력될 때에는 "Hollywood" 및 "West Hollywood" 모두를 제공할 수 있다.

다른 실시예에서, 소프트웨어 어플리케이션은 드릴-다운 어플리케이션이 아니고, 그 대신에 사용자에게 거리 번호 및 거리, 지역성 및 주된 지리적 특징을 한번에 입력하도록 요청한다. 거의 모든 경우에, 이러한 질의의 결과 모호하지 않은 지리적 데이터베이스 특징을 규정할 수 있고, 프로세스는 그 위치를 사용자에게 반 환한다. 만일 사용자가 "Main Street"의 거리 명칭 및 "Springfield"의 지역성을 입력하면, 중복 지역성 "Springfield"가 이것이 명칭 "Main Street"를 가지는 거리를 역시 가질 경우에는 중복된 지역성 "Springfield"가 발견될 것이다. 만일 해당 지리적 특징에 대하여 중복 지역성이 존재한다면, 지역성의 목록 및 그들의 보조어들이 사용자에게 디스플레이됨으로써 사용자에게 디스플레이 장치(918)의 GUI(920) 상에서 하나를 선택하도록 요청할 수 있다. "Washington, New jersey"에 대한 중복 지역성의 예시적 쌍에 대하여, 두 개의 지역성들에게 그들의 발견될 수 있는 카운티 또는 인접한 대도시의 명칭이 보조어로서 제공될 수 있다. "Easton, New jersey" 및 "Hammonton, New jersey" 각각이 두 개의 중복 지역성들의 인접한 대도시이다. 그러므로, "Washington (Easton), New jersey" 및 "Washington (Hammonton), New jersey"가 도 15의 GUI(920)에 디스플레이된다. 이러한 예시에서, 보조어들이 괄호 내에 제공되지만, 예를 들어 각 중복 지역성을 그 개별 보조어와 분리시키기 위하여 예를 들어 콤마를 이용하여 다른 방식으로 제공될 수 있다. 사용자는 중복 지역성들 중 하나를 선택하고, 맵 상의 지역성 또는 드라이빙 방향이 사용자에게 디스플레이된다.

적합한 소프트웨어 코딩이 소프트웨어 기술 분야의 당업자에게 명백한 바와 같이 본 공개 문헌의 교시 내용에 기반하여 숙련된 프로그래머에 의하여 용이하게 준비될 수 있다. 본 발명의 실시예들은 또한 주문형 집적 회로를 준비하는 것에 의하거나 또는 종래의 성분 회로들의 적합한 네트워크의 상호 연결에 의하여 구현될 수도 있는데, 이것은 당업자에게는 용이하게 명확히 이해될 수 있는 것과 같을 것이다.

본 발명의 실시예들은 본 발명의 실시예들의 프로세서 중 모든 것을 컴퓨터가 수행할 수 있도록 프로그램하기 위하여 이용되러 수 있는 명령어들을 가지는 저장 매체(들)인 컴퓨터 프로그램 생성물을 포함할 수 있다. 저장 매체는 플로피 디스크, 광학 디스크, DVD, CD-ROM, 마이크로 드라이브 및 자성-광학적 디스크를 포함하는 모든 타입의 디스크, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, 플래시 메모리 장치, 자성 또는 광학 카드, 및 분자 메모리 IC를 포함하는 나노 시스템(nanosystems)과 같은 장치를 포함하거나 또는 명령어 및/또는 데이터를 저장하기 위하여 적합한 시스템 또는 장치의 모든 타입을 포함할 수 있지만, 이에 한정되는 것은 아니다.

컴퓨터 독출 매체(들) 상에 저장되면, 본 발명의 실시예들은 범용/특수형 컴퓨터 또는 마이크로프로세서의 하드웨어 모두를 제어하고, 이러한 컴퓨터 또는 마이크로프로세서로 하여금 본 발명의 실시예들의 결과를 이용하는 인간 사용자 또는 다른 메커니즘과 상호 작용하도록 허용하기 위한 소프트웨어를 포함할 수 있다. 이러한 소프트웨어는 장치 드라이버, 운영 체제 및 사용자 어플리케이션을 포함할 수 있지만, 이에 한정되는 것은 아니다. 궁극적으로, 이러한 컴퓨터 독출 매체는 전술된 바와 같은 본 발명의 실시예들을 구현하기 위한 소프트웨어를 더욱 포함한다.

범용/특수형 컴퓨터 또는 마이크로프로세서의 프로그래밍 또는 소프트웨어 내에 포함되는 것들은 본 발명의 교시 내용을 구현하기 위한 소프트웨어 모듈이다. 본 발명의 실시예들은 컴퓨터 분야의 당업자에게 명백하게 이해되는 바와 같이, 본 공개 문헌의 교시에 따라서 프로그램된 종래의 범용 또는 특수형 디지털 컴퓨터 또는 마이크로프로세서를 이용하여 편리하게 구현될 수 있다.

본 발명의 전술된 기술 내용은 예시 및 설명의 목적을 위하여 제공되었다. 이것은 본 발명의 실시예들을 제한하거나 또는 공개된 특정 형태로 한정하려고 의도되는 것이 아니다. 다양한 수정예 및 변형예들이 당업계의 숙련된 실시자에게 명백하게 이해될 것이다. 실시예들은 본 발명 및 그 실무상 적용예의 원리를 최적으로 설명하기 위하여 선택되고 설명되며, 이를 통하여 당업자들로 하여금 다양한 실시예 및 고안된 특정 사용에 적합한 다양한 수정을 포함하는 것에 대하여 본 발명을 이해하도록 허용한다. 본 발명의 기술적 범위는 후술되는 청구의 범위 및 그 균등물에 의하여 정의되도록 의도된다.

본 발명은 지리적 데이터베이스를 위한 지역성의 인덱스에 적용될 수 있으며, 특히, 지역성 명칭 및 해당 지역성 내에 포함된 관련 지리적 특징들을 인덱싱하기 위하여 이용되는 지리적 데이터베이스 내의 데이터 구조에 적용될 수 있다.

Claims

저장 매체 상에 저장될 수 있는 지리적 데이터베이스 지역성 인덱스(locality index)로서,

지리적 데이터베이스 내의 적어도 하나의 지리적 특징(geographic features)을 향한 포인터; 및

상기 적어도 하나의 지리적 특징과 관련된 하나 또는 그 이상의 지역성 명칭의 집합을 포함하며,

상기 하나 또는 그 이상의 지역성 명칭은 하나 또는 그 이상의 지역성 명칭 소스로부터 선택되고, 의도된 어플리케이션을 위한 통상의 사용법에서 상기 하나 또는 그 이상의 지역성 명칭의 유력성(prevalence)에 기반하여 우선 순위에 의하여 정렬되는 것을 특징으로 하는 인덱스.
제1항에 있어서,

지리적 특징은 거리(street), 거리 세그먼트, 거리 세그먼트 에지(edge), 블록 페이스(block face), 랜드마크, 주립 공원(state park), 고속도로, 택배 센터(parcel center), 페리 노선(ferry line), 버스 노선(bus route), 택배 센터, 상업 지역 및 주거 지역을 포함하는 것을 특징으로 하는 인덱스.
제1항에 있어서,

상기 인덱스 내에서 이용되는 하나 또는 그 이상의 지역성 명칭 소스 각각에 대해 비트를 할당함으로써 생성되는 메인 소스 마스크(main source mask)를 더 포함하는 것을 특징으로 하는 인덱스.
제3항에 있어서,

각 지리적 특징과 관련된 각 지역성에 대한 지역성 소스 마스크(locality source mask)를 더 포함하며,

상기 지역성 소스 마스크 내의 각 비트는, 상응하는 비트가 메인 소스 마스크 내에 할당된 소스 내에서 상기 지역성이 발견될 수 있는 경우 설정되는 것을 특징으로 하는 인덱스.
제1항에 있어서,

상이한 통상의 사용법을 만족시키기 위하여 우선권 순서가 상이하게 적용될 수 있는 것을 특징으로 하는 인덱스.
제1항에 있어서,

의도된 어플리케이션을 위한 통상의 사용법은, 상기 어플리케이션이 지역 사용자(local user)에 대하여 의도될 경우 지역성 명칭이 발견될 수 있는 최소 개수의 소스를 포함하는 것을 특징으로 하는 인덱스.
제1항에 있어서,

의도된 어플리케이션을 위한 통상의 사용법은, 상기 어플리케이션이 비-지역 사용자(non-local user)에 대하여 의도될 경우 지역성 명칭이 발견될 수 있는 최대 개수의 소스를 포함하는 것을 특징으로 하는 인덱스.
제1항에 있어서,

의도된 어플리케이션을 위한 통상의 사용법에서 각각의 지역성 명칭의 유력성에 기반한 지리적 특징에 대한 지역성 명칭의 우선 순위는, 지리적 특징과 관련된 최상위 우선 순위 지역성이 선호되는 우편 명칭 소스 내에서 발견되는 지역성이된다는 결정 및 상기 지리적 특징과 관련된 잔여 지역성들의 우선 순위는 각 지역성 소스 마스크 내에 설정된 비트들의 개수에 의한 것이라는 결정을 포함하고,

상기 잔여 지역성에 대하여, 상기 지역성에 대한 상기 소스 마스크 내의 명칭 소스들의 개수가 많을수록, 상기 지역성의 우선 순위가 더 높은 것을 특징으로 하는 인덱스.
제1항에 있어서,

의도된 어플리케이션을 위한 통상의 사용법에서 각각의 지역성 명칭의 유력성에 기반한 지리적 특징에 대한 지역성 명칭의 우선 순위는, 상기 지역성이 상기 지역성과 관련된 상기 소스 마스크로부터 발견될 수 있는 지역성 명칭 소스들의 개수에 대한 결정을 포함하며,

상기 지역성에 대한 상기 소스 마스크 내의 명칭 소스들의 개수가 많을수록, 상기 지역성의 우선 순위가 높아지는 것을 특징으로 하는 인덱스.
제1항에 있어서, 지리적 특징에 대한 지역성 명칭의 다른(alternate) 우선 순위는,

각 지역성 내의 지리적 특징들의 개수로서, 상기 지역성 내의 지역성 소스의 개수가 많을수록 상기 지역성의 우선 순위가 높아지는 지리적 특징들;

각 지역성의 물리적 크기로서, 상기 지역성의 물리적 크기가 커질수록 상기 지역성의 우선 순위가 높아지는 물리적 크기; 및

각 지역성의 인구로서, 상기 지역성의 인구 크기가 커질수록 상기 지역성의 우선 순위가 높아지는 인구 중 하나의 결정에 기반하는 것을 특징으로 하는 인덱스.
제1항에 있어서, 지리적 특징에 대한 지역성 명칭의 다른 우선 순위는,

다른 지역성 명칭 소스들에 대한 특정 지역성 명칭 소스의 선호도(preference)의 상기 지역성 소스 마스크를 이용한 결정에 기반하며, 그들의 지역성 소스 마스크 내에 상기 특정 지역성에 대해 설정된 비트를 가지는 지역성들은 그렇지 않은 지역성보다 더 높은 우선 순위를 가지는 것을 특징으로 하는 인덱스.
제3항에 있어서,

상기 메인 소스 마스크는 트럼프 소스(trump source)를 더 포함하고,

지리적 특징에 대한 지역성 명칭의 다른 우선 순위는 상기 트럼프 소스에 기반하며, 그들의 지역성 소스 마스크 내에 상기 트럼프 소스에 대해 설정된 비트를 가지는 지역성들은 그렇지 않은 지역성보다 더 높은 우선 순위를 가지는 것을 특징으로 하는 인덱스.
제1항에 있어서,

지리적 특징에 대한 지역성 명칭들의 우선 순위의 결정이 지역성들 간에 동률(tie)이라면, 동률을 이루는 지역성들의 우선 순위는:

각 동률을 이루는 지역성 내의 지리적 특징들의 개수로서, 상기 동률을 이루는 지역성 내의 지역성 소스의 개수가 많을수록 상기 동률을 이루는 지역성의 우선 순위가 높아지는 지리적 특징들의 개수;

각 동률을 이루는 지역성의 물리적 크기로서, 상기 동률을 이루는 지역성의 물리적 크기가 커질수록 상기 동률을 이루는 지역성의 우선 순위가 높아지는 물리적 크기;

각 동률을 이루는 지역성의 인구로서, 상기 동률을 이루는 지역성의 인구 크기가 커질수록 상기 동률을 이루는 지역성의 우선 순위가 높아지는 인구; 및

다른 지역성 명칭 소스들에 대한 특정 지역성 명칭 소스의 상기 지역성 소스 마스크를 이용한 선호도로서, 그들의 지역성 소스 마스크 내에 상기 특정 지역성에 대해 설정된 비트를 가지는 동률을 이루는 지역성들은 그렇지 않은 동률을 이루는 지역성보다 더 높은 우선 순위를 가지는 선호도 중 하나의 결정에 기반하는 것을 특징으로 하는 인덱스.
제1항에 있어서,

상기 하나 또는 그 이상의 지역성 명칭 중 하나의 지역성 명칭의 상기 적어도 하나의 지리적 특징으로의 관련성(association)은, 직접 또는 간접 관련성을 포함하는 것을 특징으로 하는 인덱스.
제14항에 있어서, 직접 관련성은, 일반적으로 지리적 특징과 관련된 특정 지역성 명칭 소스에 대하여,

상기 지역성 명칭 소스 및 지리적 데이터베이스 내의 상기 지리적 특징 간의 적어도 하나의 공통 속성(common attribute)을 이용한, 상기 지역성 명칭과 관련된 모든 지리적 특징들의 상기 지리적 데이터베이스 내의 적어도 하나의 지리적 특징으로의 정합을 포함하는 것을 특징으로 하는 인덱스.
제15항에 있어서,

지역성을 정합되지 않은 지리적 특징에 지정하기 위하여, 상기 지리적 데이터베이스 내의 정합되지 않은 지리적 특징에 인접한 지도 상의 정합된 지리적 특징들로부터 획득된 페이스 보트(face vote)를 더 포함하는 것을 특징으로 하는 인덱스.
제16항에 있어서, 페이스 보트는 다수성 보트(majority vote), 가중 보트(weighted vote) 및 선형 길이 보트(linear length vote) 중 하나를 포함하는 것을 특징으로 하는 인덱스.
제14항에 있어서, 간접 관련성은, 일반적으로 지리적 특징과 관련되지 않은 제1 지역성 명칭 소스에 대하여,

지리적 특징들과 관련된 제2 지역성 명칭 소스가 상기 제1 소스 내의 각 지역성 명칭이 상기 제2 소스로부터의 지리적 특징들로의 관련성을 상속받도록 하기 위하여 이용되는 소스-공통(cross-source) 지역성 명칭 정합을 포함하는 것을 특징으로 하는 인덱스.
제1항에 있어서,

상기 지역성 명칭의 메인 토큰을 더 포함하며, 상기 메인 토큰은 상기 지역성 명칭들의 토큰화(tokenizing), 정규화(normalizing) 및 최적화(optimizing)는 물론 상기 지역성 명칭을 모든 중복(duplicate) 또는 유사 지역성 명칭들과 정합시키는 것 중 하나 또는 그 이상에 의하여 결정되는 것을 특징으로 하는 인덱스.
제19항에 있어서,

토큰화는 상기 지역성 명칭을 토큰 또는 성분(component)으로 나누는 것을 포함하는 것을 특징으로 하는 인덱스.
제19항에 있어서,

상기 메인 토큰은 인덱싱에 적합한 메인 보디(main body) 또는 메인 성분을 포함하는 것을 특징으로 하는 인덱스.
제20항에 있어서, 상기 메인 토큰 이외의 토큰들은,

선행 방향 토큰(leading direction token), 선행 타입 토큰, 상기 보디에 선행하는 프리네임(prename) 또는 비-타입 정보, 접두어(prefix), 후행 타입(trailing type), 후행 방향, 접미어, 상기 지역성의 분할을 규정하는 숫자 식별자, 및 보조어(adornment) 또는 인접하고 용이하게 식별되는 도시 명칭 중 하나 또는 그 이상을 포함하는 것을 특징으로 하는 인덱스.
제19항에 있어서, 정규화는,

약자의 펼침, 구두점 감소, 내장된 공백 제거, 및 대문자의 정규화 중 하나 또는 그 이상을 포함하는 것을 특징으로 하는 인덱스.
제19항에 있어서, 최적화는,

상기 지역성 명칭을 상기 지역성 내에 포함된 지리적 특징들과 관련시키는 것을 포함하는 것을 특징으로 하는 인덱스.
제19항에 있어서, 상기 지역성 명칭을 모든 중복 또는 다소 변형된 지역성 명칭들과 정합시키는 것은,

지역성 명칭 토큰을 연접시키고 상기 지역성 명칭에 대한 토큰들을 모든 중복 또는 유사한 지역성 명칭들에 대한 토큰들과 비교하여 정합되는지 결정하는 것을 포함하는 것을 특징으로 하는 인덱스.
제19항에 있어서, 상기 지역성 명칭을 모든 중복 또는 다소 변형된 지역성 명칭들과 정합시키는 것은,

상기 명칭들을 그들의 음성학적 표현(phonetic representation)에 기반하거나 또는 다른 수단에 의하여 정합시키는 것을 포함하는 것을 특징으로 하는 인덱스.
제26항에 있어서, 상기 정합은,

상기 지역성 명칭 및 모든 중복 또는 다소 변형된 지역성 명칭들에 대한 최적화 단계로부터의 지리적 특징들을 비교함으로써, 이러한 지역성들이 중첩되거나 또는 인접하는지를 결정하는 것을 더 포함하는 것을 특징으로 하는 인덱스.
제27항에 있어서,

만일 상기 지리적 특징들 모두가 상기 지역성 명칭 및 모든 중복 또는 다소 변형된 지역성 명칭들과 정합되면, 이러한 지역성 명칭들은 동일한 지역성을 나타내고, 하나의 지역성 명칭을 제외한 중복 지역성 명칭들은 상기 인덱스로부터 제거되는 것을 특징으로 하는 인덱스.
제27항에 있어서, 만일 하나 또는 그 이상의 상기 지리적 특징들이 상기 지역성 명칭 및 모든 중복 또는 유사한 지역성 명칭들과 정합되지만 상기 지리적 특징들 모두가 정합되지 않으면, 이러한 지역성 명칭들은 동일한 지역성을 나타내는 것으로 간주되고, 상기 인덱스 내에 하나의 지역성 명칭으로 통합(merge)되는 것을 특징으로 하는 인덱스.
제29항에 있어서,

중첩되거나 인접한 지역성들로부터의 모든 지리적 특징들의 연합(union)은, 상기 통합된 지역성 명칭과 관련되는 것을 특징으로 하는 인덱스.
제27항에 있어서,

상기 지리적 특징들 중 아무 것도 상기 지역성 및 모든 중복 또는 유사한 지역성 명칭들과 정합되지 않을 경우 발생되는 불일치 지역성(disjoint localities)에 대한 인덱스 내에 생성 및 저장된 인접한 잘 알려진 도시의 보조어를 더 포함하는 것을 특징으로 하는 인덱스.
제1항에 있어서,

지리적 특징 식별 번호, 지역성 식별 번호, 지역성 도시 중심 위도 및 경도점들, 지역성 보조어, 지역성의 전체 명칭 및 지역성의 크기 중 하나 또는 그 이상을 더 포함하는 것을 특징으로 하는 인덱스.
제1항에 있어서,

상기 인덱스는 자동적으로 생성되는 것을 특징으로 하는 인덱스.
지역성을 인덱싱하기 위한 방법에 있어서,

지리적 데이터베이스로부터 하나 또는 그 이상의 지리적 특징들의 선택을 수신하는 단계;

하나 또는 그 이상의 지역성 명칭 소스들의 집합으로부터 하나 또는 그 이상의 지역성 명칭들의 집합을 결정하는 단계;

상기 지역성 명칭들을 상기 지리적 데이터베이스의 지리적 특징들과 관련시키는 단계;

각 지리적 특징에 대하여 상기 관련된 지역성 명칭들을 의도된 어플리케이션에 대한 통상의 사용법에서의 유력성의 순서로 우선 순위를 부여하는 단계; 및

우선 순위에 의하여 각 지리적 특징과 관련된 지역성 명칭들을 정렬하는 단계를 포함하는 것을 특징으로 하는 방법.
사용자로 하여금 지역성 및 상기 지역성 내의 지리적 특징으로 액세스하도록 허용하는 기능성을 포함하는 시스템에 있어서,

지리적 데이터베이스 내의 적어도 하나의 지리적 특징 및 상기 적어도 하나의 지리적 특징과 관련된 하나 또는 그 이상의 지역성 명칭들의 집합을 포함하는 지리적 데이터베이스 인덱스로서, 상기 하나 또는 그 이상의 지역성 명칭들은 하나 또는 그 이상의 지역성 명칭 소스로부터 선택되고 의도된 어플리케이션에 대한 통상의 사용법에서의 상기 지역성 명칭의 유력성에 기반한 우선 순위에 의하여 정렬되는 지리적 데이터베이스 인덱스; 및

사용자에게 지역성 및 지리적 특징 정보를 디스플레이하고 사용자로부터 입력을 수신하는 것과 조합하여 상기 지리적 데이터베이스 인덱스를 이용하는 어플리케이션 프로그램을 포함하는 것을 특징으로 하는 시스템.
제35항에 있어서, 지역성 및 지리적 특징 정보의 디스플레이하는 것은,

지역성 및 지리적 특징 정보의 사용자로의 텍스트 디스플레이(textual display)하는 것, 지리적 특징들의 위치를 지도 상에서 사용자에게 디스플레이하는 것 및 라우팅 정보(routing information)를 지도 상에서 사용자에게 디스플레이하는 것 중 하나 또는 그 이상을 포함하는 것을 특징으로 하는 시스템.
제35항에 있어서,

상기 시스템은 인터넷-기반 시스템을 포함하는 것을 특징으로 하는 시스템.
제35항에 있어서,

상기 시스템은 차량-내 네비게이션 시스템을 포함하는 것을 특징으로 하는 시스템.
사용자로 하여금 지역성 및 상기 지역성 내의 지리적 특징으로 액세스하도록 허용하는 기능성을 포함하는 휴대용 핸드헬드 장치에 있어서,

지리적 데이터베이스 내의 적어도 하나의 지리적 특징 및 상기 적어도 하나의 지리적 특징과 관련된 하나 또는 그 이상의 지역성 명칭들의 집합을 포함하는 지리적 데이터베이스 인덱스로서, 상기 하나 또는 그 이상의 지역성 명칭들은 하나 또는 그 이상의 지역성 명칭 소스로부터 선택되고 의도된 어플리케이션에 대한 통상의 사용법에서의 상기 지역성 명칭의 유력성에 기반한 우선 순위에 의하여 정렬되는 지리적 데이터베이스 인덱스; 및

사용자에게 지역성 및 지리적 특징 정보를 디스플레이하고 사용자로부터 입력을 수신하는 것과 조합하여 상기 지리적 데이터베이스 인덱스를 이용하는 어플리케이션 프로그램을 포함하는 것을 특징으로 하는 핸드헬드 장치.
제39항에 있어서, 지역성 및 지리적 특징 정보의 디스플레이하는 것은,

지역성 및 지리적 특징 정보의 사용자로의 텍스트 디스플레이하는 것, 지리적 특징들의 위치를 지도 상에서 사용자에게 디스플레이하는 것 및 라우팅 정보를 지도 상에서 사용자에게 디스플레이하는 것 중 하나 또는 그 이상을 포함하는 것을 특징으로 하는 핸드헬드 장치.
제39항에 있어서,

상기 핸드헬드 장치는 개인 휴대용 단말기(PDA)를 포함하는 것을 특징으로 하는 핸드헬드 장치.
제39항에 있어서,

상기 핸드헬드 장치는 개인용 네비게이션 시스템을 포함하는 것을 특징으로 하는 핸드헬드 장치.
제39항에 있어서,

상기 핸드헬드 장치는 셀룰러 전화기를 포함하는 것을 특징으로 하는 핸드헬드 장치.
사용자로 하여금 지역성 및 상기 지역성 내의 지리적 특징으로 액세스하도록 허용하는 기능성을 포함하는 지리적 정보 시스템(GIS) 기반 어플리케이션 프로그램에 있어서,

지리적 데이터베이스 내의 적어도 하나의 지리적 특징 및 상기 적어도 하나의 지리적 특징과 관련된 하나 또는 그 이상의 지역성 명칭들의 집합을 포함하는 지리적 데이터베이스 인덱스로서, 상기 하나 또는 그 이상의 지역성 명칭들은 하나 또는 그 이상의 지역성 명칭 소스로부터 선택되고 의도된 어플리케이션에 대한 통상의 사용법에서의 상기 지역성 명칭의 유력성에 기반한 우선 순위에 의하여 정렬되는 지리적 데이터베이스 인덱스를 포함하는 것을 특징으로 하는 GIS 기반 어플리케이션 프로그램.
하나 또는 그 이상의 프로세서에 의하여 실행되는 동작이 저장된 기계 독출 매체에 있어서, 상기 동작은 시스템으로 하여금,

지리적 데이터베이스로부터 하나 또는 그 이상의 지리적 특징들의 선택을 수신하는 단계;

하나 또는 그 이상의 지역성 명칭 소스들의 집합으로부터 하나 또는 그 이상의 지역성 명칭들의 집합을 결정하는 단계;

상기 지역성 명칭들을 상기 지리적 데이터베이스의 지리적 특징들과 관련시키는 단계;

각 지리적 특징에 대하여 상기 관련된 지역성 명칭들을 의도된 어플리케이션에 대한 통상의 사용법에서의 유력성의 순서로 우선 순위를 부여하는 단계; 및

우선 순위에 의하여 각 지리적 특징과 관련된 지역성 명칭들을 정렬하는 단계를 수행하도록 야기하는 것을 특징으로 하는 기계 독출 매체.