一种手绘地图的加载方法、介质及设备

技术领域

本发明涉及地图领域，具体涉及一种手绘地图的加载方法、介质及设备。

背景技术

手绘电子地图，即对某一具体地理位置的地图进行手绘，再将手绘地图覆盖到实际使用的地图上，通过电子方式对手绘地图进行渲染并展示的地图，具体的，手绘电子地图具体应用在智慧导览等方面，其使用方式为通过用户端在手机或其他终端中利用小程序打开手绘电子地图，用户可以根据需要进行放大、移动等操作，便于提升使用观感。

现有技术中，可以利用h5结合高德地图，腾讯地图，百度地图的api，将其对应的瓦片地图进行手绘地图贴图，最后使用Web view嵌入小程序中实现手绘地图的渲染与加载；还可以通过微信小程序中关于map组件的个性化地图服务完成，或者，通过微信小程序提供的自定义图片图层渲染技术addGroundOverlay对手绘地图进行渲染获得；还可以通过支付宝中的地图组件ground-overlays对手绘地图进行渲染获得。

上述方案存在的问题是：Web view由于同层渲染的兼容问题和相互之间传递数据无法及时响应，则需要建立地图相关的人机交互，数据请求移动至web端，并且小程序提供的部分交互效果，在web端无法使用，后期的模拟也难以达到与小程序一般的交互效果，整个渲染过程受限；微信小程序使用个性化地图服务需要依托腾讯地图，并且申请工单耗时长，每次更换手绘图都需要长时间的审核，效率低；使用addGroundOverlay(微信)和ground-overlays(支付宝)的地图插件进行手绘地图的渲染都面临相同的一个问题，即如果手绘图的质量过大(手绘地图质量超过300KB)，会导致在部分性能较差的android手机上无法正常显示出手绘地图。

发明内容

鉴于上述问题，本发明提供了一种手绘地图的加载方法、介质及设备，解决了现有的微信/支付宝的地图插件加载手绘地图程序中若手绘地图质量过大将无法正常显示的问题。

为实现上述目的，在第一方面，本发明提供了一种手绘地图的加载方法，适用于服务端，方法包括：

获取初始图像信息，初始图像信息包括参考坐标组、换算比例尺以及初始图像，参考坐标组包括第一参考坐标，初始图像为手绘地图，换算比例尺为手绘地图与实际地貌之间的换算比例，第一参考坐标为经纬坐标；

利用图像处理模块对初始图像进行切片，获得残片图像组，残片图像组中包括第一残片图像以及第二残片图像，第一残片图像与第二残片图像的数据大小均置于预设数据尺寸范围内；

获取第一残片图像对应的第一位置信息，根据换算比例尺、第一位置信息与第一参考坐标的相对位置关系换算得出第一残片图像的第一地理坐标，第一位置信息为第一残片图像在初始图像中的位置；以及

获取第二残片图像对应的第二位置信息，根据换算比例尺、第二位置信息与第一参考坐标的相对位置关系换算得出第二残片图像的第二地理坐标，第二位置信息为第二残片图像在初始图像中的位置；

将第一残片图像与第一地理坐标、第二残片图像与第二地理坐标映射存储，获得残片图像集合；

将残片图像集合以及初始图像信息写入配置文件；

将配置文件发送至用户端。

在一些实施例中，利用图像处理模块对初始图像进行切片，获得残片图像组包括：

对初始图像沿预设方向进行预切片处理，生成初始图像的切片策略，根据切片策略对初始图像进行切片，预设方向被配置为与第一参考坐标在初始图像上的方位相对应。

在一些实施例中，对初始图像进行预切片处理，生成初始图像的切片策略包括：

对初始图像沿预设方向进行一级预切片，获得一级预切片组，一级预切片组包括至少一个一级预切片图像；

判断一级预切片图像的数据大小是否置于预设数据尺寸范围内，若否，则将一级预切片图像存储至一级待切片集合中，直至遍历一级预切片组；

将一级待切片集合中的一级预切片进行二级预切片，获得二级预切片组，二级预切片组包括至少两个二级预切片图像；

判断二级预切片图像的数据大小是否置于预设数据尺寸范围内，若否，则将二级预切片图像存储至二级待切片集合中，直至遍历二级预切片组；

重复上述执行步骤直至全部预切片图像的数据大小置于预设数据尺寸范围内，并记录预切片处理的全部执行步骤，生成切片策略。

在一些实施例中，第一残片图像被配置为初始图像沿预设方向进行切片后获得的含有第一参考坐标的残片图像。

在一些实施例中，参考坐标组还包括第二参考坐标，第二参考坐标通过第一参考坐标以及第二残片图像在初始图像上的方位换算获得。

在一些实施例中，图像处理模块为Node.js的sharp模块。

在第二方面，本发明还提供一种手绘地图的加载方法，适用于用户端，方法包括：

获取服务端发送的配置文件，配置文件为第一方面所述的方法获得的配置文件；

将初始图像信息中的初始图像进行加载并展示，以及，对第一残片图像进行渲染，对第二残片图像进行渲染；

根据第一地理坐标、第二地理坐标将渲染完成的第一残片图像以及第二残片图像拼合形成最终图像；

将初始图像替换成最终图像并展示。

在一些实施例中，根据第一地理坐标对第一残片图像进行渲染，根据第二地理坐标对第二残片图像进行渲染包括：

利用检测模块对第一残片图像的渲染数据进行监听，若第一残片图像渲染失败，则重新对第一残片图像进行渲染；

和/或，利用检测模块对第二残片图像的渲染数据进行监听，若第二残片图像渲染失败，则重新对第二残片图像进行渲染。

在第三方面，本发明还提供一种计算机可读存储介质，其上存储计算机程序指令，所述计算机程序指令在被处理器执行时实现在第一方面所述的方法。

在第四方面，本发明还提供一种电子设备，包括存储器和处理器，所述存储器用于存储一条或多条计算机程序指令，其中，所述一条或多条计算机程序指令被所述处理器执行以实现在第一方面所述的方法。

区别于现有技术，上述技术方案中，服务端获取初始图像信息，利用图像处理模块对初始图像信息中的初始图像进行切片，获得残片图像组，残片图像组中的第一残片图像以及第二残片图像的数据大小置于预设数据尺寸范围内，利用初始图像信息中的参考坐标组以及换算比例尺，获得第一残片图像的第一地理坐标以及第二残片图像的第二地理坐标，并生成残片图像集合，再将残片图像集合与初始图像写入配置文件中，发送至用户端，用户端根据该配置文件对残片图像集合中的第一残片图像以及第二残片图像进行渲染，同时将初始图像同步渲染后展示。本技术方案通过将初始图像分为第一残片图像以及第二残片图像，第一残片图像与第二残片图像的数据大小置于预设数据尺寸范围内，将初始图像化整为零，满足微信/支付宝的地图插件对单个渲染对象的数据要求，在第一残片图像、第二残片图像渲染结束后根据第一地理坐标、第二地理坐标拼合形成一个完整的最终图像，从而实现小程序中高质量手绘地图的加载；并且，在微信/支付宝的地图插件对第一残片图像、第二残片图像渲染过程之前，优先将初始图像加载后展示在终端显示单元上，有效避免长时间加载切片小图导致页面出现马赛克式的渲染过程，提升用户体验感。

上述发明内容相关记载仅是本发明技术方案的概述，为了让本领域普通技术人员能够更清楚地了解本发明的技术方案，进而可以依据说明书的文字及附图记载的内容予以实施，并且为了让本发明的上述目的及其它目的、特征和优点能够更易于理解，以下结合本发明的具体实施方式及附图进行说明。

附图说明

附图仅用于示出本发明具体实施方式以及其他相关内容的原理、实现方式、应用、特点以及效果等，并不能认为是对本发明的限制。

在说明书附图中：

图1为本发明第一示例性实施例所述手绘地图的加载方法步骤图；

图2为本发明第二示例性实施例所述手绘地图的加载方法步骤图；

图3为本发明第三示例性实施例所述手绘地图的加载方法步骤图；

图4为本发明第四示例性实施例所述手绘地图的加载方法步骤图；

图5为本发明一具体实施方式所述手绘地图加载方法的电子设备示意图；

图6为本发明一具体实施方式所述手绘地图的加载系统示意图；

图7为本发明一具体实施方式所述手绘地图的切片示意图。

上述各附图中涉及的附图标记说明如下：

1、手绘地图加载系统；

11、服务端；

12、用户端；

2、电子设备；

21、存储器；

22、处理器。

3、手绘地图；

31、第一残片图像；

32、第二残片图像；

33、第三残片图像。

具体实施方式

为详细说明本发明可能的应用场景，技术原理，可实施的具体方案，能实现目的与效果等，以下结合所列举的具体实施例并配合附图详予说明。本文所记载的实施例仅用于更加清楚地说明本发明的技术方案，因此只作为示例，而不能以此来限制本发明的保护范围。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本发明的至少一个实施例中。在说明书中各个位置出现的“实施例”一词并不一定指代相同的实施例，亦不特别限定其与其它实施例之间的独立性或关联性。原则上，在本发明中，只要不存在技术矛盾或冲突，各实施例中所提到的各项技术特征均可以以任意方式进行组合，以形成相应的可实施的技术方案。

除非另有定义，本文所使用的技术术语的含义与本发明所属技术领域的技术人员通常理解的含义相同；本文中对相关术语的使用只是为了描述具体的实施例，而不是旨在限制本发明。

在本发明的描述中，用语“和/或”是一种用于描述对象之间逻辑关系的表述，表示可以存在三种关系，例如A和/或B，表示：存在A，存在B，以及同时存在A和B这三种情况。另外，本文中字符“/”一般表示前后关联对象是一种“或”的逻辑关系。

在本发明中，诸如“第一”和“第二”之类的用语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何实际的数量、主次或顺序等关系。

在没有更多限制的情况下，在本发明中，语句中所使用的“包括”、“包含”、“具有”或者其他类似的开放式表述，意在涵盖非排他性的包含，这些表述并不排除在包括所述要素的过程、方法或者产品中还可以存在另外的要素，从而使得包括一系列要素的过程、方法或者产品中不仅可以包括那些限定的要素，而且还可以包括没有明确列出的其他要素，或者还包括为这种过程、方法或者产品所固有的要素。

与《审查指南》中的理解相同，在本发明中，“大于”、“小于”、“超过”等表述理解为不包括本数；“以上”、“以下”、“以内”等表述理解为包括本数。此外，在本发明实施例的描述中“多个”的含义是两个以上(包括两个)，与之类似的与“多”相关的表述亦做此类理解，例如“多组”、“多次”等，除非另有明确具体的限定。

请参阅图1与图7，在第一方面，本实施例提供了一种手绘地图的加载方法，适用于服务端，方法包括：

S11、获取初始图像信息，初始图像信息包括参考坐标组、换算比例尺以及初始图像，参考坐标组包括第一参考坐标，初始图像为手绘地图，换算比例尺为手绘地图与实际地貌之间的换算比例，第一参考坐标为经纬坐标；

S12、利用图像处理模块对初始图像进行切片，获得残片图像组，残片图像组中包括第一残片图像以及第二残片图像，第一残片图像与第二残片图像的数据大小均置于预设数据尺寸范围内；

S13、获取第一残片图像对应的第一位置信息，根据换算比例尺、第一位置信息与第一参考坐标的相对位置关系换算得出第一残片图像的第一地理坐标，第一位置信息为第一残片图像在初始图像中的位置；以及获取第二残片图像对应的第二位置信息，根据换算比例尺、第二位置信息与第一参考坐标的相对位置关系换算得出第二残片图像的第二地理坐标，第二位置信息为第二残片图像在初始图像中的位置；

S14、将第一残片图像与第一地理坐标、第二残片图像与第二地理坐标映射存储，获得残片图像集合；

S15、将残片图像集合以及初始图像信息写入配置文件；

S16、将配置文件发送至用户端。

本实施例所示初始图像信息具体包括参考坐标组、换算比例尺以及初始图像，其中，初始图像为手绘师手绘地图，换算比例尺为该手绘地图与实际地貌之间的换算比例，参考坐标组包括多个参考坐标，参考坐标也即经纬坐标，可以根据实际需求选定实际地貌上的具体某个位置所对应的经纬坐标；优选的，参考坐标为四个方位角的坐标，以上北下南、左西右东为前提，该手绘地图上正东、正南、正西、正北四个方位的坐标；也可以为手绘地图的四个角坐标，即左上角(西北)、左下角(西南)、右上角(东北)、右下角(东南)所对应的经纬坐标。具体的，本实施例所示第一参考坐标为左上角所对应的经纬坐标；参考坐标组还可以包括第二参考坐标，第二参考坐标与第二残片图像对应，需要说明的是，第二参考坐标可以预先选定，也可以通过后续第一残片图像与第一参考坐标、第二残片图像的关系换算得出，具体的换算过程详见后文。

本实施例中，图像处理模块对初始图像进行切片，即将一张完整的手绘地图切分成多个残片，获得残片图像组，残片图像组内包含有多个残片图像，并且，每一残片图像的数据尺寸大小均置于预设数据尺寸范围内，也即，每一残片图像的图像大小以及占用字节数均满足预设数据尺寸范围，预设数据尺寸范围包括预设图像的尺寸大小以及预设图像的字节数(即数据占用字节)，这一标准由用户端给出，即用户端在加载图像时给出的数据尺寸的最大限制范围，例如，以微信中的addGroundOverlay为例，预设数据图像的字节数最大为300KB，但并未给出具体的预设图像的尺寸大小值。通过图像处理模块对手绘地图进行切片，将高质量手绘地图化整为零，便于用户端对单个残片图像进行加载与渲染，降低对用户端的性能要求。

具体的，残片图像组包括第一残片图像以及第二残片图像，此处应这样理解：残片图像组中包括多个残片图像，为便于说明，将需要与第一参考坐标进行匹配的残片图像记为第一残片图像，将其与需要通过第一参考坐标换算得到的残片图像记为第二残片图像、第三残片图像……直至剩余残片图像均被标记。值得注意的是，第二参考坐标可以通过第一参考坐标与第二残片图像换算得到，因此，本实施例可以预先设定第一参考坐标，剩余的参考坐标均可以通过换算得出，无需单独输入。下面仅以第一残片图像、第二残片图像对本实施例所示残片图像在初始图像中的位置换算进行具体说明，其余的残片图像位置换算过程与此相同，第一参考坐标点即第一参考坐标所指代的点，第一地理坐标点即第一地理坐标所指代的点，关于第二参考坐标点、第二地理坐标点的表述与此相同。

需要说明的是，本实施例中关于每张残片图像上的地理坐标与参考坐标的关系如下：以第一地理坐标为例，第一地理坐标与第一参考坐标可以为同一经纬坐标，也可以为不同经纬坐标，二者的具体区别在于，第一地理坐标作为第一残片图像在用户端拼合最终图像时的拼合标识，其在第一残片图像上的具体位置(也即第一地理坐标点)可以通过人为预先设定，例如，可以将第一残片图像的中心点作为第一地理坐标点，也可以将第一残片图像的右下角顶点作为第一地理坐标点，当第一地理坐标点与第一参考坐标点不同时，需要计量第一残片图像上的第一地理坐标点与第一参考坐标点之间的直线距离，再通过换算比例尺得出第一地理坐标点的具体坐标值，也即第一地理坐标。关于第二地理坐标与第二参考坐标之间的换算关系与此相同。

优选的，本实施例中，第二地理坐标即第二参考坐标、第一地理坐标即第一参考坐标，这一方式便于节省服务端的算力，后文关于第一参考坐标的表述也可以等于针对第一地理坐标的表述，第二残片图像的第二地理坐标换算过程为：

获取第二残片图像对应的第二位置信息，此处第二位置信息是指第二残片图像相对于初始图像的位置，结合第二残片图像的长宽尺寸，与第一参考坐标以及换算比例尺换算后得出第二地理坐标。具体可结合图7进行说明：例如，以第一参考坐标为手绘地图3的左上角顶点处的经纬坐标(也即第一残片图像31，图7所示编号31位置)为例，当第二残片图像32为初始图像左下角最下方所在残片图像(图7所示编号32位置)，第二位置信息对应为自第一残片图像31自上而下第五行第一列，则第二地理坐标的经度＝第一参考坐标的经度+第一行间隔尺寸x换算比例尺；第二地理坐标的维度＝第一参考坐标的维度，其中，第一行间隔尺寸对应第二残片图像32与第一残片图像31之间的长度距离。

同样的，当第三残片图像33置于图7所示编号33位置时，也即右下角最下方所在残片图像，第三位置信息对应为第一残片图像31自上而下第五行第六列，则第三地理坐标的经度＝第一参考坐标的经度+第二行间隔尺寸x换算比例尺；第三地理坐标的维度＝第一参考坐标的维度+第二列间隔尺寸x换算比例尺，其中，第二行间隔尺寸对应第三残片图像33与第一残片图像31之间的长度距离，第二列间隔尺寸对应第三残片图像33与第一残片图像31之间的宽度距离。

以此类推，换算得出每一残片图像对应的地理坐标。

将第一残片图像与第一地理坐标、第二残片图像与第二地理坐标映射存储，获得残片图像集合并写入配置文件，需要说明的是，优选将初始图像信息进行压缩，使其置于用户端的预设数据尺寸范围内，再将初始图像信息进行标记后与残片图像集合一并写入配置文件，再将配置文件发送至用户端。关于用户端的操作详见后文表述。

本实施例通过将初始图像分为第一残片图像以及第二残片图像，第一残片图像与第二残片图像的数据大小置于预设数据尺寸范围内，将初始图像化整为零，满足微信/支付宝的地图插件对单个渲染对象的数据要求，在第一残片图像、第二残片图像渲染结束后根据第一地理坐标、第二地理坐标拼合形成一个完整的最终图像，从而实现小程序中高质量手绘地图的加载，提升用户体验感。

请参阅图7，在一些实施例中，利用图像处理模块对初始图像进行切片，获得残片图像组包括：

对初始图像沿预设方向进行预切片处理，生成初始图像的切片策略，根据切片策略对初始图像进行切片，预设方向被配置为与第一参考坐标在初始图像上的方位相对应。

在对初始图像进行切片之前，需要对初始图像进行预切片处理，生成初始图像的切片策略。预设方向是指预先设定的切割方向，具体可结合图7进行理解，预设方向与第一参考坐标所在位置相关，例如，当第一参考坐标的坐标点选定为初始图像的左下角的顶点，预设方向为从左下角开始进行切割，优选的，本实施例的切片处理具体采用沿经纬方向按照预设尺寸对初始图像进行切割，预设尺寸如前所述，根据用户端对单个图像的最大尺寸限制确定；对初始图像的切片可以如图7所示；优选的，本实施例所示第一参考坐标为左上角的顶点。

需要说明的是，在对初始图像沿预设方向切割时，必然存在切割余量，也即沿经纬方向切割时，最后一组切割线所切割的残片图像大小并不规整，以第一参考坐标为左上角的顶点为例，图7所示右侧最后一列与下方最后一行中的残片图像并不规整，此时需要单独对下方最后一行以及右侧最后一列的图像尺寸进行计算，判断单个残片图像的数据大小是否置于预设数据尺寸范围内，若否，则需要对该处残片图像进行二次切割。

请参阅图2，在一些实施例中，对初始图像进行预切片处理，生成初始图像的切片策略包括：

S21、对初始图像沿预设方向进行一级预切片，获得一级预切片组，一级预切片组包括至少一个一级预切片图像；

S22、判断一级预切片图像的数据大小是否置于预设数据尺寸范围内，若否，则将一级预切片图像存储至一级待切片集合中，直至遍历一级预切片组；

S23、将一级待切片集合中的一级预切片进行二级预切片，获得二级预切片组，二级预切片组包括至少两个二级预切片图像；

S24、判断二级预切片图像的数据大小是否置于预设数据尺寸范围内，若否，则将二级预切片图像存储至二级待切片集合中，直至遍历二级预切片组；

S25、重复上述执行步骤直至全部预切片图像的数据大小置于预设数据尺寸范围内，并记录预切片处理的全部执行步骤，生成切片策略。

需要说明的是，即便按照预设尺寸对初始图像进行切割，依然存在单个残片图像的字节数超出预设字节数限制的问题，其原因在于，每个残片图像中还包含有色块明暗、色块种类等多种具体图像属性，当单个残片图像内包含有多种图像属性时，会增加残片图像的字节数，也即数据大小，从而使其超出预设数据尺寸范围，因此，本实施例所示预切片处理流程能够对残片图像进行逐一判断并针对超出预设数据尺寸范围的残片图像进行进一步切割。

具体的，将对初始图像的第一次切片记为一级预切片，其所获得的预切片图像记为一级预切片图像；逐个对一级预切片组中的一级预切片图像的数据大小进行判断，当一级预切片图像的尺寸大小和/或其所占用的数据字节数不满足预设数据尺寸范围时，将该一级预切片图像存储至一级待切片集合中，一级待切片集合内的一级预切片图像需要进行二级预切片，进一步切分一级预切片图像，使其尺寸大小以及其所占用的数据字节数置于预设数据尺寸范围内，以此类推，还可以进行三级预切片、四级预切片等，直至全部的预切片图像的尺寸大小以及其所占用的数据字节数置于预设数据尺寸范围内。

需要说明的是，预切片处理中所产生的预切片次数、单次预切片对应的预切片数量以及单次预切片对应的预切片图像、生成的待切片集合、预切片组等，均作为预切片处理的执行步骤数据，并据此生成切片策略，便于后续对初始图像进行切片，因此，生成的残片图像组中的残片图像尺寸大小可以不完全相同，残片图像所占用的数据字节值可以不完全相同。

在一些实施例中，第一残片图像被配置为初始图像沿预设方向进行切片后获得的含有第一参考坐标的残片图像。

在一些实施例中，参考坐标组还包括第二参考坐标，第二参考坐标通过第一参考坐标以及第二残片图像在初始图像上的方位换算获得。具体的换算方式如前文所述，此处第二参考坐标也即第二地理坐标。

在一些实施例中，图像处理模块为Node.js的sharp模块。

请参阅图3，图3示出了对手绘地图进行具体切割的一种实施例，其中，预设方向为自左上角切分至右下角的方向，第一参考坐标的数量为两个，即第一残片图像中的东北角的顶点坐标与西南角的顶点坐标，在这一前提下，对手绘地图进行预切片的具体步骤如下：

S31、获取原始手绘地图，以及原始的地图比例尺和原始手绘地图对应的东北角，西南角坐标；

S32、通过原始手绘地图尺寸和质量计算得出每张小图的宽高，图片默认从左上进行切图，故每行的最右侧的小图和每列的最下方的小图的宽和高并不一定是计算得到的结果，需要单独计算；

S33、单独计算每行最右侧的小图和每列最下方的小图的宽和高，得到全部的小图的尺寸与质量，再通过原始手绘地图的东北角，西南角坐标，推算得出每张小图的东北角，西南角；

S34、对小图进行格式转换，统一修改转成WebP格式。

上方原始手绘地图也即手绘师所提供的初始图像，原始的地图比例尺也即换算比例尺，原始手绘地图对应的东北角、西南角坐标也即两个第一参考坐标，小图也即残片图像。此处每张小图的东北角、西南角可以理解为对应的地理坐标。

请参阅图4，在第二方面，本实施例还提供一种手绘地图的加载方法，适用于用户端，方法包括：

S41、获取服务端发送的配置文件，配置文件为第一方面所述的方法获得的配置文件；

S42、将初始图像信息中的初始图像进行加载并展示，以及，对第一残片图像进行渲染，对第二残片图像进行渲染；

S43、根据第一地理坐标、第二地理坐标将渲染完成的第一残片图像以及第二残片图像拼合形成最终图像；

S44、将初始图像替换成最终图像并展示。

本实施例所示用户端具体指代用户在终端上使用的程序，例如，微信上的小程序、支付宝上的地图插件等。用户端接收服务端发送的配置文件，并对该配置文件进行解析。具体的，用户端在解析出该配置文件后，识别出被压缩后的初始图像，并加载初始图像将其在前端进行展示，在执行这一步骤后，对第一残片图像、第二残片图像等其余的残片图像进行渲染，将多个残片图像均渲染完毕后，根据第一地理坐标、第二地理坐标将第一残片图像以及第二残片图像进行拼合，获得最终图像；最终将原先加载的初始图像删除，并将最终图像展示在前端。这一方式能够有效避免长时间加载切片小图导致页面出现马赛克式的渲染过程，提升用户体验感。

在一些实施例中，根据第一地理坐标对第一残片图像进行渲染，根据第二地理坐标对第二残片图像进行渲染包括：

利用检测模块对第一残片图像的渲染数据进行监听，若第一残片图像渲染失败，则重新对第一残片图像进行渲染；

和/或，利用检测模块对第二残片图像的渲染数据进行监听，若第二残片图像渲染失败，则重新对第二残片图像进行渲染。

需要说明的是，本实施例所示检测模块为用户端自带的回调函数，对第一残片图像和/或第二残片图像的渲染数据进行监听，一旦第一残片图像和/或第二残片图像渲染失败，则重新加载第一残片图像和/或第二残片图像，并对其进行二次渲染，提升整个渲染步骤的流畅程度。

在第三方面，本实施例还提供一种计算机可读存储介质，其上存储计算机程序指令，所述计算机程序指令在被处理器执行时实现在第一方面所述的方法。

请参阅图5，在第四方面，本实施例还提供一种电子设备2，包括存储器21和处理器22，所述存储器21用于存储一条或多条计算机程序指令，其中，所述一条或多条计算机程序指令被所述处理器22执行以实现在第一方面所述的方法。

所述存储介质/存储器21包括但不限于：RAM、ROM、磁碟、磁带、光盘、闪存、U盘、移动硬盘、存储卡、记忆棒、网络服务器存储、网络云存储等。所述处理器22包括但不限于CPU(中央处理器22)、GPU(图像处理器22)、MCU(微处理器22)等。

请参阅图6，在第五方面，本实施例还提供一种手绘地图加载系统1，手绘地图加载系统1包括服务端11以及用户终端，服务端11与用户终端建立数据通讯，服务端11用于执行第一方面所述的方法，并将生成的配置文件发送至用户端12，用户端12执行第二方面所述的方法，根据服务端11发送的配置文件生成手绘地图并展示。可选地，用户端12可以是手机、平板、智能手表等可移动电子设备。

上述技术方案中，服务端获取初始图像信息，利用图像处理模块对初始图像信息中的初始图像进行切片，获得残片图像组，残片图像组中的第一残片图像以及第二残片图像的数据大小置于预设数据尺寸范围内，利用初始图像信息中的参考坐标组以及换算比例尺，获得第一残片图像的第一地理坐标以及第二残片图像的第二地理坐标，并生成残片图像集合，再将残片图像集合与初始图像写入配置文件中，发送至用户端，用户端根据该配置文件对残片图像集合中的第一残片图像以及第二残片图像进行渲染，同时将初始图像同步渲染后展示。本技术方案通过将初始图像分为第一残片图像以及第二残片图像，第一残片图像与第二残片图像的数据大小置于预设数据尺寸范围内，将初始图像化整为零，满足微信/支付宝的地图插件对单个渲染对象的数据要求，在第一残片图像、第二残片图像渲染结束后根据第一地理坐标、第二地理坐标拼合形成一个完整的最终图像，从而实现小程序中高质量手绘地图的加载；并且，在微信/支付宝的地图插件对第一残片图像、第二残片图像渲染过程之前，优先将初始图像加载后展示在终端显示单元上，有效避免长时间加载切片小图导致页面出现马赛克式的渲染过程，提升用户体验感。并且，本实施例所示的加载方法所获得的最终图像依然可以支持经纬度导航导览功能。

最后需要说明的是，尽管在本发明的说明书文字及附图中已经对上述各实施例进行了描述，但并不能因此限制本发明的专利保护范围。凡是基于本发明的实质理念，利用本发明说明书文字及附图记载的内容所作的等效结构或等效流程替换或修改产生的技术方案，以及直接或间接地将以上实施例的技术方案实施于其他相关的技术领域等，均包括在本发明的专利保护范围之内。