一种地图查询请求处理方法及装置

1.一种地图查询请求处理方法，其特征在于，该方法包括：
接收查询请求，对查询请求文本进行分词，得到N个分词单元；
利用前i个分词单元构成查询子串，包括，根据预设的词典，识别前i个分词单元中的地名文本；利用未识别出的分词单元，构成查询子串；或，根据预设的词典，识别前i个分词单元中不具有空间意义的文本；利用未识别出的分词单元，构成查询子串；其中i＝1，2，
3...N-1；
在地图数据中，查询与所述查询子串文本相匹配的结果；
根据查询结果的位置信息，确定所述查询子串对应的位置区域；
在所确定的位置区域中，查询与第N个分词单元文本相匹配的结果，用于响应所述查询请求。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
接收查询请求后，判断查询请求的文本长度是否大于预设阈值，如果是，则进一步对查询请求文本进行分词。
3.根据权利要求1所述的方法，其特征在于，所述利用前i个分词单元构成查询子串，包括：
判断相邻分词单元的共现率是否大于预设的阈值，如果是，则先对相应的分词单元进行合并处理后，再构成查询子串。
4.根据权利要求1所述的方法，其特征在于，根据查询结果的位置信息，确定所述查询子串对应的位置区域，包括：
根据多个查询结果位置的空间分布，得到查询结果的聚集区域，将该聚集区域确定为所述查询子串对应的位置区域；
其中，所述聚集区域满足：
该聚集区域中所包含的查询结果比例达到预设的阈值，以及
该聚集区域的大小不超过预设的阈值。
5.根据权利要求1所述的方法，其特征在于，该方法还包括：
在确定所述查询子串对应的位置区域后，对该查询子串的相关信息进行存储。
6.一种地图查询请求处理装置，其特征在于，该装置包括：
分词模块，用于接收查询请求，对查询请求文本进行分词，得到N个分词单元；
查询子串构建模块，用于利用前i个分词单元构成查询子串，包括，根据预设的词典，识别前i个分词单元中的地名文本；利用未识别出的分词单元，构成查询子串；或，根据预设的词典，识别前i个分词单元中不具有空间意义的文本；利用未识别出的分词单元，构成查询子串；其中i＝1，2，3...N-1；
第一查询模块，用于在地图数据中，查询与所述查询子串文本相匹配的结果；
区域确定模块，用于根据查询结果的位置信息，确定所述查询子串对应的位置区域；
第二查询模块，用于在所确定的位置区域中，查询与第N个分词单元文本相匹配的结果，用于响应所述查询请求。
7.根据权利要求6所述的装置，其特征在于，所述分词模块，具体用于：
接收查询请求后，判断查询请求的文本长度是否大于预设阈值，如果是，则进一步对查询请求文本进行分词。
8.根据权利要求6所述的装置，其特征在于，所述查询子串构建模块，具体用于：
判断相邻分词单元的共现率是否大于预设的阈值，如果是，则先对相应的分词单元进行合并处理后，再构成查询子串。
9.根据权利要求6所述的装置，其特征在于，所述区域确定模块，具体用于：
根据多个查询结果位置的空间分布，得到查询结果的聚集区域，将该聚集区域确定为所述查询子串对应的位置区域；
其中，所述聚集区域满足：
该聚集区域中所包含的查询结果比例达到预设的阈值，以及
该聚集区域的大小不超过预设的阈值。
10.根据权利要求6所述的装置，其特征在于，该装置还包括：
存储模块，用于在确定所述查询子串对应的位置区域后，对该查询子串的相关信息进行存储。

一种地图查询请求处理方法及装置\n技术领域\n[0001] 本发明涉及电子地图技术领域，特别是涉及一种地图查询请求处理方法及装置。\n背景技术\n[0002] 电子地图，也称数字地图，是利用计算机技术，以数字方式存储和查询的地图。利用计算机的数据处理能力，电子地图可以实现更为快速的位置信息查询，方便用户使用。\n[0003] 对于用户的位置查询请求，最基本的处理方式是直接根据用户输入的文本，在地图数据库检索与该文本内容匹配的内容，例如兴趣点、道路等等。这种方式实际与普通的文本信息检索相同，然而对于地图查询而言，却并不一定适用，例如，用户输入的查询请求是“海淀区工商银行”，目的是要找位于海淀区工商银行，而并非要找名为“海淀区工商银行”的地点，因此使用文本匹配的查询方式，往往难以得到符合用户需求的结果。\n[0004] 针对上述问题，现有技术提供的一种改进方案是，利用预先构建的地址数据库，能够识别出“海淀区”是具有某种空间含义的，进而可以根据所识别出的地名，在地图上先定位出相应区域，然后在该区域范围内进一步搜索“工商银行”。与纯文本匹配的查询方式相比，结合空间信息进行查询显然更符合用户的需求，但是这种方式的实现，需要依赖于地址数据库的完备性，如果用户的查询请求中包含了地名词典中未覆盖的地名，那么这部分会被当做一般文本进行处理，仍然难以得到符合需求的查询结果。\n发明内容\n[0005] 为解决上述技术问题，本发明提供一种地图查询请求处理方法及装置，[0006] 技术方案如下：\n[0007] 本发明实施例提供一种地图查询请求处理方法，该方法包括：\n[0008] 接收查询请求，对查询请求文本进行分词，得到N个分词单元；\n[0009] 利用前i个分词单元构成查询子串，其中i=1,2,3…N-1；\n[0010] 在地图数据中，查询与所述查询子串文本相匹配的结果；\n[0011] 根据查询结果的位置信息，确定所述查询子串对应的位置区域；\n[0012] 在所确定的位置区域中，查询与第N个分词单元文本相匹配的结果，用于响应所述查询请求。\n[0013] 根据本发明的一种具体实施方式，所述方法还包括：\n[0014] 接收查询请求后，判断查询请求的文本长度是否大于预设阈值，如果是，则进一步对查询请求文本进行分词。\n[0015] 根据本发明的一种具体实施方式，所述利用前i个分词单元构成查询子串，包括：\n[0016] 根据预设的词典，识别分词单元中的地名文本；\n[0017] 利用未识别出的分词单元，构成查询子串。\n[0018] 根据本发明的一种具体实施方式，所述利用前i个分词单元构成查询子串，包括：\n[0019] 根据预设的词典，识别分词单元中不具有空间意义的文本；\n[0020] 利用未识别出的分词单元，构成查询子串。\n[0021] 根据本发明的一种具体实施方式，所述利用前i个分词单元构成查询子串，包括：\n[0022] 判断相邻分词单元的共现率是否大于预设的阈值，如果是，则先对相应的分词单元进行合并处理后，再构成查询子串。\n[0023] 根据本发明的一种具体实施方式，根据查询结果的位置信息，确定所述查询子串对应的位置区域，包括：\n[0024] 根据多个查询结果位置的空间分布，得到查询结果的聚集区域，将该聚集区域确定为所述查询子串对应的位置区域；\n[0025] 其中，所述聚集区域满足：\n[0026] 该聚集区域中所包含的查询结果比例达到预设的阈值，以及\n[0027] 该聚集区域的大小不超过预设的阈值。\n[0028] 根据本发明的一种具体实施方式，该方法还包括：\n[0029] 在确定所述查询子串对应的位置区域后，对该查询子串的相关信息进行存储。\n[0030] 本发明实施例还提供一种地图查询请求处理装置，该装置包括：\n[0031] 分词模块，用于接收查询请求，对查询请求文本进行分词，得到N个分词单元；\n[0032] 查询子串构建模块，用于利用前i个分词单元构成查询子串，其中i=1,2,3…N-1；\n[0033] 第一查询模块，用于在地图数据中，查询与所述查询子串文本相匹配的结果；\n[0034] 区域确定模块，用于根据查询结果的位置信息，确定所述查询子串对应的位置区域；\n[0035] 第二查询模块，用于在所确定的位置区域中，查询与第N个分词单元文本相匹配的结果，用于响应所述查询请求。\n[0036] 根据本发明的一种具体实施方式，所述分词模块，具体用于：\n[0037] 接收查询请求后，判断查询请求的文本长度是否大于预设阈值，如果是，则进一步对查询请求文本进行分词。\n[0038] 根据本发明的一种具体实施方式，所述查询子串构建模块，具体用于：\n[0039] 根据预设的词典，识别分词单元中的地名文本；\n[0040] 利用未识别出的分词单元，构成查询子串。\n[0041] 根据本发明的一种具体实施方式，所述查询子串构建模块，具体用于：\n[0042] 根据预设的词典，识别分词单元中不具有空间意义的文本；\n[0043] 利用未识别出的分词单元，构成查询子串。\n[0044] 根据本发明的一种具体实施方式，所述查询子串构建模块，具体用于：\n[0045] 判断相邻分词单元的共现率是否大于预设的阈值，如果是，则先对相应的分词单元进行合并处理后，再构成查询子串。\n[0046] 根据本发明的一种具体实施方式，所述区域确定模块，具体用于：\n[0047] 根据多个查询结果位置的空间分布，得到查询结果的聚集区域，将该聚集区域确定为所述查询子串对应的位置区域；\n[0048] 其中，所述聚集区域满足：\n[0049] 该聚集区域中所包含的查询结果比例达到预设的阈值，以及\n[0050] 该聚集区域的大小不超过预设的阈值。\n[0051] 根据本发明的一种具体实施方式，该装置还包括：\n[0052] 存储模块，用于在确定所述查询子串对应的位置区域后，对该查询子串的相关信息进行存储。\n[0053] 本发明实施例所提供的技术方案，对于查询请求中包含无法识别地名的情况，首先利用该地名文本进行查询，然后根据多个查询结果的位置分布，确定出该未知地名所对应的位置区域，最后在该位置区域再次进行搜索，从而得到最终的查询结果。与现有技术相比，本发明方案能够根据查询结果位置分布来实现对未知地名的识别，从而减小地址词典对查询结果的影响，提升查询结果的召回率。另一方面，对于能够确定位置区域的未知地名，可以将该地名反过来加入地名词典，从而不断丰富地名词典的收录内容，使得地图系统的查询性能得到持续提升。\n附图说明\n[0054] 为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。\n[0055] 图1为本发明实施例地图查询请求处理方法的一种流程图；\n[0056] 图2a-图2h为本发明实施例确定未知地名区域的示意图；\n[0057] 图3为本发明实施例地图查询请求处理装置的一种结构示意图；\n[0058] 图4为本发明实施例地图查询请求处理装置的另一种结构示意图。\n具体实施方式\n[0059] 根据现有技术，如果在用户的地图查询请求中包含了具有空间含义的内容，并且地图系统可以根据地名词典识别出这些内容，那么就可以在相应的空间范围内进行搜索。\n例如用户搜索“海淀区工商银行”，系统可以根据地名词典，识别出“海淀区”并且在地图上定位出相应区域，然后然后在该区域范围内进一步搜索“工商银行”。\n[0060] 如果用户的查询请求中包含了地名词典中未覆盖的地名，例如对于查询请求“中关村工商银行”，用户的目的可能是要找位于“中关村”区域内的工商银行，但是在地名词典中并没有收录“中关村”，那么“中关村”仍然会被当做一般文本进行处理，只有在目标数据的名称信息或者地址信息文本中同时包含“中关村”+“工商银行”的情况下，该数据才会作为查询结果被召回。\n[0061] 针对上述问题，本发明实施例提供一种地图查询请求处理方法，该方法可以包括以下步骤：\n[0062] 接收查询请求，对查询请求文本进行分词，得到N个分词单元；\n[0063] 利用前i个分词单元构成查询子串，其中i=1,2,3…N-1；\n[0064] 在地图数据中，查询与所述查询子串文本相匹配的结果；\n[0065] 根据查询结果的位置信息，确定所述查询子串对应的位置区域；\n[0066] 在所确定的位置区域中，查询与第N个分词单元文本相匹配的结果，用于响应所述查询请求。\n[0067] 本发明实施例所提供上述方法，对于查询请求中包含无法识别地名的情况，首先利用该地名文本进行查询，然后根据多个查询结果的位置分布，确定出该未知地名所对应的位置区域，最后在该位置区域再次进行搜索，从而得到最终的查询结果。与现有技术相比，本发明方案能够根据查询结果位置分布来实现对未知地名的识别，从而减小地址词典对查询结果的影响，提升查询结果的召回率。另一方面，对于能够确定位置区域的未知地名，可以将该地名反过来加入地名词典，从而不断丰富地名词典的收录内容，使得地图系统的查询性能得到持续提升。\n[0068] 为了使本领域技术人员更好地理解本发明中的技术方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本发明保护的范围。\n[0069] 图1所示，为本发明实施一种地图查询请求处理方法的流程示意图，该方法可以包括以下步骤：\n[0070] S101，接收查询请求，对查询请求文本进行分词，得到N个分词单元；\n[0071] 当用户需要获得某个地点的地理位置或其他信息时，可以将该点的描述文本作为查询请求输入电子地图的查询接口，在本发明实施例中，对于用户输入或以其他形式输入的的地图查询请求，首先进行分词处理，将查询请求文本分为若干个分词单元。\n[0072] 在本发明的一种优选实施方式中，可以先对查询请求的文本长度进行检测，判断是否大于某个预设的阈值，如果是，再进一步进行分词处理及后续的操作。如果查询请求文本过短，一方面可能无法进一步分词，另一方面，即便拆分成功，得到的分词单元也难以独立表明查询意图，这种情况下，可以不做进一步处理。\n[0073] S102，利用前i个分词单元构成查询子串，其中i=1,2,3…N-1；\n[0074] 根据用户的习惯，所输入的地图查询请求一般由两部分组成，即“where+what”的形式，其中：\n[0075] a）对查询对象位置的描述，简称where；\n[0076] b）对查询对象名称的描述，简称what；\n[0077] 例如“海淀区工商银行”，表示用户想找“海淀区”附近的“工商银行”、“北京市中关村肯德基”表示用户想找要“北京市中关村”附近的“肯德基”，等等。\n[0078] 通过对大量查询请求的文本构成进行研究，可以发现以下规律：对于一个连续形式的查询文本串，用于描述位置的词（where）位于一般位于前面，用于描述名称的词则多位于后面；另外“where”可能对应多个具有独立意义的词，例如“北京市+中关村”，而“what”则一般仅对应一个词。\n[0079] 根据上述规律，对于经分词得到的N个分词单元，可以默认将最后一个分词单元当做“what”进行处理，前N-1个分词单元则当做“where”进行处理。在本发明实施例中，对于“where”部分，利用前N-1个分词单元构成一个或多个查询子串，然后利用该查询子串进行文本搜索。\n[0080] 最简单的处理方式，是不对where部分做任何处理，直接将前N-1个分词单元作为查询子串。在本发明的其他实施例中，为了优化查询结果，还可以采用其他方式生成查询子串，以下进行详细说明：\n[0081] 对于分词结果中的前i（i=1,2,3…N-1）个分词单元，可以按照从前到后的顺序进行组合，形成可能的地名文本候选，例如“北京市/海淀区/中关村”（其中斜线表示分词结果），可以分别构成以下形式：\n[0082] 北京市\n[0083] 北京市海淀区\n[0084] 北京市海淀区中关村\n[0085] 假设当前地名词典中包含“北京市”和“海淀区”，那么理论上，上面三种形式都可以作为查询子串输入查询系统，但是针对本发明的实际情况，在“北京市”或“北京市海淀区”范围进行搜索，实际意义并不大。因此，在本发明的一种实施方式中，可以根据地名词典先对分词单元进行识别，然后滤除识别出的地名文本，仅利用剩下的部分构成查询子串。例如上面构成的三种子串，分别滤除“北京市”及“海淀区”后，仅剩下“中关村”[0086] 在本发明的另一种实施方式中，还可以将查询子串中明显不具有空间意义的文本滤除，从而避免对后续查询结果的干扰。常见滤除对象包括：\n[0087] 停用词，例如“的”、“是”等等；\n[0088] 经营范围词，例如“小吃”、“旅游”、“餐饮”等等；\n[0089] 地名后缀，例如“酒店”、“餐馆”等等。\n[0090] 这里同样可以采用预设词典的方式，对不具有空间意义的文本进行过滤，当然，本领域技术人员可以根据实际需求设置词典的具体内容，以上提到的几种类型不应该理解为对本发明技术方案的限定。\n[0091] 在本发明的另一种实施方式中，还可以根据文本的上下文关系，对查询子串的内容做进一步优化。由于分词结果并不一定和实际的位置描述或名称描述完全一致，因此，可以先利用文本在地图领域的上下文关系，对分词结果进行重新组合后再进行处理，具体方式是：先判断相邻分词单元的共现率是否大于某个预设的阈值，如果是，则先对相应的分词单元进行合并处理，然后利用合并后的分词结果构建查询子串。\n[0092] 其中，词的共现率也成为紧密度，用于衡量两个词在各种文本中邻接出现频率，是一种统计结果，也可以通过语言模型概率计算得到，这里对于共现率的计算方法不再详细说明。总之，如果两个词在地图相关领域的共现率较高，说明二者很可能是一个整体，例如对于“工商银行”而言，如果将“工商”和“银行”两个词看做两个分词单元处理，就可能会产生歧义。根据本发明方案，“工商”不应该属于“where”部分，而是应该和“银行”一起构成“what”部分。\n[0093] 当然，可以理解的是，在实际应用中，这部分处理也可以在分词阶段实现。也就是说，分词系统本身也可以根据地图系统的应用需求，将“工商银行”等类似内容识别为一个整体，避免过细的拆分对后续的查询结果造成影响。\n[0094] 以上介绍了几种生成查询子串的具体改进方法，根据实际需求，这些方法可以分别单独使用，也可以结合使用，本发明对此并不需要进行限定。\n[0095] S103，在地图数据中，查询与所述查询子串文本相匹配的结果；\n[0096] 对于所构成的一个或多个查询子串，将这些查询子串的文本作为查询条件，进行基于文本匹配的检索。由于查询子串的内容少于原始的查询请求，也就是说在匹配条件上更为宽松，因此能够得到更多的匹配结果。\n[0097] 例如原始查询请求文本为“中关村肯德基”，如果基于文本匹配检索，那么只有在目标数据的名称信息或者地址信息文本中同时包含“中关村”+“肯德基”的情况下，该数据才会作为查询结果被召回。而根据本发明实施例，处理后得到的查询子串为“中关村”，仅对“中关村”进行基于文本匹配的检索，可以得到大量的结果，这些地点可能是名称匹配，例如“中关村地铁站”、“中关村大厦”、也可能是地址匹配，例如“中关村大街x号”、“中关村南路x号”等等。\n[0098] S104，根据查询结果的位置信息，确定所述查询子串对应的位置区域；\n[0099] 根据本发明实施例，由于查询子串对应的是“where”部分，因此在成功匹配到的查询结果中，会有很大比例是在位置上与“where”空间相关的。也就是说，查询子串对应的查询结果应该在空间上具有一定的聚合性。例如“中关村大厦”、“中关村大街x号”等等，都是位于“中关村”地区附近的地点。\n[0100] 基于上述情况，可以根据每个查询结果所处的位置，求出一个位置点空间相对集中的区域，从而得到查询子串所对应的位置区域，即“where”所对应的区域。\n[0101] 具体而言，由于是在地图数据中进行查询，因此查询结果中都应该包括位置信息，例如经纬度等等。首先分别获取每个查询结果的位置信息，然后可以这些位置点在空间上进行聚类，如果可以得到一个相对集中的区域，即可以将其确定为与“where”所对应的区域。\n[0102] 其中，空间位置点在空间的算法可以有多种方式实现，在本发明实施例中并不需要对这部分进行详细介绍。但是，结合具体的应用需求，可以从整体策略上进行限定，例如：\n一种典型的聚类策略如下：\n[0103] a1）聚集区域中所包含的查询结果比例达到某个预设的阈值，例如70%、80%等等[0104] b1）聚集区域的大小不超过预设的阈值。\n[0105] 也是就说，如果结果比较多，但是空间分布都比较分散，这种情况无法确定出聚集区域。\n[0106] 当然，上述策略并不是唯一的限制方式，本领域技术人员根据实际需求，还可以制订其他策略，例如，有些地名可能对应多个实际区域，比如北京地区可以找到两个“四道口”，针对这种情况，可以增加以下策略：\n[0107] a2）存在两个聚集区域，且每个聚集区域中所包含的查询结果比例都达到某个预设的阈值，例如35%、40%等等。\n[0108] b2）聚集区域的大小不超过预设的阈值。\n[0109] 利用这种策略，就可以定位出两个名称为“where”的区域，后续可以在这两个区域分别进行查询。\n[0110] 可以理解的是，理论上还可以继续增加类似的策略，实现对三个、四个地点重名情况的识别，但是在实际应用中，结果越分散，准确程度也越难以保证，因此本领域人员可以根据实际需求灵活设置各种确定聚集区域的策略，本发明实施例对此并不需要进行限制。\n[0111] S105，在所确定的位置区域中，查询与第N个分词单元文本相匹配的结果，用于响应所述查询请求。\n[0112] 根据前面的方案，已经确定了未知地名“where”所对应的区域，进一步在该区域范围内，对“what”部分，进行基于文本匹配的查询，得到的结果就是对应最初查询请求的结果。\n[0113] 例如，原始查询请求文本为“中关村肯德基”，由于“中关村”并不在地名词典中，因此无法直接确定“中关村”所对应的区域，根据本发明实施例，利用“中关村”进行文本查询，可以找到若干类似“中关村大厦”、“中关村大街x号”的地点数据，通过对这些结果的位置分布进行综合处理，可以大致圈定出“中关村”所对应的区域，最后在所圈定出的区域中搜索“肯德基”，就可以得到符合原始查询请求的结果。\n[0114] 可以理解的是，本发明提供的地图查询请求处理方法，本身可以独立使用，也可以与其他的查询请求处理方法结合使用，例如：\n[0115] 将利用本发明方案所得到的查询结果与利用纯文本方式的查询结果取并集，给出最终的查询结果；\n[0116] 判断纯文本方式是否能够命中结果，如果不能，再进一步采用本发明所提供的方案进行查询；\n[0117] 判断查询请求中的地名是否能够识别，如果不能，再进一步采用本发明所提供的方案进行查询；等等。\n[0118] 另外，根据本发明方案，对于能够确定出位置区域的未知地名，可以将该地名反过来加入地名词典，从而不断丰富地名词典的收录内容，使得地图系统的查询性能得到持续提升。\n[0119] 下面结合一个具体的实例，对本发明的方案进行说明：\n[0120] 假设用户输入的地图查询请求为“雁田工商银行”，该用户所在地为东莞市，其目的是想找“雁田村”附近的工商银行。根据现有技术，由于地址库里面没有收录“雁田”，所以无法识别出其“雁田”所代表的空间含义，从而将这两个词都当成what文本去检索，只有同时包含雁田和工商银行的点才会被召回。而根据本发明方案，处理过程如下：\n[0121] 根据S101，对“雁田工商银行”进行分词，得到两个分词单元分别为“雁田”和“工商银行”。其中“雁田”作为“where”候选，“工商银行”作为“what”候选。\n[0122] 根据S102，对“雁田工商银行”进行条件检查，然后构建查询子串。\n[0123] 首先，“雁田工商银行”大于5个字；\n[0124] 其次，“雁田”不属于停用词、经营范围词、后缀词等；\n[0125] 最后，“雁田”与后面“工商银行”的邻接共现频率小于预设的阈值0.5，因此与工商银行不大可能为专有名词\n[0126] 条件检查没有问题，构建内容为“雁田”的查询子串。后续步骤将对未知term“雁田”的空间范围进行挖掘。\n[0127] 根据S103，在东莞市下查询“雁田”，得到M个文本匹配的查询结果，例如“雁田水库”、“雁田农贸市场”、“雁田商业城”等等。\n[0128] 根据S104，进一步确定“雁田”对应的空间范围，在本实施例中，采用计算核心MBR（Minimum bounding rectangle，最小外包矩形）的算法，基本步骤如下：\n[0129] 1）根据地图数据的存储格式，将地图的xy坐标空间划分为若干面积相等的网格，然后把M个查询结果poi的坐标映射到网格中。例如网格大小为500m*500m、“雁田”所有的查询结果位置分布如图2a所示。\n[0130] 2）选择位置点最密集的网格作为起始网格。\n[0131] 图2b所示为所有查询结果在不同网格的数量分布情况，通过遍历所有的网格，找到点最多的网格所包含点数为4，设该网格为（x_c，y_c）。\n[0132] 3）以（x_c，y_c）为中心向四周扩展，选择附近最密集的网格方向扩展1格，形成较大的网格，如图2c所示\n[0133] 4）迭代执行第3）步迭代进行，直到满足以下任一条件为止：\n[0134] a）网格边长超过预设的阈值：在本实施例中设置阈值为10km。\n[0135] b)周边网格不可以继续扩展（不包含poi点）。\n[0136] 迭代过程可以参见图2d—图2g。\n[0137] 5）迭代停止时大网格的矩形就是核心MBR，最终确定的“雁田”对应区域如图2h所示。从图2h最终的结果中可以看出，超过80%的点位于挖掘的MBR内部，且MBR边长未超过\n10km，因此成功识别出“雁田”的空间范围。\n[0138] 根据S105，在上述MBR范围内搜索“工商银行”文本，将得到查询结果返回给用户。\n[0139] 进一步地，可以将“雁田”这个新识别的地名相关信息加入地址库，以便在后续处理查询请求的过程中可以直接使用。\n[0140] 相应于上面的方法实施例，本发明还提供一种地图查询请求处理装置，参见图3所示，该装置可以包括：分词模块110、查询子串构建模块120、第一查询模块130、区域确定模块140和第二查询模块150。\n[0141] 分词模块110，用于接收查询请求，对查询请求文本进行分词，得到N个分词单元；\n[0142] 当用户需要获得某个地点的地理位置或其他信息时，可以将该点的描述文本作为查询请求输入电子地图的查询接口，在本发明实施例中，对于用户输入或以其他形式输入的的地图查询请求，首先进行分词处理，将查询请求文本分为若干个分词单元。\n[0143] 在本发明的一种优选实施方式中，可以先对查询请求的文本长度进行检测，判断是否大于某个预设的阈值，如果是，再进一步进行分词处理及后续的操作。如果查询请求文本过短，一方面可能无法进一步分词，另一方面，即便拆分成功，得到的分词单元也难以独立表明查询意图，这种情况下，可以不做进一步处理。\n[0144] 查询子串构建模块120，用于利用前i个分词单元构成查询子串，其中i=1,2,3…N-\n1；\n[0145] 根据用户的习惯，所输入的地图查询请求一般由两部分组成，即“where+what”的形式，其中：\n[0146] a）对查询对象位置的描述，简称where；\n[0147] b）对查询对象名称的描述，简称what；\n[0148] 例如“海淀区工商银行”，表示用户想找“海淀区”附近的“工商银行”、“北京市中关村肯德基”表示用户想找要“北京市中关村”附近的“肯德基”，等等。\n[0149] 通过对大量查询请求的文本构成进行研究，可以发现以下规律：对于一个连续形式的查询文本串，用于描述位置的词（where）位于一般位于前面，用于描述名称的词则多位于后面；另外“where”可能对应多个具有独立意义的词，例如“北京市+中关村”，而“what”则一般仅对应一个词。\n[0150] 根据上述规律，对于经分词得到的N个分词单元，可以默认将最后一个分词单元当做“what”进行处理，前N-1个分词单元则当做“where”进行处理。在本发明实施例中，对于“where”部分，利用前N-1个分词单元构成一个或多个查询子串，然后利用该查询子串进行文本搜索。\n[0151] 最简单的处理方式，是不对where部分做任何处理，直接将前N-1个分词单元作为查询子串。在本发明的其他实施例中，为了优化查询结果，还可以采用其他方式生成查询子串，以下进行详细说明：\n[0152] 对于分词结果中的前i（i=1,2,3…N-1）个分词单元，可以按照从前到后的顺序进行组合，形成可能的地名文本候选。\n[0153] 在本发明的另一种实施方式中，还可以将查询子串中明显不具有空间意义的文本滤除，从而避免对后续查询结果的干扰。常见滤除对象包括：\n[0154] 停用词，例如“的”、“是”等等；\n[0155] 经营范围词，例如“小吃”、“旅游”、“餐饮”等等；\n[0156] 地名后缀，例如“酒店”、“餐馆”等等。\n[0157] 这里同样可以采用预设词典的方式，对不具有空间意义的文本进行过滤，当然，本领域技术人员可以根据实际需求设置词典的具体内容，以上提到的几种类型不应该理解为对本发明技术方案的限定。\n[0158] 在本发明的另一种实施方式中，还可以根据文本的上下文关系，对查询子串的内容做进一步优化。由于分词结果并不一定和实际的位置描述或名称描述完全一致，因此，可以先利用文本在地图领域的上下文关系，对分词结果进行重新组合后再进行处理，具体方式是：先判断相邻分词单元的共现率是否大于某个预设的阈值，如果是，则先对相应的分词单元进行合并处理，然后利用合并后的分词结果构建查询子串。\n[0159] 当然，可以理解的是，在实际应用中，这部分处理也可以在分词阶段实现。也就是说，分词系统本身也可以根据地图系统的应用需求，将“工商银行”等类似内容识别为一个整体，避免过细的拆分对后续的查询结果造成影响。\n[0160] 以上介绍了几种生成查询子串的具体改进方案，根据实际需求，这些方法可以分别单独使用，也可以结合使用，本发明对此并不需要进行限定。\n[0161] 第一查询模块130，用于在地图数据中，查询与所述查询子串文本相匹配的结果；\n[0162] 对于所构成的一个或多个查询子串，将这些查询子串的文本作为查询条件，进行基于文本匹配的检索。由于查询子串的内容少于原始的查询请求，也就是说在匹配条件上更为宽松，因此能够得到更多的匹配结果。\n[0163] 例如原始查询请求文本为“中关村肯德基”，如果基于文本匹配检索，那么只有在目标数据的名称信息或者地址信息文本中同时包含“中关村”+“肯德基”的情况下，该数据才会作为查询结果被召回。而根据本发明实施例，处理后得到的查询子串为“中关村”，仅对“中关村”进行基于文本匹配的检索，可以得到大量的结果，这些地点可能是名称匹配，例如“中关村地铁站”、“中关村大厦”、也可能是地址匹配，例如“中关村大街x号”、“中关村南路x号”等等。\n[0164] 区域确定模块140，用于根据查询结果的位置信息，确定所述查询子串对应的位置区域；\n[0165] 根据本发明实施例，由于查询子串对应的是“where”部分，因此在成功匹配到的查询结果中，会有很大比例是在位置上与“where”空间相关的。也就是说，查询子串对应的查询结果应该在空间上具有一定的聚合性。例如“中关村大厦”、“中关村大街x号”等等，都是位于“中关村”地区附近的地点。\n[0166] 基于上述情况，可以根据每个查询结果所处的位置，求出一个位置点空间相对集中的区域，从而得到查询子串所对应的位置区域，即“where”所对应的区域。\n[0167] 具体而言，由于是在地图数据中进行查询，因此查询结果中都应该包括位置信息，例如经纬度等等。首先分别获取每个查询结果的位置信息，然后可以这些位置点在空间上进行聚类，如果可以得到一个相对集中的区域，即可以将其确定为与“where”所对应的区域。\n[0168] 其中，空间位置点在空间的算法可以有多种方式实现，在本发明实施例中并不需要对这部分进行详细介绍。但是，结合具体的应用需求，可以从整体策略上进行限定，例如：\n一种典型的聚类策略如下：\n[0169] a1）聚集区域中所包含的查询结果比例达到某个预设的阈值，例如70%、80%等等[0170] b1）聚集区域的大小不超过预设的阈值。\n[0171] 也是就说，如果结果比较多，但是空间分布都比较分散，这种情况无法确定出聚集区域。\n[0172] 当然，上述策略并不是唯一的限制方式，本领域技术人员根据实际需求，还可以制订其他策略，例如，有些地名可能对应多个实际区域，比如北京地区可以找到两个“四道口”，针对这种情况，可以增加以下策略：\n[0173] a2）存在两个聚集区域，且每个聚集区域中所包含的查询结果比例都达到某个预设的阈值，例如35%、40%等等。\n[0174] b2）聚集区域的大小不超过预设的阈值。\n[0175] 利用这种策略，就可以定位出两个名称为“where”的区域，后续可以在这两个区域分别进行查询。\n[0176] 可以理解的是，理论上还可以继续增加类似的策略，实现对三个、四个地点重名情况的识别，但是在实际应用中，结果越分散，准确程度也越难以保证，因此本领域人员可以根据实际需求灵活设置各种确定聚集区域的策略，本发明实施例对此并不需要进行限制。\n[0177] 第二查询模块150，用于在所确定的位置区域中，查询与第N个分词单元文本相匹配的结果，用于响应所述查询请求。\n[0178] 根据前面的方案，已经确定了未知地名“where”所对应的区域，进一步在该区域范围内，对“what”部分，进行基于文本匹配的查询，得到的结果就是对应最初查询请求的结果。\n[0179] 例如，原始查询请求文本为“中关村肯德基”，由于“中关村”并不在地名词典中，因此无法直接确定“中关村”所对应的区域，根据本发明实施例，利用“中关村”进行文本查询，可以找到若干类似“中关村大厦”、“中关村大街x号”的地点数据，通过对这些结果的位置分布进行综合处理，可以大致圈定出“中关村”所对应的区域，最后在所圈定出的区域中搜索“肯德基”，就可以得到符合原始查询请求的结果。\n[0180] 参见图4所示，本发明实施例所提供的地图查询请求处理装置，还可以进一步包括：\n[0181] 存储模块160，用于在确定所述查询子串对应的位置区域后，对该查询子串的相关信息进行存储。\n[0182] 根据本发明方案，对于能够确定出位置区域的未知地名，可以将该地名反过来加入地名词典，从而不断丰富地名词典的收录内容，使得地图系统的查询性能得到持续提升。\n[0183] 为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本发明时可以把各单元的功能在同一个或多个软件和/或硬件中实现。\n[0184] 通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例或者实施例的某些部分所述的方法。\n[0185] 本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。\n[0186] 以上所述仅是本发明的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。