为什么 GPS 会报告异常的经度数字?
Why is the GPS reporting insane longitude numbers?
我负责维护和开发一款应用程序,该应用程序严重依赖使用智能手机设备中的 GPS 跟踪用户的行车路线。
问题
问题是 GPS 坐标不准确(到了奇怪的程度)。我说的不是几百米,而是几千米。我的客户在新西兰,GPS 坐标是澳大利亚西部大洋中部的一个位置。
以下是手机正在记录的来自我的客户的错误数据示例:
如您所见,纬度值似乎是正确的,或者说足够理智。但是经度值都固定为100,一点都不正常
技术
该应用程序是使用 cordova-android 5.22 和 cordova-ios 4.2.1 构建的,但是我们在使用 Appcelerator 的 titanium 的旧版应用程序中发现了同样的问题框架(同样只针对新西兰客户),所以我不认为这个问题是 cordova 或 titanium 特有的。我们也无法重现该问题(开发团队位于加拿大)。
不幸的是,此时我不知道客户使用的是Android还是iOS,或者他们使用的是什么版本的OS。我会在获得该信息后立即更新问题。
除了读取它们并写入日志文件外,应用程序不会对 latitude/longitude 值执行任何操作,日志文件会上传到我们的服务器,数据会被读取并存储到 MySQL数据库,使用 FLOAT 长度 16,14
代码
Cordova 应用程序:
geoWatchId = navigator.geolocation.watchPosition(logGeoItem, loggingFailure, {enableHighAccuracy: true});
...
function logGeoItem(geoPoint){
if(loggingState.isLogging){
console.log(JSON.stringify(geoPoint));
var newLogItem = {latitude: geoPoint.coords.latitude, longitude: geoPoint.coords.longitude, heading: geoPoint.coords.heading, altitude: geoPoint.coords.altitude, created_datetime: Date.now()};
loggingState.currentGeoLoggingData.push(newLogItem);
}
}
是的,watchPosition 代码包含在 deviceready
事件中。
NodeJS GPS 数据存储在 MySQL 数据库中
for(var j=0; j<data.location.length; j++) {
var sqlLocation = "INSERT INTO location (session_id, heading, altitude, latitude, longitude, created_datetime) VALUES";
sqlLocation += "('" + data.location[j].session_id + "','" + data.location[j].heading + "','" + data.location[j].altitude + "','" + data.location[j].latitude + "','" + data.location[j].longitude + "','" + data.location[j].created_datetime + "');";
connection.query(sqlLocation, function(err, result){
log.info(err);
log.info(result);
if(err) {
connection.rollback(function(){
callback({ result: 'error', errorMsg: constants.errors.ERROR_UPLOAD_LOCATION_DATA });
});
}
});
}
研究
我在网上搜索,发现几篇不同的文章和堆栈溢出 post 描述了不准确的 GPS 位置,但这些描述了 GPS 仍然可能是正常的。
手头的问题是经度值完全不正常,经度值似乎始终为 100。
我还没有找到任何可以说明为什么经度如此不正常,以及为什么它始终为 100 的原因。如果我的问题实际上只是读数不准确,我希望有各种经度值,而不是常数 100.
任何人都可以向我提供有关如何进行调试的建议吗?为什么只有经度固定在100?
问题是经度值实际上超过了 MySQL 中设置的最大允许数字。
FLOAT (16,14)
表示最多可以有16位,其中14位属于小数点后的数字。
新西兰部分地区的经度值可能 >= 100。
例如,新西兰北部旺格雷是:-35.725043, 174.319490
因为 174.319490 是一个违反 16/14 规则的数字(即使该数字本身不包含小数点后的 14 位数字),它似乎以 100 为上限并补零。
如果我将 table 更改为类型 FLOAT (17,14)
允许小数点前的第三位数字,则数据将正确存储。
在 MySQL 5.6.21
上测试
我负责维护和开发一款应用程序,该应用程序严重依赖使用智能手机设备中的 GPS 跟踪用户的行车路线。
问题
问题是 GPS 坐标不准确(到了奇怪的程度)。我说的不是几百米,而是几千米。我的客户在新西兰,GPS 坐标是澳大利亚西部大洋中部的一个位置。
以下是手机正在记录的来自我的客户的错误数据示例:
如您所见,纬度值似乎是正确的,或者说足够理智。但是经度值都固定为100,一点都不正常
技术
该应用程序是使用 cordova-android 5.22 和 cordova-ios 4.2.1 构建的,但是我们在使用 Appcelerator 的 titanium 的旧版应用程序中发现了同样的问题框架(同样只针对新西兰客户),所以我不认为这个问题是 cordova 或 titanium 特有的。我们也无法重现该问题(开发团队位于加拿大)。
不幸的是,此时我不知道客户使用的是Android还是iOS,或者他们使用的是什么版本的OS。我会在获得该信息后立即更新问题。
除了读取它们并写入日志文件外,应用程序不会对 latitude/longitude 值执行任何操作,日志文件会上传到我们的服务器,数据会被读取并存储到 MySQL数据库,使用 FLOAT 长度 16,14
代码 Cordova 应用程序:
geoWatchId = navigator.geolocation.watchPosition(logGeoItem, loggingFailure, {enableHighAccuracy: true});
...
function logGeoItem(geoPoint){
if(loggingState.isLogging){
console.log(JSON.stringify(geoPoint));
var newLogItem = {latitude: geoPoint.coords.latitude, longitude: geoPoint.coords.longitude, heading: geoPoint.coords.heading, altitude: geoPoint.coords.altitude, created_datetime: Date.now()};
loggingState.currentGeoLoggingData.push(newLogItem);
}
}
是的,watchPosition 代码包含在 deviceready
事件中。
NodeJS GPS 数据存储在 MySQL 数据库中
for(var j=0; j<data.location.length; j++) {
var sqlLocation = "INSERT INTO location (session_id, heading, altitude, latitude, longitude, created_datetime) VALUES";
sqlLocation += "('" + data.location[j].session_id + "','" + data.location[j].heading + "','" + data.location[j].altitude + "','" + data.location[j].latitude + "','" + data.location[j].longitude + "','" + data.location[j].created_datetime + "');";
connection.query(sqlLocation, function(err, result){
log.info(err);
log.info(result);
if(err) {
connection.rollback(function(){
callback({ result: 'error', errorMsg: constants.errors.ERROR_UPLOAD_LOCATION_DATA });
});
}
});
}
研究
我在网上搜索,发现几篇不同的文章和堆栈溢出 post 描述了不准确的 GPS 位置,但这些描述了 GPS 仍然可能是正常的。
手头的问题是经度值完全不正常,经度值似乎始终为 100。
我还没有找到任何可以说明为什么经度如此不正常,以及为什么它始终为 100 的原因。如果我的问题实际上只是读数不准确,我希望有各种经度值,而不是常数 100.
任何人都可以向我提供有关如何进行调试的建议吗?为什么只有经度固定在100?
问题是经度值实际上超过了 MySQL 中设置的最大允许数字。
FLOAT (16,14)
表示最多可以有16位,其中14位属于小数点后的数字。
新西兰部分地区的经度值可能 >= 100。 例如,新西兰北部旺格雷是:-35.725043, 174.319490
因为 174.319490 是一个违反 16/14 规则的数字(即使该数字本身不包含小数点后的 14 位数字),它似乎以 100 为上限并补零。
如果我将 table 更改为类型 FLOAT (17,14)
允许小数点前的第三位数字,则数据将正确存储。
在 MySQL 5.6.21
上测试