配送距离确定方法、集单方法、任务下达方法及相关装置与流程

本公开涉及信息处理领域，更具体而言，涉及一种配送距离确定方法、集单方法、任务下达方法及相关装置。

背景技术：

在物流配送领域，为了提升配送效率，一般来说，骑手每次配送都不止配送一单。在配送前，考虑到多种配送因素而收集多个配送单分配给骑手用于配送一次的过程叫做一次集单。出于骑手装载率、骑行路径等因素，在不影响配送指标的情况下，骑手在一次集单形成的一个批次的基础上，再等待其它批次的配送单，从而将多个批次的配送单一起配送的过程，叫做二次集单。一次集单和二次集单时，都会考量配送目的地地址与对应的配送物理节点(配送站)之间的配送距离。

在确定配送单的目的地地址与对应的配送物理节点之间的配送距离时，可以调用通用电子地图服务器。通用电子地图服务器会提供准确的导航距离，即在规划的导航路线上的距离，它不是简单地计算两点之间的直线距离，而是考虑到高架、河流、交通管制等因素，规划一条导航路线，获得导航路线上的导航距离。该方案获得的配送距离比较精确，但物流配送时会发送大量请求，通用电子地图服务器的每秒请求数(qps)如果过大，容易造成网络堵塞。另外，大量导航距离实时计算严重消耗网络带宽，占用网络资源。为了消除这些缺点，现有技术的另一种方式采用目的地地址与对应的配送物理节点之间的直线距离作为配送距离，同时考虑区块禁表。即，将地图分成很多区块，有些相邻的区块之间能够直通，有些相邻的区块之间不能直通(例如a区块和b区块中间有个高架，因此不能直通)，将不能直通的相邻区块都事先写入区块禁表中。在采用直线距离的方案中，如果该直线正好穿过区块禁表中列出的相邻区块，该直线距离不能采纳。通过这种方式，来修正直线距离的方案。该方案的缺点是，区块禁表列出了不能直通的相邻区块，但有些相邻区块只是表面上不能直通，实际上可能存在一条可通行道路(例如小路)将其连通，通用电子地图服务器往往考察到所有的可通行道路，而区块禁表往往做不到非常精细，导致影响集单率。

技术实现要素：

有鉴于此，本公开旨在能够精确确定物流配送距离的同时，又不会导致向电子地图服务器发送大量请求而导致网络拥塞。

根据本公开的一方面，提供了一种配送距离确定方法，包括：

获取配送任务对应的目的地地址；

确定所述目的地地址所属的目标地理区块，其中，地理区块为地图上划分的区域，所述地理区块配置有所述地理区块与对应的配送物理节点之间的导航距离；

根据所述地理区块与对应的配送物理节点之间的导航距离，确定所述目标地理区块与所述目标地理区块对应的配送物理节点之间的目标导航距离，作为所述配送任务的配送距离。

可选地，所述地理区块与对应的配送物理节点之间的导航距离为所述地理区块的中心与对应的配送物理节点在电子地图上的导航路线上的距离。

可选地，在获取配送任务对应的目的地地址之前，所述方法还包括：预存由平台服务器发送的地理区块的地理区域编码；所述确定所述目的地地址所属的目标地理区块，包括：确定所述目的地地址的地理区域编码，如与预存的地理区域编码之一匹配，则确定匹配的地理区域编码对应的地理区块为所述目的地地址所属的地理区块。

可选地，在预存由平台服务器发送的地理区块的地理区域编码之后，所述方法还包括：响应于接收到所述平台服务器发送的增加的地理区块的地理区域编码，存储所述增加的地理区块的地理区域编码。

可选地，在预存由平台服务器发送的、所述当前配送物理节点管辖的地理区块的地理区域编码之后，所述方法还包括：响应于接收到所述平台服务器发送的地理区块的地理区域编码的删除指令，删除存储的对应地理区块的地理区域编码。

可选地，在获取配送任务对应的目的地地址之前，所述方法还包括：接收并存储由平台服务器发送的地理区块与对应的配送物理节点之间的导航距离。

可选地，在接收并存储由平台服务器发送的地理区块与对应的配送物理节点之间的导航距离之后，所述方法还包括：响应于接收到由平台服务器发送的增加的地理区块与对应的配送物理节点之间的导航距离，补充存储增加的地理区块与对应的配送物理节点之间的导航距离。

可选地，在接收并存储由平台服务器发送的地理区块与对应的配送物理节点之间的导航距离之后，所述方法还包括：响应于接收到由平台服务器发送的、对地理区块与对应的配送物理节点之间的导航距离的删除指令之后，删除存储的所述地理区块与对应的配送物理节点之间的导航距离。

可选地，所述确定所述目的地地址所属的目标地理区块还包括：如果确定的所述目的地地址的地理区域编码与预存的地理区域编码都不匹配，则向所述平台服务器发送确定的地理区域编码，从所述平台服务器的响应中确定所述目标地理区块，获取并存储该目标地理区块与对应的配送物理节点之间的导航距离。

可选地，所述地理区块是将地图划分成的相等边长的正方形格。

可选地，所述相等边长为20米。

可选地，所述获取配送任务对应的目的地地址，包括：

滤除所述堂食单、和自提单的配送任务；

获取过滤后的配送任务对应的目的地地址。

可选地，所述目的地地址包括目的地经度、纬度，在获取配送任务对应的目的地地址之后，所述方法还包括：确定所述目的地经度、纬度符合预定规则。

可选地，所述由平台服务器发送的地理区块与对应的配送物理节点之间的导航距离是由所述平台服务器通过以下方式从地图服务器获取的：

以所述对应的配送物理节点位置、所述地理区块的中心位置构造导航距离请求的上下文，向所述地图服务器发送导航距离请求；

接收所述地图服务器返回的导航距离。

根据本公开的一方面，还提供了一种集单方法，包括：

获取目标配送物理节点的待处理配送任务；

按照根据以上所述的配送距离确定方法，确定所述目标配送物理节点的待处理配送任务的配送距离；

基于所述目标配送物理节点的待分配运力资源数量和所述待处理配送任务的配送距离，为所述待分配骑手分配所述待处理配送任务。

根据本公开的一方面，还提供了一种配送任务下达方法，包括：

获取配送任务对应的目的地地址、和多个配送物理节点；

确定所述目的地地址所属的目标地理区块，其中，地理区块为地图上划分的区域，所述地理区块配置有所述地理区块与所述多个配送物理节点之间的导航距离；

根据所述地理区块与所述多个配送物理节点之间的导航距离，确定所述目标地理区块与所述多个配送物理节点之间的目标导航距离，作为所述配送任务对于所述多个配送物理节点的配送距离；

确定配送距离符合预设条件的配送物理节点，作为目标配送物理节点；

将所述配送任务下发到所述目标配送物理节点。

可选地，所述预设条件为所述配送距离最小。

根据本公开的一方面，还提供了一种配送距离确定装置，包括：

区块定位单元，用于获取配送任务对应的目的地地址，并确定所述目的地地址所属的目标地理区块，其中，地理区块为地图上划分的区域，所述地理区块配置有所述地理区块与对应的配送物理节点之间的导航距离；

导航距离获取单元，用于根据所述地理区块与对应的配送物理节点之间的导航距离，确定所述目标地理区块与所述目标地理区块对应的配送物理节点之间的目标导航距离，作为所述配送任务的配送距离。

可选地，所述地理区块与对应的配送物理节点之间的导航距离为所述地理区块的中心与对应的配送物理节点在电子地图上的导航路线上的距离。

可选地，该装置还包括：地理区域编码库，用于预存由平台服务器发送的地理区块的地理区域编码；所述区块定位单元进一步用于：确定所述目的地地址的地理区域编码，如确定的地理区域编码与所述地理区域编码库中预存的地理区域编码之一匹配，则确定匹配的地理区域编码对应的地理区块为所述目的地地址所属的地理区块。

可选地，该装置还包括：地理区域编码和导航距离管理单元，用于响应于接收到所述平台服务器发送的增加的地理区块的地理区域编码，在所述地理区域编码库中存储所述增加的地理区块的地理区域编码。

可选地，该装置还包括：地理区域编码和导航距离管理单元，用于响应于接收到所述平台服务器发送的地理区块的地理区域编码的删除指令，在所述地理区域编码库中删除存储的对应地理区块的地理区域编码。

可选地，该装置还包括：地理区块导航距离库，用于预存由平台服务器发送的地理区块与对应的配送物理节点之间的导航距离。

可选地，该装置还包括：地理区域编码和导航距离管理单元，用于响应于接收到由平台服务器发送的增加的地理区块与对应的配送物理节点之间的导航距离，在所述地理区块导航距离库中存储增加的地理区块与对应的配送物理节点之间的导航距离。

可选地，该装置还包括：地理区域编码和导航距离管理单元，用于响应于接收到由平台服务器发送的、对地理区块与对应的配送物理节点之间的导航距离的删除指令，在所述地理区块导航距离库中删除对应的导航距离。

可选地，该装置还包括：地理区域编码和导航距离管理单元，用于如果确定的所述目的地地址的地理区域编码与预存的地理区域编码都不匹配，则向所述平台服务器发送确定的地理区域编码，从所述平台服务器的响应中确定所述目标地理区块，并获取该目标地理区块与对应的配送物理节点之间的导航距离存储在所述地理区块导航距离库中。

根据本公开的一方面，还提供了一种集单装置，包括：

待处理配送任务获取单元，用于获取目标配送物理节点的待处理配送任务；

如上所述的配送距离确定装置；

集单单元，用于基于目标配送物理节点的待分配运力资源数量和待处理配送任务的配送距离，为待分配骑手分配所述待处理配送任务。

根据本公开的一方面，还提供了一种配送任务下达装置，包括：

获取单元，用于获取配送任务对应的目的地地址、和多个配送物理节点；

目标地理区块确定单元，用于确定所述目的地地址所属的目标地理区块，其中，地理区块为地图上划分的区域，所述地理区块配置有所述地理区块与所述多个配送物理节点之间的导航距离；

目标导航距离确定单元，用于根据所述地理区块与所述多个配送物理节点之间的导航距离，确定所述目标地理区块与所述多个配送物理节点之间的目标导航距离，作为所述配送任务对于所述多个配送物理节点的配送距离；

目标配送物理节点确定单元，用于确定配送距离符合预设条件的配送物理节点，作为目标配送物理节点；

配送任务下发单元，用于将所述配送任务下发到所述目标配送物理节点。

可选地，所述预设条件为所述配送距离最小。

根据本公开的一个方面，提供了一种计算机设备，包括：存储器，用于存储计算机可执行代码；处理器，用于执行所述计算机可执行代码，以实现如上所述的方法。

根据本公开的一个方面，提供了一种计算机可读介质，包括计算机可执行代码，所述计算机可执行代码被处理器执行时实现如上所述的方法。

本公开实施例中，将电子地图事先分成地理区块，地理区块与对应的配送物理节点之间的导航距离事先都已获得并存储好。当接到配送任务后，根据配送任务对应的目的地地址确定出其所属的目标地理区块，便可以将事先存储的该目标地理区块与对应的配送物理节点之间的导航距离作为配送距离，免于向电子地图服务器发送大量请求而造成网络拥塞，减少了网络资源的占用。另外，事先获得的目标地理区块与对应的配送物理节点之间的距离是导航距离，其已经考虑到高架、河流、交通管制等因素，因此不需要采用区块禁表，减少了采用区块禁表带来的收集信息不全面、影响集单率的缺陷。

附图说明

通过参考以下附图对本公开实施例的描述，本公开的上述以及其它目的、特征和优点将更为清楚，在附图中：

图1a-d示出本公开实施例的配送距离确定方法应用在物流配送时配送物理节点终端上显示的界面状态变化；

图2示出了在两个相邻区块之间有高架阻隔不能直通的示意图；

图3示出了根据本公开一个实施例的配送距离确定方法应用的体系构架图；

图4示出了根据本公开一个实施例的配送距离确定方法的流程图；

图5示出了根据本公开一个实施例的配送距离确定装置的内部模块及平台服务器的交互的图；

图6示出了图5的各模块交互的流程图；

图7示出了根据本公开一个实施例的集单方法的流程图；

图8示出了根据本公开一个实施例的配送任务下达方法的流程图；

图9示出了根据本公开一个实施例的集单装置的框图；

图10示出了根据本公开一个实施例的配送任务下达装置的框图；

图11示出了根据本公开一个实施例的计算机设备的结构图。

具体实施方式

以下基于实施例对本公开进行描述，但是本公开并不仅仅限于这些实施例。在下文对本公开的细节描述中，详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本公开。为了避免混淆本公开的实质，公知的方法、过程、流程没有详细叙述。另外附图不一定是按比例绘制的。

本公开实施例可用于物流配送中配送任务配送距离的确定。在为骑手集单(即分配配送任务来配送)时，每次为骑手分配哪些配送任务来配送，需要考量的一个因素就是配送任务的配送距离。

现有技术中为配送任务确定配送距离的一种方式是，请求通用电子地图服务器，由通用电子地图服务器规划一条导航路线，获得导航路线上的导航距离。该方式消除了用直线距离作为配送距离导致的确定出的配送距离不准确从而影响用户体验的问题，但通用电子地图服务器的每秒请求数(qps)有限制，而物流配送时又会发送大量请求，引起网络拥塞，而且占用网络资源过多。

为了防止网络拥塞，已有的确定配送距离的第二种方式是采用目的地地址与对应的配送物理节点之间的直线距离作为配送距离，但同时考虑区块禁表。它事先将地图分成很多区块，有些相邻的区块之间能够直通，有些相邻的区块之间不能直通(例如，图1的区块201和区块202中间有个高架，因此不能直通)，将不能直通的相邻区块都事先写入区块禁表中。针对确定的直线距离，如果该直线正好穿过区块禁表中列出的相邻区块，该直线距离不能采纳。通过这种方式，来修正直线距离的方案。如图1所示，配送物理节点位于区块201，配送单的用户地址位于区块202，但区块201和区块202之间有高架，不能采用直线距离的方案。该方案的缺点是，区块禁表列出了不能直通的相邻区块，但有些相邻区块实际上可能存在一条可通行道路(小路)将其连通。通用电子地图服务器在制作电子地图时是精细的，考虑到所有的可通行道路，而区块禁表只是大体反映了区块之间的关系，一般不精细，导致影响集单率。

因此，需要一种既能够达到与实时向通用电子地图服务器请求的导航距离类似的精确度，又不引起网络拥塞的方案。鉴于此，本公开的发明人想到，可以将电子地图事先分成地理区块，地理区块与对应的配送物理节点之间的导航距离事先都已获得并存储好。这个导航距离可能就是事先通过请求通用电子地图服务器的方式获得的，具有足够的精确度，不会有区块禁表收集的信息不全面的问题。在实际接到配送任务后，只需根据配送任务对应的目的地地址确定出其所属的目标地理区块，便可以将事先存储的该地理区块与对应的配送物理节点之间的导航距离作为配送距离，从而不用实时向电子地图服务器发送大量请求而被限流。这样，就既达到了与实时向通用电子地图服务器请求的导航距离类似的精确度，又不受限流影响。

图3示出了根据本公开一个实施例的物流配送距离确定方法应用的体系构架图。该体系构架包括平台服务器410、地图服务器420、配送物理节点终端440、骑手终端450。平台服务器410是物流平台上负责整个平台配送控制信号流的协调的服务器。整个物流平台按照地图上的地域分成不同地理区块，每个地理区块有一个配送物理节点(配送站)，负责到该地理区块中目的地用户的配送。配送物理节点具有配送物理节点终端440，负责下属的骑手的配送单的分配。骑手各自具有自己的骑手终端450，用于接收配送物理节点终端440下发的配送单，并按照下发的配送单为骑手导航。地图服务器420在配送平台外部，是专门用于进行地图服务的专门服务器，如响应于查询，提供两个地点之间的导航距离。

上述平台服务器410、地图服务器420可以体现为单个服务器，也可以是多个服务器组成的服务器集群，例如可以是云服务器的形式。配送物理节点终端440可以体现为桌面电脑、笔记本电脑、专用设备、移动终端等多种形式，也可以以虚拟机的形式体现为单台物理机的一部分，或者分布在不同的物理机上。骑手终端450可以体现为手机、pda、车载设备、专用终端等多种形式。

事先将地图划分成地理区块。预先为配送物理节点终端440分配其负责的多个地理区块。平台服务器410事先向地图服务器420请求这多个地理区块与配送物理节点的导航距离(具体请求时，可以按照每个地理区块的中心与配送物理节点的导航距离进行请求)。平台服务器410将请求到的各地理区块的导航距离发给配送物理节点终端440存储。注意，平台服务器410可以仅将配送物理节点负责的多个地理区块与该配送物理节点之间的导航距离，发给配送物理节点终端440存储。配送物理节点终端440可能不会存储其它配送物理节点负责的多个地理区块与该配送物理节点之间的导航距离。

当当前配送物理节点终端440接收到平台服务器410实际发送的需要配送的配送任务时，根据配送任务对应的目的地地址，找到该目的地地址位于的目标地理区块，从存储的各地理区块的导航距离中获取该目标地理区块的导航距离，并按照该导航距离为骑手终端450分配配送任务。

图1a-d示出了本公开实施例应用于为骑手分配配送任务的场景中的当前配送物理节点终端440的界面图。

配送物理节点终端440每次从平台服务器410接收到要分配的配送任务后，配送物理节点终端440显示如图1a所示的界面，列出需要分配给骑手终端450的配送任务号。每个配送任务对应于一个配送单，配送任务号即配送单号。

接着，配送物理节点终端440为图1a所示的配送任务(配送单)，逐一确定其配送目的地(即配送单的配送地址)所在的区块，它采用地理区域编码的形式(后文中详细描述)，并获取事先存储的该区块与该配送物理节点440之间的导航距离，显示在该配送物理节点终端440的显示屏上，如图1b所示。配送物理节点所负责的各区块与该配送物理节点之间的导航距离是事先获得(例如通过向地图服务器420请求)并存储在该配送物理节点终端440中的，因此，可以直接读取出来。但是，有一种特殊的情况是，某一区块不是该配送物理节点管辖的，因此，该配送物理节点事先没有存储其相应导航距离，但又从平台服务器410接到了该区块涉及的目的地的配送单，这时，就不能直接读取到该配送任务对应的导航距离，如图1b的订单37g78y40s5。这种情况下，由于配送单涉及的区块为新区块，配送物理节点终端440需要向平台服务器410请求该新区块与配送物理节点的导航距离，因此，界面上显示请骑手等待，如图1b所示。

平台服务器410获取到该新区块与配送物理节点的导航距离(例如通过请求地图服务器420)后，发送回配送物理节点终端440，显示在配送物理节点终端440的界面上，如图1c所示。

由于此时已获得了本次配送的配送任务的导航距离，系统可以自动根据这些导航距离和其它因素为骑手终端450分配配送任务，如图1d所示。

图5示出了根据本公开一个实施例的配送距离确定装置430的内部模块结构。配送距离确定装置430位于目标配送物理节点终端440中，是目标配送物理节点终端440中用于确定配送单的配送距离的部分。目标配送物理节点是分配用于处理配送任务的配送物理节点(配送站)。目标配送物理节点终端是该目标配送物理节点的终端。

如图5所示，该配送距离确定装置430包括收发器431、区块定位单元432、点对聚集单元436、导航距离获取单元437、配送数据存储库438、地理区域编码和导航距离管理单元433、地理区域编码库434、地理区块导航距离库435。

收发器431是配送距离确定装置430与外界进行收发消息的部件。例如，平台服务器410下发的需要配送的配送任务就是通过收发器431从平台服务器410接收的。

地理区域编码库434是存储当前配送物理节点所负责的各地理区块的地理区域编码的数据库。地理区域编码是地理区块的地理位置表示。不同的地理区块，其地理区域编码各自不同。间隔越近的地理区块，其地理区域编码越接近。目前，有很多对地理位置进行编码得到地理区域编码的技术，故不赘述。地理区域编码唯一表示了地理区块。平台服务器410事先将当前配送物理节点负责的地理区块进行编码，得到地理区域编码，存储在物流配送距离确定装置430的地理区域编码库434。

地理区块导航距离库435是存储配送物理节点所负责的各地理区块到该配送物理节点的导航距离的数据库。平台服务器410事先针对配送物理节点负责的地理区块，向地图服务器420请求相应导航距离，存储在物流配送距离确定装置430的地理区块导航距离库435。

区块定位单元432是确定配送任务对应的目的地地址所属的地理区块的单元。它可以针对配送任务对应的目的地地址，进行如上所述的地理区域编码，与地理区域编码库434中的地理位置编码进行比对，如与其中一个一致，则说明该目的地地址属于该地理位置编码对应的地理区块。

区块定位单元432确定地理区块后，就可以查找该地理区块的导航距离。本公开实施例采用集中多个配送任务对应的目的地地址，一起进行查找导航距离的方式。因此，点对聚集单元436对接收到的配送任务进行聚集，直到聚集到预定数量或达到预定标准，发送给导航距离获取单元437获取导航距离。

导航距离获取单元437根据聚集的多个配送任务分别对应的的地理区块，查找地理区块导航距离库435，找到地理区块到对应的配送物理节点(配送站)的导航距离。在查找管辖地理区块导航距离库435失败的情况下，在一些实施例中，还可以直接向地图服务器420请求。

配送数据存储库438将针对各配送任务查找到的地理区块地理位置编码、导航距离等进行存储，以方便之后查询。

平台服务器410包括配单模块411和地理区块导航距离维护模块412。配单模块411用于向物流配送距离确定装置430下发需要分配的配送任务(配送单)。地理区块导航距离维护模块412用于向物流配送距离确定装置430发送配送距离确定装置430对应的配送物理节点负责的地理区块的地理区域编码和地理区块到对应的配送物理节点的导航距离。地理区块与配送物理节点的关系是事先绑定的。某一地理区块只能对应于一个配送物理节点。

图4示出了根据本公开一个实施例的一种配送距离确定方法的流程图。该方法由图5的物流配送距离确定装置430执行。该方法包括：

步骤310、获取配送任务对应的目的地地址；

步骤320、确定所述目的地地址所属的目标地理区块，其中，地理区块为地图上划分的区域，所述地理区块配置有所述地理区块与对应的配送物理节点之间的导航距离；

步骤330、根据所述地理区块与对应的配送物理节点之间的导航距离，确定所述目标地理区块与所述目标地理区块对应的配送物理节点之间的目标导航距离，作为所述配送任务的配送距离。

在上述步骤之前，作为预备过程，地理区域编码库434要预存由平台服务器410发送的、所述配送物理节点管辖的地理区块的地理区域编码，地理区块导航距离库435要预存由平台服务器410发送的、地理区块与对应的配送物理节点之间的导航距离。由于平台服务器410只会向配送物理节点终端440发送配送物理节点终端440管辖的地理区块与对应的配送物理节点之间的导航距离，该对应的配送物理节点即配送物理节点终端440所在的节点，因此，地理区块导航距离库435预存的导航距离是该配送物理节点负责的地理区块与该配送物理节点之间的导航距离。

具体地，平台服务器410的地理区块导航距离维护模块412确定配送物理节点所管辖的地理区块，将这些地理区块进行地理区域编码(通过已有的进行地理区域编码的方法)，并从地图服务器420请求所述配送物理节点管辖的地理区块与所述该配送物理节点之间的导航距离，发送给收发器431，经地理区域编码和导航距离管理单元433将地理区域编码和导航距离分别分发给地理区域编码库434和地理区块导航距离库435。

平台服务器410将配送物理节点负责的地理区块的地理区域编码和导航距离初始分发给该配送物理节点终端440之后，如果之后要调整该配送物理节点负责的地理区块，例如增加或删除一些其负责的地理区块，可以向该配送物理节点终端440增加或删除其已经存储的其负责的地理区块的相关数据(地理区域编码和导航距离)，从而及时反映该配送物理节点负责的地理区块的变化。

在平台服务器410决定向配送物理节点终端440增加分配其负责的地理区块时，地理区块导航距离维护模块411产生该地理区块的地理区域编码，并向地图服务器420请求该地理区块与该配送物理节点的导航距离，将该地理区域编码和导航距离下发给该配送物理节点终端440的物流配送距离确定装置430。收发器431接收到该地理区域编码和导航距离后，发送给地理区域编码和导航距离管理单元433，在地理区域编码库434中增加存储该地理区域编码，在地理区块导航距离库435中增加存储该导航距离。

在平台服务器410决定向配送物理节点终端440减少分配其负责的地理区块时，地理区块导航距离维护模块411，将该地理区块的地理区域编码的删除指令和该地理区块与该配送物理节点之间的导航距离的删除指令下发给配送物理节点终端440的物流配送距离确定装置430。收发器431接收到这些指令后，发送给地理区域编码和导航距离管理单元433。地理区域编码和导航距离管理单元433在地理区域编码库434中删除该地理区域编码，在地理区块导航距离库435中删除该导航距离。

通过以上方式，实现配送物理节点终端440存储的地理区块数据的灵活控制。

在一个实施例中，所述地理区块与对应的配送物理节点之间的导航距离为所述地理区块的中心与对应的配送物理节点在电子地图上的导航路线上的距离。地理区块的中心是指地理区块的质心。例如，三角形的质心是3条中线的交点，长方形的质心是对角线的交点，不规则图形的质心可以采取坐标系的方法计算。以所述配送物理节点管辖的地理区块的中心位置代表配送物理节点的位置，来确定导航距离，可以提高导航距离的精确性。

在一个实施例中，所述配送物理节点管辖的地理区块与所述该配送物理节点之间的导航距离是由所述平台服务器410通过以下方式从地图服务器420获取的：以所述配送物理节点位置、所述配送物理节点管辖的地理区块的中心位置构造导航距离请求的上下文，向所述地图服务器420发送导航距离请求；接收所述地图服务器420返回的导航距离。

构造导航距离请求的上下文是指利用上述两个位置坐标分别作为导航的起点和终点，从而构造出一个虚假的导航距离请求，地图服务器420就会返回上述两个位置之间的导航路径和导航距离。例如，将配送物理节点坐标作为起点位置，将所述配送物理节点管辖的地理区块的中心坐标作为终点位置，从而构造一个导航距离请求。

当平台服务器410向配送物理节点终端440下发配送任务时，如图6所示，在步骤309中，收发器431接收到该配送任务，将该配送任务发送到区块定位单元432。配送任务体现为配送单，配送单是表示配送的起点、目的地、收件人及联系方式、寄件人及联系方式等配送信息的单据。然后，进入步骤310，区块定位单元432获取配送任务对应的目的地地址。

在一个实施例中，步骤310分为子步骤3101和3102。在子步骤3101中，滤除所述堂食单、和自提单的配送任务。堂食单是指对于食品类的配送单，不需要配送，用户自行来到当前配送物理节点食用的配送任务。自提单是指用户会自行来到当前配送物理节点提货，无需配送的配送任务。滤除堂食单、和自提单，有助于减少不必要的配送。在子步骤3102中，获取过滤后的配送任务对应的目的地地址。

在一个实施例中，在步骤310之后，进入步骤315，进行经纬度校验，即确定所述目的地经度、纬度符合预定规则。预定规则是预先制定的、校验什么样的经纬度有效的规则。由于下单用户gps定位错误等原因，经常发现一些订单位置离谱，不可能送到，或明显脱离地理区块(例如目标配送物理节点在北京市，目的地在上海市)等。因此，预先设置一些规则，只有经纬度满足这些规则才继续后续配送处理，否则不予处理，从而排除一些异常配送任务的干扰。

接着，在步骤320中，确定所述目的地地址所属的地理区块。其包括子步骤3201和3202。在子步骤3201中，区块定位单元432确定所述目的地地址的地理区域编码，其可以采用已有的地理区域编码方法。在子步骤3202中，区块定位单元432检查地理区域编码库434，如与该库434中预存的地理区域编码之一匹配，则确定匹配的地理区域编码对应的地理区块为所述目的地地址所属的地理区块。

在一个实施例中，步骤320之后，在步骤321中，如果确定的所述目的地地址的地理区域编码与预存的地理区域编码都不匹配，则区块定位单元432向地理区域编码和导航距离管理单元433发送确定的地理区域编码。在步骤322中，地理区域编码和导航距离管理单元433向平台服务器410发送该地理区域编码。在步骤323中，平台服务器410向地图服务器420请求该地理区块与该配送物理节点的导航距离并向地理区域编码和导航距离管理单元433返回。在步骤324中，地理区域编码和导航距离管理单元433将导航距离存储在地理区块导航距离库435中。

在步骤325，建立配送物理节点到目的地地址的点对。为一个配送任务构造一个点对。为了效率，并不是构造一个点对，就立刻为该点对确定一次导航距离。而是在步骤326，聚集点对到一定数量，或者满足一定要求(例如聚集一定时间)，然后在步骤327，发送点对和目的地地址对应的地理区块编码到导航距离获取单元437。在步骤330中，导航距离获取单元437按照各点对对应的地理区块编码查询地理区块导航距离库435，获得导航距离。地理区块导航距离库435中，地理区块的地理区块编码可以与导航距离相对应地存储。

在本公开的一个实施例中，所述地理区块是将地图划分成的相等边长的正方形格。每个地理区块是边长相等的正方形格，降低了地理区域编码的难度，也使得识别目的地地址所属的地理区块更容易。

在一个实施例中，所述相等边长为20米。地理区块太大，用其中心来代表整个地理区块的地理位置误差会太大。地理区块太小，造成地理区块过多，增加处理开销。实践证明，边长20米，能够获得更好的配送误差和开销的折中。

如图7所示，根据本公开的一个实施例，还提供了一种集单方法，该集单方法由目标配送节点终端440执行。目标配送节点是针对配送任务分配骑手执行的配送站。目标配送节点终端440即目标配送节点具有的终端。集单是指为骑手分配一次配送所需要执行的配送任务的过程。该方法包括：

步骤510、获取目标配送物理节点的待处理配送任务；

步骤520、按照前述图4所示的方法，确定目标配送物理节点的待处理配送任务的配送距离；

步骤530、基于目标配送物理节点的待分配运力资源数量和各待处理配送任务的配送距离，为各待分配骑手分配所述配送任务。

下面对上面步骤分别进行具体描述。

步骤510中，目标配送物理节点的待处理配送任务即给该目标配送物理节点分配的需要其向骑手下发的配送任务。可以从平台服务器410接收目标配送物理节点的待处理配送任务。一般来说，每个配送物理节点负责一个区域(例如海淀区中关村街道)。只要目的地地址落在该区域内的配送任务都由平台服务器410分配给该配送节点终端440。

步骤520中，按照如上结合图4所述的配送距离确定方法，确定目标配送物理节点的待处理配送任务的配送距离。

步骤530中，运力资源是指总的运输能力，包括交通工具和人力。为骑手分配配送任务(集单)时，要考虑多种配送因素，其中一项是前配送物理节点的待处理配送任务的配送距离。根据多种配送因素为多个骑手来集单，是目前通用的作法，其具体作法不属于本公开实施例所关心的，故不赘述。另外，集单时也要考虑待分配运力资源数量，这也是已有的作法，故不赘述。

在上述实施例中，每个配送任务分配到的目标配送物理节点440是由配送任务中的目的地地址决定的。每个配送物理节点440负责一个固定的区域内的目的地地址的配送任务。在另一个实施例中，每个配送物理节点440负责的区域不是固定的，而是由平台服务器410产生一个配送任务时，现场根据该配送任务的目的地地址，考察其与哪个配送物理节点的导航距离满足预设条件(如最小)，将其分配到满足预设条件的配送物理节点440。因此，每个配送物理节点440负责的区域不是固定的。

如图8所示，根据本公开一个实施例，提供了一种配送任务下达方法，它由平台服务器410执行。该方法包括：

步骤610、获取配送任务对应的目的地地址、和多个配送物理节点；

步骤620、确定所述目的地地址所属的目标地理区块，其中，地理区块为地图上划分的区域，所述地理区块配置有所述地理区块与所述多个配送物理节点之间的导航距离；

步骤630、根据所述地理区块与所述多个配送物理节点之间的导航距离，确定所述目标地理区块与所述多个配送物理节点之间的目标导航距离，作为所述配送任务对于所述多个配送物理节点的配送距离；

步骤640、确定配送距离符合预设条件的配送物理节点，作为目标配送物理节点；

步骤650、将所述配送任务下发到所述目标配送物理节点。

下面对以上步骤进行详细描述。

步骤610中的多个配送物理节点即平台服务器410下属的配送物理节点，例如物流企业的多个配送站。当平台服务器410接收到用户(需要配送的人或单位)的配送请求后，产生配送任务，配送请求中的目的地地址即为配送任务对应的目的地地址。

步骤620中，确定所述目的地地址所属的目标地理区块。该步骤与图4的步骤320类似，为节约篇幅，故不赘述。

在平台服务器410，针对每个地理区块，事先存储着其到各配送物理节点之间的导航距离。这样，在步骤620中确定了目标地理区块后，在步骤630中，就可以查找出其到各配送物理节点之间的导航距离。到哪个配送物理节点的导航距离符合预设条件，例如所述配送距离最小，用该配送物理节点作为目标配送物理节点最有利。因此，在步骤640中，确定配送距离符合预设条件的配送物理节点，作为目标配送物理节点。在步骤650中，将所述配送任务下发到所述目标配送物理节点，在配送任务中可以携带该配送任务对于该目标配送物理节点的配送距离。

上述预设条件除了可以是配送距离最小之外，也可以是配送距离小于预定距离阈值。如果有多个配送物理节点的配送距离小于预定距离阈值，可以在该多个配送物理节点中任选一个配送物理节点，作为目标配送物理节点。由于这些配送物理节点的配送距离都小于预定距离阈值，说明其任何一个作为目标配送物理节点都不会使配送距离很远，配送效率很低，选取任一个都是满足要求的。

通过上述方式，实现了配送物理节点440的合理选择，避免了配送物理节点440负责的区域事先固定，但实际上离配送任务的目的地很远的情况，实现资源合理配置。

如图9所示，根据本公开的一个实施例，还提供了一种集单装置700，它位于当前配送物理节点440内部。其包括：

待处理配送任务获取单元710，用于获取目标配送物理节点的待处理配送任务；

如上所述的配送距离确定装置720；

集单单元730，用于基于目标配送物理节点的待分配运力资源数量和待处理配送任务的配送距离，为待分配骑手分配所述配送任务。

该集单装置700的实现细节可以参考结合图7的集单方法的相关描述，故不赘述。

如图10所示，根据本公开的一个实施例，还提供了一种配送任务下达装置900，它位于平台服务器410内部。该配送任务下达装置900包括：

获取单元910，用于获取配送任务对应的目的地地址、和多个配送物理节点；

目标地理区块确定单元920，用于确定所述目的地地址所属的目标地理区块，其中，地理区块为地图上划分的区域，所述地理区块配置有所述地理区块与所述多个配送物理节点之间的导航距离；

目标导航距离确定单元930，用于用于根据所述地理区块与所述多个配送物理节点之间的导航距离，确定所述目标地理区块与所述多个配送物理节点之间的目标导航距离，作为所述配送任务对于所述多个配送物理节点的配送距离；

目标配送物理节点确定单元940，用于确定配送距离符合预设条件的配送物理节点，作为目标配送物理节点；

配送任务下发单元950，用于将所述配送任务下发到所述目标配送物理节点。

该配送任务下达装置900的实现细节可以参考结合图8的配送任务下达方法的相关描述，故不赘述。

本公开的商业价值

本公开实施例能够解决配送单的配送距离计算的准确性，可以去掉区块禁表，实验证明，使得集单率提升了10％以上(集单率是指每次骑手配送中的配送单数的平均值)，从而为每年节省1000万元配送成本，且提高了骑手的体感和消费者的体验，具有极高的商业价值。

根据本公开的一个实施例的配送距离确定方法、集单方法、配送任务下达方法可以由图11的计算机设备800实现。当实现根据本公开的一个实施例的配送距离确定方法或集单方法时，计算机设备800可以是配送物理节点终端440。当实现根据本公开一个实施例的配送任务下达方法时，计算机设备800可以是平台服务器410。

下面参照图11来描述根据本公开实施例的计算机设备800。图7显示的计算机设备800仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图11所示，计算机设备800以通用计算设备的形式表现。计算机设备800的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述示例性方法的描述部分中描述的本公开各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图4、7、8中所示的各个步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(rom)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

计算机设备800也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该计算机设备800交互的设备通信，和/或与使得该计算机设备800能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口850进行。并且，计算机设备800还可以通过网络适配器860与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与计算机设备800的其它模块通信。应当明白，尽管图中未示出，可以结合计算机设备800使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。

需要领会，以上所述仅为本公开的优选实施例，并不用于限制本公开，对于本领域技术人员而言，本说明书的实施例存在许多变型。凡在本公开的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

应该理解，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。

应该理解，上述对本说明书特定实施例进行了描述。其它实施例在权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

应该理解，本文用单数形式描述或者在附图中仅显示一个的元件并不代表将该元件的数量限于一个。此外，本文中被描述或示出为分开的模块或元件可被组合为单个模块或元件，且本文中被描述或示出为单个的模块或元件可被拆分为多个模块或元件。

还应理解，本文采用的术语和表述方式只是用于描述，本说明书的一个或多个实施例并不应局限于这些术语和表述。使用这些术语和表述并不意味着排除任何示意和描述(或其中部分)的等效特征，应认识到可能存在的各种修改也应包含在权利要求范围内。其他修改、变化和替换也可能存在。相应的，权利要求应视为覆盖所有这些等效物。