CN101432687A - 地点索引和为地点编索引的方法 - Google Patents

Abstract

呈现地点索引以与电子地图和数据库一起使用。地理数据库中的每一地理特征与来自各种地点名称源的地点名称相关联。地点名称的上下文敏感标记化、规范化、优化和匹配消除重复和不同的地点名称，同时保留意义上不同的名称。地点名称表包含每一地点名称的经解析表示和其它相关联信息，且识别用于编索引的主要标记。通过为方法中使用的每一地点名称源分配一位来创建主要源掩码。为与地点相关联的每一地理特征存储单独源掩码，针对其中可发现所述地点的每一源设定一位。与每一地理特征相关联的地点名称在地理特征表中以用于给定应用程序中的流行性为次序来编索引。

Description

地点索引和为地点编索引的方法

优先权主张

迈克尔盖利希(Michael Geilich)在2006年5月12日申请的标题为“地点索引和为地点编索引的方法(LOCALITY INDEXES AND METHOD FOR INDEXINGLOCALITIES)”的第11/433,104号美国专利申请案(代理人案号TELA-07767US0)。

技术领域

本发明涉及地理数据库的地点的索引，且更明确地说涉及地理数据库中用于为地点名称和地点中含有的相关联地理特征编索引的数据结构。

背景技术

最近一些年中，消费者已具备多种装置和***使其能够在数字地图上定位特定街道地址。这些装置和***呈使驾驶员能够在街道和道路上导航的车载导航***、例如个人数字助理(“PDA”)的便携式手持式装置、可进行相同操作的个人导航装置和手机，以及其中用户可产生展示所需位置的地图的因特网应用程序的形式。所有这些和其它类型的装置和***中的共同方面是地理特征的地理数据库和用以响应于用户的输入而存取和操纵地理数据库的软件。实质上，在所有这些装置和***中，用户均可输入目标位置且返回的结果将是目标位置的定位。

通常，用户将输入地址、商业机构(例如，饭店)的名称、市中心或目的地地标(例如，金门大桥)，且接着被返回得到所请求地方或特征的位置。所述位置可展示在地图显示器上，或可用于计算和显示到所述位置的驾驶方向，或以其它方式使用。

通常，应用程序使用自上向下搜索方法，其搜索其中定位有所需地理特征的地点，接着在所述地点内搜索地理特征。可在地点中找到的地理特征的实例是地址、地标和商业机构位置。应用程序还使用自下向上搜索方法，其搜索与某一标准匹配的所有地理特征，接着从定位有匹配的地理特征的地点列表中选择所需地理特征。

当前，地理数据库既不被供应有也不具有当在地点中搜索地理特征时具有有限功能性的地点索引。地点索引可用于选择要显示给用户的地点名称和相关联信息。地点是(例如)州(美国)、省(加拿大)、县或其它主要地理特征内的市或镇。对于当前具有地点索引的地理数据库，所述索引基本上是地点名称的以名称源排序的列表，其中源之间存在名称的重复。地点名称可在许多地点名称源(例如，行政、邮政和口语源)中找到。本申请案中的术语“地点名称”用于指代可用作地点描述的任何数据。除了上文列举的源之外，邮政编码本身可用作地点名称。电话交换机号码在一些国家也指示地点且可用作地点名称。在德国，汽车牌照前缀指示地点且可用作地点名称。以下是对地理数据库现有技术的论述(不管地理数据库是否被供应有地点索引)。

当前，如果地点名称出现在多个地点名称源中，那么用来自各种地点名称源的地点信息填充的地理数据库将含有地点的重复条目。由于地点源上重复件的表示的差异(例如，拼写、标点、缩写或重复件之间的其它差异)，装置或***制造商或应用程序开发商既不将重复地点合并为唯一的一组名称也不进行不完全合并。因此，当用户接着向地理数据库应用程序询问地点时，如果地点名称在多个地点名称源中出现，那么用户的装置或***可能会多次列举同一地点名称。这对于必须在显示给用户的***或装置屏幕的相同或接近相同名称之间进行选择的用户来说容易混淆。如果用户不能区分具有相同或稍许不同名称的实际重复地点和不相交地点，那么地点名称列表中存在另一问题。在具有有限存储空间的一些导航装置中，来自多个地点名称源的重复地点名称的问题加剧。举例来说，一些装置可对每个地理特征仅保存两个地点名称。对于与两个以上地点名称相关联的地理特征，任何选择所述地点名称中的两者以在装置中使用均可能不是最理想的，因为重复但不相交的地点和具有较流行地点名称的地点可能被漏选。漏掉的重复不相交地点可致使用户由于其在列表中的表观唯一性而挑选不正确的地点。对于具有地点索引的地理数据库，不能合并重复地址尤其对于存储空间有限的导航装置来说还形成了大小上难以操纵的地点索引。

当前，对于具有共享完全相同的地理特征的相同或稍许不同名称的地点，未从现有技术地点索引中消除重复名称条目。对于具有共享至少一个地理特征的相同或稍许不同名称的地点，在现有技术地点索引中，名称条目未合并成单一条目。如果不同源中的至少两者具有地点的稍许不同名称，那么用来自各种地点名称源的地点信息填充的地理数据库可含有所述地点的稍许不同名称。举例来说，新泽西州的霍霍库斯(Ho-Ho-Kus)在不同源中称为稍许不同的名称，例如Ho-Ho-Kus、Ho Ho Kus或Ho-Ho-Kus(Hohokus)。对于现有技术地点索引，未能消除具有稍许不同地点名称的地理数据库条目尤其对于存储空间有限的导航装置来说形成了大小上难以操纵的地点索引，且对于试图区分这些稍许不同地点名称的用户来说容易混淆。对于重复命名但不相交的地点，现有技术当前通过显示额外信息(例如，地点所处的县)来区分所述地点。对于这些地点，显示为地点的额外信息的附近的众所周知或流行城市将对用户更有帮助，因为在美国，城市名称和位置比县名称更容易为用户所辨别。

图1说明展示在普通使用中不一致对待的地点定义的实例的图。地点定义的实例是“邮政区域”和“县级分区”。在图1中，在普通使用中，奥尔斯顿(Allston)被视为波士顿(Boston)的一部分。奥尔斯顿是邮政区域而波士顿是县级分区。在图1中，邮政区域奥尔斯顿展示为包含在县级分区波士顿内。相比之下，曼哈顿(Manhattan)被视为纽约市(New York City)的一部分，但曼哈顿是县级分区而纽约市是邮政区域以及合并区域。在图1中，县级分区曼哈顿展示为包含在邮政区域纽约市内。此类矛盾说明普通使用与正式地点定义之间的差异。

此外，在在普通使用中不一致对待的地点定义的另一实例中，纽约州的某些地理特征包含在在普通使用中称为休南区(SoHo)、曼哈顿和纽约市的部分重叠地点中。如上文所提及，纽约市可在邮政区域地点名称源中找到，而曼哈顿可在合并区域地点名称源中找到。另一方面，休南区无法在地点名称源中找到且是口语上称呼的。将仅基于正式地点定义而从地点索引中漏掉休南区。

此外，不依据优先权或其对于普通使用的重要性对当前地理数据库地点索引排序。此外，对于地理数据库中的每一地理特征，不为地理特征而对与所述地理特征相关联的地点区分优先次序。在不对地点区分优先次序的情况下，对于仅可存储每一地理特征的几个地点名称的存储空间有限的装置，应用程序开发商必须为与多于几个地点相关联的地理特征选择几个地点名称。优选地，与地理特征相关联的最高优先权地点或在普通使用中最众所周知或最流行的那些地点将被显示给用户的装置。在向用户呈现地点列表的过程中，应使用与地理特征相关联的最高优先权名称，因为其将最容易辨别。

此外，地点名称的最重要名称成分或主要标记(例如，名称“南哈德利(South Hadley)”中的“哈德利(Hadley)”)在一些当前地理数据库地点索引中未被识别。当一些当前市售导航应用程序在马萨诸塞州(Massachusett)搜索城市哈德利时，检索到哈德利，但未检索到南哈德利。为了找到南哈德利，用户必须以“S”开头并分类选择以“South”开头的许多选择。

需要地理数据库地点索引，以便将重复地点名称及被称为稍许不同名称的地点合并(当且仅当其表示同一地点时)，以便为否则必须在相同或稍许不同名称的列表之间进行选择的用户消除混淆(尤其对于存储空间有限的装置)。还需要此地点索引来减小否则难以操纵的索引的大小。在将具有重复和不同名称的地点合并时，还需要保留意义上不同的地点名称。需要地点索引以便区分出表示不相交地点的重复地点名称。否则，用户没有办法区分具有相同名称的两个不同地方。此外，需要灵活的地点索引以便考虑到在普通使用中不一致对待的正式地点定义，且使得索引不基于这些正式地点定义。需要依据与多个地点相关联的每一地理特征的地点优先权来排序的地点索引。依据优先权排序允许选择最重要名称以包含在有限存储空间的应用中，且识别出最佳名称以呈现给用户。最后，需要地点索引，以使得地点的最重要名称成分是索引的一部分，以确保对名称成分的搜索将返回所有相关地点的扩展列表。

发明内容

一般来说，提供地点索引以与电子地图和电子数据库一起使用，并且提供一种用于创建所述索引的方法和***。

对于地理数据库中的每一地理特征，来自各种地点名称源的地点名称与地理特征相关联。地点名称的上下文敏感标记化、规范化、优化和匹配允许消除与合并重复和不同的地点名称，同时保留意义上不同的名称。消除重复的地点名称(当且仅当其表示同一地点时)，以便为否则必须在相同或类似名称的列表之间进行选择的用户减少混淆。如果被称为稍许不同名称的地点共同地共享至少一个地理特征，那么将所述地点的地理数据库条目合并为单一条目。通过用附近地点的名称修饰具有重复或稍许不同地点名称(当且仅当其表示不同地点时)的不相交地点来区分所述不相交地点，从而再次为否则必须在相同名称或以对于用户来说不太有意义的方式区分(例如，通过用位置一般不为用户所知的县名来修饰)的名称的列表之间进行选择的用户减少混淆。

创建地点名称表且其包含地点的全名、地点的用于编索引的主要标记和其它相关联信息(例如修饰)、市中心信息和地点的大小。通过为方法中使用的每一地点名称源分配一位来创建主要源掩码。对于特征地点优先权表中的每一地理特征，为与地理特征相关联的每一地点存储单独源掩码，针对其中可发现所述地点的每一源存在一个设定的位。在此表中存在到地点名称表的链接和与地理特征相关联的每一地点的优先权。特征地点表还包含到寻找特征表的链接，所述寻找特征表包含每一地理特征的相关联地理特征信息。

以优先权为次序为每一地理特征的地点名称编索引。在优选实施例中，与地理特征相关联的最高优先权地点是在优选邮政名称源中找到的地点，于是剩余地点的优先权由每一地点源掩码中设定的位的数目确定。在此索引中，如果第一地点在普通使用中更加众所周知或流行，那么第一地点具有比第二地点高的优先权。

依据优先权排序允许选择最重要名称以包含在存储空间有限的应用中，且在自下向上搜索中识别出最佳名称以呈现给用户。因此，原本会含有重复和稍许不同地点名称的地点索引的难以操纵的大小减小。此外，地点索引考虑到在普通使用中不一致对待的地点定义，因为索引不是基于这些正式地点定义。最后，来自标记化步骤的地点的最重要名称成分是索引的一部分，以确保对名称成分的搜索将返回所有相关地点的扩展列表。

附图说明

图1说明展示在普通使用中不一致对待的地点定义的实例的图。

图2说明展示美国行政区域的体系的图。

图3说明需要区分位于一地点(例如，“马萨诸塞州，波士顿”)内的四个不同地点中的具有相同名称(例如，“亚当斯街道(Adams Street)”)的地址的实例。

图4说明可通过使用多种类型的地点名称源来区分的官方地点和相同命名的地区(例如，“加利福尼亚州，布伦特伍德(Brentwood，California)”)的实例。

图5说明需要包含在综合性地点索引中的可在官方源中列举但不具有清楚划定的边界的小村庄的实例(例如，“佛蒙特州，块渠(Quechee，Vermont)”)。

图6说明需要包含在综合性地点索引中的作为非官方地点名称的地区的实例(例如，纽约市的“格林威治村(Greenwich Village)”)。

图7说明需要包含在综合性地点索引中的位于区的村庄的实例(例如，位于纽约市的昆斯区(Queens)的“福雷斯特·希尔斯(Forest Hills)”)。

图8A和8B展示将地点链接到地理数据库中的地理特征、标记化、规范化、优化和匹配地点名称并创建依据优先权排序的地点的索引的过程流程图的实施例。

图9说明用于确定与未知地点名称相关联的街道的地点名称的朝向投票(facevoting)的实例。

图10展示美国和加拿大的地点名称源掩码的两个实例。

图11展示用于通过地点名称的匹配而简化地点名称组的算法的实施例。

图12展示用于确定给定地理特征的地点名称的优先权的算法的实施例。

图13展示包含特征地点优先权表、地点名称表和寻找特征表的地点索引文件的实施例。

图14说明导航应用程序可在错误地指定附近城市时适应不一致性的实例。

图15展示可与实施例一起使用的示范性***的框图。

具体实施方式

为了创建较好的地点索引，必须首先通过从多种地点名称源(尤其是行政、邮政和口语地点名称源)收集名称来创建地点名称的详尽列表。使用来自任何数目和类型的源的地点名称实现用于国际性数据的通用模式。在没有此特征的情况下，仅可使用固定数目的源，例如邮政或行政名称源，从而可能漏掉重要名称并限制不同国家可能使用的源的类型。

尽管本描述内容中使用的语言特定针对美国，但在实施例中，在仅作出极小调整的情况下可国际性地应用相同原则。外国地点名称源等效物的实例包含英国的陆地测量局(Ordnance Survey)和皇家邮政(Royal Mail)，以及加拿大的加拿大国家***(Stats Can)和加拿大邮政(Canada Post)。

在实施例中，对于给定的一组地点名称源，从每一地点名称源取得一地点名称列表。在实施例中，源是含有(例如)一个或一个以上选定州、地域、省或区中的地点的源。在优选实施例中，源是含有位于美国的地点的源。举例来说，在美国，地点名称的源包含(但不限于)：

1.联邦信息处理标准55(FIPS55)。美国地质测量局(USGS)TIGER数据库的此组成部分位于公用域(http://geonames.usgs，gov/fips55.html)中。FIPS55是描述政府界定的行政地点的地点结构的标准源，例如所命名居民地、主要县划区和美国、波多黎各及边远区域的其它位置的代码。

2.美国邮政业务(USPS)市/州文件。此文件是USPS ZIP+4产物的组成部分。这些城市和州名称在地理范围或ZIP代码级处找到。五位数ZIP代码和四位数扩展(ZIP+4)视为索引中的地点名称并指向USPS市州文件中适当的名称组。虽然通常每一位置仅存在一个优选邮政地点名称，但邮政业务还包含相同位置的任何数目的可允许和不可允许的邮政地点名称。“优选”邮政地点名称是USPS建议用来为邮件定址的名称。“可允许”邮政地点名称是USPS已许可并允许用于邮件递送的别名。“不可允许”邮政地点名称是USPS不允许用于邮件递送的名称。在实施例中，地点索引将包含每一地理特征的所有优选和可允许邮政地点名称。

3.由美国地质测量局(USGS)提供的地理名称信息***(GNIS)。这是美国(包含五十个州和领土)的地点名称的公用域数据库。GNIS列举城市名称、其中心点、其人口和类似信息。

4.市中心的关注点(POI)。

5.USPS邮局的POI。

6.美国人口调查局的拓扑合并地理编码和参考***(TIGER)针对实体“P”(位于TIGER的合并区域)的记录类型C。

7.针对实体“M”的TIGER记录类型C(TIGER中的县级分区)。

完全包含在州内的地点名称可出于编索引的目的而与所述州相关联。不完全包含在州内的地点(例如，美国的某些邮政编码)可在其所含的州下被多重编索引。图2说明展示美国行政区域的体系的图。这些行政区域完全包含在图的中心处展示为国家、地区、划区、州和县的群组内。此图展示县级分区包含在县内。图2中展示为“区”的行政区完全包含在州内。行政区可跨越县和县级分区边界。大城市区、市区乃至ZIP代码甚至可跨越州边界，且因此仅完全包含在国家内，如图2所示。

图1说明展示位于美国的地点对于仅使用一组固定规则来处置来自多个地点源的名称的导航应用程序不能有用地自动模仿的实例图。邮政区域和县级分区在官方源中找到。在图1中，在马萨诸塞州，奥尔斯顿的邮政区域完全包含在波士顿的县级分区内。然而，在纽约，曼哈顿的县级分区完全包含在纽约市的邮政区域内。因此，县级分区地点名称源不一定能用于确定特定县级分区内的邮政区域。类似地，邮政区域地点名称源不一定能用于确定特定邮政区域内的县级分区。来自不同源的地点名称的普通使用随着地理布局而变化。在为来自多个源的地点名称编索引时必须考虑到此变化。

在实施例中，由存取地理数据库的软件应用程序或装置的用户使用的以下使用情况实例说明使用来自多个源的地点名称来建立索引的益处。如果仅使用一个名称源，那么会遗漏重要名称。邮政名称、行政名称乃至口语名称都很重要。

如果索引中没有邮政名称源：

输入州->佛蒙特

输入城市->块渠

未找到城市：块渠

如果索引中有邮政名称源：

输入州->佛蒙特

输入城市->块渠

找到->

块渠

如果索引中没有行政名称源：

输入州->纽约

输入城市->曼哈顿

未找到城市：“曼哈顿”

如果索引中有行政名称源：

输入州->纽约

输入城市->曼哈顿

找到：“曼哈顿”

在实施例中，以下四个使用情况实例展示汇编来自多个地点名称源的地点名称的另一益处是区分一地点内的有歧义的街道地址。美国的城市可具有位于城市的不同部分的重复的街道地址。在例如马萨诸塞州的波士顿等大城市中尤其如此。如上文所提及，可在行政地点名称源FIPS55中作为县级分区而找到波士顿。在实施例中，这四个使用情况实例中的第一实例展示以下典型的不存在问题的情况：当特定街道地址在城市内是唯一的时，针对导航目的不存在问题，即使城市较大也如此。此情况的一实例是位于波士顿的纽伯里街道(Newbury Street)。此街道名称有十个字组(block)长且在波士顿的任何其它地方均不重复。

如果索引中有行政名称源：

输入州->马萨诸塞

输入城市->波士顿

输入街道->纽伯里街道//不论房屋号码如何均是唯一的

此时，精确目的地等待来自用户的更多输入，例如特定街道号码、最近的十字路口或最近的街区。当供应了输入时，为用户在地图上将目的地精确定点：

输入街道号码->173

找到：“马萨诸塞州，波士顿，纽伯里街道173号”

在实施例中，这四个使用情况实例中的第二实例在以下情况下发生：街道名称在城市内重复，但房屋号码用以使目的地具有唯一性。延伸越过大城市内的若干较小镇的长街道是一个这样的实例。举例来说，联邦大道延伸越过波士顿，以及波士顿内奥尔斯顿和切斯努特山(Chestnut Hill)的较小镇。如上文所提及，波士顿是在行政地点名称源中找到的县级分区。奥尔斯顿和切斯努特山是可分别在邮政编码02134和02467下在邮政地点名称源中找到的镇。

如果索引中没有行政名称源：

输入州->马萨诸塞

输入城市->波士顿

输入街道->联邦大道

输入街道号码->2000

未找到街道号码：“2000”

因为根据美国邮政业务，波士顿不是邮政编码为02467的合法邮政名称，所以尽管切斯努特山是波士顿内的小镇，但在以上针对波士顿的实例中也未找到“马萨诸塞州02467，切斯努特山，联邦大道2000号”。

如果索引中有行政和邮政名称源两者：

输入州->马萨诸塞

输入城市->波士顿

输入街道->联邦大道

此时，发现联邦大道延伸越过波士顿、奥尔斯顿和切斯努特山。精确目的地等待来自用户的更多输入，例如特定街道号码、最近的十字路口或最近的街区。当供应了输入时，为用户在地图上将目的地精确定点：

输入街道号码->2000

找到：“马萨诸塞州，切斯努特山，联邦大道2000号”

在实施例中，如图3中说明的这四个使用情况实例中的第三实例类似于第二使用情况实例，只是可在波士顿内的四个不同地点中找到四个不同的亚当斯街道。图3说明需要区分位于一地点(例如，“马萨诸塞州，波士顿”)内的四个不同地点中的具有相同名称(例如，“亚当斯街道”)的地址：

如果索引中没有邮政名称源：

输入州->马萨诸塞

输入城市->波士顿

输入街道->亚当斯街道

请从以下中选择->

波士顿，亚当斯街道  //应用程序在城市波士顿中

波士顿，亚当斯街道  //找到四个不同的亚当斯街道，

波士顿，亚当斯街道  //且用户不能区分

波士顿，亚当斯街道  //这四个选择

如果索引中有邮政名称源：

输入州->马萨诸塞

输入城市->波士顿

输入街道->亚当斯街道

请从以下中选择->

查尔斯顿，亚当斯街道

海德公园，亚当斯街道

罗克斯巴瑞，亚当斯街道

多尔切斯特，亚当斯街道

输入街道号码->  //用户通过输入街道号码继续

在此使用情况实例中，应用程序在请求来自用户的更多信息之前处理每一用户输入。在其它实施例中，对于“如果索引中有邮政名称源”，用户在应用程序处理城市波士顿、街道亚当斯街道和街道号码之前输入这三个条目。假定街道号码在小镇查尔斯顿、海德公园、罗克斯巴瑞和多尔切斯特中不重复，将针对这四个镇的一者找到街道名称和号码并在地图上精确定点以向用户显示。

在实施例中，这四个使用情况实例中的第四实例展示偶数街道号码(例如，“亚当斯街道2号”)在城市内的具有相同名称的不同街道上重复。在此情况下，唯一正确的反应是向用户呈现其中定位有重复件的较小镇的列表，以便导出唯一目的地。因此，使用来自上文第三使用情况实例的实例：

如果索引中有行政和邮政名称源：

输入州->马萨诸塞

输入城市->波士顿

输入街道->亚当斯街道

输入街道号码->2

请从以下中选择->

查尔斯顿，亚当斯街道2号

海德公园，亚当斯街道2号

罗克斯巴瑞，亚当斯街道2号

多尔切斯特，亚当斯街道2号

在实施例中，在如图4中说明的另一使用情况实例中，可通过使用多种类型的地点名称源来区分官方地点与相同命名的地区(例如，“加利福尼亚州，布伦特伍德”)。加利福尼亚州布伦特伍德既是旧金山附近的官方行政区，又是洛杉矶的众所周知但非官方地区(其是可允许的但非优选的邮政名称)。图4展示位于加利福尼亚州的两个布伦特伍德地点。两个地点均含有流行用于导航目的的地址，且良好的导航应用程序将为用户对其进行区分：

输入州->加利福尼亚

输入城市->布伦特伍德

请从以下中选择->

布伦特伍德(旧金山附近的城市)

布伦特伍德(洛杉矶的地区)

在其它实施例中，使用此同一使用情况实例，如果用户在应用程序处理用户输入之前输入州、城市和街道名称，那么应用程序可确定正确的布伦特伍德。举例来说：

输入州->加利福尼亚

输入城市->布伦特伍德

输入街道名称->康科德大道

输入街道号码->767

找到：“加利福尼亚州，布伦特伍德(旧金山附近的城市)，康科德大道767号”

在实施例中，在如图5中说明的另一使用情况实例中，可在官方源中列举但不具有清楚划定的边界的小村庄(例如，“佛蒙特州，块渠”)需要包含在综合性地点索引中。佛蒙特州的村庄块渠是受欢迎的小镇旅游目的地。可在黄页中作为佛蒙特州05059，块渠，块渠主街1760号找到西蒙皮尔斯玻璃吹制(Simon Pierce Glassblowing)。然而，块渠不是行政地点，且美国邮政业务也不辨别此地址。ZIP代码05059是含有非常少的街道地址的“邮政信箱专用”ZIP代码。因此，块渠主街不是块渠内公认的街道。块渠中心周围的区域称为怀特河流域及哈特福德(White River Junction and Hartford)。图5说明具有一个可能的经划定村庄边界的块渠的将来地图。良好的导航应用程序需要辨别公布在黄页目录中的地址，而不管其是合法的邮政地址还是合并区域：

输入州->佛蒙特

输入城市->块渠

输入街道->块渠主街

输入号码->1760

找到：“佛蒙特，怀特河流域，块渠主街1760号”

不幸的是，块渠地点名称不能附加到街道地址，因为块渠的边界是未知的。事实上，怀特河流域是街道地址的指定地点。此选择是根据邮政地址。导航应用程序可通过使用如下文论述而创建的地点索引来确定其已找到所需位置。尽管块渠不是“块渠主街1760号”的地点，但地点索引可扩展块渠地点以将所述街道定位在佛蒙特怀特河流域。导航应用程序可在匹配的地点与用户输入不同时请求用户确认。尽管仅找到一个街道，但其也许仅是导航应用程序的用户可能接受或拒绝的可能的匹配。将来，随着块渠边界的添加，地图增强可使正确答案成为可能。在此情况下，定位有“块渠主街1760号”的地点的名称将实际上是块渠。

在实施例中，在如图6中说明的另一使用情况实例中，作为非官方地点名称的地区(例如，纽约市的“格林威治村”)需要包含在综合性地点索引中。在美国存在对于导航很重要但尚未公布在任何行政或邮政源中的各种地点名称。一种此类名称是著名区域。实例包含纽约市的格林威治村和休南区，以及旧金山的黑什伯里区(Haight-Ashbury)。这些地区足够大以致包含街道段、地址、商业机构和其它关注点。良好的导航应用程序将包含定位众所周知的地区及其内部的街道地址的能力，不管其是官方行政名称还是邮政名称。

如果没有来自各种源的名称：

输入州->纽约

输入城市->格林威治村

未找到城市：“格林威治村”

如果有来自各种源的名称：

输入州->纽约

输入城市->格林威治村  //既不是邮政名称也不是行政名称

输入街道->            //用户通过输入街道名称继续

在此使用情况实例中，使用来自各种源的名称，增强的地图可包含格林威治村的边界。图6展示格林威治村可界定为在格林威治街道与百老汇之间以斯普琳(Spring)和第14街道为界的曼哈顿的区域。使用具有此信息的地图，对话将继续：

输入街道->卡迈街

输入街道号码->13

找到：“纽约州，格林威治村，卡迈街13号”

在实施例中，在如图7中说明的另一使用情况实例中，位于区的村庄(例如，位于纽约市的昆斯区的“福雷斯特·希尔斯”)需要包含在综合性地点索引中。来自不同源的地点名称可用于确定街道名称可位于纽约市的哪一区。纽约市由五个区组成。其中只有一个区昆斯区独立地作为地点名称。然而，在昆斯区，界定了几十个所含地点。在昆斯区寻找地址时，用户不需要知道昆斯区内可定位有所述地址的地点。如果所述地址唯一地包含在仅一个村庄中，那么下文论述的地点索引可确定哪一村庄含有所述地址：

输入州->纽约

输入城市->昆斯

输入街道->第70街道

输入街道号码->10700

找到：“纽约州，福雷斯特·希尔斯，第70街道10700号”

对于此使用情况实例，地点索引还可处置对于位于昆斯区的村庄的名称的请求：

输入州->纽约

输入城市->福雷斯特·希尔斯

输入街道->第70街道

输入街道号码->10700

找到：“纽约州，福雷斯特·希尔斯，第70街道10700号”

图8A和8B展示将地点链接到地理数据库中的地理特征、标记化、规范化、优化和匹配地点名称并创建依据优先权排序的地点的索引的过程流程图的实施例。在实施例中，可在一地点中找到的地理特征的实例包含(但不限于)街道、街道段、街道段边缘、街区朝向、地标、州立公园、公路、渡运线路、公交路线、小宗货物中心、商业区和住宅区。街道段是街道、地址范围或单一地址的一部分。街道段边缘是街道段的街道一侧。街区朝向是组成城市街区的四个朝向中的一者。

对于来自上文的一组给定的地点名称源且对于给定的专有地理数据库，过程在步骤805中开始。如果在步骤810中存在另一拟处理的地点名称，那么在步骤815中过程确定如果源含有与地理数据库中的地理特征匹配的地理特征则地图匹配是否可能。如果在步骤815中，发现对于源的地图匹配是可能的，那么在步骤820中，地图匹配将来自地点名称源的地点名称与地理数据库中的地理特征直接关联。可通过归并或属性匹配自动执行直接关联，或可通过检查来手动执行。直接关联通常用于与地理数据库共享属性的地点名称源。在优选实施例中，当地点名称源具有附加到其处的指示其在地球上的位置和范围的空间信息时，可使用归并。通过将来自地点名称源的地点空间上覆盖于地理数据库上，将一地点指派给在所述地点的边界内发生的任何地理数据库特征，来作出直接关联。通过将源与地理数据库之间的共同属性匹配来执行属性匹配，这接着允许作出直接关联。可匹配的属性是可由字符串或数字表示的属性。间接关联通常用于其它源。

在实施例中，在步骤820中，当地点名称源与地理数据库共享属性时，通过将源中的属性与地图或地理数据库中的相同属性匹配来作出到地理数据库中的地理特征的直接关联。举例来说，范围匹配可用于将地点源与地理数据库之间的地址属性匹配。可使用具有与街道细节相关联的地点名称的任何源来进行范围匹配，包含TIGER和USPS城市地区名称目录。县级分区(实体“M”)和合并区域(实体“P”)代码直接从匹配的TIGER地理特征传播到所关注的地图或数据库中的地理特征上。范围匹配取来自TIGER的街道名称、房屋号码范围和地点并试图将这些项目与所关注的专有地理数据库中的相应街道段匹配。在TIGER中，街区的每一侧不仅具有地址范围，其还具有表示所述位置中的实体类型P(合并区域名称)、所述位置中的实体类型M(县级分区名称)、州代码、街区代码、地带代码以及最小行政划区(MCD)的标签。匹配的范围使得有可能将信息从TIGER传递到地理数据库上。范围匹配可以是街道段的精确匹配，街道段相切或精确对准，或街道段部分重叠。

在步骤820中，在USPS城市/州文件是地点名称源的情况下，可递送地址从源的USPS变动。ZIP+4目录对照地图或数据库而人口特征化(geocoded)。在实施例中，来自此源的ZIP代码本身被视为地点名称。来自此源的ZIP代码还指向城市/州文件中适当地点名称组。对于每一成功匹配，五位ZIP代码和来自ZIP+4的一个四位加4代码被视为地点名称且传播到相应地理特征上。

在步骤825中，对于地理数据库中不与地点名称源匹配的地理特征，使用朝向投票将所述地理特征与地理数据库中的其它特征匹配，借此继承来自匹配的特征的地点指派。图9说明用于确定地理数据库中与未知地点名称相关联的城市街区朝向的名称的朝向投票的实例。在实施例中，在TIGER名称源的覆盖范围中的漏洞或不匹配地理特征通过“朝向投票”过程来消除。对于具有与未知城市名称相关联的街区朝向的城市街区，朝向投票基于对应于围绕其的街区朝向或将给定街区朝向连接到其本身的街区朝向的城市名称来确定街区朝向的城市名称。图9说明对于城市街区的朝向投票，使得对于给定街区朝向，朝向投票中使用的街区朝向是邻近于其的两个街区朝向和与其相对的一个街区朝向。图9街区朝向也可视为每一者作为街道段的一侧的地理特征。在实施例中检查邻近和相对街区朝向，其中定位有未指派朝向的支配性地点由其它邻近和相对朝向的多数投票确定。此过程将县级分区和合并区域代码及其相关联名称传播到来自邻近和相对编码的地理特征(其在实施例中是街区朝向)的任何未编码地理特征上。

举例来说，在图9中，中心大街(Center Street)的一个街区街道段的北侧与未知城市名称相关联，因为其是不与地点名称源中的任何地点相关联的地理特征。然而，发现其它街区朝向，或第一大街一个街区街道段的东侧、主街一个街区街道段的南侧和第二大街一个街区街道段的西侧与“波士顿”相关联。因为街区的这三个街道段中的三者与波士顿相关联，所以朝向投票为三分之三，且中心大街也将与波士顿相关联。如果这三个街道段中的两者与特定城市相关联，那么朝向投票为三分之二，且中心大街也将与所述特定城市相关联。如果是联系的情况，其中三个街道段每一者与不同城市相关联，那么朝向投票为三分之一。由于此情况下不存在多数投票，所以中心大街将与最靠近其的邻近街道中的一者(其在此情况下是第一大街或第二大街)的城市相关联。

在实施例中，朝向投票可用于除城市街区朝向之外的其它地理特征，例如街道段侧或道路边缘。在实施例中，朝向投票可用于除与未知城市名称相关联的街道段外的两个或两个以上其它街道段侧。在实施例中，朝向投票还可用于街区朝向中的两者或两者以上与未知城市名称相关联的情况。在此情况下，从剩余街区朝向中取多数投票，且发现多数投票或联系并如上文所论述进行处置。在实施例中，朝向投票可用于将街区朝向与除城市或镇外的其它地点名称相关联。举例来说，USPS城市/州文件中的地点名称是五位ZIP代码和来自ZIP+4文件的一个四位建筑代码。

朝向投票的其它实施例包含加权投票或线性长度投票，而不是多数投票。在使用加权投票的实施例中，邻近于不与地点相关联的街区朝向的某些街区朝向被给予优先选择，或在投票过程中更大程度被加权。加权投票可具有测量邻近街区朝向指派的置信度的任何加权分量。举例来说，可将优先选择给予对应于主要街道或位于较大区域中的街区朝向。街区朝向的长度是另一此类加权。在使用线性长度投票的实施例中，对于不与地点相关联的给定街区朝向，对于与邻近于给定街区朝向的街区朝向相关联的每一已知地点，取街区朝向的总长度以确定哪一与邻近街区朝向相关联的地点具有最长总线性长度的街区朝向。接着向此所得地点指派不与地点相关联的给定街区朝向。

在图8A中，如果步骤815中地图匹配因为源不与地理数据库共享任何属性而不可能实现，那么在步骤855中，在实施例中使用交叉源名称匹配。交叉溯源是源或第一源中的地点名称与已与地理数据库中的地理特征直接相关联的另一源中的地点名称的间接关联。在步骤855中，如果交叉源名称匹配因为发现已与地理数据库中的地理特征直接相关联的第二源具有与第一源匹配的地点名称而可能实现，那么在步骤860中，将第一源与第二源匹配。在步骤865中，第一源中的每一地点名称继承与来自第二源的地理特征的关联，且因此与特定地理特征间接相关联。在实施例中，继承的地理特征的实例是街道段侧、街区朝向和渡运线路。在实施例中，FIPS55数据是交叉源名称匹配的有用名称源。举例来说，居民地源的GNIS地点与州和县内FIPS55源中的地点名称匹配。在作出匹配的情况下，GNIS名称继承与来自其匹配的FIPS55名称的街道段侧的关联。过程从步骤865移动到步骤830，如下文所论述。如果在步骤855中对于源的交叉源匹配不可能，那么所述源不可用于过程中，且过程返回以在步骤810中选择另一地点源。

在实施例中，将从各种地点名称源取得的地点名称标记化、规范化、优化和/或匹配、合并或进行修饰以消除重复和不同的地点名称。在优选实施例中，执行所有标记化、规范化、优化、匹配和合并或修饰步骤。此过程为具有两个或两个以上类似名称的每一地点减少地点名称的数目，同时还保留意义上不同的地点名称。这些步骤适应各种源之间的名称编码的差异。来自各种源的类似地点名称的一个实例是新泽西州的城市霍霍库斯，其如下在各种地点名称源中出现：

TIGER记录类型C：霍霍库斯镇区(Ho-Ho-Kus Twnshp)

USPS城市州：霍霍库斯镇区(HO HO KUS Township)

POI住宅中心：霍霍库斯(HO-HO-KUS)

FIPS55-3：霍霍库斯(Hohokus)

GNIS：霍霍库斯(Ho-Ho-Kus)

过程从图8A中的步骤825和865移动到步骤830。在步骤830中，在实施例中，名称匹配过程的第一部分(标记化或解析)可将地点名称分解为多达大约十个标记或组成部分。可使用许多技术使地点名称标记化。这些步骤的目的是分解出地点名称的重要组成部分或部分或名称“主体”，以用于编索引的目的。其它组成部分(例如，前缀或后缀)每一者将是单独组成部分。接着在索引中通过标记来表示地点名称，借此允许应用程序开发商在名称的重要部分上编索引。举例来说，阿姆赫斯特和南阿姆赫斯特均将视需要接着在“A”下编索引。在实施例中消除重复件将允许最终用户在存储空间有限的应用中存取更多名称并防止用户由于看见呈现多次的相同名称而混淆。

对来自上文针对新泽西州的霍霍库斯实例列举的前两个地点名称源的地点名称进行标记化产生以下主体和后缀标记：

主体：霍霍库斯(Ho-Ho-Kus)，后缀：镇区(Twnshp)

主体：霍霍库斯(HO HO KUS)，后缀：镇区(Township)

标记化有助于隔离界定唯一名称的组成部分，且通过关联隔离可在匹配过程中忽略的标记。大多数最终用户将希望“拉特兰”与“拉特兰镇区”匹配，即，术语“镇区”被视为不重要的。同时，大多数最终用户将希望“波士顿”不与“南波士顿”匹配，即，术语“南”被视为重要的。标记化的另一原因是在将地点名称呈现给最终用户时提供软件应用程序开发商灵活性，因为名称的重要部分将被编索引。举例来说，通过将“好莱坞”和“西好莱坞”标记化，两者将被呈现为给予输入对“好莱坞”的地图搜索的最终用户的选择。发生这种情况是因为两者的“主体”标记将是“好莱坞”，因为西好莱坞将被标记化为主体：好莱坞，前缀：西，且好莱坞将被标记化为主体：好莱坞。

在另一实施例中，标记化有助于确定上下文敏感缩写的正确扩展。举例来说，地点前缀标记“St.”最有可能表示“Saint”，而地点后缀标记“St.”最有可能表示“State”。

以下是其它类型的标记和那些标记的实例：

前方向-前导方向(“北”亚当斯)

前类型-前导类型(“湖”伊莎贝拉)

前缀-前导，但不是方向或类型(“老”兰花海滩(Orchard Beach))

前名称-主体前的非类型字(森林“的”湖)

主体-用于索引目的的主件(湖“伊莎贝拉”)

后类型-结尾类型(皇家“海滩”)

后方向-结尾方向标记(休闲村庄“西”)

后缀-结尾，但不是方向或类型(“在海边的”曼彻斯特)

划区-指定地点的拆分的数字识别符(梅勒多西亚(Meredosia)“1”)

修饰-附加补充信息，例如用以阐明地点名称在何处的县名称(米德尔顿(Middletown)“(伯利恒(Bethlehem))”)

在图8A的步骤835中，在实施例中，来自标记化步骤的标记的规范化通常涉及以下过程中的一者或一者以上：扩展缩写、减少或去除标点，使用一致的写体(大写或小写)和去除内嵌空格。在实施例中，扩展对于方向和对于类型的标准缩写。举例来说，方向缩写“N.”扩展为“North”。对于类型缩写，例如，“Mt.”扩展为“Mount”且“AFB”扩展为“Air Force Base(空军基地)”。考虑到在不同源中出现的名称可以不同方式表示，缩写的正确规范化对于匹配过程是关键性的。在实施例中，去除内嵌空格和标点。在实施例中，可使用地点名称标记的一致的大写体或小写体来规范化大写。在实施例中，还可通过仅大写每一标记的第一个字母来规范化大写。此外，在实施例中，可在匹配过程中而不是规范化过程中适应大写差异。在优选实施例中，大写规范化为一致的大写体。使用新泽西州的霍霍库斯实例，将标记规范化产生以下结果：

主体：霍霍库斯(HOHOKUS)，后缀：镇区(TOWNSHIP)

主体：霍霍库斯(HOHOKUS)，后缀：镇区(TOWNSHIP)

以下使用情况实例说明将可存储在地点索引中的特征标记化和规范化的益处，地点索引的创建在下文中论述。如果索引中没有这些特征，不同缩写呈现为不同的城市名称。如果索引中有这些特征，缩写被译成普通形式，从而允许应用程序开发商将列表分解成单一明确条目。尽管标记的大写被规范化为一致的大写体以有助于匹配，但通常在仅每一标记的第一个字母被大写的情况下将标记呈现给用户。

如果索引中没有经标记化和规范化的地点名称：

输入城市->蓝道夫(Randolph)

请从以下中选择->

蓝道夫高地(Randolph Hghts)

蓝道夫高地(Randolph Heights)

蓝道夫高地(Randolph Hts.)

如果索引中有经标记化和规范化的地点名称：

输入城市->蓝道夫(Randolph)

您选择：蓝道夫高地(Randolph Heights)

以下使用情况实例说明将地点名称中的方向标记标记化和规范化的益处。通过识别方向标记，地点名称可依据其主体而不是依据方向来编索引。在将方向规范化之后，应用程序开发商只需要检查经规范化的标记而不是那些标记的任何缩写。

如果索引中没有经标记化和规范化的地点名称：

输入城市->波士顿

找到：波士顿

输入城市->南B(South B)

请从以下中选择->

南巴斯(South Bath)

南巴瑞斯特(South Barrister)

南巴恩斯特布(South Barnstable)

南波士顿(South Boston)

输入城市->S.波士顿

未找到城市：“S.波士顿”

输入城市->南波士顿

找到：“南波士顿”

如果索引中有经标记化和规范化的地点名称：

输入城市->波士顿

请从以下中选择->

波士顿

南波士顿

在图8A的步骤840中，在实施例中，优化来自规范化步骤的两个或两个以上类似地点名称通常将每一类似地点名称与地点中包含的地理特征相关联。地理特征的实例包含街道、街道段、地标、州立公园、公路、商业区和住宅区。在新泽西州的霍霍库斯实例中，优化将找到HoHoKus和HOHOKUS的相同地理特征。

在图8A的步骤845中，在主要源掩码中，将源掩码中的下一位分配给源。在实施例中，掩码在一个国家内是唯一的。在其它实施例中，掩码可对于任何地理区域(例如，州或大陆)是唯一的。图10展示美国和加拿大的地点名称源掩码的两个实例。在实施例中，源掩码中的每一位位置表示单一地点名称源。掩码可含有一个或一个以上行政、邮政或其它地点名称源。掩码对于国家是唯一的且不暗示地点名称源的优先权。对于列“十进制位值”中的每一位值，将列“地点名称源”中的地点名称源分配给位值。出于编索引的目的，地点源掩码实现界定不同种类的地点名称以最佳适合最终应用的灵活性。在实施例中，指示为“王牌”(trump)的掩码中的源可用于出于编索引的目的向在这些源中找到的地点名称给予最高优先权。对于源中的每一地点名称，还创建单个源掩码，展示其中出现地点名称的源。

在步骤850中，将针对源中的每一地点名称的源掩码中的下一位位置设定到此源。在多个源中出现的名称将对于其出现的每一源在掩码中设定位。举例来说，名称“波士顿”同时是县级分区名称、行政区域和若干ZIP代码的优选邮政名称。不在多个源中出现的名称将在其掩码中设定对应于其源的仅单一位。过程返回到步骤810以处理下一地点名称源(如果存在的话)。

如果在图8A的步骤810中不存在留下要处理的剩余地点源，那么过程移动到图8B中的步骤868。在步骤868中，匹配来自所有有用源的经优化名称。有用源是在步骤815中对于其地图匹配可能实现的源，以及在图8A的步骤855中对于其其它源匹配可能实现的源。在实施例中，匹配将经规范化的标记连接成全名，并将其进行比较以确定其是否可被视为匹配。在实施例中，地点名称写体或大写差异的规范化可在此名称匹配步骤中而不是上文的规范化步骤中执行。在实施例中，写体非敏感匹配逻辑可用于此匹配步骤中。对于美国的每一州，来自指定源的所有地点名称在实施例中匹配。

对于名称匹配可能有许多不同算法。名称匹配技术的实例包含上下文敏感匹配、语音匹配和语音法。上下文敏感匹配是名称的字符串匹配或名称的拼写的匹配。此类型的匹配在了解哪些标记正被匹配(其容许特殊规则)的情况下执行。举例来说，在主体标记中，良好的上下文敏感匹配算法可使“John F.Kennedy”(约翰F.肯尼迪)与“JohnFitzgerald Kennedy”(约翰·菲尔斯杰尔德·肯尼迪)匹配。极好的上下文敏感匹配算法可使“MLK”与“Martin Luther King”(马丁·路德·金)匹配。另一方面，语音匹配匹配单词的发音，而不是单词的拼写。举例来说，“fish”和“phish”语音上匹配。对于在各种语言中匹配的名称，可使用不同的语音匹配算法。语音法是用于依据名称在用英语说出时的发音来为名称编索引的语音算法。基本目标是将具有相同发音的名称编码到相同字符串，使得即使拼写存在微小差异也可发生匹配。关于语音算法的更详细信息可查阅颁予杰西·谢里丹(Jesse Sheridan)的2006年3月16日申请的标题为“使用语音算法缩减地理特征名称(Geographic Feature Name Reduction Using Phonetic Algorithms)”的第11/377,764号申请案。

在实施例中，为了使两个全名匹配，字符串必须完全匹配。在实施例中，如果全名不匹配，那么试图进行主体标记的匹配。对于成功的标记匹配来说，主体标记必须匹配，且方向和类型标记也必须匹配。因此，标记的匹配可能不是以一个或两个前导标记开始，且一个标记必须是另一标记的前导子串。因此，匹配的标记也必须忽略某些标记。在实施例中，可允许两个匹配的名称之间存在微小的拼写差异，在实施例中，相当谨慎地实施名称匹配以便防止错误匹配。因此：

“北波士顿”不与“南波士顿”匹配

“南波士顿”不与“波士顿”匹配

“镇区拉特兰”与“拉特兰镇区”匹配

在图8B的步骤870中，处理步骤868中找到的所有组匹配的地点名称。每一组匹配的地点名称是具有重复或稍许不同名称的地点。在步骤870中，如果存在另一组匹配的地点名称，那么过程在步骤872中确定匹配的名称是否表示重叠的几何形状。在步骤872中，如果地点重叠或即使其仅彼此邻近，只要在优化步骤840中确定其共同地共享至少一个地理特征，那么匹配的名称就表示重叠的几何形状。

如果在图8B的步骤872中，匹配的名称表示重叠的几何形状，如果在步骤873中，重叠的几何形状是精确的，那么在步骤874中，从地理数据库中地点索引条目中消除除了一个之外的重复名称。如果与一个地点名称相关联的所有地理特征和与另一地点名称相关联的所有地理特征相同，那么这些地点名称是真实重复件且除了一个之外全部消除。当且仅当名称表示相同地点时，才消除地点名称。此步骤消除重复的地点并缩减地点名称组。对于具有许多重复条目的地点索引，此技术将大大减少编索引量和索引所需的空间。在新泽西州的霍霍库斯实例中，对于每一名称连接在一起的经规范化标记均是“霍霍库斯镇区”。因为这两个地点名称将被确定为共同具有来自优化步骤的所有地理特征，所以这些地点名称是真实重复件且消除一个。过程接着返回到步骤870以确定是否存在另一组匹配的地点名称。

如果在图8B的步骤873中，重叠的几何形状不是精确的，或一地点与另一地点(通常是具有稍许不同名称的地点)共享至少一个但少于全部地理特征，那么这些地点被认为是相同地点且在步骤875中合并。举例来说，佛蒙特州的“蓝道夫”和“蓝道夫中心”是两个单独但重叠的镇。因为两个镇重叠，所以其共同地共享至少一个地理特征，且被认为是相同地点并合并。

在实施例中，地点名称的合并仅在重叠的地点不具有不可彼此区分的非重叠特征时发生。举例来说，如果蓝道夫和蓝道夫中心均具有带有非重叠街道号码的主街，那么两个镇可合并。然而，如果两个镇均具有“主街2号”，那么所述镇不应合并。

以下使用情况实例说明将来自不同源的具有重叠几何形状的重复地点名称除了一个之外全部消除的益处。如果没有此特征，地点名称在呈现给用户的选择中会被多重列举。

如果不消除重复件：

输入城市->汉诺威

请从以下中选择->

汉诺威(县级分区)

汉诺威(行政区域)

汉诺威(03755)

消除重复件之后：

输入城市->汉诺威

找到：“汉诺威”

以下使用情况实例还说明合并具有稍许不同名称的地点的益处。如果不合并，用户可能不知道哪一稍许不同名称是其中定位有所需目的地的地点。如果合并，用户不需要区分名称。举例来说，地点“蓝道夫”、“蓝道夫中心”与“蓝道夫镇区”重叠，且因此被合并为由单一名称“蓝道夫”表示的共同区域。因此，对于用户搜索：

如果不合并：

输入城市->蓝道夫

输入街道->主街

请从以下中选择->

主街，蓝道夫

主街，蓝道夫中心

主街，蓝道夫镇区

如果合并：

输入城市->蓝道夫

输入街道->主街

找到：“主街，蓝道夫”

在图8B的步骤876中，将来自匹配的名称的所有特征的联合指派给合并的名称。举例来说，在FIPS55中，县级分区波士顿界定某一地理布局。行政区域波士顿界定重叠但不一定相同的其它地理布局。邮政区域波士顿界定覆盖美国邮件可被递送到的街道的第三组地理布局。创建这些不同特征的联合形成与波士顿相关联的一组完整特征。与这些波士顿相关名称的每一者相关联的地理特征的联合包括包含那些源的每一者的一组地理特征。举例来说，如果亚当斯街道为最终用户所关注，尽管亚当斯街道不是邮政区域波士顿的一部分，也将为用户找到亚当斯街道，因为由于来自各种地点名称源的匹配的地点名称的地理特征的联合的缘故，其是县级分区波士顿的一部分。因此，产生唯一地点名称的列表，其中在源掩码中设定对应于其中找到每一名称的源和每一名称所适用的所有地理特征的联合的位。过程接着返回到步骤870以确定是否存在另一组匹配的地点名称。

图11展示用于通过地点名称的匹配而简化地点名称组的算法的实施例。对于地点名称源中的每一地点名称A，对于与名称A匹配的任何其它源中的每一名称B，将尚未指派给A的与B相关联的任何段街道侧指派给A。这是上文图8B的步骤876。将尚未包含在源掩码A中的任何位包含在源掩码B中，并删除B。

在图8B的步骤872中，如果匹配的名称不表示重叠的几何形状，那么在步骤878中修饰匹配的名称以使其独特。不表示重叠的几何形状的匹配的名称是具有物理上不相交的重复或稍许不同名称的地点。在实施例中，这些实体上不相交的地点是位于美国的州内的城市。许多州具有多个带有相同或稍许不同名称的城市。通常，此类具有重复名称的地点存在于州内的不同县中。因此，可通过展示修饰(例如，其中定位有地点的县名称)来为用户区分这些重复名称。地点的修饰通常展示于紧接于地点名称的括号中或引号中。然而，县名称或其它边界修饰可能不能被非本地用户辨别。事实上，在具有重复名称的每一地点附近的较大、容易辨别的城市的名称将为用户提供较好的信息。因此，在步骤878中，将单独城市修饰存储在来自步骤872的名称的每一者的地点索引中。关于创建此类型的修饰的更详细信息可查阅颁予迈克尔盖利希的2006年2月1日申请的标题为“区分所关注的州或其它主要地理单位内的重复或类似命名的不相交地点的方法(Method for Differentiating Duplicate or Similarly Named Disjoint Localities within a Stateor other Principle Geographic Unit of Interest)”的第11/345,877号申请案。过程接着返回到步骤870以确定是否存在另一组匹配的地点名称。

以下使用情况实例展示对于具有重复或稍许不同名称的不相交地点的修饰：

用县名称进行修饰：

输入州->PA

输入城市->贝瑟尔(Bethel)

请从以下中选择->

贝瑟尔(伯克丝(Berks))

贝瑟尔(阿勒根尼(Allegheny))

贝瑟尔(兰开斯特(Lancaster))

贝瑟尔(美世(Mercer))

贝瑟尔(沙利文(Sullivan))

贝瑟尔(韦恩(Wayne))

用较大的附近容易辨别的城市名称进行修饰：

输入州->PA

输入城市->贝瑟尔

请从以下中选择->

贝瑟尔(弗雷德里克斯堡(Fredericksburg))

贝瑟尔(匹兹堡(Pittsburgh))

贝瑟尔(兰开斯特(Lancaster))

贝瑟尔(扬斯敦(Youngstown))

贝瑟尔(威廉斯波特(Willamsport))

贝瑟尔(斯克兰顿(Scranton))

在此使用情况实例中，应用程序在请求来自用户的更多信息之前处理每一用户输入。在其它实施例中，对于“用较大的附近容易辨别的城市名称进行修饰”，如果用户在应用程序处理州、城市和街道名称之前输入这三个用户输入，那么如果在选择的仅一者中找到街道地址则可确定唯一目的地。举例来说：

用较大的附近容易辨别的城市名称进行修饰：

输入州->PA

输入城市->贝瑟尔

输入街道名称->主街

找到：“主街，贝瑟尔(弗雷德里克斯堡)”

如果在步骤870中，不存在另一组匹配的地点名称，那么在图8B的步骤880中，创建索引。所述索引首先依据地理特征排序。对于每一地理特征，含有所述地理特征的地点以优先权次序编索引。索引中的地点名称依据优先权排序，以允许应用程序开发商将任何地理特征的最流行名称的选择编程到应用程序中。这为最终用户提供(例如)在存储空间有限的环境中可从中进行选择的最流行名称。对于仅可存储每一地理特征的几个地点名称的存储空间有限的装置，应用程序开发商可使用地点索引针对与多于几个地点相关联的地理特征为用户选择最高优先权地点。类似地，对于自下向上搜索应用程序，应用程序向用户请求地址或地理特征，并呈现用户从中进行选择的地点列表。在呈现地点列表的过程中，可使用与地址相关联的最高优先权名称。

在实施例中，与地理特征相关联的地点的优先权次序基于在针对既定应用的普通使用中每一地点名称的流行性。在实施例中，基于普通使用的优先化允许针对不同用户以不同方式对地点名称进行排序。在重叠地点(例如，“纽约市”、“曼哈顿”与“休南区”)的实例中，在普通使用中，本地用户将非常了解所述区域，将最有可能使用三个地点中较具体的地点，或“休南区”。如果应用程序既定用于此本地用户，那么最高优先权地点名称将最有可能是具有其中可找到所述地点名称的最少数目的源的地点名称。因此，优先权次序从最高到最低将是“休南区”，“曼哈顿”，接着是“纽约市”。

使用位于纽约市的重叠地点的相同实例，然而，在普通使用中，不非常了解本地区域的非本地用户将最有可能使用较众所周知、容易辨别的地点。如果应用程序既定用于此非本地用户，那么最高优先权地点名称将最有可能是具有其中可找到所述地点名称的最多数目的源的地点名称。因此，优先权次序从最高到最低将是“纽约市”，“曼哈顿”，接着是“休南区”。

在实施例中，在应用程序中用于确定优先权次序的算法可以不同方式应用以满足用户的不同普通使用。举例来说，对于在例如大城市的地点内导航的本地用户，用户可能想要得到基于本地用户的普通使用的地点名称的优先权。然而，当同一用户从远方导航到同一大城市时，用户可能想要得到基于非本地用户的普通使用的不同优先权。然而，一旦用户到达大城市并越过城市进入边界，用户可能想让优先权改变回到本地用户的优先权。

许多不同的优先权排序方案是可能的。在优选实施例中，与地理特征相关联的最高优先权地点是在优选邮政名称源中找到的地点，于是通过每一地点源掩码中设定的位的数目来确定剩余地点的优先权。在实施例中，如果第一地点在普通使用更加众所周知或流行，那么第一地点具有比第二地点高的优先权。在实施例中，地点名称的优先权由其中可找到所述名称的源的数目来确定。具有最高优先权的地理特征的地点名称是可在最多数目的源中找到且因此在其源掩码中设定有最多位的地点名称。地理特征的地点名称的优先权次序是从最高到最低。

在实施例中，应用程序开发商还可使用源掩码通过使某些地点名称源比其它地点名称源优选来忽略此默认优先权方案。在其它实施例中，依据最大物理地点大小或最大地点人口来界定优先权。在其它实施例中，将优先权界定为一地点中的地理特征(例如街道段)的最大数目。在其它实施例中，还可依据位于地点内的主要地理特征的最大数目来界定优先权，而不是依据位于地点内的地理特征的数目。主要地理特征的实例是重要的公路。在实施例中，可使用地点源掩码来确定某些地点名称源相对于其它地点名称源的优选，借此来界定优先权。在实施例中，应用程序开发商可使用来自地点源的在图10中指示为“王牌”的地点名称作为最高优先权名称。

在实施例中，在地点优先权联系的情况下，使用以上方案中的一者执行初级分类，且在必要时，基于以上方案中的一者执行次级分类。在优选实施例中，依据其中可找到每一地点的源的数目(从最高到最低)执行初级分类。次级分类(例如)是基于每一地点中包含的地理特征或街道段的数目(从最高到最低)。

图12展示用于确定给定地理特征的地点名称的优先权的算法的实施例。对于地理数据库中的每一街道段侧S，找到S被指派到的所有地点名称A。对于每一A，找到在其源掩码中设定有最多位的名称A。将A指派给对于此街道段侧S的索引中的下一最高优先权名称。

图8B的过程在步骤890中结束。

图13展示包含特征地点优先权表、地点名称表和寻找特征表的地点索引文件的实施例。这些表最终存储在数据库中。在实施例中，在图13的特征地点优先权表中，依据优先权列举了每一地理特征的地点。在实施例中，表中的每一地理特征与特征ID号码FF_ID相关联。特征ID号码可以是连续的但不一定必须是连续的。特征ID号码也是到寻找特征表的链接。在实施例中，与表中的每一地理特征相关联的每一地点还与地点ID号码NAME_ID相关联。地点ID号码可以是连续的但不一定必须是连续的。优先权字段指示与地理特征相关联的地点名称的流行性。如上文所提及，存在许多优先权方案以对与每一地理特征相关联的地点名称区分优先次序。优先权是以作为最高优先权的“1”开头的有序数字。表还含有上文描述的此地点的地点名称源掩码LOC_MASK。

地点索引的可变格式允许为特征地点优先权表中的每一地理特征包含任何数目的表条目。这在北美洲对于邮政名称尤其重要。虽然每一位置通常仅存在一个优选的邮政地点名称，但邮政业务还包含相同位置的任何数目的可允许邮政地点名称。地点索引包含每一地理特征的所有优选和可允许邮政名称。

在实施例中，图13的地点名称表通过地点ID号码NAME_ID链接到特征地点优先权表。在实施例中，所述表还含有地点的全名FULL_NAME，其使用混合写体字母。在实施例中，如FIPS55中表示的地点全名用于此表中地点全名的最后编码。然而，可使用用于表示地点全名的其它源。表的NAME_KEY字段是用于编索引目的的地点名称的重要组成部分。在实施例中，通过上文对地点名称进行标记化和规范化而找到NAME_KEY。这允许(例如)“好莱坞”和“西好莱坞”均在“H”下编索引，因为两者的主体标记均是“好莱坞”。修饰(ADORNMENT)字段是对地点名称表中含有地点附近的较大且容易辨别的位置或城市的地点名称的的另一条目的指针。在实施例中，仅当地点是国家的初级分区内的不明确地点时才将修饰存储在表中。在实施例中，修饰用于区分用户的装置或***上的列表中的重复地点。

NAME_LC字段是地点名称的语言的三字符码。在实施例中，为每一地点名称设定NAME_LC以指示支持多语言国家的名称的本民族语言。在实施例中，NAME_LC可以是任何数目的字符。LOC_SIZE指示与此地点名称相关联的地理特征的数目的计数，且可由应用程序开发商使用以忽略特征地点优先权表中供应的默认优先权方案。国家(COUNTRY)是国家代码且是其中定位有所述地点的国家的三字符缩写。在实施例中，国家可以是例如ISO3166-1等标准国家代码，所述ISO3166-1是首先由国际标准化组织公布的ISO3166标准的一部分。在实施例中，国家可以是任何数目的字符。CENTER_ID是到此地点的地理数据库中的其它地方找到的市中心点特征的链接。在实施例中，这些市中心点特征是地点中心点纬度和经度坐标，以及对应于市中心的街道段。当未请求或无法找到特定街道地址时，市中心向用户提供地点内的点。

在实施例中，图13的地点名称表可含有关于地点的许多其它有用类型的信息。举例来说，地点名称表中包含音素将对文本到语音应用有用，其中音素是认知上等效的一组言语语音或符号元素。可存储在地点名称表中的不同类型的信息的其它实例是地点的市政府的图片和地点的警察局的电话号码。

在实施例中，图13的寻找特征表含有关于每一地理特征的信息。FF_ID是用于将地理特征信息链接到特征地点优先权表的特征ID号码。FEAT_TYPE是地理特征的类型，例如道路特征的“R”和渡运线路特征的“F”。FEAT_ID是到关于特征的地理数据库中的信息(例如，街道名称和地址范围)的链接。FEAT_ID还提供到链接到地理数据库的其它内容(例如，关注点)的间接链接。侧(SIDE)是地理特征的侧部，例如街道边缘。侧包含右侧的“R”、左侧的“L”、两侧的“B”、和“不适用”的“空”。

在实施例中，以多种格式提供地点索引，包含国际性格式，以使得能够与专有地理数据库进行容易的整合。提供地点索引以适应来自任何国家的数据。虽然格式是一般化的，但内容经修改以包含每一国家中适当的特定地点源和类型。专有应用程序提供每一地点名称的正确发音。

在实施例中，对于地点索引表使用，在寻找地址的自上向下实施方案中，首先解析地点，且接着在所述地点内寻找正确的地理特征。导航应用程序将首先执行名称匹配以在地点名称表中找到所需地点名称。一旦找到地点，就使用所选地点的NAME_ID搜索特征地点优先权表以确定所述地点中包含的地理特征。那些特征的FF_ID用作进入寻找特征表的索引以检索关于寻找特定特征所需的那些特征的信息，例如街道名称和地址范围(在街道段的情况下)，且接着执行匹配以选择所需特定地理特征。举例来说，[输入城市->波士顿]。将“波士顿”与地点名称表中的名称匹配，从而返回“波士顿”的NAME_ID。[输入街道->亚当斯]。在特征地点优先权表中搜索NAME_ID是“波士顿”的NAME_ID的FF_ID的列表。在寻找特征表中搜索指向地理数据库中的“亚当斯”的FEAT_ID。随后，可向用户请求所需房屋号码，且在寻找特征表中搜索指向地理数据库中含有所请求的房屋号码的地址范围的FEAT_ID。可在寻找特征表中搜索指向地理数据库中此特征的纬度和经度点的FEAT_ID，以便(例如)在导航应用程序或装置上向用户显示特征的位置。为了改进性能，将经常预编辑地点索引以消除这些间接参考中的许多参考。

在实施例中，对于地点索引使用，在寻找地址的自下向上实施方案中，首先选择目标地理特征的列表，接着通过解析来自含有拥有所述名称的特征的所有地点的列表的所需地点而选择正确特征。导航应用程序将首先执行匹配以在寻找特征表中寻找地理特征的列表。接着将来自寻找特征表的相应FF_ID用作进入特征地点优先权表的索引。接着可扫描优先权表中这些FF_ID的条目以获得在地点名称表中的名称与所需地点匹配的NAME_ID。如果应用程序开发商希望向用户呈现地点选择，那么应用程序应以优先权次序考虑地点NAME_ID，从而选择对于考虑中的FF_ID是唯一的最高优先权地点名称。接着可向用户呈现这些名称以供从中进行选择。与自上向下情况中一样，将经常预编辑地点索引以消除表之间的间接参考中的许多参考。

在实施例中，地点索引可用于寻找例如关注点和地标等所命名的地方。此类地方的列表首先与来自专有地理数据库的街道段相关联。应用程序接着将匹配所需关注点或地标的名称以找到街道段。应用程序接着使用以上使用街道段寻找地址的实施方案以便确定正确地点。

在实施例中，地点索引可用于寻找市中心。应用程序将使用地点名称表中的FULL_NAME和NAME_KEY对所需地点进行名称匹配以在表中寻找正确条目。一旦找到正确条目，就使用CENTER_ID字段来寻找地理数据库中相应的专有地点中心信息，例如纬度和经度坐标或对应于市中心的街道段。

在实施例中，地点索引可用于消除具有重复名称但具有不同地理布局的地点的歧义。应用程序将使用地点名称表中的FULL_NAME和NAME_KEY对所需地点进行名称匹配以在表中寻找正确条目。举例来说，如果地点是“加利福尼亚州，布伦特伍德”，那么将如图4所示找到两个匹配。来自地点名称表的修饰因此将用于每一布伦特伍德地点，例如修饰“洛杉矶”和“旧金山”。这些可作为用户可从中进行选择的“布伦特伍德(洛杉矶)”和“布伦特伍德(旧金山)”而显示给用户。

在实施例中，地点索引可用于解析地址特征的不明确性。举例来说，对于图3中的“亚当斯街道2号”实例，应用程序将使用针对每一特征的多个地点名称(依据优先权排序)来区分地点马萨诸塞州，波士顿内找到的四个“亚当斯街道2号”地址。应用程序将首先使用寻找特征表的FEAT_ID字段寻找地理数据库中对应于重复地址的地址段。应用程序接着将寻找所述寻找特征表中的相应FF_ID。接着将FF_ID用作进入特征地点优先权表的索引。使用优先权以从最高到最低优先权的次序检索地点，直到找到每一FF_ID条目的唯一NAME_ID为止。将NAME_ID用作进入地点名称表的索引以检索每一重复地址的唯一地点名称FULL_NAME。在“亚当斯街道2号”实例中，将在马萨诸塞州，波士顿的所有子地点查尔斯顿、海德公园、罗克斯巴瑞和多尔切斯特中找到唯一地点名称。

在实施例中，地点索引可用于在自上向下应用程序中搜索邻近区域以找到所请求特征。在一些情况下，可能未在用户所指定的地点中找到所需特征，且导航应用程序将希望将搜索扩展到邻近或较大的包含地点。应用程序将首先匹配地点名称表中所需地点的名称，从而检索相应NAME_ID。在确定特征地点优先权表中不存在对应于具有此地点NAME_ID的所请求特征的FF_ID之后，应用程序将在特征地点优先权表中寻找确实含有此NAME_ID的一个或一个以上FF_ID。可遵循优先权链，或特征地点优先权表中这些FF_ID的较高或较低优先权，以检索对应于这些FF_ID的其它NAME_ID。可参考寻找特征表以确定所请求地址是否在这些其它相关地点的任一者内。

在实施例中，以下使用情况实例说明地点索引的优先化特征的益处。如果不优先化，应用程序开发商不会清楚在询问用户时如何使用最可辨别的名称。在一些地方，邮政名称是最常见的。在其它区域，行政名称是众所周知的。利用优先化特征，可选择最常见的名称。

如果不进行优先化：

输入街道->百老汇

请从以下中选择->

百老汇(马萨诸塞州，查尔斯顿)

百老汇(纽约州，曼哈顿)

如果进行优先化：

输入街道->百老汇

请从以下中选择->

百老汇(马萨诸塞州，波士顿)

百老汇(纽约州，纽约)

在实施例中，在如图14中说明的另一使用情况实例中，导航应用程序可适应当错误地指定附近城市时的不一致性。比如芝加哥等大城市通常周围有郊区。郊区是单独的，且具有其自身的行政结构。明确地说，其地点名称通常不同。用户可能不知道郊区，而是仅想起较大的中心城市。在芝加哥北部的郊区找到一实例，如图14所示。假设用户想要定位位于林肯伍德的“布林茅尔乡间俱乐部”，但仅知道该地区是芝加哥。如果用户知道街道地址是“北克劳福德街，6600号”，那么输入可能如下进行：

输入州->伊利诺斯

输入城市->芝加哥

输入街道->北克劳福德街

导航应用程序将注意到此处的不一致性。应用程序将首先搜索特征地点优先权表中其中NAME_ID指向芝加哥的所有FF_ID。应用程序将注意到芝加哥不存在“北克劳福德街”。应用程序将在特征地点优先权表中搜索其中FF_ID指向“北克劳福德街”的所有FF_ID。应用程序将找到位于芝加哥的林肯伍德郊区的“北克劳福德街”。如果应用程序已找到位于若干地点中的“北克劳福德街”，那么应用程序将使用特征地点优先权表中的优先权而使用此FF_ID的最高优先权地点名称。应用程序可注意到芝加哥存在“南克劳福德街”。应用程序接着请求街道号码：

输入街道号码->6600

找到：“伊利诺斯州，林肯伍德，北克劳福德街6600号”

在此实例中，如果在两个地方均找到正确的街道号码，那么应用程序可为用户提供选择：“芝加哥，南克劳福德街6600号”或“林肯伍德，北克劳福德街6600号”。由于在芝加哥的“南克劳福德街”上未找到街道号码“6600”，所以不向用户显示此地址选择。尽管针对“北克劳福德街”找到的街道号码“6600”位于林肯伍德而不是芝加哥，但应用程序可假定其是用户希望请求的地址。

在实施例中，在另一使用情况实例中，应用程序可实现处置用户对街道或对城市的哪一输入不一致且应进行修订。钱德勒音乐厅(Chandler Music Hall)在其网站上的地址是“佛蒙特州，伦道夫，主街71-73号”。在城市伦道夫，主街划分为“北主街”和“南主街”。伦道夫中心的附近镇也存在“主街”。对于最终用户，如果街道确实是主街，那么音乐厅必然位于伦道夫中心。如果音乐厅位于伦道夫，那么其位于北主街或南主街上。音乐厅实际上位于伦道夫，在北主街71号。如果最终用户在自上向下应用程序中使用网站地址，那么用户将被正确地从伦道夫引导到北主街或南主街，但应用程序将要求用户作出决策，因为两条街道上均存在街道号码71。如果用户在自下向上应用程序中使用网站地址，那么用户将被正确地从主街引导到伦道夫中心。在实施例中，导航应用程序处置此种状况的一种方式是向用户呈现所有选择：

输入州->佛蒙特

输入城市->伦道夫

输入街道->主街

输入街道号码->71

请从以下中选择->

伦道夫，北主街71号

伦道夫，南主街71号

伦道夫中心，主街71号

在实施例中，自动实行本发明的一个或一个以上步骤。使用适当软件来实施自动特征。自动特征实现创建地点索引的效率和速度的实质提高。

本发明的实施例经过修改可应用于非导航应用程序和装置。举例来说，在空间黄页应用程序中，需要找到依据距一点的距离而分类的某一类型的所有商业机构。在实施例中，针对此类型的应用程序为地点编索引可使用基于在黄页目录中的出现频率的优先权方案。

图15展示可与本发明的实施例一起使用的示范性***900的框图。尽管此图将组件描绘为逻辑上分离的，但此描绘仅出于说明性目的。所属领域的技术人员将了解，此图中描绘的组件可组合或划分为单独的软件、固件和/或硬件组件。此外，所属领域的技术人员还将了解，此类组件，不管其如何组合或划分，都可在相同计算装置/***上执行，或可分布在通过一个或一个以上网络或其它适宜的通信手段连接的不同计算装置/***间。

如图15所示，***900通常包含计算装置910，其可包括相同种类的一个或一个以上存储器912、一个或一个以上处理器914，以及一个或一个以上存储装置或储存库916。***900可进一步包含显示装置918，包含在其上操作的图形用户界面或GUI 920，***可借助所述GUI 920向用户显示地图和其它信息。用户使用计算装置来请求(例如)在地图上显示地点或将驾驶指示显示为地图上的路线和/或文本指示。GUI920显示“新泽西州，华盛顿”的一对重复地点及其修饰“伊斯顿”和“哈蒙顿”的实例。用户将选择所述重复地点中的一者以显示给GUI920。

地理数据库930展示为计算装置或***910外部的存储装置，但在一些情况中地理数据库930可以是与存储装置916相同的存储装置。在实施例中，针对地理数据库930中的重复和不同地点932合并地点名称条目。在实施例中，地理数据库930含有地点源的主要源掩码934。在实施例中，包含特征地点优先权表、地点名称表和寻找特征表的地点索引936存储在地理数据库930中。

专有地理数据库创建软件940可使用现实地点源和定义960来合并和/或修饰重复和不同地点名称条目932，创建地点源的主要源掩码934，并创建地点索引936。现实地点源和定义的实例在上文对于图2的论述中描述。来自地理数据库930的信息由地理数据库到应用程序转换器及装置应用程序软件950使用，其最终由计算装置910的用户使用。地理数据库到应用程序转换器及装置应用程序软件950展示为远离用户的计算装置910但也可驻存在用户的计算装置910上。

对于由用户在因特网上或导航装置上使用的地理数据库到应用程序转换器及装置应用程序软件950的实例，用户可选择一地点以在地图上显示。或者，如果用户请求(例如)驾驶指示，那么所述地点可以是开始或结束地点。

在实施例中，询问用户的软件应用程序的类型可以是向下钻取(drill-down)、自上向下或自下向上应用程序。向下钻取方法在具有有限存储空间的基于汽车的导航***中有用。在可用于存储空间有限的装置的实施例中，应用程序开发商可仅将在优先权方面等级较高的地点名称包含在装置中。自上向下应用程序首先请求用户输入主要地理特征，例如州或省。应用程序接着请求用户输入位于所述主要地理特征中的地点，例如城市或镇。应用程序接着请求用户输入所述地点中街道的名称。最后，应用程序请求用户输入街道号码。在大多数情况下，询问导致对供应用程序使用的明确地理数据库特征的说明，例如在显示装置918的GUI 920上向用户显示所述地点。自下向上应用程序首先请求用户输入房屋号码和街道名称。应用程序接着显示其中可找到此地址的所有地点。最后，应用程序请求用户选择或输入所需地点的名称。自下向上方法通常也导致接着对可由应用程序使用的明确地理数据库特征的说明。

在实施例中，应用程序软件可在向下钻取应用程序中使用地理数据库索引，其允许最终用户输入通常位于给定州内的部分或完全的地点名称。在实施例中，应用程序向最终用户呈现与用户的输入匹配的名称，且用户选择最佳选项。在匹配经标记化名称主体的情况下，当最终用户输入“好莱坞”的首字母的任一者时，应用程序可呈现“好莱坞”和“西好莱坞”两者。

在其它实施例中，应用程序软件不是向下钻取应用程序，而是同时向用户询问街道号码和街道、地点和主要地理特征。在大多数情况下，询问导致对明确地理数据库特征的说明，且过程将位置返回给用户。如果用户输入街道名称“主街”和地点“斯普林菲尔德”，那么将发现重复地点“斯普林菲尔德”(如果其也具有名称为“主街”的街道)。如果地理特征存在重复地点，那么可(例如)在显示装置918的GUI 920上向用户显示地点及其修饰的列表以便要求用户选择一者。对于“新泽西州，华盛顿”的一对实例重复地点，可用其中找到所述地点的县或用附近较大城市的名称来修饰两个地点。“新泽西州，伊斯顿”和“新泽西州，哈蒙顿”分别是两个重复地点的附近大城市。因此，向图15的GUI 920显示“新泽西州，华盛顿(伊斯顿)”和“新泽西州，华盛顿(哈蒙顿)”。在此实例中，在括号中呈现修饰，但可以其它方式呈现，例如通过使用逗号将每一重复地点与其各自的修饰隔离。用户选择重复地点中的一者，且接着向用户显示地图上的地点或驾驶指示。

如软件领域的技术人员将了解的，熟练的程序设计员可基于本发明的教示容易地准备适当的软件编码。如所属领域的技术人员将容易了解的，还可通过准备专用集成电路或通过互连常规组成电路的适当网络来实施本发明的实施例。

本发明的实施例可包含计算机程序产品，其是上面/内部存储有可用于对计算机进行编程以执行本发明实施例的过程中的任一者的指令的存储媒体。所述存储媒体可包含(但不限于)任何类型的盘，包含软盘、光盘、DVD、CD-ROM、微驱动器和磁-光盘、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、快闪存储器装置、磁性或光学卡、毫微***(包含分子存储器IC)，或适宜用于存储指令和/或数据的任何类型的***或装置。

本发明的实施例存储在计算机可读媒体的任一者上，本发明的实施例可包含用于控制通用/专用计算机或微处理器的硬件和用于使计算机或微处理器能够与人类用户或利用本发明实施例的结果的其它机构交互的软件。此类软件可包含(但不限于)装置驱动器、操作***和用户应用程序。最终，此类计算机可读媒体进一步包含用于执行本发明实施例的软件，如上文所描述。

通用/专用计算机或微处理器的编程或软件中包含用于实施本发明的教示的软件模块。如计算机领域的技术人员将了解的，可使用根据本发明的教示编程的常规通用/专用数字计算机或微处理器来便利地实施本发明的实施例。

已出于说明和描述的目的提供本发明的以上描述。不希望其为详尽的或将本发明实施例限于所揭示的精确形式。所属领域的从业者将了解许多修改和变化。选择并描述所述实施例是为了最佳地阐释本发明的原理及其实践应用，借此使所属领域的其他技术人员能够理解本发明是用于各种实施例，且具有适于所预期的特定用途的各种修改。希望本发明的范围由所附权利要求书及其等效物界定。

Claims (45)

1.一种可存储在存储媒体上的地理数据库地点索引，其包括：

到地理数据库中的至少一个地理特征的指针；以及

与所述至少一个地理特征相关联的一组一个或一个以上地点名称，其中所述一个或一个以上地点名称选自一个或一个以上地点名称源并依据基于所述一个或一个以上地点名称在针对既定应用程序的普通使用中的流行性的优先权进行排序。

2.根据权利要求1所述的索引，其中地理特征包括街道、街道段、街道段边缘、街区朝向、地标、州立公园、公路、小宗货物中心、渡运线路、公交路线、小宗货物中心、商业区和住宅区。

3.根据权利要求1所述的索引，其进一步包括通过为所述索引中使用的所述一个或一个以上地点名称源的每一者分配一位而创建的主要源掩码。

4.根据权利要求3所述的索引，其进一步包括与每一地理特征相关联的每一地点的地点源掩码，其中如果所述地点可在相应位在所述主要源掩码中分配所针对的源中找到，那么设定所述地点源掩码中的每一位。

5.根据权利要求1所述的索引，其中可以不同方式应用程序优先权次序以满足不同的普通使用。

6.根据权利要求1所述的索引，其中如果既定应用程序既定用于本地用户，则针对所述应用程序的普通使用包括其中可找到地点名称的最少数目的源。

7.根据权利要求1所述的索引，其中如果既定应用程序既定用于非本地用户，则针对所述应用程序的普通使用包括其中可找到地点名称的最多数目的源。

8.根据权利要求1所述的索引，其中基于每一地点名称在针对既定应用程序的普通使用中的流行性的地理特征的地点名称的优先权包括将与地理特征相关联的最高优先权地点确定为在优选邮政名称源中找到的地点，接着将与所述地理特征相关联的剩余地点的优先权确定为是依据每一地点源掩码中设定的位的数目，其中对于所述剩余地点，所述地点的所述源掩码中的名称源的数目越大，则所述地点的所述优先权越高。

9.根据权利要求1所述的索引，其中基于每一地点名称在针对既定应用程序的普通使用中的流行性的地理特征的地点名称的优先权包括确定其中可根据与所述地点相关联的所述源掩码找到所述地点的地点名称源的数目，其中所述地点的所述源掩码中的名称源的所述数目越大，则所述地点的所述优先权越高。

10.根据权利要求1所述的索引，其中地理特征的地点名称的替代优先权包括基于以下中的一者的确定：

每一地点中地理特征的数目，其中所述地点中的地理源的所述数目越大，则所述地点的所述优先权越高；

每一地点的物理大小，其中所述地点的所述物理大小越大，则所述地点的所述优先权越高；以及

每一地点的人口数量，其中所述地点的所述人口数量越大，则所述地点的所述优先权越高。

11.根据权利要求1所述的索引，其中地理特征的地点名称的替代优先权包括基于特定地点名称源相对于使用所述地点源掩码的其它地点名称源的优先选择的确定，其中对于所述特定地点在其地点源掩码中设定位的地点比未设定位的地点具有更高优先权。

12.根据权利要求3所述的索引，其中所述主要源掩码进一步包括王牌源，其中地理特征的地点名称的替代优先权包括基于所述王牌源，其中对于所述王牌源在其地点源掩码中设定位的地点比未设定位的地点具有更高优先权。

13.根据权利要求1所述的索引，其中如果地理特征的地点名称的优先权的确定导致地点之间的联系，那么所述联系的地点的优先权包括基于以下中的一者的确定：

每一联系的地点中地理特征的数目，其中所述联系的地点中地理源的所述数目越大，则所述联系的地点的所述优先权越高；

每一联系的地点的物理大小，其中所述联系的地点的所述物理大小越大，则所述联系的地点的所述优先权越高；

每一联系的地点的人口数量，其中所述联系的地点的所述人口数量越大，则所述联系的地点的所述优先权越高；以及

特定地点名称源相对于使用所述地点源掩码的其它地点名称源的优先选择，其中对于所述特定地点在其地点源掩码中设定位的联系的地点比未设定位的联系的地点具有更高优先权。

14.根据权利要求1所述的索引，其中来自所述一个或一个以上地点名称的一地点名称与所述至少一个地理特征的关联包括直接或间接关联。

15.根据权利要求14所述的索引，其中通常对于与地理特征相关联的特定地点名称源，直接关联包括使用所述地点名称源与所述地理数据库中的所述地理特征之间的至少一个共同属性将与所述地点名称相关联的任何地理特征与所述地理数据库中的所述至少一个地理特征匹配。

16.根据权利要求15所述的索引，其进一步包括为地图上邻近于所述地理数据库中的不匹配地理特征的匹配的地理特征取得的向所述不匹配地理特征指派地点的朝向投票。

17.根据权利要求16所述的索引，其中朝向投票包括多数投票、加权投票和线性长度投票。

18.根据权利要求14所述的索引，其中通常对于不与地理特征相关联的第一地点名称源，间接关联包括使用和与地理特征相关联的第二地点名称源匹配的交叉源地点名称，使得所述第一源中的每一地点名称继承与来自所述第二源的地理特征的关联。

19.根据权利要求1所述的索引，其进一步包括所述地点名称的主要标记，其中所述主要标记通过将所述地点名称标记化、规范化和优化以及将所述地点名称与任何重复或类似地点名称匹配中的一者或一者以上而确定。

20.根据权利要求19所述的索引，其中标记化包括将所述地点名称分解为标记或组成部分。

21.根据权利要求19所述的索引，其中所述主要标记包括适用于编索引的主体或主要组成部分。

22.根据权利要求20所述的索引，其中除所述主要标记以外，标记包括前导方向标记、前导类型标记、在主体之前的前名称或非类型信息、前缀、结尾类型、结尾方向、后缀、指定所述地点的拆分的数字识别符，和修饰或附近的容易辨别的城市名称中的一者或一者以上。

23.根据权利要求19所述的索引，其中规范化包括扩展缩写、减少标点、去除内嵌空格和规范化大写中的一者或一者以上。

24.根据权利要求19所述的索引，其中优化包括将所述地点名称与所述地点中包含的地理特征相关联。

25.根据权利要求19所述的索引，其中将所述地点名称与任何重复或稍许不同地点名称匹配包括连接地点名称标记，和将所述地点名称的标记与任何重复或类似地点名称的所述标记进行比较以确定匹配。

26.根据权利要求19所述的索引，其中将所述地点名称与任何重复或稍许不同地点名称匹配包括基于所述名称的语音表示或依据其它方式来匹配所述名称。

27.根据权利要求26所述的索引，其中匹配进一步包括将来自所述优化步骤的所述地点名称的地理特征与任何重复或稍许不同地点名称进行比较以确定这些地点是否重叠或邻近。

28.根据权利要求27所述的索引，其中如果所述地点名称和任何重复或稍许不同地点名称的所有所述地理特征匹配，那么这些地点名称表示相同地点，且从所述索引中消除除了一个地点名称外的重复地点名称。

29.根据权利要求27所述的索引，其中如果所述地点和任何重复或类似地点的一个或一个以上但并非所有的所述地理特征匹配，那么认为这些地点名称表示相同地点且在所述索引中合并为一个地点名称。

30.根据权利要求29所述的索引，其中来自重叠或邻近的地点的所有地理特征的联合与所述合并的地点名称相关联。

31.根据权利要求27所述的索引，如果所述地点和任何重复或类似地点的所述地理特征均不匹配，则所述索引进一步包括所产生的创建和存储在所述索引中的对于不相交地点的附近、众所周知的城市的修饰。

32.根据权利要求1所述的索引，其进一步包括地理特征识别号码、地点识别号码、地点市中心纬度和经度点、地点修饰、地点的全名和地点的大小中的一者或一者以上。

33.根据权利要求1所述的索引，其中所述索引是自动创建的。

34.一种为地点编索引的方法，其包括以下步骤：

接收对来自地理数据库的一个或一个以上地理特征的选择；

确定来自一组一个或一个以上地点名称源的一组一个或一个以上地点名称；

将所述地点名称与所述地理数据库的所述地理特征相关联；

对于每一地理特征，以针对既定应用程序的普通使用中的流行性为次序对所述相关联的地点名称区分优先次序；以及

依据优先权对与每一地理特征相关联的所述地点名称进行排序。

35.一种包含使用户能够存取地点和所述地点内的地理特征的功能性的***，其包括：

地理数据库索引，其具有地理数据库中的至少一个地理特征和与所述至少一个地理特征相关联的一组一个或一个以上地点名称，其中所述一个或一个以上地点名称选自一个或一个以上地点名称源并依据基于所述地点名称在针对既定应用程序的普通使用中的流行性的优先权进行排序；以及

应用程序，其结合向用户显示地点和地理特征信息并结合接收来自用户的输入而使用所述地理数据库索引。

36.根据权利要求35所述的***，其中地点和地理特征信息的所述显示包括以下中的一者或一者以上：向用户以文本显示地点和地理特征信息、向所述用户在地图上显示地理特征的位置，以及向所述用户在地图上显示路线安排信息。

37.根据权利要求35所述的***，其中所述***包括基于因特网的***。

38.根据权利要求35所述的***，其中所述***包括车载导航***。

39.一种包含使用户能够存取地点和所述地点内的地理特征的功能性的便携式手持式装置，其包括：

地理数据库索引，其具有地理数据库中的至少一个地理特征和与所述至少一个地理特征相关联的一组一个或一个以上地点名称，其中所述一个或一个以上地点名称选自一个或一个以上地点名称源并依据基于所述地点名称在针对既定应用程序的普通使用中的流行性的优先权进行排序；以及

应用程序，其结合向用户显示地点和地理特征信息并结合接收来自用户的输入而使用所述地理数据库索引。

40.根据权利要求39所述的便携式手持式装置，其中地点和地理特征信息的所述显示包括以下中的一者或一者以上：向用户以文本显示地点和地理特征信息、向所述用户在地图上显示地理特征的位置，以及向所述用户在地图上显示路线安排信息。

41.根据权利要求39所述的便携式手持式装置，其中所述便携式手持式装置包括个人数字助理(PDA)。

42.根据权利要求39所述的便携式手持式装置，其中所述便携式手持式装置包括个人导航***。

43.根据权利要求39所述的便携式手持式装置，其中所述便携式手持式装置包括手机。

44.一种包含使用户能够存取地点和所述地点内的地理特征的功能性的基于地理信息***(GIS)的应用程序，其包括：

地理数据库索引，其具有地理数据库中的至少一个地理特征和与所述至少一个地理特征相关联的一组一个或一个以上地点名称，其中所述一个或一个以上地点名称选自一个或一个以上地点名称源并依据基于所述地点名称在针对既定应用程序的普通使用中的流行性的优先权进行排序。

45.一种机器可读媒体，其包含存储在其上的操作，所述操作当由一个或一个以上处理器处理时，致使***执行以下步骤：

接收对来自地理数据库的地理特征的选择；

确定来自一组一个或一个以上地点名称源的一组一个或一个以上地点名称；

将所述地点名称与来自所述地理数据库的所述地理特征相关联；

对于每一地理特征，以针对既定应用程序的普通使用中的流行性为次序对所述相关联的地点名称区分优先次序；以及

依据优先权对与每一地理特征相关联的所述地点名称进行排序。

Images