餐馆或菜品评价方法、装置、服务器和计算机可读介质与流程

本公开涉及通信技术领域，具体涉及一种餐馆或菜品评价方法、装置、服务器和计算机可读介质。

背景技术：

在外出就餐或者订外卖的时候，一般都会查看餐馆或菜品的评价作为选择的参考，但是由于每个人的口味偏好不同，这就导致了评价只能反映餐馆或菜品的受欢迎程度，评价高的餐馆或菜品并不一定适合每个人，用户根据评价选择的餐馆或菜品不一定符合其口味偏好。

技术实现要素：

本公开针对现有技术中存在的上述不足，提供一种餐馆或菜品评价方法、装置、服务器和计算机可读介质。

第一方面，本公开实施例提供一种餐馆或菜品评价方法，所述方法包括：

接收餐馆或菜品查询请求；

确定发起所述餐馆或菜品查询请求的用户的口味偏好；

获取每个待评价的餐馆或菜品已获得的评价结果，并确定已做出评价的用户的口味偏好；

根据所述发起所述餐馆或菜品查询请求的用户的口味偏好和所述已做出评价的用户的口味偏好，为已获得的评价结果分配权重；

根据每个待评价的餐馆或菜品已获得的评价结果和相应的权重，确定每个待评价的餐馆或菜品的评价结果。

优选的，所述根据所述发起所述餐馆或菜品查询请求的用户的口味偏好和所述已做出评价的用户的口味偏好，为已获得的评价结果分配权重，具体包括：

判断已对待评价的餐馆或菜品做出评价的用户中是否存在与所述发起所述餐馆或菜品查询请求的用户的口味偏好一致的用户，若存在，则为所述口味偏好一致的用户的评价结果分配第一权重，并为与所述发起所述餐馆或菜品查询请求的用户的口味偏好不一致的用户的评价结果分配第二权重，其中，所述第一权重大于第二权重。

优选的，所述确定发起所述餐馆或菜品查询请求的用户的口味偏好，具体包括：根据发起所述餐馆或菜品查询请求的用户的用户信息或历史行为信息确定该用户的口味偏好。

优选的，所述根据发起所述餐馆或菜品查询请求的用户的用户信息或历史行为信息确定该用户的口味偏好，具体包括：

获取所述发起所述餐馆或菜品查询请求的用户的用户信息；

若获取到用户信息，则根据所述用户信息确定该用户的口味偏好；否则，获取该用户的历史行为信息，并根据所述历史行为信息确定该用户的口味偏好。

进一步的，所述根据每个待评价的餐馆或菜品已获得的评价结果和相应的权重，确定每个待评价的餐馆或菜品的评价结果之后，所述方法还包括：

向所述发起所述餐馆或菜品查询请求的用户反馈所述待评价的餐馆或菜品的评价结果；或者，对所述待评价的餐馆或菜品的评价结果排序，并向所述发起所述餐馆或菜品查询请求的用户反馈所述排序。

优选的，所述餐馆或菜品查询请求包括路线搜索请求，进一步的，在接收餐馆或菜品查询请求之后、获取每个待评价的餐馆或菜品已获得的评价结果之前，还包括：

根据所述路线搜索请求确定推荐路线，并确定所述推荐路线沿线的餐馆或者所述餐馆的菜品；其中，所述推荐路线沿线的餐馆为所述待评价的餐馆，所述推荐路线沿线的餐馆的菜品为所述待评价的菜品。

进一步的，根据所述路线搜索请求确定推荐路线之后、确定所述推荐路线沿线的餐馆或者所述餐馆的菜品之前，所述方法还包括：

获取所述路线搜索请求中携带的出发时间和出行方式信息；

根据所述推荐路线、所述出发时间和出行方式信息，计算到达目的地的时间；

判断所述到达目的地的时间是否在预设的时间段内；

所述确定所述推荐路线沿线的餐馆或者所述餐馆的菜品，具体包括：若所述到达目的地的时间在所述时间段内，则确定所述推荐路线沿线的餐馆或者所述餐馆的菜品。

另一方面，本公开实施例还提供一种餐馆或菜品评价装置，包括接收模块、第一确定模块、第一获取模块、第二确定模块、权重分配模块和评价模块；

所述接收模块用于，接收餐馆或菜品查询请求；

所述第一确定模块用于，确定发起所述餐馆或菜品查询请求的用户的口味偏好；

所述第一获取模块用于，获取每个待评价的餐馆或菜品已获得的评价结果；

所述第二确定模块用于，确定已做出评价的用户的口味偏好；

所述权重分配模块用于，根据所述发起所述餐馆或菜品查询请求的用户的口味偏好和所述已做出评价的用户的口味偏好，为已获得的评价结果分配权重；

所述评价模块用于，根据每个待评价的餐馆或菜品已获得的评价结果和相应的权重，确定每个待评价的餐馆或菜品的评价结果。

优选的，所述权重分配模块包括判断单元和分配单元，所述判断单元用于，判断已对待评价的餐馆或菜品做出评价的用户中是否存在与所述发起所述餐馆或菜品查询请求的用户的口味偏好一致的用户；

所述分配单元用于，当所述判断单元判断出已对待评价的餐馆或菜品做出评价的用户中存在与所述发起所述餐馆或菜品查询请求的用户的口味偏好一致的用户时，为所述口味偏好一致的用户的评价结果分配第一权重，并为与所述发起所述餐馆或菜品查询请求的用户的口味偏好不一致的用户的评价结果分配第二权重，其中，所述第一权重大于第二权重。

优选的，所述第一确定模块具体用于，根据发起所述餐馆或菜品查询请求的用户的用户信息或历史行为信息确定该用户的口味偏好。

优选的，所述第一确定模块包括第一获取单元、处理单元和第二获取单元；

所述第一获取单元用于，获取所述发起所述餐馆或菜品查询请求的用户的用户信息；

所述处理单元用于，当所述第一获取单元获取到用户信息时，根据所述用户信息确定该用户的口味偏好；当所述第一获取单元未获取到用户信息时，指示所述第二获取单元获取该用户的历史行为信息；以及，根据所述历史行为信息确定该用户的口味偏好。

进一步的，所述餐馆或菜品评价装置还包括反馈模块，所述反馈模块用于，向所述发起所述餐馆或菜品查询请求的用户反馈所述待评价的餐馆或菜品的评价结果；或者，对所述待评价的餐馆或菜品的评价结果排序，并向所述发起所述餐馆或菜品查询请求的用户反馈所述排序。

优选的，所述餐馆或菜品查询请求包括路线搜索请求，所述餐馆或菜品评价装置还包括路线推荐模块和第三确定模块；

所述路线推荐模块用于，在所述接收模块接收餐馆或菜品查询请求之后、所述第一获取模块获取每个待评价的餐馆或菜品已获得的评价结果之前，根据所述路线搜索请求确定推荐路线；

所述第三确定模块用于，确定所述推荐路线沿线的餐馆或者所述餐馆的菜品；其中，所述推荐路线沿线的餐馆为所述待评价的餐馆，所述推荐路线沿线的餐馆的菜品为所述待评价的菜品。

进一步的，所述餐馆或菜品评价装置还包括第二获取模块、计算模块和判断模块；

所述第二获取模块用于，在所述线路推荐模块根据所述路线搜索请求确定推荐路线之后、所述第三确定模块确定所述推荐路线沿线的餐馆或者所述餐馆的菜品之前，获取所述路线搜索请求中携带的出发时间和出行方式信息；

所述计算模块用于，根据所述推荐路线、所述出发时间和出行方式信息，计算到达目的地的时间；

所述判断模块用于，判断所述到达目的地的时间是否在预设的时间段内，当判断出所述到达目的地的时间在预设的时间段内时，指示所述第三确定模块确定所述推荐路线沿线的餐馆或者所述餐馆的菜品。

又一方面，本公开实施例还提供一种服务器，包括：

一个或多个处理器；

存储装置，其上存储有一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如前所述的餐馆或菜品评价方法。

再一方面，本公开实施例还提供一种计算机可读介质，其上存储有计算机程序，其中，所述程序被执行时实现如前所述的餐馆或菜品评价方法。

本公开的实施例，通过确定发起餐馆或菜品查询请求的用户的口味偏好，获取每个待评价的餐馆或菜品已获得的评价结果，并确定已做出评价的用户的口味偏好，根据发起餐馆或菜品查询请求的用户的口味偏好和已做出评价的用户的口味偏好，为每个待评价的餐馆或菜品已获得的评价结果分配权重，并根据已获得的评价结果和相应的权重，确定每个待评价的餐馆或菜品的评价结果；本公开可以针对查询用户的口味偏好，在已经获得评价结果的餐馆或菜品中，重新分配原有评价结果的权重，并以此为依据得到的待评价餐馆或菜品的评价结果，对于该用户来说更为客观、合理，便于查询用户选择出贴近其口味的餐馆或菜品；此外，当用户到外地查询当地美食时，不会受当地人口味的影响，选择出的餐馆或菜品相对符合自己的口味。

附图说明

图1为本公开一实施例提供的餐馆或菜品评价方法流程图；

图2为本公开一实施例提供的确定用户的口味偏好流程图；

图3为本公开一实施例提供的权重分配方法的流程图；

图4为本公开又一实施例提供的餐馆或菜品评价方法流程图；

图5为本公开再一实施例提供的确定待评价的餐馆或菜品的流程图；

图6为本公开另一实施例提供的确定待评价的餐馆或菜品的流程图；

图7为本公开一实施例提供的餐馆或菜品评价装置结构示意图；

图8为本公开实施例提供的权重分配模块结构示意图；

图9为本公开实施例提供的第一确定模块结构示意图；

图10为本公开又一实施例提供的餐馆或菜品评价装置结构示意图；

图11为本公开再一实施例提供的餐馆或菜品评价装置结构示意图；

图12为本公开另一实施例提供的餐馆或菜品评价装置结构示意图。

具体实施方式

为使本领域的技术人员更好地理解本发明的技术方案，下面结合附图对本发明提供的无人驾驶车辆控制器测试方案进行详细描述。

在下文中将参考附图更充分地描述示例实施例，但是所述示例实施例可以以不同形式来体现且不应当被解释为限于本文阐述的实施例。反之，提供这些实施例的目的在于使本公开透彻和完整，并将使本领域技术人员充分理解本公开的范围。

如本文所使用的，术语“和/或”包括一个或多个相关列举条目的任何和所有组合。

本文所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其他特征、整体、步骤、操作、元件、组件和/或其群组。

本文所述实施例可借助本公开的理想示意图而参考平面图和/或截面图进行描述。因此，可根据制造技术和/或容限来修改示例图示。因此，实施例不限于附图中所示的实施例，而是包括基于制造工艺而形成的配置的修改。因此，附图中例示的区具有示意性属性，并且图中所示区的形状例示了元件的区的具体形状，但并不旨在是限制性的。

除非另外限定，否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。

本公开的一个实施例提供一种餐馆或菜品评价方法，所述方法应用于餐馆或菜品评价装置，餐馆或菜品评价装置可以为云端服务器，例如，外卖网站的服务器、第三方平台服务器(如餐饮点评网站)等。

以下结合图1，对所述餐馆或菜品评价方法进行详细说明，如图1所示，该方法包括以下步骤：

步骤11，接收餐馆或菜品查询请求。

具体的，当用户想就餐时，可以利用终端向餐馆或菜品评价装置发送餐馆或菜品查询请求，所述餐馆或菜品查询请求中可以携带就餐位置信息。

步骤12，确定发起餐馆或菜品查询请求的用户的口味偏好。

具体的，可以根据用户信息或用户历史行为信息确定用户的口味偏好。优选的，用户信息可以包括家乡所在地信息或长期居住地信息。用户历史行为信息可以包括以下信息中的至少一个：曾经点餐的餐馆或菜品、曾经选择相同餐馆或菜品的次数。

所述根据用户信息或用户行为信息确定用户的口味偏好的具体实现方式，后续结合附图2再详细说明。

需要说明的是，在某些应用场景下，所述餐馆或菜品查询请求中可以携带用户的口味偏好信息，这样就可以根据所述餐馆或菜品查询请求直接确定该用户的口味偏好。例如，用户直接在餐饮点评网站上选择就餐地点范围以及菜品种类(如川菜、湘菜、粤菜等)。

步骤13，获取每个待评价的餐馆或菜品已获得的评价结果，并确定已做出评价的用户的口味偏好。

待评价的餐馆或菜品为餐馆或菜品查询请求携带的就餐位置信息范围内的餐馆及其菜品。

具体的，先获取每个待评价的餐馆或菜品已获得的评价结果，待评价的餐馆或菜品的评价结果可以是用户的评分，然后根据所述评价结果确定对所述餐馆或菜品做出所述评价的用户，再确定这些用户的口味偏好。确定对所述餐馆或菜品做出所述评价的用户的口味偏好的具体实现方式，与确定发起餐馆或菜品查询请求的用户的口味偏好的具体实现方式相同，即可以根据该用户的用户信息或用户历史行为信息确定该用户的口味偏好，在此不再赘述。

步骤14，根据发起所述餐馆或菜品查询请求的用户的口味偏好和已做出评价的用户的口味偏好，为已获得的评价结果分配权重。

在本公开实施例中，每个待评价的餐馆或菜品的评价结果具有不同的权重，权重的大小与做出评价的用户的口味偏好以及发起餐馆或菜品查询请求的用户的口味偏好相关。所述为已获得的评价结果分配权重的具体实现方式，后续结合附图3再详细说明。

步骤15，根据每个待评价的餐馆或菜品已获得的评价结果和相应的权重，确定每个待评价的餐馆或菜品的评价结果。

具体的，对所有做出评价的用户的评价结果进行加权平均，得到最终的评价结果。也就是说，针对一个待评价的餐馆或菜品来说，通过将已获得的各个评价结果和与其相应的权重相乘再求和，得到最终的对该待评价的餐馆或菜品的评价结果，这个评价结果即为针对发起餐馆或菜品查询请求的用户的所述待评价的餐馆或菜品的评价结果。

通过步骤11-15可以看出，本公开通过确定发起餐馆或菜品查询请求的用户的口味偏好，获取每个待评价的餐馆或菜品已获得的评价结果，并确定已做出评价的用户的口味偏好，根据发起餐馆或菜品查询请求的用户的口味偏好和已做出评价的用户的口味偏好，为每个待评价的餐馆或菜品已获得的评价结果分配权重，并根据已获得的评价结果和相应的权重，确定每个待评价的餐馆或菜品的评价结果；本公开可以针对查询用户的口味偏好，在已经获得评价结果的餐馆或菜品中，重新分配原有评价结果的权重，并以此为依据得到的待评价餐馆或菜品的评价结果，对于该用户来说更为客观、合理，便于查询用户选择出贴近其口味的餐馆或菜品；此外，当用户到外地查询当地美食时，不会受当地人口味的影响，选择出的餐馆或菜品相对符合自己的口味。

以下结合图2，对确定用户的口味偏好的流程进行详细说明。如图2所示，所述根据用户信息或用户行为信息确定用户的口味偏好的流程包括以下步骤：

步骤121，获取发起餐馆或菜品查询请求的用户的用户信息。

具体的，用户在注册时，会询问用户的家乡所在地信息或长期居住地信息，该项内容是非必填选项，如果用户提交家乡所在地信息或长期居住地信息，相应的，在本步骤中，餐馆或菜品评价装置即可获得上述用户信息。如果用户未提交家乡所在地信息或长期居住地信息，则在本步骤中，餐馆或菜品评价装置无法获得上述用户信息。

步骤122，若获取到用户信息，则执行步骤123，否则，执行步骤124。

具体的，如果获取到用户信息，则根据用户信息确定该用户的口味偏好；如果未获取到用户信息，则获取该用户的历史行为信息，并根据历史行为信息确定该用户的口味偏好。

步骤123，根据用户信息确定该用户的口味偏好。

具体的，根据用户的家乡所在地信息或长期居住地信息，推断其口味偏好信息，例如，若用户的家乡或长期居住地为湖南、贵州、四川等地，则认为该用户的口味偏好为辣口味；若用户的家乡或长期居住地为广东、福建等地，则认为该用户的口味偏好为清淡口味。

步骤124，获取该用户的历史行为信息。

具体的，如果无法根据用户的家乡、长期居住地确定其口味偏好，则需要通过该用户就餐的历史行为确定其口味偏好。

步骤125，根据历史行为信息确定该用户的口味偏好。

具体的，用户曾经点餐的餐馆或菜品，以及曾经选择相同餐馆或菜品的次数，可以在一定程度上反映出该用户的口味偏好，例如，用户曾经选择就餐餐厅主打的菜系、口味，以及用户曾经选择的菜品的口味，与用户的口味相对接近。用户曾经选择相同餐馆或菜品的次数，更是可以直接反映出用户对其的喜好程度。

通过步骤121-125可以看出，本公开优先通过用户信息直接确定用户口味偏好，这样确定出的用户口味偏好最为准确，当无法通过用户信息确定用户口味偏好时，可以基于大数据，根据用户历史行为推断该用户的口味偏好，在一定程度上也能够保证结果的准确性。

以下结合图3，详细说明为已获得的评价结果分配权重的流程，如图3所示，所述流程包括以下步骤：

步骤141，判断已对待评价的餐馆或菜品做出评价的用户中是否存在与发起餐馆或菜品查询请求的用户的口味偏好一致的用户，若存在，则执行步骤142，否则，执行步骤143。

步骤142，为口味偏好一致的用户的评价结果分配第一权重，并为与发起餐馆或菜品查询请求的用户的口味偏好不一致的用户的评价结果分配第二权重，其中，第一权重大于第二权重。

具体的，在已对待评价的餐馆或菜品做出评价的用户中，针对与发起餐馆或菜品查询请求的用户的口味偏好一致的用户，以及口味偏好不一致的用户，对其做出的评价结果分别设置不同的权重。也就是说，与发起餐馆或菜品查询请求的用户的口味偏好一致的用户，其对待评价的餐馆或菜品的评价结果对本次计算的评价结果的贡献程度大于口味偏好不一致的用户的评价结果的贡献程度。

步骤143，为各个已做出评价的用户的评价结果分配相同的权重。

若在已对待评价的餐馆或菜品做出评价的用户中，没有与发起餐馆或菜品查询请求的用户的口味偏好一致的用户，则各个已做出评价的用户的评价结果具有相同的权重，并通过加权平均方式计算本次评价结果。

进一步的，在本公开又一实施例中，如图4所示，在根据每个待评价的餐馆或菜品已获得的评价结果和相应的权重，确定每个待评价的餐馆或菜品的评价结果(即步骤15)之后，所述方法还包括以下步骤：

步骤16，向发起餐馆或菜品查询请求的用户反馈待评价的餐馆或菜品的评价结果；或者，对待评价的餐馆或菜品的评价结果排序，并向发起餐馆或菜品查询请求的用户反馈排序。

具体的，餐馆或菜品评价装置可以直接将各个待评价餐馆或菜品的评价结果反馈给用户，也可以先按照评价结果对各个待评价的餐馆或菜品进行排序，然后将排序反馈给用户，以供用户选择。

在本公开的再一实施例中，将餐馆或菜品评价与地图搜索路线的应用场景相结合，在用户请求搜索路线时，在为用户反馈推荐路线的基础上，为其提供推荐路线沿线的餐馆或菜品的评价结果，以方便其用餐。在这种情况下，用户发送的餐馆或菜品查询请求即为路线搜索请求。相应的，如图5所示，在接收餐馆或菜品查询请求(即步骤11)之后、获取每个待评价的餐馆或菜品已获得的评价结果(即步骤13)之前，还包括以下步骤：

步骤12’，根据路线搜索请求确定推荐路线。

确定推荐路线的具体实现方式属于现有技术，在此不再赘述。

步骤13’，确定推荐路线沿线的餐馆或者所述餐馆的菜品。

其中，推荐路线沿线的餐馆即为所述待评价的餐馆，推荐路线沿线的餐馆的菜品即为待评价的菜品。

进一步的，在本公开另一实施例中，并不是在确定出推荐路线之后就确定推荐路线沿线的餐馆或餐馆的菜品的评价结果，而是先判断用户是否有就餐的可能性，在有就餐的可能性时，才确定推荐路线沿线的餐馆或餐馆的菜品的评价结果。

相应的，如图6所示，根据路线搜索请求确定推荐路线(即步骤12’)之后、确定推荐路线沿线的餐馆或者所述餐馆的菜品(即步骤13’)之前，所述方法还可以包括以下步骤：

步骤21，获取路线搜索请求中携带的出发时间和出行方式信息。

出行方式包括：公交、地铁、出租车、自驾等。

步骤22，根据推荐路线、出发时间和出行方式信息，计算到达目的地的时间。

步骤23，判断到达目的地的时间是否在预设的时间段内，若是，则执行步骤13’，否则，结束流程。

具体的，预设的时间段为午饭或晚饭时段，例如，11:00-13:00、17:00-19:00，若到达目的地的时间在所述时间段内，认为用户就餐的可能性较大，则确定推荐路线沿线的餐馆或者所述餐馆的菜品；若到达目的地的时间不在所述时间段内，认为用户就餐的可能性较小，则无需再向用户提供推荐路线沿线的餐馆或者所述餐馆的菜品的评价结果，直接结束流程。

基于相同的技术构思，本公开实施例还提供一种餐馆或菜品评价装置，如图7所示，该餐馆或菜品评价装置包括：接收模块1、第一确定模块2、第一获取模块3、第二确定模块4、权重分配模块5和评价模块6。

接收模块1用于，接收餐馆或菜品查询请求。

第一确定模块2用于，确定发起所述餐馆或菜品查询请求的用户的口味偏好。

第一获取模块3用于，获取每个待评价的餐馆或菜品已获得的评价结果。

第二确定模块4用于，确定已做出评价的用户的口味偏好。

权重分配模块5用于，根据所述发起所述餐馆或菜品查询请求的用户的口味偏好和所述已做出评价的用户的口味偏好，为已获得的评价结果分配权重。

评价模块6用于，根据每个待评价的餐馆或菜品已获得的评价结果和相应的权重，确定每个待评价的餐馆或菜品的评价结果。

优选的，如图8所示，权重分配模块5包括判断单元51和分配单元52，判断单元51用于，判断已对待评价的餐馆或菜品做出评价的用户中是否存在与所述发起所述餐馆或菜品查询请求的用户的口味偏好一致的用户。

分配单元52用于，当判断单元51判断出已对待评价的餐馆或菜品做出评价的用户中存在与所述发起所述餐馆或菜品查询请求的用户的口味偏好一致的用户时，为所述口味偏好一致的用户的评价结果分配第一权重，并为与所述发起所述餐馆或菜品查询请求的用户的口味偏好不一致的用户的评价结果分配第二权重，其中，所述第一权重大于第二权重。

优选的，第一确定模块2具体用于，根据发起所述餐馆或菜品查询请求的用户的用户信息或历史行为信息确定该用户的口味偏好。

优选的，如图9所示，第一确定模块2包括第一获取单元21、处理单元22和第二获取单元23。

第一获取单元21用于，获取所述发起所述餐馆或菜品查询请求的用户的用户信息。

处理单元22用于，当第一获取单元21获取到用户信息时，根据所述用户信息确定该用户的口味偏好；当第一获取单元21未获取到用户信息时，指示第二获取单元22获取该用户的历史行为信息；以及，根据所述历史行为信息确定该用户的口味偏好。

在本公开又一实施例中，如图10所示，所述餐馆或菜品评价装置还可以包括反馈模块7，反馈模块7用于，向所述发起所述餐馆或菜品查询请求的用户反馈所述待评价的餐馆或菜品的评价结果；或者，对所述待评价的餐馆或菜品的评价结果排序，并向所述发起所述餐馆或菜品查询请求的用户反馈所述排序。

优选的，在本公开的再一实施例中，所述餐馆或菜品查询请求包括路线搜索请求，如图11所示，所述餐馆或菜品评价装置还可以包括路线推荐模块8和第三确定模块9。

路线推荐模块8用于，在接收模块1接收餐馆或菜品查询请求之后、第一获取模块3获取每个待评价的餐馆或菜品已获得的评价结果之前，根据所述路线搜索请求确定推荐路线。

第三确定模块9用于，确定所述推荐路线沿线的餐馆或者所述餐馆的菜品；其中，所述推荐路线沿线的餐馆为所述待评价的餐馆，所述推荐路线沿线的餐馆的菜品为所述待评价的菜品。

在本公开另一实施例中，如图12所示，所述餐馆或菜品评价装置还可以包括第二获取模块10、计算模块11和判断模块12。

第二获取模块10用于，在线路推荐模块8根据所述路线搜索请求确定推荐路线之后、第三确定模块9确定所述推荐路线沿线的餐馆或者所述餐馆的菜品之前，获取所述路线搜索请求中携带的出发时间和出行方式信息。

计算模块11用于，根据所述推荐路线、所述出发时间和出行方式信息，计算到达目的地的时间。

判断模块12用于，判断所述到达目的地的时间是否在预设的时间段内，当判断出所述到达目的地的时间在预设的时间段内时，指示第三确定模块9确定所述推荐路线沿线的餐馆或者所述餐馆的菜品。

本公开实施例还提供了一种服务器，该服务器包括：一个或多个处理器以及存储装置；其中，存储装置上存储有一个或多个程序，当上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个或多个处理器实现如前述各实施例所提供的自动驾驶车辆停车方法。

本公开实施例还提供了一种计算机可读介质，其上存储有计算机程序，其中，该计算机程序被执行时实现如前述各实施例所提供的自动驾驶车辆停车方法。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于ram、rom、eeprom、闪存或其他存储器技术、cd-rom、数字多功能盘(dvd)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其他实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本发明的范围的情况下，可进行各种形式和细节上的改变。