GPS部标平台的架构设计(四)-百度地图设计

部标GPS软件平台之百度地图设计

地图是客户端中不可缺少的一个模块,很多人在设计和画图时候,喜欢加上地图引擎这样高大上的字眼,显得自己的平台有内涵,说白了就是用第三方的SDK来开发,早期的GPS监 控软件用的都是mapx、mapxtrem、acrgis之类的,使用的都是本地地图。不仅要购买正版地图,还要购买价格不菲的地图引擎license,服务器版的部署的时候,还要绑定到服务器ID上,现在这种开发方式已被抛弃。现在的百度地图、谷歌地图提供的SDK接口丰富,开发方便,系统稳定,大家都用的很爽。

在部标GPS软件平台中,由于部标过检的时候,指定要求在四维地图和高德地图中任选一家,必须要有审图号,也就是说必要购买,不能用免费的地图,年费三万起,这个无疑加大了运营成本,加重了企业负担,现在物流运输企业挣钱都是从车轱辘里蹦出来的,那些地图厂商坐地收费,因为是年费,要年年交,真是黑。

但是虽说是部标平台,过检是第一步,第二步要给客户用,很多客户由于在实际上网的过程中,对于百度地图已经很接受了,所以经常会指定要求用百度地图。所以我们在设计平 台的时候,考虑多个地图切换和兼容是顺理成章的事情。

百度地图的主要优势如下:
1) 卫星地图,百度的卫星地图虽然远不如谷歌的卫星地图,但是比国内这些四维之类的垃圾要强大多了,谷歌的服务经常被搞,所以忍痛放弃;
2) 百度的javascript SDK和手机SDK较其他地图要完善的多,升级较多;
3) API上要比其他厂商的API要丰富,出来Javascript API,也提供了web service API(高德地图目前不提供), 可以在后台使用C#或Java语言调用web服务接口进行坐标转换和位置解析服务。
5) 地图美观。这个美观主要是在地图图层优化上,不同的zoom下,显示不同的图层,这样地图加载的速度会比较流畅,显示也比较美观。我们自己在开发时,较少考虑这一点,比如车辆图标,当地图缩小到国家级的时候,车辆密密麻麻的显示在一起,实际上要根据不同的zoom进行优化。

因为地图SDK都是基于Javascript的SDK,所以设计主要集中在前端的Javascript的设计上。

主要设计模块分为:
1)地图主界面页面(jsp);
2)后台ajax数据调用接口;
3)地图接口js;
4)工具栏;

地图页面主要控制地图界面UI的布局和显示方式,主要的UI部分包括:
1) 地图操作工具条;
2)中心地图DIV;
3) 历史轨迹查询工具条;
4) 实时数据显示栏;
5) 历史轨迹数据显示栏

地图接口js设计
首先根据部标要求的地图功能,我们来设计地图操作的放大、缩小、围栏、线路、标注、图层等接口等。

地图接口的核心就是对较复杂的围栏和线路操作进行一个封装,因为部标808不仅要求围栏和线路指令下发给终端,终端支持报警,还需要平台也能支持围栏报警和路线偏移报警,主要的操作如下:

1)地图上画出多边形、矩形和圆形围栏及线路,并持久化;

2)  绑定给车辆;

3) 下发绑定指令给终端;

4) 车辆进入围栏,触发报警; (这里可能是终端报警,平台也要支持报警)

5)报警后,显示车辆在地图中心;

ajax调用接口
1) 当初始化地图的时候,获取用户的权限,根据权限显示不同的地图操作工具;
2) 获取用户录入的各种图元并加载到地图上显示,如自定义标注、各种类型的围栏、线路等;
3) 实时监控时,不断获取实时数据,并刷新地图车辆位置,画出实时轨迹;
4) 历史轨迹回放时,获取历史数据,并刷新地图车辆位置,画出历史轨迹;
5) 持久化接口,将用户在地图上的标注、画出的围栏、线路等保存到后台数据库;

地图服务模块
1.位置解析模块,不断的解析车辆的坐标,转为地理位置描述,更新到系统中,并在前台显示;
2.加偏服务模块,根据前台的调用request,调用百度地图的加偏地址,转换坐标在前台地图上显示;

GPS部标平台的架构设计(四)-百度地图设计,布布扣,bubuko.com

时间: 2025-01-02 16:49:00

GPS部标平台的架构设计(四)-百度地图设计的相关文章

GPS部标平台的架构设计(十)-基于Asp.NET MVC构建GPS部标平台

在当前很多的GPS平台当中,有很多是基于asp.NET+siverlight开发的遗留项目,代码混乱而又难以维护,各种耦合和关联,要命的是界面也没见到比Javascript做的控件有多好看,随着需求的增多,平台已经臃肿不堪. 设计基于.NET的GPS部标平台,我们坚定不移的选择了基于JQUERY+Asp.NET MVC来作为前端交互和后台处理的框架.选用一个灵活的脚手架,同时团队又能掌握这个脚手架为团队所用. 对于一个web应用项目,基于MVC的框架,前面文章提到过,最大的优点就是结构清晰,强制

GPS部标平台的架构设计(五)-地图服务算法库

GPS平台,需要和各种地图打交道,需要解决以下的问题: 1.坐标偏移,这个不用多说,需要将原始坐标加偏,然后在百度地图或谷歌上显示出来,需要注意的是百度地图的加偏是偏上再偏,谷歌.高德地图等是火星坐标: 2.坐标解偏,或者纠偏,这个我们也是需要的,因为当用户在地图上画出的各种区域,标注,发送到后台存储的坐标都是基于地图所采用的坐标系统,因而是偏移的,这就面临一个严重的问题,因为在部标808协议中,对于区域报警,需要将区域的顶点坐标,下发给终端,终端在实际运行中,不断用GPS坐标和区域坐标进行比对

GPS部标平台的架构设计(六)-Android手机客户端和手机查车设计

对于GPS软件平台,虽然有功能非常丰富的PC端或BS客户端,但是客户也是需要移动客户端来作为自己的辅助工具,也是需要的.做为GPS平台的设计者和开发者,在开发移动客户端的时候,也需要从常规的服务器开发和客户端开发的思维中,转变过来,当然客户的需求也需要转变,因为毕竟不能随心所欲的将PC端的所有功能需求照搬到手机客户端,手机的开发环境.网络环境.使用环境都决定了设计理念与PC端的设计是完全不一样的. 通常我们成为GPS部标平台的手机客户端为手机查车,实际上现在的功能不仅仅是查车,由于客户需求的推进

GPS部标平台的架构设计(九)-GPS监控客户端设计

交通部的部标过检,所有的测试都是从客户端发起的,也是在客户端体现的,在客户端承载了部标标准所要求的所有的功能,是整个部标平台当中工作量最大的部分,也是最繁琐的部分. 客户端设计面临两个问题: 1.基于CS还是基于BS,这是个问题 萝卜白菜各有所爱,客户要什么,我们就开发什么,从客户来讲,更适应桌面客户端,没有浏览器的七七八八问题,速度感觉上也比网页的快,操作方便.当然网页客户端也有很大的优势,部署和维护方便,不需要开发升级系统. 2.与服务端的交互通信,采用Socket, WebService还

GPS部标监控平台的架构设计(八)-基于WCF的平台数据通信设计

总体来讲,GPS部标平台的软件开发是一个对网络通信和应用程序之间通信的技术应用密集型的开发工作,也是有一定设计技术含量的工作. 1.设计通信接口 在设计的时候,根据职责划分,拆分成不同的应用子系统,对各个子系统进行功能隔离,并通过设计接口规定子系统直接的调用规约. 首先我们根据部标平台的要求,设计和开发出各个主要的服务器子系统,这是平台中最核心的子系统,在实际的应用中,由于车辆规模的大小和行业需求,还会扩展出各种业务子系统.核心子系统如下: 1)808GPS服务器,采用交通部的部标808协议,负

数据交换平台的架构设计

序言 说到架构设计,不敢妄自牛逼.只能默默地向Linux致敬,没有强大的linux系统,我们做的架构设计,做的程序一天说不定挂几次.(windows系统就不说了,呵呵) 数据交换平台的架构发展 架构不是一蹴而就的,是随着团队技术能力的积累,随着公司数据平台的逐步完善,随着相关开源产品的深入学习,逐步形成和进化的. 不同阶段,需要不同的架构.因此,不能单纯地说,哪个架构就好,哪个架构就不好.只要适合当时的环境,就是最好的.对公司业务的发展,对其他模块的项目支撑,没有起到约束和限制的作用,就OK.如

GPS部标监控平台的架构设计(七)-压力测试

部标监控平台的压力测试是部标检测流程的最后一个检测环节,也是最难的,很多送检的企业平台都是卡壳在这一个环节.企业平台面临的问题如下: 1.对于压力测试的具体指标要求理解含糊,只知道是模拟一万辆车终端进行数据包传输,不知道具体的检测标准是那些指标,等进京考试后落榜了,才知道压力测试失败了,这个时候,还要通知后方的同志改进,耽误的时间和差旅费用成本惊人.很多检测人员需要在京住上几十天,算算得多少钱.因为不知道方向,所以改进也是盲目改进,不知道行不行,应付任务再次送检,也是摇骰子,祈求上天让我们通过吧

.NET应用架构设计—四色原型模式(色彩造型、域无关的模型)(概念版)

阅读文件夹: 1.背景介绍 2.问自己,UML对你来说有意义吗?它帮助过你对系统进行分析.建模吗? 3.一直以来事实上我们被一个缝隙隔开了,使我们对OOAD遥不可及 4.四色原型模式填补这个历史缝隙,让我们真的看见OOAD的希望 5.在四色原型上运用彩色建模增强视觉冲击力 6.通过四色原型模式建模出领域无关模型 7.结束语:建模时你能够不考虑详细实现,可是建模者要懂技术实现 1.背景介绍 至今我都清楚的记得我第一次被面试官问起什么叫"建模"技术时的情景,那是好几年前的事情了.当时是胸有

支付平台的架构设计

2018-04-29 李艳鹏 程序员小灰 本文转载自公众号  Fastpay快付 作者李艳鹏,阿里P8技术专家,小灰在Qcon大会上有幸结识,技术又好为人又很谦和. 互联网平台架构日益成为互联网发展的基石,对于 Java 开发者和架构师而言,只有在了解架构背后的原理后,才能写出更高质量的代码,才能设计出更好的方案,才能在错综复杂平台架构下产出价值,才能在各种场景下快速发现问题.快速定位问题.快速解决问题. 本场 Chat 会带领大家从支付平台架构设计评审入手,讲解设计评审的核心要点,为读者带去现