![\"collections\"](\"https://i.imgur.com/MjE9LRl.png\")
After a few days of handling the data, I think I finally have handle on it - so here is a quick explanation of all of the data:
\nThe data was collected in 48 different \"collections\", or runs - each about 1 hour long.
\nThese are broken up into train and test, with each sub folder being the result of one of these hour long runs:
\n
Each collection had between 1-5 phones collecting data, which are represented as folders inside each collection folder - so this run had 2 phones, a Pixel4 and a Pixel4XL:
\n![\"phones\"](\"https://i.imgur.com/RBEExy6.png\")
The phones were mounted on the dashboard, while the \"ground truth\" gps location was collected by a much larger gps antenna in the back seat. More detail is available in this video: https://www.kaggle.com/google/android-smartphones-high-accuracy-datasets?select=ION+GNSS+2020+Presentation+%28Michael+Fu%29.mp4
\nThe sample_submission.csv file contains all of the collection/phone/timestamp combos that you have to submit:
\n![\"sample](\"https://i.imgur.com/U65Qwzj.png\")
The \"phone\" column is a combo of the collection name and phone name, and you are supposed to predict the lat/lng location for that phone at each of the timestamps listed.
\nBefore looking at the raw GNSS data, have a look at the baseline files:
\n![\"baseline](\"https://i.imgur.com/ECgivJJ.png\")
They contain a preliminary baseline lat/lng for all of the collections/phones at each timestamp. If you process and submit those lat/lngs, you will get a score of ~7m.
\nThe method for getting those baseline estimates is described here: https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238583
\nThe train and test phone folders each contain the raw GNSS data in a couple of different standard formats, as well as a \"derived\" csv format that is easier to read:
\n![\"derived\"](\"https://i.imgur.com/nSs2z8J.png\")
Understanding this data requires a post all to itself - so if it is overwhelming, you can start by totally ignoring this raw gnss data completely, and just by processing the baseline_ files.
\nThe raw GNSS contains all the base information you need to figure out the actual distance to individual satellites, and then figure out what that means for lat/long. This can be confusing! So don't start there :)
\nThese files also contain IMU data (acceleration, gyro, mag), which is kind of confusing - both the raw GNSS satellite data and the IMU data is in the same file, so you'll need to parse the file carefully to pull out just the information you want.
\nThe ground truth files contain the gps readings collected by the much more accurate gps antennas in the back of the cars (only provided for the training data):
\n![\"ground](\"https://i.imgur.com/suqAC4Q.png\")
and it's these values that you're really trying to predict for the test data.
\nI hope that helps some!
\nIf you're unsure about how to attack the problem, I'd recommend looking at this post as well: https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238590 which describes an approach that lets you start with the easier to parse baseline_ files, before moving on to the IMU data, and then finally the raw GNSS logs.
", "messages": [ { "id": "1318980", "postDate": "05/22/2021 18:39:59", "content": "After a few days of handling the data, I think I finally have handle on it - so here is a quick explanation of all of the data:
\nThe data was collected in 48 different \"collections\", or runs - each about 1 hour long.
\nThese are broken up into train and test, with each sub folder being the result of one of these hour long runs:
\n
Each collection had between 1-5 phones collecting data, which are represented as folders inside each collection folder - so this run had 2 phones, a Pixel4 and a Pixel4XL:
\n
The phones were mounted on the dashboard, while the \"ground truth\" gps location was collected by a much larger gps antenna in the back seat. More detail is available in this video: https://www.kaggle.com/google/android-smartphones-high-accuracy-datasets?select=ION+GNSS+2020+Presentation+%28Michael+Fu%29.mp4
\nThe sample_submission.csv file contains all of the collection/phone/timestamp combos that you have to submit:
\n
The \"phone\" column is a combo of the collection name and phone name, and you are supposed to predict the lat/lng location for that phone at each of the timestamps listed.
\nBefore looking at the raw GNSS data, have a look at the baseline files:
\n
They contain a preliminary baseline lat/lng for all of the collections/phones at each timestamp. If you process and submit those lat/lngs, you will get a score of ~7m.
\nThe method for getting those baseline estimates is described here: https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238583
\nThe train and test phone folders each contain the raw GNSS data in a couple of different standard formats, as well as a \"derived\" csv format that is easier to read:
\n
Understanding this data requires a post all to itself - so if it is overwhelming, you can start by totally ignoring this raw gnss data completely, and just by processing the baseline_ files.
\nThe raw GNSS contains all the base information you need to figure out the actual distance to individual satellites, and then figure out what that means for lat/long. This can be confusing! So don't start there :)
\nThese files also contain IMU data (acceleration, gyro, mag), which is kind of confusing - both the raw GNSS satellite data and the IMU data is in the same file, so you'll need to parse the file carefully to pull out just the information you want.
\nThe ground truth files contain the gps readings collected by the much more accurate gps antennas in the back of the cars (only provided for the training data):
\n
and it's these values that you're really trying to predict for the test data.
\nI hope that helps some!
\nIf you're unsure about how to attack the problem, I'd recommend looking at this post as well: https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238590 which describes an approach that lets you start with the easier to parse baseline_ files, before moving on to the IMU data, and then finally the raw GNSS logs.
", "rawMarkdown": "After a few days of handling the data, I think I finally have handle on it - so here is a quick explanation of all of the data:\n\n\n## \"Collections\"\n\nThe data was collected in 48 different \"collections\", or runs - each about 1 hour long.\n\nThese are broken up into train and test, with each sub folder being the result of one of these hour long runs:\n\n\n\nEach collection had between 1-5 phones collecting data, which are represented as folders inside each collection folder - so this run had 2 phones, a Pixel4 and a Pixel4XL:\n\n\n\nThe phones were mounted on the dashboard, while the \"ground truth\" gps location was collected by a much larger gps antenna in the back seat. More detail is available in this video: https://www.kaggle.com/google/android-smartphones-high-accuracy-datasets?select=ION+GNSS+2020+Presentation+%28Michael+Fu%29.mp4\n\n\n## Sample Submission\n\nThe sample_submission.csv file contains all of the collection/phone/timestamp combos that you have to submit:\n\n\n\nThe \"phone\" column is a combo of the collection name and phone name, and you are supposed to predict the lat/lng location for that phone at each of the timestamps listed.\n\n\n## Baselines\n\nBefore looking at the raw GNSS data, have a look at the baseline files:\n\n\n\nThey contain a preliminary baseline lat/lng for all of the collections/phones at each timestamp. If you process and submit those lat/lngs, you will get a score of ~7m.\n\nThe method for getting those baseline estimates is described here: https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238583\n\n\n## Raw GNSS data\n\nThe train and test phone folders each contain the raw GNSS data in a couple of different standard formats, as well as a \"derived\" csv format that is easier to read:\n\n\n\nUnderstanding this data requires a post all to itself - so if it is overwhelming, you can start by totally ignoring this raw gnss data completely, and just by processing the baseline_ files.\n\nThe raw GNSS contains all the base information you need to figure out the actual distance to individual satellites, and then figure out what that means for lat/long. This can be confusing! So don't start there :)\n\nThese files also contain IMU data (acceleration, gyro, mag), which is kind of confusing - both the raw GNSS satellite data and the IMU data is in the same file, so you'll need to parse the file carefully to pull out just the information you want.\n\n\n## Ground Truth\n\nThe ground truth files contain the gps readings collected by the much more accurate gps antennas in the back of the cars (only provided for the training data):\n\n\n\nand it's these values that you're really trying to predict for the test data.\n\nThank you!
\nPosts like this can really help for the first steps of everyone 👍
Hope you can win from indoor to outdoor😄
", "rawMarkdown": "Hope you can win from indoor to outdoor😄", "votes": null }, { "id": "1336683", "postDate": "06/05/2021 06:33:22", "content": "Thanks !!
\nThis post is very helpful as @avivlevi815 pointed out.
Well explained!
", "rawMarkdown": "Well explained!", "votes": null }, { "id": "1339224", "postDate": "06/07/2021 05:48:37", "content": "extremely helpful! Thank you.
", "rawMarkdown": "extremely helpful! Thank you.", "votes": null }, { "id": "1339685", "postDate": "06/07/2021 11:57:04", "content": "Very informative, Thanks for sharing chris.
", "rawMarkdown": "Very informative, Thanks for sharing chris.", "votes": null }, { "id": "1342646", "postDate": "06/09/2021 16:13:41", "content": "This post should help many to understand data and it saves lot of time while data exploration. @chris62
", "rawMarkdown": "This post should help many to understand data and it saves lot of time while data exploration. @chris62", "votes": null } ], "comments": [ { "id": 1319540, "author_name": "avivlevi815", "author_url": "", "post_date": "05/23/2021 09:52:15", "content": "Thank you!
\nPosts like this can really help for the first steps of everyone 👍
Hope you can win from indoor to outdoor😄
", "votes": null, "replies": [] }, { "id": 1336683, "author_name": "padmanaban1027", "author_url": "", "post_date": "06/05/2021 06:33:22", "content": "Thanks !!
\nThis post is very helpful as @avivlevi815 pointed out.
Well explained!
", "votes": null, "replies": [] }, { "id": 1339224, "author_name": "cherylwang", "author_url": "", "post_date": "06/07/2021 05:48:37", "content": "extremely helpful! Thank you.
", "votes": null, "replies": [] }, { "id": 1339685, "author_name": "nischaydnk", "author_url": "", "post_date": "06/07/2021 11:57:04", "content": "Very informative, Thanks for sharing chris.
", "votes": null, "replies": [] }, { "id": 1342646, "author_name": "vishnudevalla2404", "author_url": "", "post_date": "06/09/2021 16:13:41", "content": "This post should help many to understand data and it saves lot of time while data exploration. @chris62
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "1318980": "After a few days of handling the data, I think I finally have handle on it - so here is a quick explanation of all of the data:\n\n\n## \"Collections\"\n\nThe data was collected in 48 different \"collections\", or runs - each about 1 hour long.\n\nThese are broken up into train and test, with each sub folder being the result of one of these hour long runs:\n\n\n\nEach collection had between 1-5 phones collecting data, which are represented as folders inside each collection folder - so this run had 2 phones, a Pixel4 and a Pixel4XL:\n\n\n\nThe phones were mounted on the dashboard, while the \"ground truth\" gps location was collected by a much larger gps antenna in the back seat. More detail is available in this video: https://www.kaggle.com/google/android-smartphones-high-accuracy-datasets?select=ION+GNSS+2020+Presentation+%28Michael+Fu%29.mp4\n\n\n## Sample Submission\n\nThe sample_submission.csv file contains all of the collection/phone/timestamp combos that you have to submit:\n\n\n\nThe \"phone\" column is a combo of the collection name and phone name, and you are supposed to predict the lat/lng location for that phone at each of the timestamps listed.\n\n\n## Baselines\n\nBefore looking at the raw GNSS data, have a look at the baseline files:\n\n\n\nThey contain a preliminary baseline lat/lng for all of the collections/phones at each timestamp. If you process and submit those lat/lngs, you will get a score of ~7m.\n\nThe method for getting those baseline estimates is described here: https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238583\n\n\n## Raw GNSS data\n\nThe train and test phone folders each contain the raw GNSS data in a couple of different standard formats, as well as a \"derived\" csv format that is easier to read:\n\n\n\nUnderstanding this data requires a post all to itself - so if it is overwhelming, you can start by totally ignoring this raw gnss data completely, and just by processing the baseline_ files.\n\nThe raw GNSS contains all the base information you need to figure out the actual distance to individual satellites, and then figure out what that means for lat/long. This can be confusing! So don't start there :)\n\nThese files also contain IMU data (acceleration, gyro, mag), which is kind of confusing - both the raw GNSS satellite data and the IMU data is in the same file, so you'll need to parse the file carefully to pull out just the information you want.\n\n\n## Ground Truth\n\nThe ground truth files contain the gps readings collected by the much more accurate gps antennas in the back of the cars (only provided for the training data):\n\n\n\nand it's these values that you're really trying to predict for the test data.\n\n