Yesterday, the product issued a new interactive manual, which mainly increased the recording and display of " pace " information during exercise. Most people may not be very familiar with the term "pace". Baidu Encyclopedia says this:
That is, the pace is expressed in time per kilometer. In the new interaction, the pace per kilometer during a certain run needs to be displayed sequentially in a list. This information was not saved in the previous motion profile file (GPX file), and nowhere else was the pace displayed. When the user moves, we can already record the latitude and longitude, speed, distance and GPS time of each GPS point collected. In order to keep this information consistent when the Android client and the iOS client synchronize data to the server, the GPX format defined together is used, which is roughly like this:
The type indicates the riding mode, whether it is running or cycling. We have no objection to how to obtain pace information during exercise. By comparing the rounding down and rounding up of adjacent trajectory points, we can obtain trajectory points with a moving distance of an integer number of kilometers. But we had a different idea about how to save in GPX files. For the formulation of data files for public use, please refer to the requirements of the public database format:
1. Minimize changes to the format of public data files as long as the requirements are met;
2. While compatible with old and new data files, generate as little redundant data as possible.
In this regard, my colleagues in the Android team suggested adding a <duration>0</duration> node under the trkpt node , which stores the number of seconds from the trajectory point to the first trajectory point, and finally looks like this:
<trkpt lat="31.828234815111482" lon="117.18830751582587"><ele>49.6828332826443</ele><dis>0.008209216</dis><sp>7.497872</sp><time>2016-02-24 14:12:49</time><type>0</type><duration>42</duration></trkpt>
The basis for this is that the GPX file stores relatively primitive information, and with this information, the client can easily get the speed table per kilometer based on these points. But this requires all points to record the duration, which will generate a lot of useless data in terms of demand. Therefore, my opinion is to open up the information of the speed table separately before the data area of the track point, like this:
<?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.2" creator="Cycling"> <trk> <name>1918_0_track</name> <paceseg> <pace value=“320” ><pace> <pace value=“345” ><pace> <pace value=“325” ><pace> </paceseg> <trkseg> <trkpt lat="31.828524" lon="117.189110"> <dis>0.018462</dis> <sp>7.008073</sp> <ele>73.000000</ele> <time>2015-11-12T13:37:40Z</time> <type>0</type> </trkpt>
The advantage of this definition is that the pace table can be read directly when processing the GPX file, without having to process all the track points. However, the disadvantage is also obvious, that is, the separate data area is expanded, and there is still a certain degree of data redundancy. After some discussion, we finally decided that the second way is better.
But, yes, but, at this moment, I suddenly thought of the definition of pace on Baidu Encyclopedia, which is the thing at the beginning of the article. Pace is the time it takes to run per kilometer. There seems to be a problem with this time, because our sports modes - cycling and running, do not count the time when paused, which means that when the speed is below a certain threshold, our timing is stopped. This is also the direct reason why we want to calculate the pace and store it in the GPX file instead of using the GPS time of the track points in the GPX file. But how is pace time calculated? Should the pause time be taken into account, or should it not be counted as if it were riding. According to the definition of Baidu Encyclopedia, I am afraid it should be in accordance with the former.
Thus, this article returns to the title of the importance of understanding product requirements in the development process. When we confirmed the timing of the pace with our product colleagues, we confirmed that the pace calculation should start from the beginning of the exercise, and no matter what the exercise speed is, if it ends, it should be included in the time. As an extreme example, if I start running, but I run very slowly, I run 500m in 15 minutes, sleep for half an hour, and then run 500m in 15 minutes, then my pace for the first mile is 60 minutes . Considering this situation, the extensions we discussed earlier about GPX files are useless! Because the existing data already contains complete information, we can get the speed table per kilometer according to the GPS time of the track point.
So, to sum up, since we didn't develop a deep understanding of the concept of pace, we didn't realize the difference from the previous ride time recording (and to a certain extent because the product requirements were not detailed enough), so we Spent a lot of work on a technical issue that didn't need to be discussed. I think many developers have encountered this kind of problem. Therefore, when we get new requirements, before we take it for granted, we might as well have in-depth communication with our relatively unfamiliar domain knowledge and product personnel to deepen our understanding of the details. To understand, it is also good to discover the problems that the product personnel did not consider when entering the requirements.
Reprint please indicate the source http://grayheart.iteye.com.