在遥感行业我们经常会用到各类的坐标系相互之间的转换,常见的度分秒转化为度很简单,直接上代码: //经纬度 ////118度48分54.152秒=118+(48/60)+(54.152/3600)=118.81504度 public static string GetLongLatByDMS(byte Deg, byte Mis, byte Sec) { decimal result = Convert.ToInt32(Deg) + (Convert.ToDecimal(Mis) / 60) +

转载请注明出处:http://www.cnblogs.com/Joanna-Yan/p/5715879.html GPS定位系统由三部分组成,即由GPS卫星组成的空间部分,若干地面组成的控制部分和普通用户手中的接收机这三部分.对于手机用户来说,手机就是GPS定位系统的接收机,也就是说GPS定位需要手机的硬件支持GPS功能. 一.核心API Android为GPS功能支持专门提供了一个LocationManager类, LocationManager lm=(LocationManager) ge

package com.jasgroup.cn.amhdeam; import java.io.IOException; import java.util.Iterator; import android.Manifest; import android.app.Activity; import android.content.Context; import android.content.Intent; import android.content.pm.ActivityInfo; impor

1)解析实现 gps_main.c #include <nmea/nmea.h> #include <string.h> #include <stdio.h> #include <stdint.h> #include <stdlib.h> #include "nrf_gpio.h" #include "gps_main.h" #include "main.h" #define GPS_P

1.GPS型号为ublox(EVK-M8L),配有USB接口,Qt版本5.7 2.实现步骤: (1)实现串口通信 采用Qt5.7 内置的串口操作类QSerialPort和QSerialPortInfo,通过QSerialPortInfo提供的函数availablePorts(),可枚举出当前计算机中可用的com口.使用该类需在pro文件中添加: QT += serialport (2)筛选感兴趣的信号,解析 GPRMC数据包基本上包含经纬度.航向角.时间等常用的信号. 3.效果图 4.源码 4.

气压计测某个点的高度是不准的,因为天气.温度等原因会导致不同时刻同一地点气压不同,所以气压计测量不准.但气压计测量相对高度是很准的.GPS测相对高度不准,但测定点高度比较准.

作者:Vamei 出处:http://www.cnblogs.com/vamei 欢迎转载,也请保留这段声明.谢谢! 简介 GPS的全称是全球定位系统(the Global Positioning System).它属于美国政府,并由洛杉矶的联合项目办公室(JPO, Joint Program Office)管理. 1957年,苏联发射第一颗人造卫星.为了确定卫星的位置,多个地面基站同时观测卫星发出的电波,并据此计算从基站到卫星的距离.这个想法很快被美国人发展下去: 既然多个地面基站可以确定空中

http://my.oschina.net/fankun2013/blog/338100 地图供应商比较多,产生了许多地图坐标.地图坐标正确转换是个问题.在之前开发地图应用的时候发现从WGS84坐标系(GPS)转换成某个地图坐标系都比较困难.然后只能使用地图供应商提供的webservice接口转换.百度也提供了免费的webservice接口(限制并发量).对于少数点的转换性能还可以,但是对于非常多点的转换压力比较大(使用多线程并行计算).个人感觉比较繁琐,而且很难保证转换的稳定性. 时间飞逝,百

GPS数据读取与处理 GPS模块简介 SiRF芯片在2004年发布的最新的第三代芯片SiRFstar III(GSW 3.0/3.1),使得民用GPS芯片在性能方面登上了一个顶峰,灵敏度比以前的产品大为提升.这一芯片通过采用20万次/频率的相关器提高了灵敏度,冷开机/暖开机/热开机的时间分别达到42s/38s/8s,可以同时追踪20个卫星信道.是目前市场上应用最为广泛,同时性价比也非常高的一款芯片,因此在本设计中同样采用以此芯片为核心的GPS模块. GPS模块的数据格式 对GPS模块的数据处理本

题目描述 Farmer John has recently purchased a new car online, but in his haste he accidentally clicked the "Submit" button twice when selecting extra features for the car, and as a result the car ended up equipped with two GPS navigation systems! Ev

GPS 串口读出的是 DDMM.MMMM格式 一般上位机是 DD.DDDDDD°或 DD°MM'SS" 格式, 这两种都可以在 GE 里直接输入 举例说明: 3147.8749 (示例,经纬度一样) 格式为 DDMM.MMMM  转换成度:  1. 度的部分直接就是31,  2.剩下的 MM.MMMM/60=度, 所以 47.8749/60=0.797915  则 转换成度是 31.797915° 转换成度分秒:  1. 同样,度的部分直接就是31, 2. 分直接是整数部分 47 3. 秒则是

内容实在是太太了 7.8MB 以至于浏览器 都奔溃 就算浏览器可以 博客园的文章也保存不了 只好保存到百度云 提供下载 地址: 链接:http://pan.baidu.com/s/16ggIq 密码:hyiw 总结:以上代码来源MapX 使用 : pl为 PointLatLng类 地图坐标转换GPS坐标 xxxx.Gcj02ToWgs(pl); GPS转换地图坐标 WgsToGcj02(px) 希望提供有需要的朋友

开发企业级的部标GPS监控平台,投入的开发力量很大,开发周期也很长,选择主流的开发语言以及成熟的开源技术框架来构建基础平台,是最恰当不过的事情,在设计之初就避免掉了技术选型的风险,避免以后在开发过程中,不断的填坑走弯路,以至于整个团队被坑埋掉.做GPS平台这么多年,以前就了解到一些开发团队过于关注某一种语言的优势,比如过于选用GO,Erlang,python,php等技术,最后团队熟悉这些技术的关键人员离职了,都没人接手,不能不说是个悲剧.所以说平台的技术架构选型要注重的是稳健,均衡而不是偏激,

基于交通部796标准开发部标监控平台,选择开发语言和技术也是团队要思考的因素,其实这由团队自己擅长的技术来决定,如果擅长C#和Asp.NET, 当然开发效率就高很多.当然了技术选型一定要选用当前主流的技术,现在Asp.NET技术已经发展到5.0, 如果你还是用旧的ASP技术写程序,无疑是为以后的项目维护埋下地雷,后面新来人手学习不到技术,没有兴趣去改进,不愿意维护,没有人愿意接手.代码最关键的是要不断的重构,保持与当前的技术和需求同步,平台才有生命力,否则就会越来越臃肿而变得难以维护.开发一个基

使用Java语言开发一个高质量和高性能的jt808 协议的GPS通信服务器,并不是一件简单容易的事情,开发出来一段程序和能够承受数十万台车载接入是两码事,除去开发部标808协议的固有复杂性和几个月长周期的协议Bug调试,作为大批量794车载终端接入的服务端,需要能够处理网络的闪断.客户端的重连.安全认证和消息的编解码.半包处理等.如果没有足够的网络编程经验积累和深入了解部标808协议文档,自研的GPS服务器往往需要半年甚至数年的时间才能最终稳定下来,这种成本即便对一个大公司而言也是个严重的挑战.

最近一个客户要求将gps部标平台移植到bootStrap框架作为前端框架,符合交通部796部标只是他们的一个基本要求,重点是要和他们的冷链云物流平台进行适配.我自己先浏览了客户的云物流平台的界面,采用的是bootStrap框架,自适应页面大小,基于html5开发,界面设计非常的简洁,清爽,冷色调,有点像苹果或者锤子的官方商城页面,这样可以快速的关注到自己想看到的内容.不像传统的物流网站千人一面,充斥着大量的物流广告还配有slider动图效果让人眼晕,显得很cheap. 显然如果直接将一个以后台数

部标gps监控平台的架构,随着平台接入的车辆越来越多,架构也面临越来越大的负载挑战,我们当然希望软件尽可能的优化并能够接入更多的车辆,减少在硬件上的投资.但是当车辆增多到某一个临界点的时候,仍然要面临的三个问题: 1)连接的限制 服务器软件接入终端的连接数是有限的,无论如何优化,都是有限的,接入的增多就会排队,超时timeout重置reset等问题就会出现; 2)部标808服务器软件的内存限制的问题 内存的限制,服务器操作系统中一个进程所承受的内存是有限制的,超过则导致服务器软件进程内存溢出而退

在2011年交通部的796标准推出后,随着各地交管部门的硬性要求,大多数的GPS监控系统或者车辆管理系统或者物流管理系统,无论是旧的,还是新开发的,都必须要以796标准为基础蓝本,首先要满足796的要求,然后在此基础上增加行业应用的个性化要求,如物流运输车辆非常关心的油耗管理,冷链运输非常关心温度控制等等. 所以开发GPS平台的时候,必须要首先阅读交通部的jt/t 796 , jt/t808和jt/t809的文档,以此作为自己的功能设计的需求来源,行业需求或用户需求是排在后面的.很多开发团队做出

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

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