{ "id": 250614, "title": "Is the receivedSvTimeInGpsNanos in some *_derived.csv correct?", "url": "/competitions/google-smartphone-decimeter-challenge/discussion/250614", "author_name": "", "post_date": "2021-07-03T14:10:41.149455600Z", "votes": 8, "comment_count": 2, "views": 0, "content": "

I am trying to reproduce base_locations_train.csv with *_derive.csv referring to the following article, and I was able to get similar results with some of the files.
\nhttps://www.kaggle.com/gymf123/tips-notes-from-the-competition-hosts
\nhttps://www.kaggle.com/hyperc/gsdc-reproducing-baseline-wls-on-one-measurement
\nHowever, I failed in some files and got a worse score comparing with baseline, and the receivedSvTimeInGpsNanos for some of the files seemed to be wrong. For example, in \"2020-07-17-US-MTV-2_Mi8\", this figure shows ground truth (red) and my estimation based on *_derived.csv (blue), and values indicate receivedSvTimeInGpsNanos. After missing value(?), one-second gaps occur.
\nAre there any other rules for receivedSvTimeInGpsNanos besides Tips 1? I saw strange behavior when the GPS observation interval was irregular. Has anyone been able to reproduce them?

\n

\"\"

", "messages": [ { "id": "1374688", "postDate": "07/03/2021 14:10:41", "content": "

I am trying to reproduce base_locations_train.csv with *_derive.csv referring to the following article, and I was able to get similar results with some of the files.
\nhttps://www.kaggle.com/gymf123/tips-notes-from-the-competition-hosts
\nhttps://www.kaggle.com/hyperc/gsdc-reproducing-baseline-wls-on-one-measurement
\nHowever, I failed in some files and got a worse score comparing with baseline, and the receivedSvTimeInGpsNanos for some of the files seemed to be wrong. For example, in \"2020-07-17-US-MTV-2_Mi8\", this figure shows ground truth (red) and my estimation based on *_derived.csv (blue), and values indicate receivedSvTimeInGpsNanos. After missing value(?), one-second gaps occur.
\nAre there any other rules for receivedSvTimeInGpsNanos besides Tips 1? I saw strange behavior when the GPS observation interval was irregular. Has anyone been able to reproduce them?

\n

\"\"

", "rawMarkdown": "I am trying to reproduce base_locations_train.csv with *_derive.csv referring to the following article, and I was able to get similar results with some of the files.\nhttps://www.kaggle.com/gymf123/tips-notes-from-the-competition-hosts\nhttps://www.kaggle.com/hyperc/gsdc-reproducing-baseline-wls-on-one-measurement\nHowever, I failed in some files and got a worse score comparing with baseline, and the receivedSvTimeInGpsNanos for some of the files seemed to be wrong. For example, in \"2020-07-17-US-MTV-2_Mi8\", this figure shows ground truth (red) and my estimation based on *_derived.csv (blue), and values indicate receivedSvTimeInGpsNanos. After missing value(?), one-second gaps occur. \nAre there any other rules for receivedSvTimeInGpsNanos besides Tips 1? I saw strange behavior when the GPS observation interval was irregular. Has anyone been able to reproduce them?\n\n![](https://user-images.githubusercontent.com/50971798/124356582-af832000-dc51-11eb-8951-2d92c13b63e8.png)", "votes": null }, { "id": "1374791", "postDate": "07/03/2021 15:55:13", "content": "

I've seen similar issues - a few missing _derived points (compared to the baseline given - or perhaps other mismatched time issues when comparing _derived with the .20o and with the baseline file (I haven't fully tracked it all down yet)).

\n

It's only a few points per run that I've seen (and not on every one), though it does make it a bit tricky to make sure all the timestamps line up - it took me awhile to figure out what was going on :)

", "rawMarkdown": "I've seen similar issues - a few missing _derived points (compared to the baseline given - or perhaps other mismatched time issues when comparing _derived with the .20o and with the baseline file (I haven't fully tracked it all down yet)).\n\nIt's only a few points per run that I've seen (and not on every one), though it does make it a bit tricky to make sure all the timestamps line up - it took me awhile to figure out what was going on :)", "votes": null }, { "id": "1374813", "postDate": "07/03/2021 16:24:44", "content": "

Thank you for your comment.

\n
\n

it does make it a bit tricky to make sure all the timestamps line up

\n
\n

Yes. If this is a practical problem, we should deal with it, but if it is a data preprocessing problem, thinking about it is boring for me. Therefore, I’m thinking about whether to deal with it.

", "rawMarkdown": "Thank you for your comment.\n> it does make it a bit tricky to make sure all the timestamps line up\n\nYes. If this is a practical problem, we should deal with it, but if it is a data preprocessing problem, thinking about it is boring for me. Therefore, I’m thinking about whether to deal with it.", "votes": null } ], "comments": [ { "id": 1374791, "author_name": "chris62", "author_url": "", "post_date": "07/03/2021 15:55:13", "content": "

I've seen similar issues - a few missing _derived points (compared to the baseline given - or perhaps other mismatched time issues when comparing _derived with the .20o and with the baseline file (I haven't fully tracked it all down yet)).

\n

It's only a few points per run that I've seen (and not on every one), though it does make it a bit tricky to make sure all the timestamps line up - it took me awhile to figure out what was going on :)

", "votes": null, "replies": [ { "id": 1374813, "author_name": "yawata", "author_url": "", "post_date": "07/03/2021 16:24:44", "content": "

Thank you for your comment.

\n
\n

it does make it a bit tricky to make sure all the timestamps line up

\n
\n

Yes. If this is a practical problem, we should deal with it, but if it is a data preprocessing problem, thinking about it is boring for me. Therefore, I’m thinking about whether to deal with it.

", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "1374688": "I am trying to reproduce base_locations_train.csv with *_derive.csv referring to the following article, and I was able to get similar results with some of the files.\nhttps://www.kaggle.com/gymf123/tips-notes-from-the-competition-hosts\nhttps://www.kaggle.com/hyperc/gsdc-reproducing-baseline-wls-on-one-measurement\nHowever, I failed in some files and got a worse score comparing with baseline, and the receivedSvTimeInGpsNanos for some of the files seemed to be wrong. For example, in \"2020-07-17-US-MTV-2_Mi8\", this figure shows ground truth (red) and my estimation based on *_derived.csv (blue), and values indicate receivedSvTimeInGpsNanos. After missing value(?), one-second gaps occur. \nAre there any other rules for receivedSvTimeInGpsNanos besides Tips 1? I saw strange behavior when the GPS observation interval was irregular. Has anyone been able to reproduce them?\n\n![](https://user-images.githubusercontent.com/50971798/124356582-af832000-dc51-11eb-8951-2d92c13b63e8.png)", "1374791": "I've seen similar issues - a few missing _derived points (compared to the baseline given - or perhaps other mismatched time issues when comparing _derived with the .20o and with the baseline file (I haven't fully tracked it all down yet)).\n\nIt's only a few points per run that I've seen (and not on every one), though it does make it a bit tricky to make sure all the timestamps line up - it took me awhile to figure out what was going on :)", "1374813": "Thank you for your comment.\n> it does make it a bit tricky to make sure all the timestamps line up\n\nYes. If this is a practical problem, we should deal with it, but if it is a data preprocessing problem, thinking about it is boring for me. Therefore, I’m thinking about whether to deal with it." }, "source": "meta" }