【问题标题】:Calculating Cumulative elevation gain give me wierd results计算累积海拔增益给了我奇怪的结果
【发布时间】:2013-10-06 15:05:08
【问题描述】:

我的应用程序使用 CoreLocation 并跟踪用户移动。
当用户走路或开车时,我将每个坐标保存到本地数据库 (lat/lng/alt),以便我可以根据保存的坐标绘制路线。
几天前我添加了Cumulative elevation gain,并在

中使用了这段代码
didLocationUpdate:
- (void)locationManager:(CLLocationManager *)manager didUpdateToLocation:(CLLocation *)newLocation fromLocation:(CLLocation *)oldLocation
{
    netElevationGain += MAX(0, oldLocation.altitude - newLocation.altitude);
}

但有些事情是错误的。
我启动了应用程序并开始走动并四处走动几英里,我得到netElevationGain 近 500 米。这不可能是正确的。
这是每个点保存在数据库中的netElevation 列表:

0,41,43,44,47,52,55,62,73,80,91,100,114,140,146,153,159,180,199,208,228,240,259,275,320,329,349,359,366,375,381,392,408,419,428,437,446,449,462,469,478,486

海拔
0.000000,181.678055,181.891495,182.786850,179.315399,177.035721,182.636307,181.259399,178.653015,192.552551,185.398819,182.693436,181.369766,154.306747,157.031693,159.748871,185.080856,198.080673,176.473877,178.646851,175.784424,178.184128,181.237488,188.956894,177.713181,193.673019,188.470184,182.749054,181.966507,181.547592,191.638657,198.713989,188.582977,197.977921,203.184540,205.108856,198.304123

为了显示增益,我使用简单的select max(gain) from table where ...



更新

现在我得到更差的值(按降序排列):
替代:

200.334869,200.594666,196.293945,195.240234,191.800446,192.622375,179.951385,179.185577,179.681122,177.843719,183.459595,174.170502,0.000000

获得:

307,301,294,285,275,269,252,246,234,227,217,202,0

【问题讨论】:

  • netElevation 的值是根据您粘贴在下面的altitudes 计算得出的吗?
  • 是的。它来自同一个数据库。我存储高度,同时存储当前的 netElevation。我主要担心的是我认为这个数字应该更小。所以我想知道我做错了什么。
  • 我也看不到海拔值与您的海拔高度的对应关系(例如,值 41 来自哪里?)。您应该将它们一起打印在一个表格中。 - 不应该是newLocation.altitude - oldLocation.altitude吗?而且您可能不得不忽略第一个更改0 -> 181.678055
  • 我不知道这就是我问的原因。所以坐应该是新的-旧的为什么?
  • @1110: 你能显示- (void)locationManager:didUpdateToLocation:fromLocation:的完整来源吗?

标签: ios objective-c core-location cllocationmanager


【解决方案1】:

我采用了您列出的值并按如下方式运行它们:

NSArray *altitudes = @[ @(0.000000), @(181.678055), @(181.891495), @(182.786850), @(179.315399), 
                        @(177.035721), @(182.636307), @(181.259399), @(178.653015), @(192.552551), 
                        @(185.398819), @(182.693436), @(181.369766), @(154.306747), @(157.031693), 
                        @(159.748871), @(185.080856), @(198.080673), @(176.473877), @(178.646851), 
                        @(175.784424), @(178.184128), @(181.237488), @(188.956894), @(177.713181), 
                        @(193.673019), @(188.470184), @(182.749054), @(181.966507), @(181.547592), 
                        @(191.638657), @(198.713989), @(188.582977), @(197.977921), @(203.184540), 
                        @(205.108856), @(198.304123) ];

float netAlt = 0.0f;

// Start with the third value as we're only interesting in net gain
for (NSInteger i = 2; i < altitudes.count; i++) {
    float oldAlt = [altitudes[i-1] floatValue];
    float newAlt = [altitudes[i] floatValue];

    // newAlt - oldAlt because we're interested in the 
    // difference between current and previous
    float diff = newAlt - oldAlt;

    netAlt += MAX(0, diff);
    printf("%.0f,", netAlt);
}

这产生了以下输出:

0,1,1,1,7,7,7,21,21,21,21,21,23,26,51,64,64,67,67,69,72,80,80,96 ,96,96,96,96,106,113,113,122,127,129,129

这在我看来是合理和现实的。目前还不清楚你是如何设法获得你所拥有的价值观的。他们没有任何意义。

【讨论】:

  • 所以我实际上根本不需要将增益存储到数据库,因为我可以仅从高度数组计算它?
  • 这取决于你想用增益做什么。
  • 今天我正在下山,并在您的代码中使用存储的高度。没有起落。我获得了 79 米的净增益。我应该以某种方式对数据进行排序吗?据我了解,收益就是你上升的时候。
  • 不,不需要对数据进行排序。
  • 那么,如果我从 alt 开始,例如 200 米,然后下降到 100 米,你认为有什么可能获得 79 米的增益?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-08-01
  • 2020-04-30
  • 1970-01-01
  • 2021-09-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多