First of all, I would like to thank the host for hosting such a wonderful competition.
\nAlso thanks to my three excellent teammates.
\nWithout them, I would never have been able to achieve these results.
Here is a brief description of my part.
\nMy teammate shimacos's part is here
My part is divided into seven sections.
Most of the processing is done for each three areas shown in the notebook below.
\nhttps://www.kaggle.com/columbia2131/area-knn-prediction-train-hand-label
A lot of the credit for my part goes to my other teammates.
\n(In particular, shimacos's ADR contributed greatly to my model as well.)
This is almost same as public kernel.
\nBy interpolating, I also used the prediction of the phone with a slight shift in timestamp.
I searched the stopping point and filled in the prediction with the median of near timestamp predictions.
\nWhen the distance from the previous position is less than threshold, I process this as stopping.
By repeating \"phone mean\" and \"removing noise while stopped\" several times, the score improved.
\nI don't know much about why the repetition was effective, but I expect it was due to the smoothing effect.
\nThe number of repetitions was optimized for each area.
I predict the relative latDeg and LngDeg to the Ground Truth in each timestamp.
\nFor example, the following features were effective.
After predicting the relative position, I corrected the solution using it.
\nThis was mostly pao's work, with a few changes on my part.
\nWe used linearly interpolated ground truth for grid points.
\nWe evaluated the cost of each grid point and used the greedy method.
\nThere are four points to evaluate the cost.
This is my teammate shimacos's findings.This worked also well for my model.
\nHere are the details.
\nhttps://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/261904
I did 1-6 for several types of baselines.
\nBy ensembling them at the end, CV has been improved.
\nI used the following three kinds of baselines.
After \"Ensembles in different baselines\", best score of my part is this.
\nBy blending it with other team members' models and adding post-processing, we got the final score.
", "messages": [ { "id": "1453762", "postDate": "08/06/2021 02:00:07", "content": "First of all, I would like to thank the host for hosting such a wonderful competition.
\nAlso thanks to my three excellent teammates.
\nWithout them, I would never have been able to achieve these results.
Here is a brief description of my part.
\nMy teammate shimacos's part is here
My part is divided into seven sections.
Most of the processing is done for each three areas shown in the notebook below.
\nhttps://www.kaggle.com/columbia2131/area-knn-prediction-train-hand-label
A lot of the credit for my part goes to my other teammates.
\n(In particular, shimacos's ADR contributed greatly to my model as well.)
This is almost same as public kernel.
\nBy interpolating, I also used the prediction of the phone with a slight shift in timestamp.
I searched the stopping point and filled in the prediction with the median of near timestamp predictions.
\nWhen the distance from the previous position is less than threshold, I process this as stopping.
By repeating \"phone mean\" and \"removing noise while stopped\" several times, the score improved.
\nI don't know much about why the repetition was effective, but I expect it was due to the smoothing effect.
\nThe number of repetitions was optimized for each area.
I predict the relative latDeg and LngDeg to the Ground Truth in each timestamp.
\nFor example, the following features were effective.
After predicting the relative position, I corrected the solution using it.
\nThis was mostly pao's work, with a few changes on my part.
\nWe used linearly interpolated ground truth for grid points.
\nWe evaluated the cost of each grid point and used the greedy method.
\nThere are four points to evaluate the cost.
This is my teammate shimacos's findings.This worked also well for my model.
\nHere are the details.
\nhttps://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/261904
I did 1-6 for several types of baselines.
\nBy ensembling them at the end, CV has been improved.
\nI used the following three kinds of baselines.
After \"Ensembles in different baselines\", best score of my part is this.
\nBy blending it with other team members' models and adding post-processing, we got the final score.
", "rawMarkdown": "First of all, I would like to thank the host for hosting such a wonderful competition.\nAlso thanks to my three excellent teammates.\nWithout them, I would never have been able to achieve these results.\n\nHere is a brief description of my part.\nMy teammate [shimacos](https://www.kaggle.com/shimacos)'s part is [here](https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/261904)\n### Overview\n* My part is divided into seven sections.\n\n* Most of the processing is done for each three areas shown in the notebook below.\nhttps://www.kaggle.com/columbia2131/area-knn-prediction-train-hand-label\n\n* A lot of the credit for my part goes to my other teammates.\n(In particular, shimacos's ADR contributed greatly to my model as well.)\n\n### 1. Phone Mean\nThis is almost same as public kernel.\nBy interpolating, I also used the prediction of the phone with a slight shift in timestamp.\n\n### 2. Remove noise while stopping\nI searched the stopping point and filled in the prediction with the median of near timestamp predictions.\nWhen the distance from the previous position is less than threshold, I process this as stopping.\n \n### 3. Repeat \"phone mean\" and \"Remove noise while stopping\"\nBy repeating \"phone mean\" and \"removing noise while stopped\" several times, the score improved.\nI don't know much about why the repetition was effective, but I expect it was due to the smoothing effect.\nThe number of repetitions was optimized for each area.\n\n### 4. Predict relative positions with LightGBM \nI predict the relative latDeg and LngDeg to the Ground Truth in each timestamp.\nFor example, the following features were effective.\n* Relative lat,lng and dist of Neighnor Groud Truth(in train, except for that collection)\n* other phone relative lat or lng of same timestamp\n* lat, lng of previous or next timestamp (etc..)\n\nAfter predicting the relative position, I corrected the solution using it.\n\n### 5. Snap to Grid using cost optimization(downtown only)\nThis was mostly [pao](https://www.kaggle.com/go5kuramubon)'s work, with a few changes on my part.\nWe used linearly interpolated ground truth for grid points. \nWe evaluated the cost of each grid point and used the greedy method.\nThere are four points to evaluate the cost.\n* we want to snap to nearest ground truth.(simplest )\n* The distance to the previous grid point should be as close as possible to the predicted relative distance (using LGBM speed prediction).\n* The distance of the previous snap to grid and the distance of the current snap to grid are equal.\n* Use the same collection as the grid point used for the previous snap to grid.\n\n### 6. Smoothing of AccumulatedDeltaRange\nThis is my teammate shimacos's findings.This worked also well for my model.\nHere are the details.\nhttps://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/261904\n\n### 7. Ensembles in different baselines\nI did 1-6 for several types of baselines.\nBy ensembling them at the end, CV has been improved.\nI used the following three kinds of baselines.\n* original baseline + Kalman filter\n* WLSADR + position shift(this is also my teammate pao`s work)\n* WLSADR + gauss smoothing\n \n### Result \nAfter \"Ensembles in different baselines\", best score of my part is this.\n* CV:2.36026, Public:3.745, Private:2.336(Public and Private were checked on latesub)\n\nBy blending it with other team members' models and adding post-processing, we got the final score.", "votes": null }, { "id": "1454771", "postDate": "08/06/2021 10:15:04", "content": "Congrats Competition Master, and It was fun to work with you.
\nOur almost solution is written by Shimacos and monnu, so I will add some other point especially ensemble phase.
\nIn ensemble phase, some point has large different between each model prediction, in that case one of them have possible to missing prediction.
\nSo in that pattern, I will remove this point and interpolate it from previous and next point.
\nIt makes a little improvement
Model has good point and bad point at not only area but also speed.
\nOne model has good in high speed, but not good in slow or stop.
\nSo I will change weight per speed which is predicted by LightGBM.
\nIt makes also a little improvement.
Congratulations on Gold Medal and promotion to Competition Master.
\nI have some questions about \"4. Predict relative positions with LightGBM\".I am happy you to answer if you have time.
Thanks for your comments and questions!
\nI will answer in order.
Q1.
\nIn my case, the CV improved on the highway as well, though only slightly.
\nThe CV(highway only) before and after this process are shown below.
\n2.163→2.082
Q2.
\nYes. I used GroupKFold to build the CV(group = collectionName)
BTW, You kept the top positions during the competition and also published useful kernels and discussions.
\nI think you are definitely one of the great contributors to this competition.
Thank you for answer to questions.
\nIt's great to see the effect on the highway.
\nCompared to our model, I think your model has better feature set.
Also,Thanks for your kinds words.
\nI was depressed by the shake down, but your words have cheered me up.
Congrats Competition Master, and It was fun to work with you.
\nOur almost solution is written by Shimacos and monnu, so I will add some other point especially ensemble phase.
\nIn ensemble phase, some point has large different between each model prediction, in that case one of them have possible to missing prediction.
\nSo in that pattern, I will remove this point and interpolate it from previous and next point.
\nIt makes a little improvement
Model has good point and bad point at not only area but also speed.
\nOne model has good in high speed, but not good in slow or stop.
\nSo I will change weight per speed which is predicted by LightGBM.
\nIt makes also a little improvement.
Congratulations on Gold Medal and promotion to Competition Master.
\nI have some questions about \"4. Predict relative positions with LightGBM\".I am happy you to answer if you have time.
Thanks for your comments and questions!
\nI will answer in order.
Q1.
\nIn my case, the CV improved on the highway as well, though only slightly.
\nThe CV(highway only) before and after this process are shown below.
\n2.163→2.082
Q2.
\nYes. I used GroupKFold to build the CV(group = collectionName)
BTW, You kept the top positions during the competition and also published useful kernels and discussions.
\nI think you are definitely one of the great contributors to this competition.
Thank you for answer to questions.
\nIt's great to see the effect on the highway.
\nCompared to our model, I think your model has better feature set.
Also,Thanks for your kinds words.
\nI was depressed by the shake down, but your words have cheered me up.