本申请涉及互联网技术，尤其涉及一种出行数据的获取方法、装置、设备和系统。
背景技术：
随着城市的发展,城市的范围越来越大，人们对出行有了更高的需求，网络叫车服务或者拼车服务，例如快车、快滴等成为了出租车、私家车和公共交通的有益补充。
现有技术中的叫车服务，一般是由出行用户的用户端设备发起出行需求至云端服务器，云端服务器将出行需求公布在服务平台上，由服务端(即可以提供出行服务的车主的终端设备)在服务平台上应答用户需求，并随之提供相应的出行服务。现有技术中，服务平台会根据用户端的地理位置和出行时间，以及服务端的地理位置和空闲时间来提供一定的指导性服务，以使服务端根据双方的地理位置来应答用户的出行需求。
但是，随着城市道路的不断发展，交通路况日益复杂，经常会出现某一区域的用户出行需求较多，提供服务的服务端却很少，而另一个区域的用户出行需求较少，提供服务的服务端却供大于求，因此，现有技术中的出行服务很难满足用户的出行需求，也很难平衡服务端的车主的收益，服务效率低下。
技术实现要素：
本申请提供一种出行数据的获取方法、装置、设备和系统，用以解决现有技术中用户出行需求和提供服务的服务端设备不匹配，并且无法保证车主的收益的技术问题。
一个方面，本申请提供一种出行数据的获取方法，包括：
根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息；其中，所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息。
上述所提供的出行数据的获取方法，通过根据预设的出行数据库中的第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息，并向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息，以使服务端设备根据所述用户出行信息为用户进行服务，并使得用户端设备的出行需求能够及时被响应，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
作为一种可实现的方式，所述方法还包括：
根据每个所述区域在未来时间范围内的用户出行信息，获取每个所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量的差值；
将所述差值大于预设阈值的区域确定为热点区域；
将所述热点区域的信息推送给所述至少一个服务端设备。
该方式通过将确定的热点区域的信息推送给至少一个服务端设备，使得服务端设备可以前往该热点区域的信息所指示的地理位置，更好的为热点区域内的用户提供服务，即更好的满足了热点区域的用户的出行需求，也更好的保证了车主的收益。
作为一种可实现的方式，所述区域为对地图中的基础地理位置信息进行离散处理后的网格，每个网格对应地图中的一个经纬度范围；
所述热点区域的信息为所述差值大于所述预设阈值的网格中的地图注点poi信息。
作为一种可实现的方式，所述根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息之前，还包括：
对地图中的基础地理位置信息进行离散处理，获得至少一个网格；
根据预设的时间段划分策略，对获取的所有第一历史出行订单添加时间戳，得到至少一个第二历史出行订单；所述时间戳包括所述第一历史出行订单的发生日期和所述第一历史出行订单的发生时间所在的时间段标识；所述第一历史出行订单携带所述第一历史出行订单对应的经纬度信息和所述第一历史出行订单的发生时间；
根据每个所述第二历史出行订单和所获得的响应信息，生成第二历史出行数据，所述第二历史出行数据包括至少一个第三历史出行订单，每个第三历史出行订单包括所述第二历史出行订单和所述第二历史出行订单的响应状态；所述响应信息用于指示每个所述第二历史出行订单的响应状态；
根据所述第二历史出行数据中每个所述第三历史出行订单的经纬度信息，将所述第二历史出行数据映射至所述至少一个网格，获得所述第一历史出行数据。
作为一种可实现的方式，所述第一历史出行数据具体包括：每个所述网格在每个历史日期下的每个时间段的历史出行订单量和历史出行订单响应量；
相应的，
所述用户出行信息具体包括：所述网格在未来日期下的每个时间段的未来出行订单量和未来出行订单响应量。
作为一种可实现的方式，所述第一历史出行数据还包括：每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的等待时间，和/或，每个所述网格在每个历史日期下的每个时间段的历史出行订单被所述历史出行订单所属的网格中的服务端设备所响应的订单量。
该方式通过对地图中的基础地理位置信息进行离散处理得到至少一个网格，并根据预设的时间段划分策略，对从出行订单数据库中获取的所有第一历史出行订单添加时间戳，得到至少一个第二历史出行订单，然后根据每个第二历史出行订单和从响应数据库中获得的响应信息生成第二历史出行数据，进而根据该所述第二历史出行数据中每个第三历史出行订单的经纬度信息，将第二历史出行数据映射至所述至少一个网格，得到第一历史出行数据，从而使得云端服务器可以根据该第一历史出行数据获知每个网格在每个历史日期下的每个时间段的历史出行订单量和历史出行订单响应量，进而便于云端服务器根据第一历史出行数据所提供的信息对每个网格在未来日期下的每个时间段的未来出行订单量和未来出行订单响应量进行预测，大大提高了出行需求预测的准确性。
作为一种可实现的方式，所述未来时间范围包括当前日期，所述根据预设的出行数据库中的第一历史出行数据，预测至少一个区域在未来时间范围内的用户出行信息，具体包括：
根据所述第一历史出行数据，预测每个网格在当前日期的出行订单总量和出行订单响应总量；
根据预设的时间段划分策略，获取每个网格中不同日期属性下历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势；所述日期属性包括工作日属性、双休日属性、节假日属性中的任一个；
根据每个所述网格在当前日期的出行订单总量和所述第一变化趋势，获得每个所述网格在当前日期的每个时间段的出行订单量；
根据每个所述网格在当前日期的出行订单响应总量和所述第二变化趋势，获得每个所述网格在当前日期的每个时间段的出行订单响应量。
作为一种可实现的方式，所述根据所述第一历史出行数据，预测每个网格在当前日期的出行订单总量和出行订单响应总量，具体包括：
以每个网格的标识为主键，根据所述第一历史出行数据构建每个所述网格的第一时间序列和第二时间序列；其中，所述第一时间序列中包括所述网格内每个历史日期下的历史出行订单总量，所述第二时间序列包括所述网格内每个历史日期下的历史出行订单响应总量；所述第一时间序列和所述第二时间序列的长度等于所述网格内的历史日期的数量；
根据第一arima模型和每个所述网格的第一时间序列，预测每个geohash网格在当前日期的出行订单总量；
根据第二arima模型和每个所述网格的第二时间序列，预测每个geohash网格在当前日期的出行订单响应总量。
作为一种可实现的方式，所述根据预设的时间段划分策略，获取每个网格中不同日期属性下历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势，具体包括：
以每个网格的标识和日期维度为主键，根据所述第一历史出行数据构建每个所述网格的至少一个第三时间序列和至少一个第四时间序列；其中，所述第三时间序列中包括一个历史日期下的不同时间段的历史出行订单量，所述第四时间序列包括所述一个历史日期下的不同时间段的历史出行订单响应量；
根据预设的日期属性对每个所述网格中的历史日期进行聚类，获得每个所述网格中的第一属性日期类；所述第一属性日期类包括多个满足所述日期属性的历史日期；
根据所述第一属性日期类下的所有第三时间序列，获得每个网格中所述日期属性下历史出行订单量的第一变化趋势；
根据所述第一属性日期类下的所有第四时间序列，获得每个网格中所述日期属性下历史出行订单响应量的第二变化趋势。
作为一种可实现的方式，每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的等待时间，具体包括：
每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的平均等待时间、每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的最大等待时间、每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的中值等待时间、每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的最小等待时间中的至少一个。
作为一种可实现的方式，所述第一历史出行订单还包括：发出所述第一历史出行订单的用户名，和/或，用户发出所述第一历史出行订单的地址。
作为一种可实现的方式，所述响应信息包括响应所述第二历史出行订单的司机名、响应所述第二历史出行订单时服务端设备的经纬度信息以及响应所述第二历史出行订单的时间。
该方式通过根据第一历史出行数据预测不同的网格在当前日期的出行订单量和出行订单响应量，为服务端设备提供了服务参考，从而使得用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
另一方面，本申请提供一种出行数据的获取方法，包括：
接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
根据所述用户出行信息向云端服务器发送出行请求。
上述方法，通过接收云端服务器发送的至少一个区域在未来时间范围内的用户出行信息并推送给用户，使得用户通过用户端设备有选择的向云端服务器发送出行请求，从而可以使得用户避免用户高峰时段或者应答车辆较少的区域等不利于用户约车的情况，大大提高了用户约车的及时响应率，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，大大提高了用户体验。
作为一种可实现的方式，所述方法还包括：
接收所述云端服务器发送的热点区域的信息并进行显示，所述热点区域为所述未来时间范围内的未来出行订单量和未来出行订单响应量的差值大于预设阈值的区域。
作为一种可实现的方式，所述接收所述云端服务器发送的热点区域的信息并进行显示，具体包括：
接收所述云端服务器发送的热点区域的信息；
根据所述热点区域的信息，将接收到的用户出行信息对应的区域进行热点区域标识显示。
作为一种可实现的方式，所述根据所述热点区域的信息，将接收到的用户出行信息对应的区域进行热点区域标识显示，包括：
若接收到的用户出行信息对应的区域为热点区域，将所述用户出行信息对应的区域进行颜色突出显示；
或者，
若接收到的用户出行信息对应的区域为热点区域，将所述用户出行信息对应的区域进行位置优先显示；
或者，
若接收到的用户出行信息对应的区域为热点区域，将所述用户出行信息对应的区域进行左上悬浮标记显示、或者右上悬浮标记显示。
该方式通过接收云端服务器发送的热点区域的信息，并根据该热点区域的信息将热点区域显示给用户，从而使得用户可以有针对性的向云端服务器发送出行请求，大大提高了用户的出行请求的响应率，极大地方便了用户的出行。
作为一种可实现的方式，根据所述用户出行信息向云端服务器发送出行请求，具体包括：
根据所述用户出行信息和所述热点区域的信息，确定向所述服务端设备发送出行请求的时间和地点；
根据所述发送出行请求的时间和地点，向云端服务器发送所述出行请求。
作为一种可实现的方式，所述接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息之前，还包括：
向云端服务器发送携带所述未来时间范围的获取请求，所述获取请求用于请求地图上至少一个区域在所述未来时间范围内的用户出行信息。
作为一种可实现的方式，所述获取请求还包括地理位置；所述接收云端服务器根据第一历史出行数据预测的所述用户出行信息，具体包括：
接收所述云端服务器根据所述第一历史出行数据预测的、与所述地理位置对应的用户出行信息。
作为一种可实现的方式，所述地理位置包括用户当前所处的地理位置、用户请求查询出行信息的其他地理位置中的至少一个。
作为一种可实现的方式，所述接收所述云端服务器根据所述第一历史出行数据预测的、与所述地理位置对应的用户出行信息并进行显示之后，所述方法还包括：
若所述地理位置所在的区域为热点区域，则向所述云端服务器发送出行价格上浮请求，以使所述云端服务器根据所述出行价格上浮请求分配为用户提供出行服务的服务端设备。
该方式通过使得云端服务器接收到该价格上浮请求时，根据该价格上浮请求为该用户优先分配提供出行服务的服务端设备，极大的提高用户出行的响应率，丰富了用户的体验。
另一方面，本申请提供一种出行数据的获取方法，包括：
接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
根据所述用户出行信息向服务端设备发送出行请求。
上述方法，通过接收云端服务器发送的至少一个区域在未来时间范围内的用户出行信息并推送给用户，使得用户通过用户端设备有选择的向服务端设备发送出行请求，从而可以使得用户避免用户高峰时段或者应答车辆较少的区域等不利于用户约车的情况，大大提高了用户约车的及时响应率，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，大大提高了用户体验。
另一方面，本申请提供一种出行数据的获取方法，包括：
接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
根据所述用户出行信息向云端服务器发送确认服务响应。
上述方法，通过接收云端服务器发送的至少一个区域在未来时间范围内的用户出行信息并推送给服务端设备，从而可以使得服务端设备根据该用户出行信息选择性的向云端服务器发送确认服务响应，以为用户进行服务，不仅使得用户端设备的出行需求能够及时被响应，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
作为一种可实现的方式，所述方法还包括：
接收所述云端服务器发送的热点区域的信息并进行显示，所述热点区域为所述未来时间范围内的未来出行订单量和未来出行订单响应量的差值大于预设阈值的区域。
作为一种可实现的方式，接收所述云端服务器发送的热点区域的信息并进行显示，具体包括：
接收所述云端服务器发送的热点区域的信息；
根据所述热点区域的信息，将接收到的用户出行信息对应的区域进行热点区域标识显示。
作为一种可实现的方式，所述根据所述热点区域的信息，将接收到的用户出行信息对应的区域进行热点区域标识显示，包括：
若接收到的用户出行信息对应的区域为热点区域，将所述用户出行信息对应的区域进行颜色突出显示；
或者，
若接收到的用户出行信息对应的区域为热点区域，将所述用户出行信息对应的区域进行位置优先显示；
或者，
若接收到的用户出行信息对应的区域为热点区域，将所述用户出行信息对应的区域进行左上悬浮标记显示、或者右上悬浮标记显示。
该方式通过接收云端服务器发送的热点区域的信息，并根据该热点区域的信息将热点区域显示给服务端设备的用户，从而使得服务端设备的用户有选择性的向云端服务器发送确认服务响应，以为用户进行服务，不仅使得用户端设备的出行需求能够及时被响应，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
作为一种可实现的方式，所述根据所述用户出行信息向云端服务器发送确认服务响应，具体包括：
根据所述用户出行信息和所述热点区域的信息，确定为用户端设备提供约车服务的时间和地点；
将所述提供约车服务的时间和地点携带在所述确认服务响应中发送给所述云端服务器。
作为一种可实现的方式，所述接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示之前，所述方法还包括：
向云端服务器发送携带所述未来时间范围的获取请求，所述获取请求用于请求地图上至少一个区域在所述未来时间范围内的用户出行信息。
作为一种可实现的方式，所述获取请求还包括地理位置；所述接收云端服务器根据第一历史出行数据预测的所述用户出行信息，具体包括：
接收所述云端服务器根据所述第一历史出行数据预测的、与所述地理位置对应的用户出行信息，所述地理位置包括用户当前所处的地理位置、用户请求查询出行信息的其他地理位置中的至少一个。
作为一种可实现的方式，所述接收所述云端服务器根据所述第一历史出行数据预测的、与所述地理位置对应的用户出行信息并进行显示之后，所述方法还包括：
若所述地理位置所在的区域为热点区域，则向所述云端服务器发送服务价格上浮请求，以使所述云端服务器将所述服务价格上浮请求发送给所述地理位置所在区域内的用户端设备。
该方式通过服务端设备向云端服务器发送价格上浮请求，以通知云端服务器当前的服务端设备需要通过加价的方式才可以为用户提供约车服务。当云端服务器接收到该价格上浮请求时，会将该价格上浮请求发送给该地理位置所在区域内的用户端设备，由用户端设备进行选择，服务端设备优先为同意加价的用户提供约车服务，保证了热点区域内的服务端设备的车主收益，丰富了用户的体验。
另一方面，本申请提供一种出行数据的获取方法，包括：
接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
根据所述用户出行信息为用户端设备提供出行服务。
上述方法，通过接收云端服务器发送的至少一个区域在未来时间范围内的用户出行信息并推送给服务端设备，从而可以使得服务端设备根据该用户出行信息为用户进行服务，不仅使得用户端设备的出行需求能够及时被响应，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
另一方面，本申请提供一种出行数据的获取装置，包括：
处理模块，用于根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息；其中，所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
发送模块，用于向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息，以使所述至少一个服务端设备根据所述用户出行信息为用户进行服务。
上述所提供的出行数据的获取装置，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
另一方面，本申请提供一种出行数据的获取装置，包括：
接收模块，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
显示模块，用于显示所述用户出行信息；
发送模块，用于根据所述用户出行信息向云端服务器发送出行请求。
上述所提供的出行数据的获取装置，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
另一方面，本申请提供一种出行数据的获取装置，包括：
接收模块，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
显示模块，用于显示所述用户出行信息；
发送模块，用于根据所述用户出行信息向服务端设备发送出行请求。
上述所提供的出行数据的获取装置，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
另一方面，本申请提供一种出行数据的获取装置，包括：
接收模块，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
显示模块，用于显示所述用户出行信息；
发送模块，用于根据所述用户出行信息向云端服务器发送确认服务响应。
上述所提供的出行数据的获取装置，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
另一方面，本申请提供一种出行数据的获取装置，包括：
接收模块，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
显示模块，用于显示所述用户出行信息；
发送模块，用于根据所述用户出行信息为用户端设备提供出行服务。
上述所提供的出行数据的获取装置，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
另一方面，本申请提供一种云端服务器，包括：处理器、与所述处理器耦合的收发器；
所述处理器，用于根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息；其中，所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
所述收发器，用于向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息。
上述所提供的云端服务器，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
另一方面，本申请提供一种用户端设备，包括：接收器、与所述接收器耦合的显示设备和发送器；
所述接收器，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
所述显示设备，用于显示所述用户出行信息；
发送器，用于根据所述用户出行信息向云端服务器发送出行请求。
上述所提供的用户端设备，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
另一方面，本申请提供一种用户端设备，包括：接收器、与所述接收器耦合的显示设备和发送器；
所述接收器，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
所述显示设备，用于显示所述用户出行信息；
发送器，用于根据所述用户出行信息向服务端设备发送出行请求。
上述所提供的用户端设备，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
另一方面，本申请提供一种服务端设备，包括：接收器、与所述接收器耦合的显示设备和发送器；
所述接收器，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
所述显示设备，用于显示所述用户出行信息；
所述发送器，用于根据所述用户出行信息向云端服务器发送确认服务响应。
上述所提供的服务端设备，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
另一方面，本申请提供一种服务端设备，包括：接收器、与所述接收器耦合的显示设备和发送器；
所述接收器，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
所述显示设备，用于显示所述用户出行信息；
所述发送器，用于根据所述用户出行信息为用户端设备提供出行服务。
上述所提供的服务端设备，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
另一方面，本申请提供一种出行数据的获取系统，包括：用户端设备、服务端设备和云端服务器；
所述云端服务器，用于根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息，并向至少一个服务端设备和至少一个用户端设备推送所述用户出行信息；
所述用户端设备，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示；以及，根据所述用户出行信息向服务端设备发送出行请求；
所述服务端设备，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示；以及，根据所述用户出行信息为用户端设备提供出行服务；
其中，所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量。
上述所提供的出行数据的获取系统，其有益效果可以参照上述各可实现方式中的出行数据的获取方法所带来的有益效果，在此不再赘述。
在本申请中，通过根据预设的出行数据库中的第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息，并向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息，以使服务端设备根据所述用户出行信息为用户进行服务，并使得用户端设备的出行需求能够及时被响应，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请的一种可选的geohash网格示意图；
图2为本申请一实施例提供的出行服务系统的场景架构图；
图3为本申请一实施例提供的出行数据的获取方法的流程示意图；
图4为本申请一实施例提供的出行数据的获取方法的流程示意图；
图5为本申请一实施例提供的出行数据的获取方法的流程示意图；
图6为本申请一实施例提供的出行数据的获取方法的流程示意图；
图7为本申请一实施例提供的预测每个网格在当前日期的出行订单总量和出行订单响应总量的方法流程示意图；
图8本申请一实施例提供的获得每个网格中不同日期属性下历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势的方法流程示意图；
图9为本申请一实施例提供的出行数据的获取方法的流程示意图；
图10为本申请一实施例提供界面示意图一；
图11为本申请一实施例提供界面示意图二；
图12为本申请一实施例提供的出行数据的获取方法的流程示意图；
图13为本申请一实施例提供界面示意图三；
图14为本申请一实施例提供的出行数据的获取方法的流程示意图；
图15为本申请一实施例提供界面示意图四；
图16为本申请一实施例提供界面示意图五；
图17为本申请一实施例提供界面示意图六；
图18为本申请一实施例提供界面示意图七；
图19为本申请一实施例提供的出行数据的获取方法的流程示意图；
图20为本申请一实施例提供的出行数据的获取方法的流程示意图；
图21为本申请一实施例提供界面示意图八；
图22为本申请一实施例提供的出行数据的获取方法的流程示意图；
图23为本申请一实施例提供的出行数据的获取方法的流程示意图；
图24为本申请一实施例提供的出行数据的获取方法的信令流程图；
图25为本申请一实施例提供的出行数据的获取装置结构示意图；
图26为本申请一实施例提供的出行数据的获取装置结构示意图；
图27为本申请一实施例提供的出行数据的获取装置结构示意图；
图28为本申请一实施例提供的出行数据的获取装置结构示意图；
图29为本申请一实施例提供的出行数据的获取装置结构示意图；
图30为本申请一实施例提供的出行数据的获取装置结构示意图；
图31为本申请一实施例提供的出行数据的获取装置结构示意图；
图32为本申请一实施例提供的出行数据的获取装置结构示意图；
图33为本申请一实施例提供的出行数据的获取装置结构示意图；
图34为本申请一实施例提供的出行数据的获取装置结构示意图；
图35为本申请一实施例提供的云端服务器的硬件结构示意图；
图36为本申请一实施例提供的用户端设备的硬件结构示意图；
图37为本申请一实施例提供的服务端设备的硬件结构示意图；
图38为本申请一实施例提供的出行数据的获取系统的结构示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。
为了清楚起见，首先说明本发明使用的特定词或短语的定义。
geohash：geohash是将二维的经纬度转换成字符串，比如图1所示的基础地图，上面展示了北京9个区域的geohash字符串，分别是wx4er，wx4g2、wx4g3等等，每一个字符串代表了某一矩形区域(geohash网格)。也就是说，这个矩形区域内所有的点(经纬度坐标)都共享相同的geohash字符串，这样既可以保护隐私(只表示大概区域位置而不是具体的点)，又比较容易做缓存。比如左上角这个区域内的用户不断发送位置信息请求餐馆数据，这些用户的geohash字符串都是wx4er，可以把wx4er作为索引(key)；由于地图数据库中存储有geohash网格和经纬度范围的对应关系，每个geohash字符串的key对应相应的值(value，可以将该value进行缓存)，该value可以包括不同类型的地图注点(pointofinteres，简称poi)信息，因此地图后台可以根据用户的位置请求，获得与wx4er对应的value，然后根据poi信息的属性进行筛选，得到该区域的餐馆信息。
本申请实施例涉及的出行数据的获取方法、装置和设备，可以适用于任一具有叫车服务、拼车服务、或者为用户提供其他出行服务的系统。如图2所示，该系统可以包括云端服务器、用户端设备和服务端设备。其中，用户端设备用于向云端服务器发起出行需求，云端服务器将出行需求公布在服务平台上，由服务端设备在服务平台上应答用户需求，并随之提供相应的出行服务，该服务平台例如是滴滴打车、uber打车、高德地图、百度地图等。另外，在本申请实施例中，云端服务器可以根据用户的历史出行数据，预测用户在未来某一天某一时间段的出行需求，并将预测的用户在未来时间内的用户出行信息发送给用户端设备和/或服务端设备，使得用户端设备可以根据云端服务器预测的用户出行信息获知当前哪些区域的出行需求量大，哪些区域的出行需求量小以及获知哪些区域当前提供服务的服务端设备较多，从而使得用户端设备可以根据该用户出行信息确定当前是否要向云端服务器发送出行需求，或者何时何地云端服务器发送出行需求；另外，也使得服务端设备(即司机端所使用的设备)可以根据该用户出行信息获知当前哪些区域的出行需求量大，哪些区域的出行需求量小，从而使得服务端设备可以根据该用户出行信息确定当前应该前往哪一个区域为用户提供服务或者何时为用户提供服务。即，本申请实施例方便服务端设备根据所预测的出行需求为用户提供服务，也满足用户端设备的出行需求，从而避免出现现有技术中用户出行需求和提供服务的服务端设备不匹配的情况，也保证了车主的收益。
可选的，上述用户端设备可以是手机、平板电脑、可穿戴设备、个人数字助理、pda等，上述服务端设备可以是手机、交通工具上的机载设备、可穿戴设备等，该交通工具可以包括但不限于：内燃机汽车或摩托车、电动汽车或摩托车、电动助力车、电动平衡车、遥控车辆等车辆。这里所涉及的车辆可以为单一的油路车辆、还可以是单一的汽路车辆、还可以是油汽结合的车辆、还可以是助力的电动车辆，本申请实施例对车辆的类型并不做限定；上述机载设备可以是车载导航、中控台等设备。
下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
图3为本申请一实施例提供的出行数据的获取方法的流程示意图。可选的，本申请实施例的执行主体可以是出行数据的获取装置，该装置可以通过软件、硬件或者软硬结合的方式实现，该装置可以集成在云端服务器中，还可以集成在管理云端服务器的核心网设备上，还可以是独立的云端服务器，本实施例以执行主体是云端服务器为例来进行说明。本实施例涉及的是云端服务器根据出行数据库中用户的第一历史出行数据，预测用户在未来时间范围内的出行需求，从而将所预测的用户出行需求发送给服务端设备，以使服务端设备根据预测的用户出行需求为用户提供出行服务的具体过程。如图3所示，该方法可以包括如下步骤：
s101：根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息。
其中，所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量。
具体的，本实施例中，为了避免出现现有技术中用户出行需求和提供服务的服务端设备不匹配的情况，并为了保证车主的收益，云端服务器可以将用户的历史出行数据(即第一历史出行数据)记录至出行数据库中，该第一历史出行数据可以用于表征地图上不同区域的历史出行订单信息，可选的，该历史出行订单信息可以包括用户的账号、用户名、出发地和目的地、订单数量等信息，也就是说上述出行数据库中包括了所有用户的历史出行订单信息。云端服务器可以根据该第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息，该用户出行信息包括每个区域在未来时间范围内的未来出行订单量和未来出行订单响应量(即未来出行订单被服务端设备响应的数量)。可选的，本申请实施例所涉及的区域，可以是云端服务器对地图上的基础地理信息进行geohash处理后得到的geohash网络、还可以是地图上的行政区域、还可以是地图上的其他区域等。可选的，上述未来时间范围可以是当天，可以是当天的某个时间段，还可以是未来连续几日，本申请实施例对未来时间范围的跨度并不做限制。
云端服务器在预测至少一个区域在未来时间范围内的用户出行信息时，例如可以是，云端服务器根据第一历史出行数据中某一个区域在某一些工作日的历史出行订单信息，来预测该区域在当前工作日的用户出行信息，可选的，其可以根据第一历史出行数据进行建模，然后将所预测的区域的标识和下一个工作日的日期作为模型的输入，得到模型的输出，该模型的输出即就是该区域在当前工作日的用户出行信息；再例如，云端服务器还可以根据第一历史出行数据中某一区域在一段时间内的订单变化趋势，来预测该区域在未来某个时间的用户出行信息。本申请实施例对云端服务器预测不同区域在未来时间范围内的用户出行信息的方式并不做限定，只要能够为服务端设备预测出用户未来的出行信息，为服务端设备服务用户提供参考依据即可。
s102：向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息。
具体的，云端服务器预测了至少一个区域在未来时间范围内的用户出行信息后，云端服务器将可以将至少一个区域中的部分区域或者全部区域在未来时间范围内的用户出行信息发送给至少一个服务端设备和/或至少一个服务端设备，即云端服务器可以广播所预测的用户出行信息；或者，云端服务器可以将所预测的用户出行信息有针对性的发送给查询该用户出行信息的服务端设备和/或用户端设备。
当服务端设备在接收到这些用户出行信息后，可以根据这些所预测的用户出行信息获知哪一个区域的未来出行需求量较大以及该区域未来出行需求被响应的数量，从而确定是否为该区域的用户服务。例如，当服务端设备通过所预测的至少一个区域在未来时间范围内的用户出行信息，获知区域a在星期一的未来出行订单量为1000，且区域a中的未来出行订单响应量超过98％，并且获知区域b在星期一的未来出行订单量为500，且区域b的未来出行订单响应量为20％，则服务端设备可以根据这些信息选择前往区域b，为区域b的用户提供出行服务，这样可以保证区域b的用户出行需求得到满足，也确保了服务端设备的车主的收益，大大提高了用户和车主的服务体验。
当用户端设备在接收到这些用户出行信息后，可以根据这些所预测的用户出行信息获知哪一个区域的未来出行需求量较大以及该区域未来出行需求被响应的数量，从而确定是否在该区域内发起出行需求；例如，当用户端设备通过所预测的至少一个区域在未来时间范围内的用户出行信息，获知区域a在星期一的未来出行订单量为1000，且区域a中的未来出行订单响应量超过98％，并且获知区域b在星期一的未来出行订单量为500，且区域b的未来出行订单响应量为20％，则用户端设备可以选择在区域a发起出行需求，以确保自身发出的出行需求能够及时被响应，从而大大提高了约车端的用户的使用体验。
本申请实施例提供的出行数据的获取方法，通过根据预设的出行数据库中的第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息，并向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息，以使服务端设备根据所述用户出行信息为用户进行服务，并使得用户端设备的出行需求能够及时被响应，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
图4为本申请一实施例提供的出行数据的获取方法的流程示意图。本实施例涉及的是云端服务器将热点区域的信息推送给至少一个服务端设备和/或至少一个用户端设备，以使服务端设备更好的为热点区域的用户提供服务、用户端设备可以有选择性的发起出行需求的具体过程。在上述实施例的基础上，进一步地，该方法还可以包括：
s201：根据每个所述区域在未来时间范围内的用户出行信息，获取每个所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量的差值。
具体的，云端服务器所获取的每个区域在未来时间范围内的未来出行订单量和未来出行订单响应量的差值，可以是未来出行订单量和未来出行订单响应量直接相减的差值，还可以是相减后加权的差值，这里的差值算法是由下述s202中的预设阈值决定的，若下述s202中的预设阈值为加权阈值，则未来出行订单量和未来出行订单响应量的差值即就是加权后的差值，若下述s202中的预设阈值为未加权的阈值，则未来出行订单量和未来出行订单响应量的差值即就是二者直接相减的差值。
s202：将所述差值大于预设阈值的区域确定为热点区域。
可选的，这里的热点区域实际上就是用户在未来时间范围内的未来出行订单较多的区域。可选的，热点区域可以为一个，也可以为多个。
s203：将所述热点区域的信息推送给所述至少一个服务端设备和/或所述至少一个用户端设备。
可选的，热点区域的信息可以是一个，也可以是多个，该热点区域的信息可以是热点区域的标识、热点区域的经纬度信息等。
可选的，当云端服务器所预测的用户出行信息所对应的区域可以是对地图中的基础地理位置信息进行离散处理后的网格，可选的，该网格可以以任一的方法进行划分，只要确保每个网格对应地图中的一个经纬度范围即可。可选的，该网格可以是geohash网格。上述热点区域的信息即就是差值大于上述预设阈值的geohash网格中的poi信息，其中，每个geohash网格对应地图中的一个经纬度范围，也就是说在某一个经纬度范围内的所有地理位置信息，均可以被划分在该经纬度范围对应的geohash网格中。上述poi信息可以是餐馆信息、建筑物信息等。为了方便描述，下述实施例中的网格均已geohash网格为例来进行说明。
服务端设备在接收到云端服务器发送的热点区域的信息之后，可以前往该热点区域的信息所指示的地理位置，更好的为热点区域内的用户提供服务，即更好的满足了热点区域的用户的出行需求，也更好的保证了车主的收益；另外，用户端设备在接收到云端服务器发送的热点区域的信息之后，可以选择前往该热点区域的信息所指示的地理位置进行约车服务，还可以是避开该热点区域进行约车服务，即用户端设备可以根据用户出行信息和该热点区域的信息自主的选择发起出行需求的地点，极大了提高了约车用户的体验。
图5为本申请一实施例提供的出行数据的获取方法的流程示意图。本实施例涉及的是云端服务器构建便于预测未来用户出行信息的出行数据库的具体过程。在上述实施例的基础上，进一步地，在上述s101之前，该方法还可以包括：
s301：对地图中的基础地理位置信息进行离散处理，获得至少一个网格。
具体的，本申请实施例中的地图可以是任意形式的地图，地图中的基础地理位置信息可以为一系列的经纬度信息，以geohash网格为例，云端服务器可以采用geohash技术对地图中的基础地理位置信息进行离散处理，获得至少一个geohash网格，每个geohash网格对应一个经纬度范围，且每个geohash网格各自对应一个标识，可选的，该标识可以为geohash字符串。
s302：根据预设的时间段划分策略，对获取的所有第一历史出行订单添加时间戳，得到至少一个第二历史出行订单。
其中，所述时间戳包括所述第一历史出行订单的发生日期和所述第一历史出行订单的发生时间所在的时间段标识；所述第一历史出行订单携带所述第一历史出行订单对应的经纬度信息和所述第一历史出行订单的发生时间。
具体的，出行订单数据库中记录地图上所有区域的所有用户的第一历史出行订单，云端服务器可以根据预设的时间段划分策略，为出行订单数据库中的每个第一历史出行订单添加时间戳，从而得到至少一个第二历史出行订单。其中，每个第一历史出行订单携带了第一历史出行订单对应的经纬度信息和该第一历史出行订单的发生时间，可选的，该第一历史出行订单还可以包括发出第一历史出行订单的用户名，和/或，用户发出第一历史出行订单的地址；因此，上述每个第二历史出行订单不仅包含第一历史出行订单上的所有信息，还包括了时间戳的信息。可选的，上述时间段划分策略可以包括：将一天24个小时按照相应的时间长度划分为若干个时间段，例如，可以将一天24个小时按照半小时的维度划分为48个时间段，每个时间段按照时间先后进行排序，其中，0点到0点30分为第一个时间段，以此类推，23点30分至24点为第48个时间段，本申请实施例对如何划分时间段并不做限定。
可选的，每个第一历史出行订单还可以携带一个订单标识，云端服务器为该第一历史出行订单添加时间戳之后得到的第二历史出行订单与该第一历史出行订单的订单标识相同。可选的，该订单标识可以是订单编号。
例如，若第一历史出行订单为“15***001用户a阿里巴巴西溪园区北纬**x度东经**y度2015-10-8-21:18:10”，其中“15***001”为该第一历史出行订单的编号或者标识，“用户a”为发出该第一历史出行订单的用户名，“阿里巴巴西溪园区”为发出第一历史出行订单的地址，“北纬**x度东经**y度”为发出第一历史出行订单的经纬度信息，“2015-10-8-21:18:10”为第一历史出行订单的发生时间；按照该例子，则添加时间戳之后得到的第二历史出行订单就可以为“15***001用户a阿里巴巴西溪园区北纬x度东经y度2015-10-8-21:18:102015-10-843”，其中，“2015-10-8”为第一历史出行订单的发生日期，“43”为第一历史出行订单的发生时间所在的时间段标识。
基于此，云端服务器就可以获知在每个历史日期的每个时间段内有多少个第二历史出行订单。
s303：根据每个所述第二历史出行订单和所获得的响应信息，生成第二历史出行数据。
其中，所述第二历史出行数据包括至少一个第三历史出行订单，每个第三历史出行订单包括所述第二历史出行订单和所述第二历史出行订单的响应状态；所述响应信息用于指示每个所述第二历史出行订单的响应状态。
具体的，响应数据库中记录的是每个第二历史出行订单的响应信息，该响应信息可以表征第二历史出行订单的响应状态，即表征第二历史出行订单是否被服务端设备响应以及被服务端设备响应时的具体信息，例如车主是否接单以及接单时的具体信息。故而，云端服务器可以根据上述每个第二历史出行订单和从响应数据库中获得的响应信息，生成第二历史出行数据，该第二历史出行数据包括至少一个第三历史出行订单，每个第三历史出行订单包括一个第二历史出行订单和该第二历史出行订单的响应状态。可选的，该响应消息可以包括响应所述第二历史出行订单的司机名、响应所述第二历史出行订单时服务端设备的经纬度信息以及响应所述第二历史出行订单的时间，可选的，该响应消息还可以包括第二历史出行订单的订单标识。
例如，假设针对上述s302中的第二历史出行订单，其响应信息为“15***001司机x北纬m度东经n度2015-10-8-21:19:00”，其中，“15***001”为第二历史出行订单的订单标识，“司机x”为响应该第二历史出行订单的司机名，“北纬m度东经n度”为响应该第二历史出行订单时服务端设备的经纬度信息，“2015-10-8-21:19:00”为响应该第二历史出行订单的时间。则云端服务器根据上述s302的例子中的第二历史订单和该响应信息，就可以得到第三历史出行订单，该第三历史出行订单可以为“15***001用户a阿里巴巴西溪园区北纬x度东经y度2015-10-8-21:18:102015-10-843是司机a北纬m度东经n度2015-10-8-21:19:002015-10-843”，其中，“15***001用户a阿里巴巴西溪园区北纬x度东经y度2015-10-8-21:18:102015-10-843”是第二历史出行订单，“是司机a北纬m度东经n度2015-10-8-21:19:002015-10-843”为该第二历史订单被响应以及被响应时的具体信息，即第二历史出行订单的响应状态。
采用同样的方式，云端服务器就可以得到其他第二历史出行订单对应的第三历史出行订单，多个第三历史出行订单构成第二历史出行数据。
s304：根据所述第二历史出行数据中每个第三历史出行订单的经纬度信息，将所述第二历史出行数据映射至所述至少一个网格，获得所述第一历史出行数据。
具体的，当云端服务器获得第二历史出行数据后，云端服务器可以确定第二历史出行数据中的每个第三历史出行订单的经纬度信息对应的geohash字符串，从而将第二历史出行数据中的每个第三历史出行订单与上述s301中确定的至少一个geohash网格进行映射，从而得到每个geohash网格对应的历史出行订单，从而构建得到出行数据库，该出行数据库中包括第一历史出行数据，其可以表征地图上不同geohash网格的历史出行订单信息。
可选的，该第一历史出行数据具体可以包括：每个网格在每个历史日期下的每个时间段的历史出行订单量和历史出行订单响应量，这里的历史出行订单量指的是该网格内每个历史日期下的每个时间段所有第三历史出行订单中的第二历史出行订单的总数量，历史出行订单响应量指的是该网格内每个历史日期下的每个时间段所有第三历史出行订单的被响应的总量；相应的，所预测的用户出行信息具体可以包括：每个网格在未来日期下的每个时间段的未来出行订单量和未来出行订单响应量。可选的，该第一历史出行数据还可以包括每个网格在每个历史日期下的每个时间段的历史出行订单被响应的等待时间，该等待时间可以是该网格在每个历史日期下的每个时间段的历史出行订单被响应的平均等待时间、该网格在每个历史日期下的每个时间段的历史出行订单被响应的最大等待时间、该网格在每个历史日期下的每个时间段的历史出行订单被响应的中值等待时间、该网格在每个历史日期下的每个时间段的历史出行订单被响应的最小等待时间中的至少一个。
可选的，上述第三历史出行订单的经纬度信息可以包括第二历史出行订单对应的经纬度信息以及该第二历史出行订单对应的响应信息中服务端设备响应该第二历史出行订单时的经纬度信息，当第二历史出行订单对应的经纬度信息对应的geohash字符串与响应信息中的经纬度信息对应的geohash字符串相同时，则最终确定的第三历史出行订单对应的geohash字符串即为一个，当第二历史出行订单对应的经纬度信息对应的geohash字符串与响应信息中的经纬度信息对应的geohash字符串不同时，则最终确定的第三历史出行订单对应的geohash字符串即为两个。这样，在将第二历史出行数据映射至上述至少一个geohash网格时，可以是：
1)将第三历史出行订单中的第二历史出行订单对应的经纬度信息按照其对应的geohash字符串映射至相应的geohash网格中；
2)将第三历史出行订单中的第二历史出行订单对应的响应信息中的经纬度信息按照其对应的geohash字符串映射至相应的geohash网格中；
最终映射的结果，可以分为两种情况：第一种，第二历史出行订单所映射到的geohash网格(即出行方所在的geohash网格)与响应信息所映射的geohash网格(即司机方所在的geohash网格)为同一个geohash网格，即出行方和司机方位于同一个geohash网格；第二种，第二历史出行订单所映射到的geohash网格与响应信息所映射的geohash网格不同，即出行方和司机方位于不同的geohash网格内。
因此，当出行方和司机方位于同一个geohash网格时，上述第一历史出行数据可以包括每个geohash网格在每个历史日期下的每个时间段的历史出行订单量和历史出行订单响应量，可选的，还可以包括每个geohash网格在每个历史日期下的每个时间段的历史出行订单被响应的等待时间。可选的，第一历史出行数据的具体格式可以是“geohash网格序号+历史日期+该历史日期下的时间段标识+历史出行订单量+历史出行订单响应量(即被响应的订单数)+平均等待时间+最大等待时间+中值等待时间+最小等待时间。
当出行方和司机方不在同一个geohash网格时，上述第一历史出行数据可以包括每个geohash网格在每个历史日期下的每个时间段的历史出行订单量和历史出行订单响应量、每个geohash网格在每个历史日期下的每个时间段的历史出行订单被该历史出行订单所属的geohash网格中的服务端设备所响应的订单量，可选的，还可以包括每个geohash网格在每个历史日期下的每个时间段的历史出行订单被响应的等待时间。可选的，这种情况下，第一历史出行数据的具体格式可以是“geohash网格序号+历史日期+该历史日期下的时间段标识+历史出行订单量+历史出行订单响应量(即被响应的订单数)+平均等待时间+最大等待时间+中值等待时间+最小等待时间+被当前历史出行订单所属的geohash网格中的服务端设备所响应的订单量。例如，假设历史出行订单所在的geohash网格为a，历史出行订单量为100，历史出行订单响应量也是100，但是被当前历史出行订单所属的geohash网格中的服务端设备所响应的订单量为90，其余的10个历史出行订单被其他的geohash网格中的服务端设备所响应。
综上所述，无论出行方和司机方是否在同一个geohash网格，出行数据库中的第一历史出行数据均表征了每个geohash网格在每个历史日期下的每个时间段的历史出行订单量和历史出行订单响应量，从而便于云端服务器根据第一历史出行数据所提供的信息对每个geohash网格在未来日期下的每个时间段的未来出行订单量和未来出行订单响应量进行预测，大大提高了出行需求预测的准确性。
本申请实施例提供的出行数据的获取方法，通过对地图中的基础地理位置信息进行离散处理得到至少一个网格，并根据预设的时间段划分策略，对从出行订单数据库中获取的所有第一历史出行订单添加时间戳，得到至少一个第二历史出行订单，然后根据每个第二历史出行订单和从响应数据库中获得的响应信息生成第二历史出行数据，进而根据该所述第二历史出行数据中每个第三历史出行订单的经纬度信息，将第二历史出行数据映射至所述至少一个网格，得到第一历史出行数据，从而使得云端服务器可以根据该第一历史出行数据获知每个网格在每个历史日期下的每个时间段的历史出行订单量和历史出行订单响应量，进而便于云端服务器根据第一历史出行数据所提供的信息对每个网格在未来日期下的每个时间段的未来出行订单量和未来出行订单响应量进行预测，大大提高了出行需求预测的准确性。
图6为本申请一实施例提供的出行数据的获取方法的流程示意图。本实施例涉及的是云端服务器根据第一历史出行数据，预测每个区域在未来时间范围内的用户出行信息的具体过程。本实施例中的“未来时间范围”可以包括当前日期，即云端服务器根据第一历史出行数据预测当天的用户出行信息。在上述实施例的基础上，进一步地，上述s101具体可以包括：
s401：根据所述第一历史出行数据，预测每个网格在当前日期的出行订单总量和出行订单响应总量。
具体的，仍然以geohash网格为例，云端服务器可以通过第一历史出行数据中每个geohash网格内的历史出行订单量以及历史出行订单响应量的连续变化趋势，来预测每个geohash网格在当前日期的出行订单总量和出行订单响应总量，还可以是通过相应的建模算法，以当前网格的每个历史日期为输入、每个历史日期下的历史出行订单量和历史出行订单响应量为输出，训练出相应的模型，然后将当前日期作为输入，所得到的输出就是当前日期的出行订单总量和出行订单响应量。
可选的，作为一种可能的实施方式，上述预测每个网格在当前日期的出行订单总量和出行订单响应总量的方法还可以参见图7所示的流程示意图，即本申请另一实施例提供了预测每个网格在当前日期的出行订单总量和出行订单响应总量的方法，具体为：
s501：以每个网格的标识为主键，根据所述第一历史出行数据构建每个所述网格的第一时间序列和第二时间序列。
其中，所述第一时间序列中包括所述网格内每个历史日期下的历史出行订单总量，所述第二时间序列包括所述网格内每个历史日期下的历史出行订单响应总量；所述第一时间序列和所述第二时间序列的长度等于所述网格内的历史日期的数量。
具体的，继续以geohash网格为例，每个geohash网格在每个历史日期下都有对应的历史出行订单量，则可以以每个geohash网格的标识为主键，以该geohash网格在每个历史日期下都有对应的历史出行订单量为value，获取每个geohash网格的第一时间序列和第二时间序列。以一个geohash网格为例来进行说明，该geohash网格的第一时间序列中包括该geohash网格内每个历史日期对应的历史出行订单总量，该第一时间序列的长度等于该geohash网格内的历史日期的天数，该geohash网格的第二时间序列包括该geohash网格内每个历史日期下的历史出行订单响应总量，该第二时间序列的长度等于该geohash网格内的历史日期的天数。
例如，假设第一历史出行数据库中包括geohash网格a在1月1日至1月30日每个历史日期下每个时间段的历史出行订单量和历史出行订单响应量，则geohash网格a的第一时间序列就包括1月1日至1月30日每天的历史出行订单量(即一天的所有时间段的历史出行订单量的总和)，第二时间序列就包括1月1日至1月30日每天的历史出行订单响应总量(即一天的所有时间段的历史出行订单响应量的总和)。
s502：根据第一arima模型和每个所述网格的第一时间序列，预测每个网格在当前日期的出行订单总量。
s503：根据第二arima模型和每个所述网格的第二时间序列，预测每个网格在当前日期的出行订单响应总量。
具体的，上述第一arima模型是针对出行订单建立的模型，因此，可以通过每个geohash网格的第一时间序列并结合该第一arima模型进行预测，得到每个geohash网格在当前日期的出行订单总量；另外，上述第二arima模型是针对出行订单响应量建立的模型，因此，可以通过每个geohash网格的第二时间序列并结合该第二arima模型进行预测，得到每个geohash网格在当前日期的出行订单响应总量。
综上，云端服务器就得到了每个网格在当前日期的出行订单总量和出行订单响应总量，然后执行s402。可选的，本申请实施例对上述s502和s503的执行顺序并不做限定。
s402：根据预设的时间段划分策略，获取每个网格中不同日期属性下历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势；所述日期属性包括工作日属性、双休日属性、节假日属性中的任一个。
具体的，继续以geohash网格为例，每个geohash网格中所包含的历史日期的日期属性可以包括工作日属性、双休日属性、节假日属性中的任一个，该节假日为元旦、春节、劳动节等法定假日，不包含双休日。因此，以工作日属性为例，云端服务器可以结合某个geohash网格内所有历史日期中工作日的历史出行订单量得到第一变化趋势，并且结合该geohash网格内所有历史日期中工作日的历史出行订单响应量得到第二变化趋势，其中，该第一变化趋势和第二变化趋势是以日期和按照上述时间段划分策略所划分的该日期下的时间段为维度的，即第一变化趋势表明历史出行订单量在不同工作日下的不同时间段的走势，第二变化趋势表明历史出行订单响应量在不同工作日下的不同时间段的走势。采用类似的方式，也可以得到每个geohash网格中双休日属性下的历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势，以及得到每个geohash网格中节假日属性下的历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势。
可选的，作为一种可能的实施方式，上述获得每个网格中不同日期属性下历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势，还可以参见图8所示的流程示意图，即本申请另一实施例提供了获得每个网格中不同日期属性下历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势的方法，继续以geohash网格为例，该方法具体为：
s601：以每个网格的标识和日期维度为主键，根据所述第一历史出行数据构建每个所述网格的至少一个第三时间序列和至少一个第四时间序列。
其中，所述第三时间序列中包括一个历史日期下的不同时间段的历史出行订单量，所述第四时间序列包括所述一个历史日期下的不同时间段的历史出行订单响应量。
具体的，每个geohash网格在每个历史日期的每个时间段都有对应的历史出行订单量，则可以以每个geohash网格的标识和日维度为主键，以该geohash网格在每个历史日期下的每个时间段对应的历史出行订单量为value，获取每个geohash网格的至少一个第三时间序列和至少一个第四时间序列。也就是说，对于一个geohash网格来说，一个历史日期对应一条第三时间序列和一个第四时间序列，该第三时间序列中包括该历史日期下的多个时间段的历史出行订单量，该第三时间序列的长度等于所划分的时间段的个数，该第四时间序列中包括该历史日期下的多个时间段的历史出行订单响应量，该第四时间序列的长度等于所划分的时间段的个数。
例如，以上述将一天划分为48个时间段的划分策略为例，假设第一历史出行数据库中包括geohash网格a在1月1日至1月30日每个历史日期下每个时间段的历史出行订单量和历史出行订单响应量，则对于该geohash网格a来说，可以包括30条第三时间序列和30条第四时间序列，即每个历史日期对应一条第三时间序列和一个第四时间序列，以1月1日为例，该1月1日的第三时间序列就包括：0点至0点30分这一时间段的历史出行订单量、0点30分至1点这一时间段的历史出行订单量、……以及23点30分至24点这一时间段的历史出行订单量，即第三时间序列包括48个时间段各自的历史出行订单量，相应的，第四时间序列包括48个时间段各自的历史出行订单响应量。
s602：根据预设的日期属性对每个所述网格中的历史日期进行聚类，获得每个所述网格中的第一属性日期类；所述第一属性日期类包括多个满足所述日期属性的历史日期。
具体的，假设云端服务器当前预设的日期属性为工作日属性，则云端服务器可以将每个geohash网格中的历史日期进行聚类，获得每个所述geohash网格中的工作日类(即第一属性日期类)，该工作日类可以包括多个满足该工作日期属性的历史日期(即历史工作日)，可选的，继续以上述第一历史出行数据库中包括geohash网格a在1月1日至1月30日每个历史日期下每个时间段的历史出行订单量和历史出行订单响应量为例，这里的聚类可以是：云端服务器选取一个工作日，将该工作日的历史出行订单量的变化趋势与上述30天中每一个工作日的历史出行订单量的变化趋势进行比对，将变化趋势相似性大于预设相似度阈值的工作日归到一类，得到geohash网格a中的工作日类(即第一属性日期类)，采用这种方法，就可以得到geohash网格a中的双休日类和节假日类。依次类推，得到每个geohash网格的第一属性日期类。
s603：根据所述第一属性日期类下的所有第三时间序列，获得每个网格中所述日期属性下历史出行订单量的第一变化趋势。
具体的，继续以第一属性日期类为工作日类为例，当云端服务器获得geohash网格a的工作日类时，云端服务器可以将该geohash网格a的工作日类下的所有的第三时间序列的第一个时间段的历史出行订单量进行平均，得到第一个时间段的平均订单量，然后将所有的第三时间序列的第二个时间段的历史出行订单量进行平均，得到第二个时间段的平均订单量，以此类推，得到48个时间段的平均订单量，将其按照各自的时间段顺序进行排列，得到geohash网格a中工作日属性下历史出行订单量的第一变化趋势。当预设日期属性是双休日和节假日时，采用此种方式，分别可以得到geohash网格a中双休日属性下历史出行订单量的第一变化趋势以及节假日属性下历史出行订单量的第一变化趋势。
s604：根据所述第一属性日期类下的所有第四时间序列，获得每个网格中所述日期属性下历史出行订单响应量的第二变化趋势。
具体的，继续以第一属性日期类为工作日类为例，当云端服务器获得geohash网格a的工作日类时，云端服务器可以将该geohash网格a的工作日类下的所有的第四时间序列的第一个时间段的历史出行订单响应量进行平均，得到第一个时间段的平均订单响应量，然后将所有的第四时间序列的第二个时间段的历史出行订单响应量进行平均，得到第二个时间段的平均订单响应量，以此类推，得到48个时间段的平均订单响应量，将其按照各自的时间段顺序进行排列，得到geohash网格a中工作日属性下历史出行订单响应量的第二变化趋势。采用此种方式，分别可以得到geohash网格a中双休日属性下历史出行订单响应量的第二变化趋势以及节假日属性下历史出行订单响应量的第二变化趋势。
综上所述，采用上述s602至s604的方法，就可以得到每个geohash网格中不同日期属性下历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势，然后执行s403和s404。可选的，本申请实施例对s603和s604的执行顺序并不做限定。
s403：根据每个所述网格在当前日期的出行订单总量和所述第一变化趋势，获得每个所述网格在当前日期的每个时间段的出行订单量。
s404：根据每个所述网格在当前日期的出行订单响应总量和所述第二变化趋势，获得每个所述网格在当前日期的每个时间段的出行订单响应量。
具体的，云端服务器在上述s401中已经预测得到每个geohash网格在当前日期的出行订单总量，因此，云端服务器可以根据上述s603中所得到的不同日期属性下的第一变化趋势，选择与当前日期的属性相同的第一变化趋势，根据该第一变化趋势获得每个geohash网格在当前日期的每个时间段的出行订单量。类似的，云端服务器可以根据上述s604中所得到的不同日期属性下的第二变化趋势，选择与当前日期的属性相同的第二变化趋势，根据该第二变化趋势获得每个geohash网格在当前日期的每个时间段的出行订单响应量。
可选的，本申请实施例对上述s403和s404的执行顺序并不做限定。
本申请实施例提供的出行数据的获取方法，可以根据第一历史出行数据预测不同的网格在当前日期的出行订单量和出行订单响应量，为服务端设备提供了服务参考，从而使得用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
图9为本申请一实施例提供的出行数据的获取方法的流程示意图。本实施例涉及的是用户端设获取未来时间范围内的用户出行信息，以根据该用户出行信息进行约车服务的具体过程。如图9所示，该方法包括：
s701：接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示。
所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量。
s702：根据所述用户出行信息向云端服务器发送出行请求。
具体的，云端服务器根据第一历史出行数据预测至少一个区域在未来时间范围内的用户出行信息可以参见上述实施例中介绍的具体过程，在此不再赘述。当云端服务器获取到至少一个区域在未来时间范围内的用户出行信息之后，云端服务器将该用户出行信息发送给用户端设备，用户端设备将该信息进行显示，便于用户通过用户端设备的界面查看该用户出行信息。可选的，用户端设备可以将该预测的用户出行信息进行分页显示或者分条显示，还可以通过图像或者动画的方式显示，并在动画显示的同时还可以配带相应的语音说明。该用户出行信息包括每个区域在未来时间范围内的未来出行订单量和未来出行订单响应量(即未来出行订单被服务端设备响应的数量)。可选的，本申请实施例所涉及的区域，可以是云端服务器对地图上的基础地理信息进行geohash处理后得到的geohash网络、还可以是地图上的行政区域、还可以是地图上的其他区域等。可选的，上述未来时间范围可以是当天，可以是当天的某个时间段，还可以是未来连续几日，本申请实施例对未来时间范围的跨度并不做限制。
当用户获知至少一个区域在未来时间范围的用户出行信息之后，用户根据该用户出行信息有选择性的向云端服务器发送出行请求，例如避开用车高峰时段、避免应答车辆较少的区域等。可选的，用户端设备在显示预测的用户出行信息的界面上，可以部署一虚拟控件a，点击该虚拟控件a就可以向云端服务器发送该用户的出行请求(参见图10所示的界面示意图一)，从而使得云端服务器将该出行请求公布在服务平台上，由服务端设备在服务平台上应答用户需求，并随之提供相应的出行服务。
本申请实施例提供的出行数据的获取方法，通过接收云端服务器发送的至少一个区域在未来时间范围内的用户出行信息并推送给用户，使得用户通过用户端设备有选择的向云端服务器发送出行请求，从而可以使得用户避免用户高峰时段或者应答车辆较少的区域等不利于用户约车的情况，大大提高了用户约车的及时响应率，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，大大提高了用户体验。
可选的，上述用户出行信息可以是云端服务器主动推送给用户端设备的，还可以是用户端设备通过向云端服务器发送携带未来时间范围(即预测的时间段)的获取请求，来查询地图上至少一个区域在该未来时间范围内的用户出行信息，本申请实施例对此并不做限定。可选的，上述获取请求还可以包括地理位置，则上述s701具体可以为：接收所述云端服务器根据所述第一历史出行数据预测的、与所述地理位置对应的用户出行信息。
也就是说，当用户需要查询某一地理位置在未来时间范围内的用户出行信息时，用户可以通过用户端设备向云端服务器发送获取请求，该获取请求中携带用户所需查询的地理位置和所需预测的未来时间范围，云端服务器在接收到该获取请求后，可以根据上述第一历史出行数据预测该地理位置在未来时间范围内的用户出行信息，从而将与该地理位置对应的用户出行信息发送给用户端设备。可选的，上述地理位置可以是用户当前所处的地理位置、还可以是用户请求查询出行信息的其他地理位置(例如用户当前处于地理位置a，但用户想查询地理位置b在未来时间范围内的用户出行信息)，还可以是用户当前所处的地理位置和用户请求查询出行信息的其他地理位置。可选的，参见图11所示的界面示意图二，在虚拟控件b的左边设置一输入框，用户在输入框中输入想要查询的地理位置和未来时间范围，然后点击右边的虚拟控件b，就可以向云端服务器发送携带地理位置和未来时间范围的获取请求。当然，上述图10和图11均是一种界面显示示例，本申请对用户通过用户端设备向云端服务器发送获取请求的方式并不做限定。
图12为本申请一实施例提供的出行数据的获取方法的流程示意图。本实施例涉及的是云端服务器将所预测的热点区域的信息推送给用户端设备之后，用户端设备的处理过程。在上述实施例的基础上，进一步地，上述方法还可以包括：
s801：接收所述云端服务器发送的热点区域的信息并进行显示，所述热点区域为所述未来时间范围内的未来出行订单量和未来出行订单响应量的差值大于预设阈值的区域。
具体的，云端服务器确定热点区域的具体过程可以参见上述图4所示的实施例的具体过程，在此不再赘述，该热点区域为上述未来时间范围内的未来出行订单量和未来出行订单响应量的差值大于预设阈值的区域。当云端服务器确定热点区域之后，将该热点区域的信息发送给用户端设备。可选的，该热点区域的信息可以是该热点区域的标识或者该热点区域的经纬度坐标等。
用户端设备在接收到该热点区域的信息之后，可以根据该热点区域的信息将热点区域进行显示，从而使得用户可以获知当前哪些区域是热点区域，然后决定当前是否避让热点区域以发送出行请求。
可选的，用户端设备在接收到该热点区域的信息之后，还可以根据之前接收到的用户出行信息和该热点区域的信息，确定向云端服务器发送出行请求的时间和地点，然后根据所确定的发送出行请求的时间和地点，向云端服务器发送该出行请求，从而使得用户能够根据详细的预测信息有针对性的向云端服务器发送出行请求，大大提高了用户的出行请求的响应率。
可选的，若上述用户请求查询的地理位置所在的区域为热点区域，则用户可以通过用户端设备向云端服务器发送价格上浮请求，以通知云端服务器当前的用户可以通过加价的方式要求约车服务。当云端服务器接收到该价格上浮请求时，根据该价格上浮请求为该用户优先分配提供出行服务的服务端设备，极大的提高用户出行的响应率，丰富了用户的体验。
可选的，用户端设备根据该热点区域的信息将热点区域进行显示时，可以是将该热点区域与之前显示的用户出行信息对应的区域进行分开显示，例如，参见图13所示的界面示意图三。可选的，还可以是根据该热点区域的信息，将之前接收到的用户出行信息对应的区域进行热点区域标识，例如参见图14所示的本申请一实施例提供的出行数据的获取方法的流程示意图以及参见图15至图18所示的界面示意图四至七，即上述s801具体可以包括：
s901：接收所述云端服务器发送的热点区域的信息。
s902：根据所述热点区域的信息，将接收到的用户出行信息对应的区域进行热点区域标识显示。
具体的，当接收到的用户出行信息对应的区域为热点区域时，可选的，可以将该用户出行信息对应的区域进行颜色突出显示，即将热点区域的颜色与其他用户出行信息对应的区域的颜色分开标识，参见图15所示；可选的，还可以将所述用户出行信息对应的区域进行位置优先显示，即如果之前接收到的用户出行信息是分条显示，则将热点区域和热点区域对应的用户出行信息放在最顶端显示，参见图16所示，可选的，还可以将所述用户出行信息对应的区域进行左上悬浮标记显示、或者右上悬浮标记显示，参见图17或图18所示。
本申请实施例提供的出行数据的获取方法，通过接收云端服务器发送的热点区域的信息，并根据该热点区域的信息将热点区域显示给用户，从而使得用户可以有针对性的向云端服务器发送出行请求，大大提高了用户的出行请求的响应率，极大地方便了用户的出行。
图19为本申请一实施例提供的出行数据的获取方法的流程示意图。本实施例涉及的是用户端设获取未来时间范围内的用户出行信息，以根据该用户出行信息进行约车服务的具体过程。如图19所示，该方法包括：
s1001：接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示。
所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量。
该s1001的步骤，可以参见上述实施例中介绍的具体过程，在此不再赘述。当云端服务器获取到至少一个区域在未来时间范围内的用户出行信息之后，云端服务器将该用户出行信息发送给用户端设备，用户端设备将该信息进行显示，便于用户通过用户端设备的界面查看该用户出行信息。
s1002：根据所述用户出行信息向服务端设备发送出行请求。
具体的，当用户获知至少一个区域在未来时间范围的用户出行信息之后，用户根据该用户出行信息有选择性的向服务端设备发送出行请求，可选的，如果服务端设备和用户端设备距离较近，可以通过蓝牙的方式或其他近场通信的方式有针对性的向该服务端设备发送出行请求，以使该服务端设备为该用户提供出行服务。具体的用户出行信息的显示方式可以参见是上述图10所示。
本申请实施例提供的出行数据的获取方法，通过接收云端服务器发送的至少一个区域在未来时间范围内的用户出行信息并推送给用户，使得用户通过用户端设备有选择的向服务端设备发送出行请求，从而可以使得用户避免用户高峰时段或者应答车辆较少的区域等不利于用户约车的情况，大大提高了用户约车的及时响应率，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，大大提高了用户体验。
图20为本申请一实施例提供的出行数据的获取方法的流程示意图。本实施例涉及的是服务端设获取未来时间范围内的用户出行信息，以根据该用户出行信息为用户提供出行服务的具体过程。如图20所示，该方法包括：
s1101：接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示。
所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量。
s1102：根据所述用户出行信息向云端服务器发送确认服务响应。
具体的，云端服务器根据第一历史出行数据预测至少一个区域在未来时间范围内的用户出行信息可以参见上述实施例中介绍的具体过程，在此不再赘述。当云端服务器获取到至少一个区域在未来时间范围内的用户出行信息之后，云端服务器将该用户出行信息发送给服务端设备，服务端设备将该信息进行显示，便于服务端设备的用户(例如车主或者司机，下述实施例服务端设备的用户以司机为例来说明)通过服务端设备的界面查看该用户出行信息。可选的，服务端设备可以将该预测的用户出行信息进行分页显示或者分条显示，还可以通过图像或者动画的方式显示，并在动画显示的同时还可以配带相应的语音说明。该用户出行信息包括每个区域在未来时间范围内的未来出行订单量和未来出行订单响应量(即未来出行订单被服务端设备响应的数量)。可选的，本申请实施例所涉及的区域，可以是云端服务器对地图上的基础地理信息进行geohash处理后得到的geohash网络、还可以是地图上的行政区域、还可以是地图上的其他区域等。可选的，上述未来时间范围可以是当天，可以是当天的某个时间段，还可以是未来连续几日，本申请实施例对未来时间范围的跨度并不做限制。
当司机获知至少一个区域在未来时间范围的用户出行信息之后，司机根据该用户出行信息获知哪些区域的出行订单量大，哪些区域的出行订单量小，还可以获知哪些区域的出行订单响应量大等信息，从而使得司机可以向云端服务器有选择性的发送确认服务响应，例如通过在确认服务响应中携带提供服务的区域，以避开距离服务端设备当前所处位置较远的区域，从而使得云端服务器获知在未来时间范围内能够提供出行服务的服务端设备，进而使得云端服务器在未来某个时间接收到用户的出行请求时，能够合理的为用户分配能够提供出行服务的服务端设备。
可选的，服务端设备在显示预测的用户出行信息的界面上，可以部署一虚拟控件，点击该虚拟控件就可以向云端服务器发送确认服务响应(参见图21所示的界面示意图八)，从而使得云端服务器记录各服务端设备的确认服务响应，从而在云端服务器接收到用户的出行请求时，为该出行请求匹配合适的服务端设备，即由服务端设备在服务平台上应答用户需求，并随之提供相应的出行服务。
本申请实施例提供的出行数据的获取方法，通过接收云端服务器发送的至少一个区域在未来时间范围内的用户出行信息并推送给服务端设备，从而可以使得服务端设备根据该用户出行信息选择性的向云端服务器发送确认服务响应，以为用户进行服务，不仅使得用户端设备的出行需求能够及时被响应，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
可选的，上述用户出行信息可以是云端服务器主动推送给服务端设备的，还可以是服务端设备通过向云端服务器发送携带未来时间范围(即预测的时间段)的获取请求，来查询地图上至少一个区域在该未来时间范围内的用户出行信息，本申请实施例对此并不做限定。可选的，上述获取请求还可以包括地理位置，则上述s1101具体可以为：接收所述云端服务器根据所述第一历史出行数据预测的、与所述地理位置对应的用户出行信息。
也就是说，当司机需要查询某一地理位置在未来时间范围内的用户出行信息时，司机通过服务端设备向云端服务器发送获取请求，该获取请求中携带该用户所需查询的地理位置和所需预测的未来时间范围，云端服务器在接收到该获取请求后，可以根据上述第一历史出行数据预测该地理位置在未来时间范围内的用户出行信息，从而将与该地理位置对应的用户出行信息发送给服务端设备。可选的，上述地理位置可以是司机当前所处的地理位置、还可以是司机请求查询出行信息的其他地理位置(例如司机当前处于地理位置a，但司机想查询地理位置b在未来时间范围内的用户出行信息)，还可以是司机当前所处的地理位置和司机请求查询出行信息的其他地理位置。具体的显示方式可以参见上述图11所示的界面示意图二，用户需要在输入框中输入想要查询的地理位置和未来时间范围，然后点击右边的虚拟控件b，就可以向云端服务器发送携带地理位置和未来时间范围的获取请求。
图22为本申请一实施例提供的出行数据的获取方法的流程示意图。本实施例涉及的是云端服务器将所预测的热点区域的信息推送给服务端设备之后，服务端设备的处理过程。在上述实施例的基础上，进一步地，上述方法还可以包括：
s1201：接收所述云端服务器发送的热点区域的信息并进行显示，所述热点区域为所述未来时间范围内的未来出行订单量和未来出行订单响应量的差值大于预设阈值的区域。
具体的，云端服务器确定热点区域的具体过程可以参见上述图4所示的实施例的具体过程，在此不再赘述，该热点区域为上述未来时间范围内的未来出行订单量和未来出行订单响应量的差值大于预设阈值的区域。当云端服务器确定热点区域之后，将该热点区域的信息发送给服务端设备。可选的，该热点区域的信息可以是该热点区域的标识或者该热点区域的经纬度坐标等。
服务端设备在接收到该热点区域的信息之后，可以根据该热点区域的信息将热点区域进行显示，从而使得服务端设备的用户可以获知当前哪些区域是热点区域，然后决定当前是否前往热点区域为用户提供出行服务。
可选的，服务端设备在接收到该热点区域的信息之后，可以根据之前接收到的用户出行信息和该热点区域的信息，确定为用户端设备提供约车服务的时间和地点，从而将提供约车服务的时间和地点携带在上述确认服务响应中发送给所述云端服务器，从而避免服务端设备盲目的在某一区域某一时间段提供约车服务，而错失了出行订单量较大的区域或者时间段，从而大大提高了服务端设备的订单响应率，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
可选的，若上述用户请求查询的地理位置所在的区域为热点区域，则用户可以通过服务端设备向云端服务器发送价格上浮请求，以通知云端服务器当前的服务端设备需要通过加价的方式才可以为用户提供约车服务。当云端服务器接收到该价格上浮请求时，会将该价格上浮请求发送给该地理位置所在区域内的用户端设备，由用户端设备进行选择，服务端设备优先为同意加价的用户提供约车服务，保证了热点区域内的服务端设备的车主收益，丰富了用户的体验。
可选的，服务端设备根据该热点区域的信息将热点区域进行显示时，可以是将该热点区域与之前显示的用户出行信息对应的区域进行分开显示，例如可以参见上述图13所示的界面示意图三。可选的，还可以是根据该热点区域的信息，将之前接收到的用户出行信息对应的区域进行热点区域标识，例如上述图15至图18所示的界面示意图四至七，即当接收到的用户出行信息对应的区域为热点区域时，可选的，可以将该用户出行信息对应的区域进行颜色突出显示，即将热点区域的颜色与其他用户出行信息对应的区域的颜色分开标识，参见上述图15所示；可选的，还可以将所述用户出行信息对应的区域进行位置优先显示，即如果之前接收到的用户出行信息是分条显示，则将热点区域和热点区域对应的用户出行信息放在最顶端显示，参见上述图16所示，可选的，还可以将所述用户出行信息对应的区域进行左上悬浮标记显示、或者右上悬浮标记显示，参见上述图17或上述图18所示。
本申请实施例提供的出行数据的获取方法，通过接收云端服务器发送的热点区域的信息，并根据该热点区域的信息将热点区域显示给服务端设备的用户，从而使得服务端设备的用户有选择性的向云端服务器发送确认服务响应，以为用户进行服务，不仅使得用户端设备的出行需求能够及时被响应，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
图23为本申请一实施例提供的出行数据的获取方法的流程示意图。本实施例涉及的是服务端设获取未来时间范围内的用户出行信息，以根据该用户出行信息为用户提供出行服务的具体过程。如图23所示，该方法包括：
s1301：接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示。
所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量。
该s1301的步骤，可以参见上述实施例中介绍的具体过程，在此不再赘述。当云端服务器获取到至少一个区域在未来时间范围内的用户出行信息之后，云端服务器将该用户出行信息发送给服务端设备，服务端设备将该信息进行显示，便于司机通过服务端设备的界面查看所预测的用户出行信息。
s1302：根据所述用户出行信息为用户端设备提供出行服务。
具体的，当服务端设备在接收到这些用户出行信息后，可以根据这些所预测的用户出行信息获知哪一个区域的未来出行需求量较大以及该区域未来出行需求被响应的数量，从而确定是否为该区域的用户服务。例如，当服务端设备通过所预测的至少一个区域在未来时间范围内的用户出行信息，获知区域a在星期一的未来出行订单量为1000，且区域a中的未来出行订单响应量超过98％，并且获知区域b在星期一的未来出行订单量为500，且区域b的未来出行订单响应量为20％，则服务端设备可以根据这些信息选择前往区域b，为区域b的用户提供出行服务，这样可以保证区域b的用户出行需求得到满足，也确保了服务端设备的车主的收益，大大提高了用户和车主的服务体验。
本申请实施例提供的出行数据的获取方法，通过接收云端服务器发送的至少一个区域在未来时间范围内的用户出行信息并推送给服务端设备，从而可以使得服务端设备根据该用户出行信息为用户进行服务，不仅使得用户端设备的出行需求能够及时被响应，进而确保用户出行需求和提供服务的服务端设备匹配，满足了用户的出行需求，也保证了车主的收益，大大提高了用户和车主的服务体验。
图24为本申请一实施例提供的出行数据的获取方法的信令流程图。本实施例涉及的是云端服务器根据第一历史出行数据为用户端设备以及服务端设备预测至少一个区域在未来时间范围内的用户出行信息，用户端设备和服务端设备根据用户出行信息为用户提供相应的查询或者约车服务等处理过程。如图24所示，该方法包括：
s1401：云端服务器根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息。
其中，所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量。
s1402：云端服务器向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息，以使所述至少一个服务端设备根据所述用户出行信息为用户进行服务。
s1403：用户端设备将接收到的用户出行信息显示给用户端设备侧的用户。
s1404：服务端设备将接收到的用户出行信息显示给服务端设备侧的用户。
可选的，在上述s1401之后，云端服务器还可以根据每个区域在未来时间范围内的用户出行信息，确定热点区域的信息，具体确定过程可以参见上述图4所示的实施例，在此不再赘述。
故而，可选的，在上述s1402之后，云端服务器还可以向至少一个用户端设备和至少一个服务端设备发送热点区域的信息。
s1405：用户端设备根据所述用户出行信息，或者根据用户出行信息和热点区域的信息，向云端服务器发送出行请求。
s1406：服务端设备根据所述用户出行信息，或者根据用户出行信息和热点区域的信息，向云端服务器发送确认服务响应。
s1407：云端服务器根据服务端设备的确认服务响应和用户端设备的出行请求，为用户端设备合理的分配服务端设备。
上述s1401至s1407的具体过程可以参见上述图2至图23所示的实施例，其实现原理和技术效果类似，在此不再赘述。
以下将详细描述根据本申请的一个或多个实施例的出行数据的获取装置。该出行数据的获取装置的部分或者全部可以被实现在云端服务器上或者管理云端服务器的设备上，还可以被集成在用户端设备上，还可以被集成在服务端设备上。本领域技术人员可以理解，该出行数据的获取装置的部分或者全部均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。例如，下述实施例中的涉及处理功能、确定功能的模块可以使用单片机、微控制器、微处理器等组件实现。
下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。
图25为本申请一实施例提供的出行数据的获取装置结构示意图，该出行数据的获取装置，可以通过软件、硬件或者软硬结合两者的结合实现。如图25所示，该装置可以包括：处理模块10和发送模块11。
处理模块10，用于根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息；其中，所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
发送模块11，用于向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息。
本申请实施例提供的出行数据的获取装置，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图26为本申请一实施例提供的出行数据的获取装置结构示意图，在上述图25所示实施例的基础上，进一步地，该出行数据的获取装置还可以包括：第一获取模块12和确定模块13。
具体的，第一获取模块12，用于根据每个所述区域在未来时间范围内的用户出行信息，获取每个所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量的差值；
确定模块13，用于将所述差值大于预设阈值的区域确定为热点区域；
所述发送模块11，还用于将所述热点区域的信息推送给所述至少一个服务端设备。
进一步地，所述区域为对地图中的基础地理位置信息进行离散处理后的网格，每个网格对应地图中的一个经纬度范围；
所述热点区域的信息为所述差值大于所述预设阈值的网格中的地图注点poi信息。
本申请实施例提供的出行数据的获取装置，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图27为本申请一实施例提供的出行数据的获取装置结构示意图，在上述图26所示实施例的基础上，进一步地，该出行数据的获取装置还可以包括：第二获取模块14、第三获取模块15、第四获取模块16和构建模块17。
具体的，第二获取模块14，用于对地图中的基础地理位置信息进行离散处理，获得至少一个网格；
第三获取模块15，用于根据预设的时间段划分策略，对获取的所有第一历史出行订单添加时间戳，得到至少一个第二历史出行订单；所述时间戳包括所述第一历史出行订单的发生日期和所述第一历史出行订单的发生时间所在的时间段标识；所述第一历史出行订单携带所述第一历史出行订单对应的经纬度信息和所述第一历史出行订单的发生时间；
第四获取模块16，用于根据每个所述第二历史出行订单和所获得的响应信息，生成第二历史出行数据，所述第二历史出行数据包括至少一个第三历史出行订单，每个第三历史出行订单包括所述第二历史出行订单和所述第二历史出行订单的响应状态；所述响应信息用于指示每个所述第二历史出行订单的响应状态；
构建模块17，用于根据所述第二历史出行数据中每个所述第三历史出行订单的经纬度信息，将所述第二历史出行数据映射至所述至少一个网格，获得所述第一历史出行数据。
可选的，所述第一历史出行数据具体包括：所述第一历史出行数据具体包括：每个所述网格在每个历史日期下的每个时间段的历史出行订单量和历史出行订单响应量；
相应的，
所述用户出行信息具体包括：所述网格在未来日期下的每个时间段的未来出行订单量和未来出行订单响应量。
可选的，所述第一历史出行数据还包括：所述第一历史出行数据还包括：每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的等待时间，和/或，每个所述网格在每个历史日期下的每个时间段的历史出行订单被所述历史出行订单所属的网格中的服务端设备所响应的订单量。
本申请实施例提供的出行数据的获取装置，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图28为本申请一实施例提供的出行数据的获取装置结构示意图，在上述图27所示实施例的基础上，进一步地，所述处理模块10，具体包括：预测子模块101、第一获取子模块102、第二获取子模块103。
具体的，预测子模块101，用于根据所述第一历史出行数据，预测每个网格在当前日期的出行订单总量和出行订单响应总量；
第一获取子模块102，用于根据预设的时间段划分策略，获取每个网格中不同日期属性下历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势；所述日期属性包括工作日属性、双休日属性、节假日属性中的任一个；
第二获取子模块103，用于根据每个所述网格在当前日期的出行订单总量和所述第一变化趋势，获得每个所述网格在当前日期的每个时间段的出行订单量，并根据每个所述网格在当前日期的出行订单响应总量和所述第二变化趋势，获得每个所述网格在当前日期的每个时间段的出行订单响应量。
继续参见上述图29所示的装置结构，上述预测子模块101，具体可以包括：第一构建单元1011和预测单元1012。
具体的，第一构建单元1011，用于以每个网格的标识为主键，根据所述第一历史出行数据构建每个所述网格的第一时间序列和第二时间序列；其中，所述第一时间序列中包括所述网格内每个历史日期下的历史出行订单总量，所述第二时间序列包括所述网格内每个历史日期下的历史出行订单响应总量；所述第一时间序列和所述第二时间序列的长度等于所述网格内的历史日期的数量；
预测单元1012，用于根据第一arima模型和每个所述网格的第一时间序列，预测每个网格在当前日期的出行订单总量，并根据第二arima模型和每个所述网格的第二时间序列，预测每个网格在当前日期的出行订单响应总量。
继续参见上述图29所示的装置结构，上述第一获取子模块102，具体包括：第二构建单元1021、聚类单元1022和变化趋势获取单元1023。
具体的，第二构建单元1021，用于以每个网格的标识和日期维度为主键，根据所述第一历史出行数据构建每个所述网格的至少一个第三时间序列和至少一个第四时间序列；其中，所述第三时间序列中包括一个历史日期下的不同时间段的历史出行订单量，所述第四时间序列包括所述一个历史日期下的不同时间段的历史出行订单响应量；
聚类单元1022，用于根据预设的日期属性对每个所述网格中的历史日期进行聚类，获得每个所述网格中的第一属性日期类；所述第一属性日期类包括多个满足所述日期属性的历史日期；
变化趋势获取单元1023，用于根据所述第一属性日期类下的所有第三时间序列，获得每个网格中所述日期属性下历史出行订单量的第一变化趋势，并根据所述第一属性日期类下的所有第四时间序列，获得每个网格中所述日期属性下历史出行订单响应量的第二变化趋势。
可选的，每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的等待时间，具体包括：
每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的平均等待时间、每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的最大等待时间、每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的中值等待时间、每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的最小等待时间中的至少一个。
可选的，所述第一历史出行订单还包括：发出所述第一历史出行订单的用户名，和/或，用户发出所述第一历史出行订单的地址。
可选的，所述响应信息包括响应所述第二历史出行订单的司机名、响应所述第二历史出行订单时服务端设备的经纬度信息以及响应所述第二历史出行订单的时间。
本申请实施例提供的出行数据的获取装置，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图29为本申请一实施例提供的出行数据的获取装置的结构示意图。该出行数据的获取装置可以被集成在用户端设备上，其可以通过软件、硬件或者软硬结合的方式实现。如图29所示，该装置可以包括接收模块20、显示模块21和发送模块22。
具体的，接收模块20，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
显示模块21，用于显示所述用户出行信息；
发送模块22，用于根据所述用户出行信息向云端服务器发送出行请求。
本申请实施例提供的出行数据的获取装置，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
所述接收模块20，还用于接收所述云端服务器发送的热点区域的信息，所述热点区域为所述未来时间范围内的未来出行订单量和未来出行订单响应量的差值大于预设阈值的区域；
所述显示模块21，还用于显示所述热点区域。
图30为本申请一实施例提供的出行数据的获取装置的结构示意图。该出行数据的获取装置可以被集成在用户端设备上，其可以通过软件、硬件或者软硬结合的方式实现。在图29所示实施例的基础上，如图30所示，该装置还可以包括处理模块23。
具体的，处理模块23，用于根据所述用户出行信息和所述热点区域的信息，确定向所述云端服务器发送出行请求的时间和地点；
所述发送模块22，具体用于根据所述发送出行请求的时间和地点，向云端服务器发送所述出行请求。
进一步地，所述显示模块21，具体用于根据所述热点区域的信息，将所述接收模块20接收到的用户出行信息对应的区域进行热点区域标识显示。
本申请实施例提供的出行数据的获取装置，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图31为本申请一实施例提供的出行数据的获取装置的结构示意图。该出行数据的获取装置可以被集成在用户端设备上，其可以通过软件、硬件或者软硬结合的方式实现。如图31所示，该装置可以包括：接收模块30、显示模块31和发送模块32。
具体的，接收模块30，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
显示模块31，用于显示所述用户出行信息；
发送模块32，用于根据所述用户出行信息向服务端设备发送出行请求。
本申请实施例提供的出行数据的获取装置，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图32为本申请一实施例提供的出行数据的获取装置的结构示意图。该出行数据的获取装置可以被集成在服务端设备上，其可以通过软件、硬件或者软硬结合的方式实现。如图32所示，该装置可以包括：接收模块40、显示模块41和发送模块42。
具体的，接收模块40，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
显示模块41，用于显示所述用户出行信息；
发送模块42，用于根据所述用户出行信息向云端服务器发送确认服务响应。
本申请实施例提供的出行数据的获取装置，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
可选的，所述接收模块40，还用于接收所述云端服务器发送的热点区域的信息；所述热点区域为所述未来时间范围内的未来出行订单量和未来出行订单响应量的差值大于预设阈值的区域；
所述显示模块41，还用于显示所述热点区域。
图33为本申请一实施例提供的出行数据的获取装置的结构示意图。该出行数据的获取装置可以被集成在服务端设备上，其可以通过软件、硬件或者软硬结合的方式实现。在上述图32所示实施例的基础上，如图33所示，该装置还可以包括：处理模块43。
其中，处理模块43，用于根据所述用户出行信息和所述热点区域的信息，确定为用户端设备提供约车服务的时间和地点；
所述发送模块42，具体用于将所述提供约车服务的时间和地点携带在所述确认服务响应中发送给所述云端服务器。
进一步地，所述显示模块41，具体用于根据所述热点区域的信息，将所述接收模块40接收到的用户出行信息对应的区域进行热点区域标识显示。
本申请实施例提供的出行数据的获取装置，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图34为本申请一实施例提供的出行数据的获取装置的结构示意图。该出行数据的获取装置可以被集成在服务端设备上，其可以通过软件、硬件或者软硬结合的方式实现。如图34所示，该装置可以包括：接收模块51、显示模块52和发送模块53。
具体的，接收模块51，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
显示模块52，用于显示所述用户出行信息；
发送模块53，用于根据所述用户出行信息为用户端设备提供出行服务。
本申请实施例提供的出行数据的获取装置，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图35为本申请一实施例提供的云端服务器的硬件结构示意图。如图35所示，该云端服务器可以包括处理器61、存储器62、至少一个通信总线63和收发器64。通信总线63用于实现元件之间的通信连接。存储器62可能包含高速ram存储器，也可能还包括非易失性存储nvm，例如至少一个磁盘存储器，存储器62中可以存储各种程序，用于完成各种处理功能以及实现本实施例的方法步骤；收发器64可以为具有收发功能的收发信机、或者单纯具有发送功能的发送信机、或者收发天线，还可以是具有信号处理和发送功能的射频和基带单元。
可选的，上述处理器61例如可以为中央处理器(centralprocessingunit，简称cpu)、应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现。
本实施例中，所述处理器61，与所述收发器64耦合，用于根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息；其中，所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
所述收发器64，用于向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息。。
本申请实施例提供的云端服务器，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
可选的，所述处理器61，还用于根据每个所述区域在未来时间范围内的用户出行信息，获取每个所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量的差值，并将所述差值大于预设阈值的区域确定为热点区域；
所述收发器64，还用于将所述热点区域的信息推送给所述至少一个服务端设备和/或所述至少一个用户端设备。
可选的，所述区域为对地图中的基础地理位置信息进行离散处理后的网格，每个对应地图中的一个经纬度范围；
所述热点区域的信息为所述差值大于所述预设阈值的网格中的地图注点poi信息。
可选的，所述处理器61，还用于对地图中的基础地理位置信息进行离散处理，获得至少一个网格，并根据预设的时间段划分策略，对所获取的所有第一历史出行订单添加时间戳，得到至少一个第二历史出行订单；所述时间戳包括所述第一历史出行订单的发生日期和所述第一历史出行订单的发生时间所在的时间段标识；所述第一历史出行订单携带所述第一历史出行订单对应的经纬度信息和所述第一历史出行订单的发生时间；
进一步地，所述处理器61，还用于根据每个所述第二历史出行订单和所获得的响应信息，生成第二历史出行数据，并根据所述第二历史出行数据中每个所述第三历史出行订单的经纬度信息，将所述第二历史出行数据映射至所述至少一个网格，获得所述第一历史出行数据；其中，所述第二历史出行数据包括至少一个第三历史出行订单，每个第三历史出行订单包括所述第二历史出行订单和所述第二历史出行订单的响应状态；所述响应信息用于指示每个所述第二历史出行订单的响应状态。
可选的，所述第一历史出行数据具体包括：每个所述网格在每个历史日期下的每个时间段的历史出行订单量和历史出行订单响应量；
相应的，
所述用户出行信息具体包括：所述网格在未来日期下的每个时间段的未来出行订单量和未来出行订单响应量。
可选的，所述第一历史出行数据还包括：每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的等待时间，和/或，每个所述网格在每个历史日期下的每个时间段的历史出行订单被所述历史出行订单所属的网格中的服务端设备所响应的订单量。
进一步地，所述处理器61，具体可以用于根据所述第一历史出行数据，预测每个网格在当前日期的出行订单总量和出行订单响应总量，并根据预设的时间段划分策略，获取每个网格中不同日期属性下历史出行订单量的第一变化趋势和历史出行订单响应量的第二变化趋势；以及，根据每个所述网格在当前日期的出行订单总量和所述第一变化趋势，获得每个所述网格在当前日期的每个时间段的出行订单量，并根据每个所述网格在当前日期的出行订单响应总量和所述第二变化趋势，获得每个所述网格在当前日期的每个时间段的出行订单响应量；所述日期属性包括工作日属性、双休日属性、节假日属性中的任一个。
进一步地，所述处理器61，还可以用于以每个网格的标识为主键，根据所述第一历史出行数据构建每个所述网格的第一时间序列和第二时间序列，并根据第一arima模型和每个所述网格的第一时间序列，预测每个网格在当前日期的出行订单总量，以及根据第二arima模型和每个所述网格的第二时间序列，预测每个网格在当前日期的出行订单响应总量；其中，所述第一时间序列中包括所述网格内每个历史日期下的历史出行订单总量，所述第二时间序列包括所述网格内每个历史日期下的历史出行订单响应总量；所述第一时间序列和所述第二时间序列的长度等于所述网格内的历史日期的数量。
更进一步地，所述处理器61，还可以用于以每个网格的标识和日期维度为主键，根据所述第一历史出行数据构建每个所述网格的至少一个第三时间序列和至少一个第四时间序列，并根据预设的日期属性对每个所述网格中的历史日期进行聚类，获得每个所述网格中的第一属性日期类；所述第一属性日期类包括多个满足所述日期属性的历史日期；以及根据所述第一属性日期类下的所有第三时间序列，获得每个网格中所述日期属性下历史出行订单量的第一变化趋势，并根据所述第一属性日期类下的所有第四时间序列，获得每个网格中所述日期属性下历史出行订单响应量的第二变化趋势；其中，所述第三时间序列中包括一个历史日期下的不同时间段的历史出行订单量，所述第四时间序列包括所述一个历史日期下的不同时间段的历史出行订单响应量。
可选的，每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的等待时间，具体包括：
每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的平均等待时间、每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的最大等待时间、每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的中值等待时间、每个所述网格在每个历史日期下的每个时间段的历史出行订单被响应的最小等待时间中的至少一个。
可选的，所述第一历史出行订单还包括：发出所述第一历史出行订单的用户名，和/或，用户发出所述第一历史出行订单的地址。
可选的，所述响应信息包括响应所述第二历史出行订单的司机名、响应所述第二历史出行订单时服务端设备的经纬度信息以及响应所述第二历史出行订单的时间。
本申请实施例提供的云端服务器，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图36为本申请一实施例提供的用户端设备的硬件结构示意图。如图36所示，该用户端设备可以包括处理器70、存储器71、至少一个通信总线72、接收器73、与接收器73耦合的显示设备74和发送器75。通信总线72用于实现元件之间的通信连接。存储器71可能包含高速ram存储器，也可能还包括非易失性存储nvm，例如至少一个磁盘存储器，存储器中可以存储各种程序，用于完成各种处理功能以及实现本实施例的方法步骤；发送器75或接收器73可以为具有收发功能的收发信机、或者单纯具有发送功能的发送信机、或者收发天线，还可以是具有信号处理和发送功能的射频和基带单元。
可选的，上述处理器70例如可以为中央处理器(centralprocessingunit，简称cpu)、应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现。
本实施例中，所述接收器73，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
所述显示设备74，用于显示所述用户出行信息；
所述发送器75，用于根据所述用户出行信息向云端服务器或者服务端设备发送出行请求。
本申请实施例提供的用户端设备，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图37为本申请一实施例提供的服务端设备的硬件结构示意图。如图37所示，该服务端设备可以包括处理器80、存储器81、至少一个通信总线82、接收器83、与接收器83耦合的显示设备84和发送器85。通信总线82用于实现元件之间的通信连接。存储器81可能包含高速ram存储器，也可能还包括非易失性存储nvm，例如至少一个磁盘存储器，存储器中可以存储各种程序，用于完成各种处理功能以及实现本实施例的方法步骤；发送器85或接收器83可以为具有收发功能的收发信机、或者单纯具有发送功能的发送信机、或者收发天线，还可以是具有信号处理和发送功能的射频和基带单元。
可选的，上述处理器80例如可以为中央处理器(centralprocessingunit，简称cpu)、应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现。
本实施例中，所述接收器83，用于接收云端服务器根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息；所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
所述显示设备84，用于显示所述用户出行信息；
所述发送器85，用于根据所述用户出行信息向云端服务器发送确认服务响应；或者，用于根据所述用户出行信息为用户提供出行服务。
本申请实施例提供的服务端设备，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
图38为本申请一实施例提供的出行数据的获取系统的结构示意图。如图39所示，该出行数据的获取系统可以包括上述图35所示的云端服务器91、上述图36所示的用户端设备92和上述图37所示的服务端设备93。
具体的，所述云端服务器91，分别与所述用户端设备92和服务端设备93耦合，用于根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息，并向至少一个服务端设备93和至少一个用户端设备92推送所述用户出行信息；
所述用户端设备92，用于接收云端服务器91根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示；以及，根据所述用户出行信息向服务端设备93发送出行请求；
所述服务端设备93，用于接收云端服务器91根据第一历史出行数据预测的至少一个区域在未来时间范围内的用户出行信息并显示；以及，根据所述用户出行信息为用户端设备92提供出行服务；
其中，所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量。
本申请实施例提供的出行数据的获取系统，可以执行上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
一种计算机/处理器可读存储介质，所述存储介质中存储有程序指令，所述程序指令用于使所述计算机/处理器执行：
根据第一历史出行数据，预测地图上的至少一个区域在未来时间范围内的用户出行信息；其中，所述第一历史出行数据用于表征所述地图上不同区域的历史出行订单信息；所述用户出行信息包括所述区域在所述未来时间范围内的未来出行订单量和未来出行订单响应量；
向至少一个服务端设备和/或至少一个用户端设备推送所述用户出行信息。
上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。
最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。