CN116433322A - 网约车订单处理方法、司机端、乘客端以及存储介质 - Google Patents

网约车订单处理方法、司机端、乘客端以及存储介质 Download PDF

Info

Publication number
CN116433322A
CN116433322A CN202310236022.7A CN202310236022A CN116433322A CN 116433322 A CN116433322 A CN 116433322A CN 202310236022 A CN202310236022 A CN 202310236022A CN 116433322 A CN116433322 A CN 116433322A
Authority
CN
China
Prior art keywords
order
passenger
driver
map
display
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310236022.7A
Other languages
English (en)
Inventor
苏小林
陈厚鑫
曾超
陶白镪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nanjing Leading Technology Co Ltd
Original Assignee
Nanjing Leading Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nanjing Leading Technology Co Ltd filed Critical Nanjing Leading Technology Co Ltd
Priority to CN202310236022.7A priority Critical patent/CN116433322A/zh
Publication of CN116433322A publication Critical patent/CN116433322A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0645—Rental transactions; Leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Tourism & Hospitality (AREA)
  • Development Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Navigation (AREA)

Abstract

本发明提供一种网约车订单处理方法、司机端、乘客端以及存储介质，涉及网约车技术领域，该方法包括：从多个订单中，选择展示订单；根据非展示订单中的信息，在与非展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，将导航中的司乘同显数据发送给非展示订单中的乘客端；根据多个订单中的信息，在与展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；将导航中的司乘同显数据发送给展示订单的乘客端。本发明实施例在司机端同时运行不同地图类型的地图，来专门提供每个乘客端的司乘同显数据，解决多个乘客端使用多种地图类型的地图时导致司乘无法正常进行司乘同显的问题。

Description

网约车订单处理方法、司机端、乘客端以及存储介质
技术领域
本发明涉及网约车技术领域，尤其涉及一种网约车订单处理方法、司机端、乘客端以及存储介质。
背景技术
现在的打车软件都需要依赖地图能力实现定位、起点、终点、途径点、绘制路线、覆盖物、导航、搜索等。为了能够更好的服务乘客和司机，地图服务商开发司乘同显功能，即司机位置，司机行驶路线，司机剩余里程与到达时间等信息会同步显示给乘客端。
一般相同的服务商开发出的地图软件能够实现乘客端和司机端之间的司乘同显等功能，然而，当出现拼车单、接力单、顺风车单等多乘客同坐的订单时，如果乘客使用不同的地图服务商提供的地图下单，会导致乘客端和司机端无法正常进行司乘同显。
发明内容
本发明提供一种网约车订单处理方法、司机端、乘客端及存储介质，能够针对多个乘客端的不同的地图类型，司机端同时运行不同地图类型的地图，来专门提供每个乘客端的司乘同显数据，解决多个乘客端使用多种地图类型的地图时导致司乘无法正常进行司乘同显的问题。
第一方面，本发明实施例提供一种网约车订单处理方法，应用于司机端，包括：
在处理至少一个第一订单时，若接收到的第二订单的类型为目标类型，且所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同，则从至少一个所述第一订单和所述第二订单中，选择第二展示订单；
若所述第二展示订单不为所述第二订单，且所述第二展示订单和第一展示订单相同，则根据所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；其中，所述第一展示订单为在接收到所述第二订单之前，从至少一个所述第一订单中选择出的第一订单；
根据至少一个所述第一订单和所述第二订单中的信息，在与所述第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单的乘客端。
上述方法，能够在司机端接到多个订单，且他们的地图类型不均相同或均不相同时，从多个订单中选择展示订单，对于非展示订单，则直接按照订单的信息进行导航，并控制其导航画面不显示，同时发送司乘同显数据给乘客端，对于展示订单，则根据多个订单的信息进行导航，同时将导航时的司乘同显数据发送给展示订单的乘客，这样针对不同的乘客端的不同地图类型，司机端单独进行司乘同显数据的供应，从而解决了当前多个乘客端使用多种地图类型的地图时导致司乘无法正常进行司乘同显的问题，提高了工作效率。
在一种可能实施的方式中，所述方法还包括：
若所述第二展示订单、所述第一展示订单均不所述第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同，则根据所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；
以及根据至少一个所述第一订单和所述第二订单中的信息，在所述第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单中的乘客端；
以及根据所述第一展示订单中的信息，在与所述第一展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第一展示订单中的乘客端；
若所述第二展示订单为所述第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同，则根据至少一个所述第一订单和所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；
以及根据所述第一展示订单中的信息，在与所述第一展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第一展示订单的乘客端。
上述方法，针对第二订单不是第二展示订单，第二展示订单和第一展示订单不相同时，司机端针对第二订单和第一展示订单，将他们的地图类型相同的地图类型对应的地图上进行导航，导航画面不显示，将导航的司乘同显数据发送他们的乘客，针对第二展示订单，则需要根据所有的订单制定导航，同时展示导航画面，将导航的司乘同显数据发送给对应的乘客；针对第二订单为第二展示订单，两个展示订单地图类型不相同时，多乘客的导航在第二订单的地图类型相同的地图类型对应的地图上进行导航，将导航的司乘同显数据进行发送，将以前展示订单，单独进行导航，并进行司乘同显，这样针对不同情况，不同地图类型的乘客均得到司乘同显数据，提高了工作效率。
在一种可能实施的方式中，从至少一个所述第一订单和所述第二订单中，选择第二展示订单，包括：
从至少一个所述第一订单和所述第二订单中，将多个目标地点中最先达到的目标地点所在的订单作为第二展示订单；其中，所述目标地点为至少一个所述第一订单和所述第二订单中司机未到达的地点。
上述方法，能够根据订单的最先达到地点确定展示订单，即从司机关心的行程出发进行路线展示，更加人性化，提高了工作的便捷度。
在一种可能实施的方式中，所述方法还包括：
接收乘客端发送的修改指令；
根据所述第二订单中的信息，在与修改指令中的优先地图类型相同的地图类型对应的地图上重新进行导航；并控制重新导航时的显示画面不进行显示，将重新导航中的司乘同显数据发送给所述第二订单中的乘客端。
上述方法，能够针对乘客端的地图类型的服务器故障导致无法提供地图服务时，能够通过修改指令修改地图类型进行导航，从而避免因为地图服务商故障而导致司乘无法正常进行司乘同显的情况。
第二方面，本发明实施例提供一种网约车订单处理方法，应用于乘客端，包括：
响应乘客发起的下单指令，将乘客提供的第二订单的信息以及所使用地图的地图类型发送给服务器，以使所述服务器将第二订单进行分配；
响应乘客发起的同意指令，针对每个预设间隔，若接收到的该预设间隔的司乘同显数据仅包含所述第二订单相应的司乘同显数据，则在乘客所使用地图上直接展示该预设间隔的司乘同显数据；
其中，所述第二订单相应的司乘同显数据为所述司机端在处理至少一个第一订单时，接收到的第二订单的类型为目标类型，所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同时，从至少一个所述第一订单和所述第二订单中，确定的第二展示订单非第二订单，且所述第二展示订单和第一展示订单相同后，根据所述第二订单的信息，在所述第二订单中乘客端的地图类型对应的地图上进行导航的数据。
在一种可能实施的方式中，所述方法还包括：
若接收到的该预设间隔的司乘同显数据中包括多个乘客的司乘同显数据，则从该预设间隔的司乘同显数据中挑选出所述第二订单相应的司乘同显数据，并在乘客所使用地图上展示挑选出的司乘同显数据；
其中，多个乘客的司乘同显数据为所述司机端在处理至少一个第一订单时，接收到的第二订单的类型为目标类型，所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同时，从至少一个第一订单和所述第二订单中，确定的第二展示订单为第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同后，根据至少一个所述第一订单和所述第二订单中的信息，在所述展示订单中乘客端的地图类型对应的地图上进行导航的数据。
在一种可能实施的方式中，从该预设间隔的司乘同显数据中挑选出所述第二订单相应的司乘同显数据，并在乘客所使用地图上展示挑选出的司乘同显数据，包括：
在乘客端的地图类型对应的地图上添加多个乘客的司乘同显数据，得到展示画面；
若该预设间隔的司乘同显数据为所述司机端第一次发送的司乘同显数据，则从该预设间隔的司乘同显数据中，提取与所述第二订单相应的第一司乘同显数据；在所述第二订单中乘客端的地图类型对应的地图上添加所述第一司乘同显数据，得到并展示所述展示画面；其中，所述第一司乘同显数据包括司机当前位置、根据第二订单的乘客的起/终点创建的导航路线；
若该预设间隔的司乘同显数据不为所述司机端第一次发送的司乘同显数据，则从该预设间隔的司乘同显数据中，提取与所述第二订单相应的第二司乘同显数据；根据所述第二司乘同显数据更新上一次展示画面，得到新的展示画面，并展示新的展示画面；其中，所述第二司乘同显数据包括司机当前位置、该预设间隔内司机所走的路线。
在一种可能实施的方式中，根据所述第二司乘同显数据更新上一次展示画面，得到新的展示画面，包括：
将所述第二司乘同显数据中的该预设时间段内司机所走的路线，从上一次展示画面的导航路线中剔除；
并将剔除后的上一次展示画面的导航路线的起点设置为所述第二司乘同显数据中的司机当前位置。
在一种可能实施的方式中，在乘客所使用地图上直接展示所述第二订单相应的司乘同显数据之后，所述方法还包括：
在满足预设条件之后，根据优先地图类型生成修改指令，将修改指令发送给司机端；其中，所述优先地图类型是从多种地图类型中选择的；
接收所述司机端发送的重新导航中的司乘同显数据；
在修改指令中的优先地图类型对应的地图上直接展示重新导航中的司乘同显数据；
其中，所述重新导航中的司乘同显数据是所述司机端在接收到乘客端发送的修改指令后，根据所述第二订单中的信息，在修改指令中的优先地图类型对应的地图上重新进行导航的数据。
第三方面，本发明实施例提供一种司机端，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如第一方面中任一项所述的网约车订单处理方法。
第四方面，本发明实施例提供一种乘客端，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如第二方面中任一项所述的网约车订单处理方法。
第五方面，本发明实施例提供一种存储介质，当所述存储介质中的指令由司机端的处理器执行时，使得所述司机端能够执行如第一方面中任一项所述的网约车订单处理方法；或者当所述存储介质中的指令由乘客端的处理器执行时，使得所述乘客端能够执行如第二方面中任一项所述的网约车订单处理方法。
另外，第二方面至第五方面中任一种实现方式所带来的技术效果可参见第一方面中不同实现方式所带来的技术效果，此处不再赘述。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。
附图说明
图1为本发明实施例提供的一种网约车交互系统的结构图；
图2为本发明实施例提供的一种网约车交互方法的流程图；
图3为本发明实施例提供的一种由多个乘客导航路线中提取单个乘客导航路线的示意图；
图4为本发明实施例提供的一种行程过程中乘客端的导航路线变化的示意图；
图5为本发明实施例提供的另一种网约车交互系统的结构图；
图6为本发明实施例提供的另一种网约车交互方法的流程图；
图7为本发明实施例提供的一种一个乘客下单到司机接单后的乘客页面的示意图；
图8为本发明实施例提供的一种乘客下单到司机接单后的司机页面的示意图；
图9为本发明实施例提供的一种另一个乘客下单到司机接单后的乘客页面的示意图；
图10为本发明实施例提供的一种修改导航时的地图的流程图；
图11为本发明实施例提供的一种网约车订单处理方法的流程图；
图12为本发明实施例提供的另一种网约车订单处理方法的流程图；
图13为本发明实施例提供的一种网约车订单处理装置的结构图；
图14为本发明实施例提供的另一种网约车订单处理装置的结构图；
图15为本发明实施例提供的一种电子设备的结构示意图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
以下结合附图进行详细说明本发明：
目前在网约车领域中，网约车平台的乘客端会配置不相同类型的地图，然而在司机端接收到拼车单等多乘客同坐的订单时，不同乘客端采用不同地图类型的地图进行下单时，会导致司机端无法与乘客端进行正常的司乘共显。为了改善这个问题，本发明实施例提供了以下方案：在司机端和乘客端配置多种地图类型的地图sdk(Software DevelopmentKit，软件开发工具包)。
其中，采用工厂模式、代理模块封装地图sdk，多个地图对业务层提供相同的方法名字,如初始化(init)、设置订单状态(onPickup，onWaiting，onStartService，onComplete)、传递订单号、设置路线颜色、放大缩小、坐标回调等。
本发明实施例提供了以下具体方案：
乘客端响应乘客发起的下单指令，将乘客提供的第二订单的信息以及所使用地图的地图类型发送给服务器，服务器将第二订单进行分配。
正在处理至少一个第一订单的司机端接收到第二订单后，司机端判断若接收到的第二订单的类型为目标类型，且第二订单中乘客端的地图类型与至少一个第一订单中乘客端的地图类型不均相同或均不相同，则从至少一个第一订单和第二订单中，选择第二展示订单；
若第二展示订单不为第二订单，且第二展示订单和第一展示订单相同，则根据第二订单中的信息，在与第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二订单中的乘客端；其中，第一展示订单为在接收到第二订单之前，从至少一个第一订单中选择出的第一订单；
根据至少一个第一订单和第二订单中的信息，在与第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单的乘客端。
乘客端响应乘客发起的同意指令，针对每个预设间隔，若接收到的该预设间隔的司乘同显数据仅包含所述第二订单相应的司乘同显数据，则在乘客所使用地图上直接展示该预设间隔的司乘同显数据。
其中，地图类型是根据不同的商家开发的地图的类型，地图类型可以包括但不限于高德地图、百度地图、腾讯地图等。
订单的类型可以包括但不限于实时单、接力单、拼车单、顺风车等等。订单的类型的目标类型包括但不限于接力单、拼车单、顺风车等等。
司乘同显数据为司机位置，司机行驶路线，司机剩余里程与到达时间等信息。
上述实施例中，司机端正在处理订单时，如果司机新接收到的订单的类型为目标类型，且司机接收到的订单的地图类型与当前正在处理的订单的地图类型不均相同或均不相同，由于不同的地图类型他们之间的信息无法交互，所以，先从这些订单中选择一个订单作为司机端展示导航路线的订单，如果该展示订单不为新接收的订单，那么司机端在与接收到的订单的地图类型相同的地图类型对应的地图上，根据所有订单的信息，建立多乘客导航路线，并按照这个路线进行导航，同时发起旧的展示订单的乘客接收到该多乘客导航路线后，截取与自己相关的导航路线，进行展示，同时，针对新接收到的订单，司机端可以在后台启动该地图进行新的订单的导航，并不进行导航页面的显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给新订单的乘客，乘客接收到后直接进行显示即可，这样尽管乘客下单的地图类型不同，也能够正常进行司乘同显，即司机的信息能够实时给乘客，乘客显示司机侧的导航路线。
其中，乘客端和司机端均内置多个地图类型的软件包。
司机端中根据至少一个第一订单和第二订单中的信息，在与第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单的乘客端，具体实现方式为：
司机端从至少一个第一订单和第二订单中提取目标地点；目标地点包括至少一个第一订单和第二订单中司机未到达的地点，该地点为至少一个第一订单的初始地、和/或至少一个第一订单的目的地、和/或第二订单的初始地、和/或第二订单的目的地。例如，第一订单的初始地a和目的地aa，第二订单的初始地b和目的地bb，如果司机已经达到过第一订单的初始地a，也就是说已经接到第一订单的乘客，正在处于送第一订单的乘客到目的地aa的状态。那么目标地点包括第一订单的目的地aa，第二订单的初始地b和目的地bb。
根据多个目标地点，调用与第二展示订单中乘客端的地图类型相同的地图类型对应的地图软件包实现在第二展示订单中乘客端的地图类型相同的地图类型对应的地图上创建多乘客导航路线，并且根据多乘客导航路线进行导航，使用该地图软件包内的司乘同显的方法，实现在导航过程中，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单的乘客端。
对于乘客的未达到的地点，可以从订单的状态进行确定，如果是接乘客状态，那么根据第一展示订单中的乘客初始地和目的地、第二订单的乘客初始地和目的地、司机的当前位置，确定多乘客导航路线。
如果是送客状态，那么根据第一展示订单中的乘客的目的地、第二订单的乘客初始地和目的地、司机的当前位置，确定多乘客导航路线。
同样的，司机端根据第二订单中的信息，在与第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二订单中的乘客端，具体实现方式为：
根据第二订单的乘客初始地和目的地，调用与第二订单中乘客端的地图类型相同的地图类型对应的地图软件包，实现根据第二订单中的信息，在与第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，同时截取导航时的显示画面，进行删除，使得导航时的显示画面不进行显示，使用该地图软件包内的司乘同显的方法，实现在导航过程中，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二订单的乘客端。
对于上述方案，以下结合附图进行说明：
结合图1所示，本发明实施例提供了一种网约车交互系统，包括：司机所使用的终端，以下简称为司机端100；乘客所使用的终端，以下简称为乘客端，该系统包括乘客端1和乘客端2，乘客端1和乘客端2使用的地图类型不同，司机端100可以处理一个乘客端发出的订单，也可以同时处理多个乘客端发出的订单；派单的服务器110，也可以称为派单平台，接收乘客的下单信息，并根据乘客的下单信息筛选匹配的司机，给司机派单的平台。
其中，第一订单为乘客2发出的，第二订单为乘客1发出的。结合图2所示，本发明实施例提供了一种网约车交互的方法，包括：
乘客端1响应乘客下单指令，将乘客提供的第二订单的信息以及所使用地图的地图类型发送给服务器110；
服务器110将第二订单分配给司机；
司机端100在处理乘客端2发出的订单时，接收到乘客端1发出的订单，判定乘客端2的订单的类型为目标类型，且乘客端1的地图类型与乘客端2的地图类型不相同，则从乘客端1与乘客端2的订单中，选择第二展示订单；
若第二展示订单不为乘客端1的订单，且第二展示订单和第一展示订单相同，说明由于第一展示订单为乘客端2的订单，第二展示订单并非乘客端1的订单，所以，第一展示订单和第二展示订单相同，均为乘客端2的订单，则根据第二订单中的信息，在与乘客端1的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端1；
以及根据乘客1和乘客端2的订单中的信息，在与乘客端2的地图类型相同的地图类型对应的地图上进行导航，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端2。
乘客端1响应乘客发起的同意指令，针对每个预设间隔，在乘客所使用地图上直接展示该预设间隔的司乘同显数据。
乘客端2针对每个预设间隔，从该预设间隔的司乘同显数据中挑选出乘客端2所在的订单相应的司乘同显数据，并在乘客所使用地图上展示挑选出的司乘同显数据。
也就是说，乘客端2在司机端接收到第二订单之前，与司机端进行导航的地图类型相同。在接收到第二订单之后，司机端的地图类型依然没有改变，针对乘客端1的导航，为控制导航画面不显示，也可以说司机端将乘客端1的导航进行后台运行。
对于从该预设间隔的司乘同显数据中挑选出第二订单相应的司乘同显数据，并在乘客所使用地图上展示挑选出的司乘同显数据，本发明实施例提供了一种实现方式为：
若该预设间隔的司乘同显数据为司机端第一次发送的司乘同显数据，则从该预设间隔的司乘同显数据中，提取与第二订单相应的第一司乘同显数据；在第二订单中乘客端的地图类型对应的地图上添加第一司乘同显数据，得到并展示该展示画面；其中，第一司乘同显数据包括司机当前位置、根据第二订单的乘客的起/终点创建的导航路线；预设间隔可以设置为3秒，2秒等。
若该预设间隔的司乘同显数据不为司机端第一次发送的司乘同显数据，则从该预设间隔的司乘同显数据中，提取与第二订单相应的第二司乘同显数据；根据第二司乘同显数据更新上一次展示画面，得到新的展示画面，并展示新的展示画面；其中，第二司乘同显数据包括司机当前位置、该预设间隔内司机所走的路线。
详细来说，由于司机和乘客之间所使用的地图类型相同，即他们之间发送的数据能够解析出来，所以，本发明提出乘客接收到多个乘客的导航路线的司乘同显数据之后，直接解析其司乘同显数据，将与乘客的订单相应的司乘同显数据提取出来，当预设间隔的司乘同显数据为司机端第一次发送的司乘同显数据，那么初始化乘客的地图类型的地图，并在地图上添加提取到的司乘同显数据，并进行展示。
结合图3所示，司机接到乘客甲和乘客乙的订单，从司机当前位置C，到乘客甲的初始地a，乘客乙的初始地b，乘客甲的目的地aa，乘客乙的目的地bb；司机端在确定乘客甲对应的订单为第二展示订单时，司机端在与乘客甲的地图类型相同的地图类型对应的地图上进行导航，导航展示画面如图3所示，按照预设间隔将导航中的预设间隔内的司乘显示数据发送给乘客甲，乘客甲接收到如图3的导航路线后，从司乘同显数据中，将司机当前位置、根据乘客甲的起始点创建的导航路线提取出来；然后初始化地图，在地图上添加司机当前位置、根据乘客甲的起始点创建的导航路线，得到展示画面，如图3所示的导航路线。
根据第二订单的乘客的起/终点创建的导航路线，包括：
若处于接客状态，则根据第二订单的乘客的起始点和司机的当前位置创建导航路线；
若处于送客状态，则根据第二订单的乘客的终点和司机的当前位置创建导航路线。
其中，起/终点为起点，或者终点。
示例性的，当司机对于乘客甲来说，处于接客状态，即前往乘客甲的初始地a的过程中，那么乘客甲提取的导航路线可以仅为从司机当前位置C到初始地a的导航路线。当司机对于乘客甲来说，处于送客状态，即前往乘客甲的目的地aa的过程中时，那么乘客甲提取的导航路线为司机当前位置到乘客甲的目的地aa的导航路线进行显示。
对于图3来说，仅为示例性的，对于司机端的显示图，也可以不显示全部导航路线，根据不同的状态展示不同的导航路线。例如当处于接乘客甲的状态时，可以仅显示从司机当前位置C到乘客甲的初始地a的导航路线。当处于接乘客乙的状态时，可以仅显示从司机当前位置C到乘客乙的初始地b的导航路线。当处于送乘客甲的状态时，可以仅显示从司机当前位置C到乘客甲的目的地的导航路线。当处于送乘客乙的状态时，可以仅显示从司机当前位置C到乘客乙的目的地的导航路线。
当该预设间隔的司乘同显数据不为司机端第一次发送的司乘同显数据，则无需初始化地图，直接在上一次展示画面中进行更新即可，即，将司机当前位置、该预设间隔内司机所走的路线为依据，更新上一次展示画面，具体来说：
将第二司乘同显数据中的该预设时间段内司机所走的路线，从上一次展示画面的导航路线中剔除；并将剔除后的上一次展示画面的导航路线的起点设置为第二司乘同显数据中的司机当前位置。
其中，该预设间隔内司机所走的路线可以由多个经纬度的坐标点组成。司机的当前位置也可以为经纬度表示。
结合图4所示，第一次司机位置为位置C，第二次司机端发送的司乘同显数据之后，乘客端将第二次司机端发送的司机位置CC，在第一次得到的展示画面中找到相应位置，同时，该预设时间段内司机所走的路线，在第一次得到的展示画面的导航路线中找到相应的路段，然后将该路段剔除，并将剔除后的导航路线中的起点设置为司机当前位置CC，从而得到本次的展示画面。
其中，将该路段剔除的方式可以为，将第一次得到的展示画面的导航路线中该路段设置为已走完的状态，对于画面显示来说，可以把该路段设置为灰色的，或者直接把该路段设置与其他非导航路段相同的颜色。
结合图5所示，示出了司机端100正在处理的第一订单为多个时的情况，本发明实施例提供了一种网约车交互系统，包括：司机端100；乘客端1～3，服务器110。
乘客端1为第二订单中的乘客端，乘客端2为第一展示订单中的乘客端，乘客端3为与乘客端2不同地图类型的乘客端，例如，乘客端1使用高德地图，乘客端2为百度地图，乘客端3为腾讯地图。
结合图6所示，在未接收到乘客端1发起的订单时，司机端100正在处理乘客端2和乘客端3的订单。
由于乘客端2为第一展示订单，司机端100根据乘客端2和乘客端3的订单中的信息，在与乘客端2的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端2；以及根据乘客端3的订单中的信息，在与乘客端3的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端3。
乘客端2针对每个预设间隔，从该预设间隔的司乘同显数据中挑选出乘客端2所在的订单相应的司乘同显数据，并在乘客所使用地图上展示挑选出的司乘同显数据。
乘客端3响应乘客发起的同意指令，针对每个预设间隔，在乘客所使用地图上直接展示司机端发送的该预设间隔的司乘同显数据。
在接收到乘客端1发起的订单后，司机端100根据乘客端1～乘客端3的订单中的信息，在与乘客端2的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端2；以及根据乘客端1的订单中的信息，在与乘客端1的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端1；根据乘客端3的订单中的信息，在与乘客端3的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端3。
示例性的，以司机端和乘客端的展示画面说明本发明实施例。结合图7所示，乘客甲在高德地图上输入初始地a和目的地aa，点击打车按钮，即在高德地图上下单，下单类型为拼车单，乘客甲将上述下单的信息和高德地图这个地图类型发送给服务器，服务器给司机发配该订单，结合图8所示，司机乙的终端界面显示乘客甲的订单，并在点击接单后，即接到乘客甲的订单，司机乙调用高德地图的软件包，渲染高德地图，并创建司机位置C到乘客甲的初始地a，然后再到乘客甲的目的地aa的导航路线，采用该导航路线进行导航，启动司乘同显功能将司机端创建的司机位置C到乘客甲的初始地a，然后再到乘客甲的目的地的导航路线与乘客甲进行同步显示，结合图7和图8所示，由于司机乙在接乘客甲的阶段，司机乙和乘客甲均显示司机位置C到乘客甲的初始地a的导航路线，到乘客甲的目的地aa。
结合图9所示，乘客丙在百度地图上输入初始地b和目的地bb，点击打车按钮，即在百度地图上下单，下单类型为拼车单，乘客丙将上述下单的信息和百度地图这个地图类型发送给服务器，服务器给司机乙发配该订单。
结合图8所示，司机乙的终端界面显示乘客丙的订单，并在点击接单后，即接到乘客丙的订单，这时司机乙正在前往接乘客甲的初始地a，从乘客甲和乘客丙对应的订单中，确定第二展示订单，如果第二展示订单不为乘客丙对应的订单，依然是乘客甲对应的订单，司机乙调用百度地图的软件包，根据司机乙的位置C、乘客丙的初始地b、乘客丙的目的地bb，创建导航路线进行导航，并控制导航时的显示画面不进行显示，启动司乘同显功能将司机端创建的导航路线与乘客丙进行同步显示，结合图8和图9所示。
结合图7所示，由于乘客甲并不关心乘客丙的情况，所以，在与司机乙进行司乘同显时，得到展示的导航路线后，并不直接展示，而是从导航路线后，截取自己这一部分的导航路线，进行显示。
同样的，当司机乙接到乘客丙的订单，这时司机乙正在处于前往送乘客甲到目的地aa的状态，从乘客甲和乘客丙对应的订单中，确定第二展示订单，如果第二展示订单为乘客甲对应的订单，司机乙调用高德地图的软件包，初始化高德地图，并根据乘客甲的目的地aa、司机乙的位置C、乘客丙的初始地b、乘客丙的目的地bb，创建导航路线。
本发明实施例还提供了以下其他方案：
司机端判断若第二展示订单、第一展示订单均不第二订单，且第一展示订单和第二展示订单的地图类型不相同，则根据第二订单中的信息，在与第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二订单中的乘客端；
以及根据至少一个第一订单和第二订单中的信息，在与第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单中的乘客端；
以及根据第一展示订单中的信息，在与第一展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第一展示订单中的乘客端。
示例性的，结合图5所示，乘客端1为第二订单的乘客端，乘客端2为第一展示订单的乘客端，乘客端3为第二展示订单的乘客端。
本发明实施例提供了另一种网约车交互的方法，包括：
司机端100根据第二订单中的信息，在与乘客端1的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端1；
乘客端1针对每个预设间隔，在乘客所使用地图上直接展示司机端100发送的该预设间隔的司乘同显数据；
司机端100根据乘客端1～乘客端3的订单中的信息，在与乘客端3中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端3；
乘客端3针对每个预设间隔，从该预设间隔的司乘同显数据中挑选出乘客端3的订单相应的司乘同显数据，并在乘客所使用地图上展示乘客端3的订单相应的司乘同显数据；
司机端100根据第一展示订单中的信息，在与乘客端2的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端2；
乘客端2针对每个预设间隔，在乘客所使用地图上直接展示司机端100发送的该预设间隔的司乘同显数据。
本发明实施例还提供了以下其他方案：
司机端判断若第二展示订单为第二订单，且第一展示订单和第二展示订单的地图类型不相同，则根据至少一个第一订单和第二订单中的信息，在与第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二订单中的乘客端；
以及根据第一展示订单中的信息，在与第一展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第一展示订单的乘客端。
示例性的，结合图1所示，乘客端1为第二订单的乘客端，乘客端2为第一展示订单的乘客端。
本发明实施例提供了一种网约车交互的方法，包括：
司机端100根据乘客端1和乘客端2的订单中的信息，在与乘客端1的地图类型相同的地图类型对应的地图上进行导航，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端1。
乘客端1针对每个预设间隔，从该预设间隔的司乘同显数据中挑选出乘客端1所在的订单相应的司乘同显数据，并在乘客所使用地图上展示乘客端1所在的订单相应的司乘同显数据。
司机端100根据乘客端2的订单中的信息，在与乘客端2的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端2；
乘客端2针对每个预设间隔，在乘客所使用地图上直接展示司机端100发送的该预设间隔的司乘同显数据。
示例性的，结合图5所示，乘客端1为第二订单的乘客端，乘客端2为第一展示订单的乘客端，乘客端3为非第一展示订单的第一订单的乘客端。
司机端100根据乘客端1和乘客端2的订单中的信息，在与乘客端1的地图类型相同的地图类型对应的地图上进行导航，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端1。
乘客端1针对每个预设间隔，从该预设间隔的司乘同显数据中挑选出乘客端1所在的订单相应的司乘同显数据，并在乘客所使用地图上展示乘客端1所在的订单相应的司乘同显数据。
司机端100根据乘客端2的订单中的信息，在与乘客端2的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端2；
乘客端2针对每个预设间隔，在乘客所使用地图上直接展示司机端100发送的该预设间隔的司乘同显数据。
司机端100根据乘客端3的订单中的信息，在与乘客端3的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给乘客端3；
乘客端3针对每个预设间隔，在乘客所使用地图上直接展示司机端100发送的该预设间隔的司乘同显数据。
也就是说，乘客端3在司机端接收到第二订单之前一直是，在司机端后台运行。在接收到第二订单之后，司机端的地图类型依然不是乘客端3的地图类型，针对乘客端3的导航，为控制导航画面不显示，也可以说司机端将乘客端3的导航一直在后台运行。
其中，对于上述实施例，从至少一个所述第一订单和所述第二订单中，确定第二展示订单，具体实现方式包括：
从至少一个第一订单和第二订单中，将多个目标地点中最先达到的目标地点所在的订单作为第二展示订单；其中，所述目标地点为至少一个第一订单和第二订单中司机未到达的地点。
以一个第一订单为例，第一订单的初始地a和目的地aa，第二订单的初始地b和目的地bb，如果司机已经达到过第一订单的初始地a，也就是说已经接到第一订单的乘客，正在处理送第一订单的乘客到目的地aa的状态。那么多个目标地点包括第一订单的目的地aa，第二订单的初始地b和目的地bb。
根据达到第一订单的目的地aa，第二订单的初始地b和目的地bb这些地点最短行程的原则，确定导航路线为第二订单的初始地b，第二订单的目的地bb，第一订单的目的地aa的顺序，那么多个目标地点中最先达到的目标地点为第二订单的初始地b，那么第二展示订单为第二订单。
又如，司机在接第一订单的乘客过程中，接收到第二订单，那么多个目标地点包括：第一订单的初始地a和目的地aa，第二订单的初始地b和目的地bb，根据最短行程的原则，确定导航路线为：第一订单的初始地a，第二订单的初始地b，第一订单的目的地aa，第二订单的目的地bb的顺序；那么多个目标地点中最先达到的目标地点为第一订单的初始地a，那么第二展示订单为第一订单。
如果路程行驶过程中，出现某个地图服务商的服务不可用，例如天气、地震等导致的地图服务不可用，本发明实施例提供了以下解决方案：
乘客端在满足预设条件之后，根据优先地图类型生成修改指令，将修改指令发送给司机端；其中，优先地图类型是从多种地图类型中选择的；
司机端接收乘客端发送的修改指令；根据第二订单中的信息，在与修改指令中的优先地图类型相同的地图类型对应的地图上重新进行导航；并控制重新导航时的显示画面不进行显示，将重新导航中的司乘同显数据发送给第二订单中的乘客端；
乘客端接收司机端发送的重新导航中的司乘同显数据；并在修改指令中的优先地图类型对应的地图上直接展示重新导航中的司乘同显数据。
针对上述解决方案，本发明实施例提供了一种实现方式，结合图10所示，若乘客端当前使用高德地图，乘客端在满足预设条件之后，将高德地图不可用信息发送给服务器，服务器接收到乘客端发送的信息后，从多个地图类型中选择优选地图类型，例如，从百度地图、腾讯地图中选择百度地图；然后将百度地图可用信息发送给乘客端，乘客端将包含百度地图的修改指令发送给司机端，司机端接收到包含百度地图的修改指令之后，在百度地图上重新进行导航，并将重新导航时的司乘同显数据发送给乘客端，乘客端接收到上述方案后，在百度地图上显示司乘同显数据。
本发明实施例还提供了另一种实现方式，若乘客端当前使用高德地图，乘客端在满足预设条件之后，无需服务器，而是直接从多个地图类型中选择优选地图类型，例如，从百度地图、腾讯地图中选择百度地图，乘客端将包含百度地图的修改指令发送给司机端，司机端接收到包含百度地图的修改指令之后，在百度地图上重新进行导航，并将重新导航时的司乘同显数据发送给乘客端，乘客端接收到上述方案后，在百度地图上显示司乘同显数据。
当然，对于第一订单来说，流程也是相似的。
司机端若乘客端来源于所述第二展示订单或第一展示订单，则根据至少一个第一订单和第二订单中的信息，在与修改指令中的优先地图类型相同的地图类型对应的地图上重新进行导航；将重新导航中的司乘同显数据发送给第二展示订单的乘客端。
乘客端若接收到的司乘同显数据中包括多个乘客的司乘同显数据，则从多个乘客的司乘同显数据中挑选出订单相应的司乘同显数据，并在乘客所使用地图上展示订单相应的司乘同显数据。
如图11所示，本发明还提供一种网约车订单处理方法，应用于司机端，包括：
S1100：在处理至少一个第一订单时，若接收到的第二订单的类型为目标类型，且第二订单中乘客端的地图类型与至少一个第一订单中乘客端的地图类型不均相同或均不相同，则从至少一个第一订单和第二订单中，选择第二展示订单；
S1101：若第二展示订单不为第二订单，且第二展示订单和第一展示订单相同，则根据第二订单中的信息，在与第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二订单中的乘客端；
其中，所述第一展示订单为在接收到所述第二订单之前，从至少一个所述第一订单中选择出的第一订单；
S1102：根据至少一个第一订单和第二订单中的信息，在与第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单的乘客端。
可选的，所述方法还包括：
若所述第二展示订单、所述第一展示订单均不所述第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同，则根据所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；
以及根据至少一个所述第一订单和所述第二订单中的信息，在与所述第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单中的乘客端；
以及根据所述第一展示订单中的信息，在与所述第一展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第一展示订单中的乘客端；
若所述第二展示订单为所述第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同，则根据至少一个所述第一订单和所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；
以及根据所述第一展示订单中的信息，在与所述第一展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第一展示订单的乘客端。
可选的，从至少一个所述第一订单和所述第二订单中，选择第二展示订单，包括：
从至少一个所述第一订单和所述第二订单中，将多个目标地点中最先达到的目标地点所在的订单作为第二展示订单；其中，所述目标地点为至少一个所述第一订单和所述第二订单中司机未到达的地点。
可选的，所述方法还包括：
接收乘客端发送的修改指令；
根据所述第二订单中的信息，在与修改指令中的优先地图类型相同的地图类型对应的地图上重新进行导航；并控制重新导航时的显示画面不进行显示，将重新导航中的司乘同显数据发送给所述第二订单中的乘客端。
结合图12所示，本发明实施例提供了一种网约车订单处理方法，应用于乘客端，包括：
S1200：响应乘客发起的下单指令，将乘客提供的第二订单的信息以及所使用地图的地图类型发送给服务器，以使服务器将第二订单进行分配；
S1201：响应乘客发起的同意指令，针对每个预设间隔，若接收到的该预设间隔的司乘同显数据仅包含第二订单相应的司乘同显数据，则在乘客所使用地图上直接展示该预设间隔的司乘同显数据；
其中，所述第二订单相应的司乘同显数据为所述司机端在处理至少一个第一订单时，接收到的第二订单的类型为目标类型，所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同时，从至少一个所述第一订单和所述第二订单中，确定的第二展示订单非第二订单，且所述第二展示订单和第一展示订单相同后，根据所述第二订单的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航的数据。
可选的，所述方法还包括：
若接收到的该预设间隔的司乘同显数据中包括多个乘客的司乘同显数据，则从该预设间隔的司乘同显数据中挑选出所述第二订单相应的司乘同显数据，并在乘客所使用地图上展示挑选出的司乘同显数据；
其中，多个乘客的司乘同显数据为所述司机端在处理至少一个第一订单时，接收到的第二订单的类型为目标类型，所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同时，从至少一个第一订单和所述第二订单中，确定的第二展示订单为第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同后，根据至少一个所述第一订单和所述第二订单中的信息，在与所述展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航的数据。
可选的，从该预设间隔的司乘同显数据中挑选出所述第二订单相应的司乘同显数据，并在乘客所使用地图上展示挑选出的司乘同显数据，包括：
若该预设间隔的司乘同显数据为所述司机端第一次发送的司乘同显数据，则从该预设间隔的司乘同显数据中，提取与所述第二订单相应的第一司乘同显数据；在所述第二订单中乘客端的地图类型对应的地图上添加所述第一司乘同显数据，得到并展示所述展示画面；其中，所述第一司乘同显数据包括司机当前位置、根据第二订单的乘客的起/终点创建的导航路线；
若该预设间隔的司乘同显数据不为所述司机端第一次发送的司乘同显数据，则从该预设间隔的司乘同显数据中，提取与所述第二订单相应的第二司乘同显数据；根据所述第二司乘同显数据更新上一次展示画面，得到新的展示画面，并展示新的展示画面；其中，所述第二司乘同显数据包括司机当前位置、该预设间隔内司机所走的路线。
可选的，根据所述第二司乘同显数据更新上一次展示画面，得到新的展示画面，包括：
将所述第二司乘同显数据中的该预设时间段内司机所走的路线，从上一次展示画面的导航路线中剔除；
并将剔除后的上一次展示画面的导航路线的起点设置为所述第二司乘同显数据中的司机当前位置。
可选的，在乘客所使用地图上直接展示所述第二订单相应的司乘同显数据之后，所述方法还包括：
在满足预设条件之后，根据优先地图类型生成修改指令，将修改指令发送给司机端；其中，所述优先地图类型是从多种地图类型中选择的；
接收所述司机端发送的重新导航中的司乘同显数据；
在修改指令中的优先地图类型对应的地图上直接展示重新导航中的司乘同显数据；
其中，所述重新导航中的司乘同显数据是所述司机端在接收到乘客端发送的修改指令后，根据所述第二订单中的信息，在修改指令中的优先地图类型对应的地图上重新进行导航的数据。
结合图13所示，本发明实施例还提供了一种网约车订单处理方法，应用于司机端，包括：
选择模块1300，用于在处理至少一个第一订单时，若接收到的第二订单的类型为目标类型，且所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同，则从至少一个所述第一订单和所述第二订单中，选择第二展示订单；
第一导航模块1301，用于若所述第二展示订单不为所述第二订单，且所述第二展示订单和第一展示订单相同，则根据所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；其中，所述第一展示订单为在接收到所述第二订单之前，从至少一个所述第一订单中选择出的第一订单；
第二导航模块1302，用于根据至少一个所述第一订单和所述第二订单中的信息，在与所述第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单的乘客端。
可选的，所述装置还包括：
第三导航模块，用于若所述第二展示订单、所述第一展示订单均不所述第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同，则根据所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；
以及根据至少一个所述第一订单和所述第二订单中的信息，在所述第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单中的乘客端；
以及根据所述第一展示订单中的信息，在与所述第一展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第一展示订单中的乘客端；
若所述第二展示订单为所述第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同，则根据至少一个所述第一订单和所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；
以及根据所述第一展示订单中的信息，在与所述第一展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第一展示订单的乘客端。
可选的，选择模块1300，具体用于：
从至少一个所述第一订单和所述第二订单中，将多个目标地点中最先达到的目标地点所在的订单作为第二展示订单；其中，所述目标地点为至少一个所述第一订单和所述第二订单中司机未到达的地点。
可选的，所述装置还包括：
修改模块，用于接收乘客端发送的修改指令；
根据所述第二订单中的信息，在与修改指令中的优先地图类型相同的地图类型对应的地图上重新进行导航；并控制重新导航时的显示画面不进行显示，将重新导航中的司乘同显数据发送给所述第二订单中的乘客端。
结合图14所示，本发明实施例还提供了一种网约车订单处理方法，应用于乘客端，包括：
下单模块1400，用于响应乘客发起的下单指令，将乘客提供的第二订单的信息以及所使用地图的地图类型发送给服务器，以使所述服务器将第二订单进行分配；
第一展示模块1401，用于响应乘客发起的同意指令，针对每个预设间隔，若接收到的该预设间隔的司乘同显数据仅包含所述第二订单相应的司乘同显数据，则在乘客所使用地图上直接展示该预设间隔的司乘同显数据；
其中，所述第二订单相应的司乘同显数据为所述司机端在处理至少一个第一订单时，接收到的第二订单的类型为目标类型，所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同时，从至少一个所述第一订单和所述第二订单中，确定的第二展示订单非第二订单，且所述第二展示订单和第一展示订单相同后，根据所述第二订单的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航的数据。
可选的，所述装置还包括：
第二展示模块，用于若接收到的该预设间隔的司乘同显数据中包括多个乘客的司乘同显数据，则从该预设间隔的司乘同显数据中挑选出所述第二订单相应的司乘同显数据，并在乘客所使用地图上展示挑选出的司乘同显数据；
其中，多个乘客的司乘同显数据为所述司机端在处理至少一个第一订单时，接收到的第二订单的类型为目标类型，所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同时，从至少一个第一订单和所述第二订单中，确定的第二展示订单为第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同后，根据至少一个所述第一订单和所述第二订单中的信息，在与所述展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航的数据。
可选的，第二展示模块，具体用于若该预设间隔的司乘同显数据为所述司机端第一次发送的司乘同显数据，则从该预设间隔的司乘同显数据中，提取与所述第二订单相应的第一司乘同显数据；在所述第二订单中乘客端的地图类型对应的地图上添加所述第一司乘同显数据，得到并展示所述展示画面；其中，所述第一司乘同显数据包括司机当前位置、根据第二订单的乘客的起/终点创建的导航路线；
若该预设间隔的司乘同显数据不为所述司机端第一次发送的司乘同显数据，则从该预设间隔的司乘同显数据中，提取与所述第二订单相应的第二司乘同显数据；根据所述第二司乘同显数据更新上一次展示画面，得到新的展示画面，并展示新的展示画面；其中，所述第二司乘同显数据包括司机当前位置、该预设间隔内司机所走的路线。
可选的，第二展示模块，具体用于：
将所述第二司乘同显数据中的该预设时间段内司机所走的路线，从上一次展示画面的导航路线中剔除；
并将剔除后的上一次展示画面的导航路线的起点设置为所述第二司乘同显数据中的司机当前位置。
可选的，所述装置还包括：
修改模块，用于在满足预设条件之后，根据优先地图类型生成修改指令，将修改指令发送给司机端；其中，所述优先地图类型是从多种地图类型中选择的；
接收所述司机端发送的重新导航中的司乘同显数据；
在修改指令中的优先地图类型对应的地图上直接展示重新导航中的司乘同显数据；
其中，所述重新导航中的司乘同显数据是所述司机端在接收到乘客端发送的修改指令后，根据所述第二订单中的信息，在修改指令中的优先地图类型对应的地图上重新进行导航的数据。
另外，本发明实施例的应用于司机端的网约车订单处理方法和装置，可以由司机端来实现。
司机端，包括：处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如上述介绍的任一项所述的网约车订单处理方法。
本发明实施例的应用于乘客端的网约车订单处理方法和装置，可以由乘客端来实现。
司机端，包括：处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如上述介绍的任一项所述的网约车订单处理方法。
基于上述的介绍，示例性的，司机端和乘客端的结构相似，均可以为图15所示的结构。
电子设备可以包括处理器1510以及存储有计算机程序指令的存储器1520。
具体地，上述处理器1510可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本发明实施例的一个或多个集成电路。
存储器1520可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器1520可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器1520可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器1520可在数据处理装置的内部或外部。在特定实施例中，存储器1520是非易失性固态存储器。在特定实施例中，存储器1520包括只读存储器(ROM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除PROM(EEPROM)、电可改写ROM(EAROM)或闪存或者两个或更多个以上这些的组合。
处理器1510通过读取并执行存储器1520中存储的计算机程序指令，以实现上述实施例中的任意一种执行任务的方法。
在一个示例中，电子设备还可包括通信接口1530和总线1540。其中，如图15所示，处理器1510、存储器1520、通信接口1530通过总线1540连接并完成相互间的通信。
通信接口1530，主要用于实现本发明实施例中各模块、装置、单元和/或设备之间的通信。
总线1540包括硬件、软件或两者，将电子设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线1540可包括一个或多个总线。尽管本发明实施例描述和示出了特定的总线，但本发明考虑任何合适的总线或互连。
该电子设备可以基于接收到的任务，执行本发明实施例中的执行任务的方法，从而实现网约车订单处理方法和装置。
另外，本发明实施例提供一种存储介质，当所述存储介质中的指令由司机端的处理器执行时，使得所述司机端能够执行如上述中任一项所述的网约车订单处理方法；或者当所述存储介质中的指令由乘客端的处理器执行时，使得所述乘客端能够执行如上述中任一项所述的网约车订单处理方法。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (12)

1.一种网约车订单处理方法，其特征在于，应用于司机端，包括：
在处理至少一个第一订单时，若接收到的第二订单的类型为目标类型，且所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同，则从至少一个所述第一订单和所述第二订单中，选择第二展示订单；
若所述第二展示订单不为所述第二订单，且所述第二展示订单和第一展示订单相同，则根据所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；其中，所述第一展示订单为在接收到所述第二订单之前，从至少一个所述第一订单中选择出的第一订单；
根据至少一个所述第一订单和所述第二订单中的信息，在与所述第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单的乘客端。
2.根据权利要求1所述的网约车订单处理方法，其特征在于，所述方法还包括：
若所述第二展示订单、所述第一展示订单均不所述第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同，则根据所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；
以及根据至少一个所述第一订单和所述第二订单中的信息，在与所述第二展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航；按照预设间隔将导航中的预设间隔内的司乘同显数据发送给第二展示订单中的乘客端；
以及根据所述第一展示订单中的信息，在与所述第一展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第一展示订单中的乘客端；
若所述第二展示订单为所述第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同，则根据至少一个所述第一订单和所述第二订单中的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第二订单中的乘客端；
以及根据所述第一展示订单中的信息，在与所述第一展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航，并控制导航时的显示画面不进行显示，按照预设间隔将导航中的预设间隔内的司乘同显数据发送给所述第一展示订单的乘客端。
3.根据权利要求1所述的网约车订单处理方法，其特征在于，从至少一个所述第一订单和所述第二订单中，选择第二展示订单，包括：
从至少一个所述第一订单和所述第二订单中，将多个目标地点中最先达到的目标地点所在的订单作为第二展示订单；其中，所述目标地点为至少一个所述第一订单和所述第二订单中司机未到达的地点。
4.根据权利要求1所述的网约车订单处理方法，其特征在于，所述方法还包括：
接收乘客端发送的修改指令；
根据所述第二订单中的信息，在与修改指令中的优先地图类型相同的地图类型对应的地图上重新进行导航；并控制重新导航时的显示画面不进行显示，将重新导航中的司乘同显数据发送给所述第二订单中的乘客端。
5.一种网约车订单处理方法，其特征在于，应用于乘客端，包括：
响应乘客发起的下单指令，将乘客提供的第二订单的信息以及所使用地图的地图类型发送给服务器，以使所述服务器将第二订单进行分配；
响应乘客发起的同意指令，针对每个预设间隔，若接收到的该预设间隔的司乘同显数据仅包含所述第二订单相应的司乘同显数据，则在乘客所使用地图上直接展示该预设间隔的司乘同显数据；
其中，所述第二订单相应的司乘同显数据为所述司机端在处理至少一个第一订单时，接收到的第二订单的类型为目标类型，所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同时，从至少一个所述第一订单和所述第二订单中，确定的第二展示订单非第二订单，且所述第二展示订单和第一展示订单相同后，根据所述第二订单的信息，在与所述第二订单中乘客端的地图类型相同的地图类型对应的地图上进行导航的数据。
6.根据权利要求5所述的网约车订单处理方法，其特征在于，所述方法还包括：
若接收到的该预设间隔的司乘同显数据中包括多个乘客的司乘同显数据，则从该预设间隔的司乘同显数据中挑选出所述第二订单相应的司乘同显数据，并在乘客所使用地图上展示挑选出的司乘同显数据；
其中，多个乘客的司乘同显数据为所述司机端在处理至少一个第一订单时，接收到的第二订单的类型为目标类型，所述第二订单中乘客端的地图类型与至少一个所述第一订单中乘客端的地图类型不均相同或均不相同时，从至少一个第一订单和所述第二订单中，确定的第二展示订单为第二订单，且所述第一展示订单和所述第二展示订单的地图类型不相同后，根据至少一个所述第一订单和所述第二订单中的信息，在与所述展示订单中乘客端的地图类型相同的地图类型对应的地图上进行导航的数据。
7.根据权利要求5所述的网约车订单处理方法，其特征在于，从该预设间隔的司乘同显数据中挑选出所述第二订单相应的司乘同显数据，并在乘客所使用地图上展示挑选出的司乘同显数据，包括：
若该预设间隔的司乘同显数据为所述司机端第一次发送的司乘同显数据，则从该预设间隔的司乘同显数据中，提取与所述第二订单相应的第一司乘同显数据；在所述第二订单中乘客端的地图类型对应的地图上添加所述第一司乘同显数据，得到并展示所述展示画面；其中，所述第一司乘同显数据包括司机当前位置、根据第二订单的乘客的起/终点创建的导航路线；
若该预设间隔的司乘同显数据不为所述司机端第一次发送的司乘同显数据，则从该预设间隔的司乘同显数据中，提取与所述第二订单相应的第二司乘同显数据；根据所述第二司乘同显数据更新上一次展示画面，得到新的展示画面，并展示新的展示画面；其中，所述第二司乘同显数据包括司机当前位置、该预设间隔内司机所走的路线。
8.根据权利要求7所述的网约车订单处理方法，其特征在于，根据所述第二司乘同显数据更新上一次展示画面，得到新的展示画面，包括：
将所述第二司乘同显数据中的该预设时间段内司机所走的路线，从上一次展示画面的导航路线中剔除；
并将剔除后的上一次展示画面的导航路线的起点设置为所述第二司乘同显数据中的司机当前位置。
9.根据权利要求5所述的网约车订单处理方法，其特征在于，在乘客所使用地图上直接展示所述第二订单相应的司乘同显数据之后，所述方法还包括：
在满足预设条件之后，根据优先地图类型生成修改指令，将修改指令发送给司机端；其中，所述优先地图类型是从多种地图类型中选择的；
接收所述司机端发送的重新导航中的司乘同显数据；
在修改指令中的优先地图类型对应的地图上直接展示重新导航中的司乘同显数据；
其中，所述重新导航中的司乘同显数据是所述司机端在接收到乘客端发送的修改指令后，根据所述第二订单中的信息，在修改指令中的优先地图类型对应的地图上重新进行导航的数据。
10.一种司机端，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求1至权利要求4中任一项所述的网约车订单处理方法。
11.一种乘客端，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求5至权利要求9中任一项所述的网约车订单处理方法。
12.一种存储介质，其特征在于，当所述存储介质中的指令由司机端的处理器执行时，使得所述司机端能够执行如权利要求1至权利要求4中任一项所述的网约车订单处理方法；或者当所述存储介质中的指令由乘客端的处理器执行时，使得所述乘客端能够执行如权利要求5至权利要求9中任一项所述的网约车订单处理方法。
CN202310236022.7A 2023-03-13 2023-03-13 网约车订单处理方法、司机端、乘客端以及存储介质 Pending CN116433322A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310236022.7A CN116433322A (zh) 2023-03-13 2023-03-13 网约车订单处理方法、司机端、乘客端以及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310236022.7A CN116433322A (zh) 2023-03-13 2023-03-13 网约车订单处理方法、司机端、乘客端以及存储介质

Publications (1)

Publication Number Publication Date
CN116433322A true CN116433322A (zh) 2023-07-14

Family

ID=87089843

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310236022.7A Pending CN116433322A (zh) 2023-03-13 2023-03-13 网约车订单处理方法、司机端、乘客端以及存储介质

Country Status (1)

Country Link
CN (1) CN116433322A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116828000A (zh) * 2023-08-28 2023-09-29 山东未来互联科技有限公司 基于确定性网络与sdn网络的乘车订单处理系统及方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116828000A (zh) * 2023-08-28 2023-09-29 山东未来互联科技有限公司 基于确定性网络与sdn网络的乘车订单处理系统及方法
CN116828000B (zh) * 2023-08-28 2023-11-17 山东未来互联科技有限公司 基于确定性网络与sdn网络的乘车订单处理系统及方法

Similar Documents

Publication Publication Date Title
US10839217B2 (en) Augmented reality assisted pickup
US11915176B2 (en) Vehicle dispatch system, vehicle dispatch method, server, user terminal, and storage medium
CN107491825B (zh) 一种约车处理方法及系统
CN108062865B (zh) 停车方向提示方法及装置
US11815359B2 (en) Method, device and system for processing positioning information
KR20140106206A (ko) 차량 단말 및 군집주행 제어 시스템과 이를 이용한 선행 차량 선택 방법
CN107702725B (zh) 行车路线推荐方法及装置
CN106327311B (zh) 订单处理方法、装置及系统
CN110634045B (zh) 一种多途经点订单处理方法及装置
CN105606114A (zh) 一种车载导航方法、交互系统服务器、终端以及系统
CN105719173A (zh) 订单处理方法和订单处理设备
TW201800287A (zh) 資料的推送方法、裝置和設備
CN109302492B (zh) 用于推荐服务位置的方法、设备和计算机可读存储介质
CN115140090A (zh) 车辆控制方法、装置、电子设备和计算机可读介质
CN116433322A (zh) 网约车订单处理方法、司机端、乘客端以及存储介质
WO2021253955A1 (zh) 一种信息处理方法、装置、车辆以及显示设备
CN106403972A (zh) 一种导航分析方法及系统
CN107765691A (zh) 用于控制无人驾驶车辆的方法和装置
CN113343128A (zh) 用于推送信息的方法、装置、设备以及存储介质
US20200175446A1 (en) System and method for managing taxi dispatch, and program for controlling taxi dispatch requests
EP2789978B1 (en) Navigation system and method for displaying photomap on navigation system
US8954277B2 (en) Adding visual image of traffic condition to help driver determine a route from multiple options
CN108519093B (zh) 一种导航路线确定方法及装置
CN111143706A (zh) 一种提示信息展示方法、装置、电子设备和存储介质
CN109670614A (zh) 一种处理订单的方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination