{ "id": 335810, "title": "4th place solution", "content": "

Hello !

\n

First of all, I would like to thank the organizers for this very interesting and challenging competition. Also, congratulations to all participants : the suspense was so tense in the last few days that I can’t believe it’s over now. I’m writing this at 3am, very grateful and relieved ! Also, a kind word for the deserving people who missed a medal by very few positions, because it can be hard to accept. You did really great, and I’m sure you’ll do even better the next time. Hardwork pays off.

\n

Finally, thanks to my talented and hard-working teammates @ymatioun and @theoviel, with whom I enjoyed to work and learn.
\n

\n

\n

Our solution relies on the following steps :

\n

• Clean data, mostly names. Remove special characters + space, apply unidecode to unify non-latin languages, lower text…
\n• Create some meaningful features. This has required some work beforehand, for instance to create groups of similar categories ('gyms', 'gyms or fitness centers', 'gymnastics gyms', 'gym pools'…), and to compute the average distance for each of them where we would be likely to find at least 50%, 75%, 90% and 95% of true matches. We also grouped names, cities and states, if they designated the same place. You can find 3 useful notebooks here that show how we did it.
\n• Find candidate pairs to match. To do this, we used different ideas : consider near neighbors; name-similarity; same words in names; grouped-category equality; (cleaned) phone number equality; same address; TF-IDF (especially for airports and indian places); …
\n• Pair matching. At this point, we had so much pairs that we had to use 2 models to avoid memory errors. The first one, a 5-fold LGBM, was only using a few features such as distance or name similarity to avoid issues. Its goal was to delete every non-relevant pairs (threshold < 0.007). We then computed more than 200 features to feed a 2nd LGBM (20 folds !), which was endorsed to give the final results. Both of these models were trained on the whole train set (1,1M rows), which was not possible on Kaggle and had to be done elsewhere due to memory constraints.
\n• Post-processing. We tried a lot of ideas (graph-based; 3rd LGBM model taking the 2nd model’s score as an input, as well as contextual features such as the number of high-scored neighbors of a places). In the end, the key idea was to adapt the thresholds to the sizes of the groups we were merging. In fact, merging 2 places has not the same impact (and probability) than merging 2 groups of 10 places.

\n

: some rows of the private test set were very similar to rows of the train set. Thankfully, we found this on the very last day of the competition. So we recorded every matched ids of the train set, and if they were found in the test set, then we would automatically matched them. In practice, we made the parallel between the train and test set by identifying ids with the following key : cleaned_name + round(latitude, 5) + round(longitude, 5).
\nIn my opinion, it would have been better for the competition if the entries of the train set and the test set were distinct.
\nEdit : we didn't use the leak to delete false positives but it would have surely given a big boost.
\n

\n

\n

\"4sq-drawio\"
\nThanks to @theoviel for this great illustration.
\n

\n
\nThis part would be very long, but mainly:

\n

• Tf-idf was not very useful : less than 3% of true matches added, and it added some false-positives that were hard to catch (since the names were similar by definition).
\n• Translation of foreign languages was not a game-changer compared to unidecode (except pykakasi that was better for Japanese translation)
\n• (Offline) reverse geocoder was not that useful, mainly because the main features were foremost based on the name/latitude/longitude rather than on city/state.
\n• Model stacking. We tried to add an XGBoost and Catboost, but in the end, the gain was very poor compared to the efforts.

\n


\n

\n

Our code is avalaible here.

\n


\n

\n

I really enjoyed this competition, because a lot of approaches were possible. In the end, a great solution required to tackle very different and complementary tasks: text-processing, out-of-the-box ideas, models tuning, memory handling, features engineering… So everyone ends to learn something ! And thanks to it, after a lot of hard-work, I've become a Kaggle Competition Master ! ✔️

\n

To finish, thank you all once again for your great efforts and contributions. This competition has been very fun, and I'm looking forward to continue my journey on Kaggle.

\n

If you have any question about our work, feel free to ask, and I wish you all the best for the next competitions. 🙂

", "comments": [ { "id": 1849726, "author_name": "Shiny Singh", "author_url": "", "post_date": "2022-07-09T18:30:47.703000", "content": "

great work 👍 congratulations

", "votes": 3, "replies": [] }, { "id": 1848753, "author_name": "Lennart Haupts", "author_url": "", "post_date": "2022-07-08T21:31:13.907000", "content": "

Congratulations, what an impressive and interesting solution.🎉 There is so much to learn from this that I don’t even know where to start.

", "votes": 2, "replies": [ { "id": 1849202, "author_name": "Vincent Schuler", "author_url": "", "post_date": "2022-07-09T09:54:37.140000", "content": "

Thank you. This is normal, don't worry, it must be taken step-by-step. One can't learn in 10 minutes what asked us more than 100 hours !

", "votes": 2, "replies": [] } ] }, { "id": 1848538, "author_name": "SoupMonster", "author_url": "", "post_date": "2022-07-08T17:56:00.307000", "content": "

great work and nice explanation. thank you

", "votes": 2, "replies": [] }, { "id": 1847911, "author_name": "Vincent Schuler", "author_url": "", "post_date": "2022-07-08T08:48:44.577000", "content": "

I just shared 3 useful notebooks that we used : https://www.kaggle.com/competitions/foursquare-location-matching/discussion/335873

", "votes": 2, "replies": [] }, { "id": 1847768, "author_name": "Ning Wang", "author_url": "", "post_date": "2022-07-08T06:26:08.260000", "content": "

Thanks a lot for the nice solution! The 'create some meaningful features' part is very interesting for me. Could i learn more details or get some sample code? Currently i don't fully understand how you did it in practice.

", "votes": 2, "replies": [ { "id": 1847838, "author_name": "Vincent Schuler", "author_url": "", "post_date": "2022-07-08T07:31:16.423000", "content": "

Yes, I will soon share one or two notebooks. Moreover, @theoviel will soon add a diagram to illustrate the pipeline.

\n

[EDIT] You can find the notebooks here : https://www.kaggle.com/competitions/foursquare-location-matching/discussion/335873

", "votes": 1, "replies": [] }, { "id": 1847957, "author_name": "Ning Wang", "author_url": "", "post_date": "2022-07-08T09:21:21.400000", "content": "

Thanks so much, Vincent!

", "votes": 1, "replies": [] } ] }, { "id": 1853969, "author_name": "Zayaz", "author_url": "", "post_date": "2022-07-13T10:48:03.940000", "content": "

Finally a clear explanation. I've read other winning solutions, but I think this is the best presentation with an awesome picture. Thank you for your effort to explain your solution!

", "votes": 1, "replies": [ { "id": 1854246, "author_name": "Vincent Schuler", "author_url": "", "post_date": "2022-07-13T14:36:43.793000", "content": "

Thank you for your kind comment !

", "votes": 0, "replies": [] } ] }, { "id": 1849938, "author_name": "Kong Dezheng", "author_url": "", "post_date": "2022-07-10T00:19:16.227000", "content": "

wonderful,in my opinion

", "votes": 1, "replies": [] }, { "id": 1849937, "author_name": "Kong Dezheng", "author_url": "", "post_date": "2022-07-10T00:18:04.973000", "content": "

wonderful！！

", "votes": 1, "replies": [] }, { "id": 1847937, "author_name": "AK", "author_url": "", "post_date": "2022-07-08T09:04:29.883000", "content": "

Congrats to you and your team Finally Master Tier 😎

", "votes": 1, "replies": [ { "id": 1847942, "author_name": "Vincent Schuler", "author_url": "", "post_date": "2022-07-08T09:06:12.317000", "content": "

Thank you Aman !

", "votes": 1, "replies": [] } ] }, { "id": 1847736, "author_name": "Oleg Sidorshin", "author_url": "", "post_date": "2022-07-08T05:39:59.653000", "content": "

Thanks a lot for your solution! I want to ask about zip/url/phone columns - to us they were really bad, features based on them caused potential overfitting, despite a lot of efforts to make them work (special cleaning and such). Did you use them and if so, how?

", "votes": 1, "replies": [ { "id": 1847941, "author_name": "Vincent Schuler", "author_url": "", "post_date": "2022-07-08T09:05:43.963000", "content": "

We used phone to create candidates, since a same phone number was often indicating a true match.

\n

As for model features, we create some of them (LCS, jaro-winkler, count of occurences…) but as you said, most of them were not very relevant.

", "votes": 1, "replies": [] } ] }, { "id": 1848201, "author_name": "Phaedrus", "author_url": "", "post_date": "2022-07-08T12:48:34.047000", "content": "

Great solution. Any chance of releasing the code?

", "votes": 0, "replies": [ { "id": 1848209, "author_name": "Theo Viel", "author_url": "", "post_date": "2022-07-08T12:57:34.757000", "content": "

Working on it ;)

", "votes": 3, "replies": [] }, { "id": 1848221, "author_name": "Phaedrus", "author_url": "", "post_date": "2022-07-08T13:03:26.370000", "content": "

Thankyou 🙏🙏🙏

", "votes": 0, "replies": [] } ] }, { "id": 1849317, "author_name": "alu arjun", "author_url": "", "post_date": "2022-07-09T12:16:41.747000", "content": "

Thanks for sharing

", "votes": 1, "replies": [] } ], "comment_count": 20, "messages": [ { "id": 1847517, "postDate": "2022-07-08T01:21:17.430Z", "content": "

Hello !

\n

First of all, I would like to thank the organizers for this very interesting and challenging competition. Also, congratulations to all participants : the suspense was so tense in the last few days that I can’t believe it’s over now. I’m writing this at 3am, very grateful and relieved ! Also, a kind word for the deserving people who missed a medal by very few positions, because it can be hard to accept. You did really great, and I’m sure you’ll do even better the next time. Hardwork pays off.

\n

Finally, thanks to my talented and hard-working teammates @ymatioun and @theoviel, with whom I enjoyed to work and learn.
\n

\n

\n

Our solution relies on the following steps :

\n

• Clean data, mostly names. Remove special characters + space, apply unidecode to unify non-latin languages, lower text…
\n• Create some meaningful features. This has required some work beforehand, for instance to create groups of similar categories ('gyms', 'gyms or fitness centers', 'gymnastics gyms', 'gym pools'…), and to compute the average distance for each of them where we would be likely to find at least 50%, 75%, 90% and 95% of true matches. We also grouped names, cities and states, if they designated the same place. You can find 3 useful notebooks here that show how we did it.
\n• Find candidate pairs to match. To do this, we used different ideas : consider near neighbors; name-similarity; same words in names; grouped-category equality; (cleaned) phone number equality; same address; TF-IDF (especially for airports and indian places); …
\n• Pair matching. At this point, we had so much pairs that we had to use 2 models to avoid memory errors. The first one, a 5-fold LGBM, was only using a few features such as distance or name similarity to avoid issues. Its goal was to delete every non-relevant pairs (threshold < 0.007). We then computed more than 200 features to feed a 2nd LGBM (20 folds !), which was endorsed to give the final results. Both of these models were trained on the whole train set (1,1M rows), which was not possible on Kaggle and had to be done elsewhere due to memory constraints.
\n• Post-processing. We tried a lot of ideas (graph-based; 3rd LGBM model taking the 2nd model’s score as an input, as well as contextual features such as the number of high-scored neighbors of a places). In the end, the key idea was to adapt the thresholds to the sizes of the groups we were merging. In fact, merging 2 places has not the same impact (and probability) than merging 2 groups of 10 places.

\n

: some rows of the private test set were very similar to rows of the train set. Thankfully, we found this on the very last day of the competition. So we recorded every matched ids of the train set, and if they were found in the test set, then we would automatically matched them. In practice, we made the parallel between the train and test set by identifying ids with the following key : cleaned_name + round(latitude, 5) + round(longitude, 5).
\nIn my opinion, it would have been better for the competition if the entries of the train set and the test set were distinct.
\nEdit : we didn't use the leak to delete false positives but it would have surely given a big boost.
\n

\n

\n

\"4sq-drawio\"
\nThanks to @theoviel for this great illustration.
\n

\n
\nThis part would be very long, but mainly:

\n

• Tf-idf was not very useful : less than 3% of true matches added, and it added some false-positives that were hard to catch (since the names were similar by definition).
\n• Translation of foreign languages was not a game-changer compared to unidecode (except pykakasi that was better for Japanese translation)
\n• (Offline) reverse geocoder was not that useful, mainly because the main features were foremost based on the name/latitude/longitude rather than on city/state.
\n• Model stacking. We tried to add an XGBoost and Catboost, but in the end, the gain was very poor compared to the efforts.

\n


\n

\n

Our code is avalaible here.

\n


\n

\n

I really enjoyed this competition, because a lot of approaches were possible. In the end, a great solution required to tackle very different and complementary tasks: text-processing, out-of-the-box ideas, models tuning, memory handling, features engineering… So everyone ends to learn something ! And thanks to it, after a lot of hard-work, I've become a Kaggle Competition Master ! ✔️

\n

To finish, thank you all once again for your great efforts and contributions. This competition has been very fun, and I'm looking forward to continue my journey on Kaggle.

\n

If you have any question about our work, feel free to ask, and I wish you all the best for the next competitions. 🙂

", "rawMarkdown": "Hello !\n\nFirst of all, I would like to thank the organizers for this very interesting and challenging competition. Also, congratulations to all participants : the suspense was so tense in the last few days that I can’t believe it’s over now. I’m writing this at 3am, very grateful and relieved ! Also, a kind word for the deserving people who missed a medal by very few positions, because it can be hard to accept. You did really great, and I’m sure you’ll do even better the next time. Hardwork pays off.\n\nFinally, thanks to my talented and hard-working teammates @ymatioun and @theoviel, with whom I enjoyed to work and learn.\n
\n## **Overview**\nOur solution relies on the following steps :\n\n•\t**Clean data, mostly names.** Remove special characters + space, apply unidecode to unify non-latin languages, lower text…\n•\t**Create some meaningful features.** This has required some work beforehand, for instance to create groups of similar categories ('gyms', 'gyms or fitness centers', 'gymnastics gyms', 'gym pools'…), and to compute the average distance for each of them where we would be likely to find at least 50%, 75%, 90% and 95% of true matches. We also grouped names, cities and states, if they designated the same place. You can find [3 useful notebooks here](https://www.kaggle.com/competitions/foursquare-location-matching/discussion/335873) that show how we did it.\n•\t**Find candidate pairs to match.** To do this, we used different ideas : consider near neighbors; name-similarity; same words in names; grouped-category equality; (cleaned) phone number equality; same address; TF-IDF (especially for airports and indian places); …\n•\t**Pair matching.** At this point, we had so much pairs that we had to use 2 models to avoid memory errors. The first one, a 5-fold LGBM, was only using a few features such as distance or name similarity to avoid issues. Its goal was to delete every non-relevant pairs (threshold < 0.007). We then computed more than 200 features to feed a 2nd LGBM (20 folds !), which was endorsed to give the final results. Both of these models were trained on the whole train set (1,1M rows), which was not possible on Kaggle and had to be done elsewhere due to memory constraints.\n•\t**Post-processing.** We tried a lot of ideas (graph-based; 3rd LGBM model taking the 2nd model’s score as an input, as well as contextual features such as the number of high-scored neighbors of a places). In the end, the key idea was to adapt the thresholds to the sizes of the groups we were merging. In fact, merging 2 places has not the same impact (and probability) than merging 2 groups of 10 places.\n\n**And the magic that boosted our score from 0.939 (15th) to 0.957 (4th)** : some rows of the private test set were very similar to rows of the train set. Thankfully, we found this on the very last day of the competition. So we recorded every matched ids of the train set, and if they were found in the test set, then we would automatically matched them. In practice, we made the parallel between the train and test set by identifying ids with the following key : cleaned_name + round(latitude, 5) + round(longitude, 5).\nIn my opinion, it would have been better for the competition if the entries of the train set and the test set were distinct.\nEdit : we didn't use the leak to delete false positives but it would have surely given a big boost.\n
\n## **Diagram**\n \"4sq-drawio\"\nThanks to @theoviel for this great illustration.\n
\n**What did not worked well**\nThis part would be very long, but mainly:\n\n•\tTf-idf was not very useful : less than 3% of true matches added, and it added some false-positives that were hard to catch (since the names were similar by definition).\n•\tTranslation of foreign languages was not a game-changer compared to unidecode (except pykakasi that was better for Japanese translation)\n•\t(Offline) reverse geocoder was not that useful, mainly because the main features were foremost based on the name/latitude/longitude rather than on city/state.\n•\tModel stacking. We tried to add an XGBoost and Catboost, but in the end, the gain was very poor compared to the efforts.\n\n
\n## **Code**\nOur code is avalaible [here](https://www.kaggle.com/competitions/foursquare-location-matching/discussion/335921).\n\n
\n## **Conclusion**\nI really enjoyed this competition, because a lot of approaches were possible. In the end, a great solution required to tackle very different and complementary tasks: text-processing, out-of-the-box ideas, models tuning, memory handling, features engineering… So everyone ends to learn something ! And thanks to it, after a lot of hard-work, I've become a Kaggle Competition Master ! ✔️\n\nTo finish, thank you all once again for your great efforts and contributions. This competition has been very fun, and I'm looking forward to continue my journey on Kaggle.\n\nIf you have any question about our work, feel free to ask, and I wish you all the best for the next competitions. 🙂", "votes": 58 }, { "id": 1849726, "postDate": "2022-07-09T18:30:47.703Z", "content": "

great work 👍 congratulations

", "rawMarkdown": "great work 👍 congratulations ", "votes": 3 }, { "id": 1848753, "postDate": "2022-07-08T21:31:13.907Z", "content": "

Congratulations, what an impressive and interesting solution.🎉 There is so much to learn from this that I don’t even know where to start.

", "rawMarkdown": "Congratulations, what an impressive and interesting solution.🎉 There is so much to learn from this that I don’t even know where to start.", "votes": 2, "replies": [ { "id": 1849202, "postDate": "2022-07-09T09:54:37.140Z", "content": "

Thank you. This is normal, don't worry, it must be taken step-by-step. One can't learn in 10 minutes what asked us more than 100 hours !

", "rawMarkdown": "Thank you. This is normal, don't worry, it must be taken step-by-step. One can't learn in 10 minutes what asked us more than 100 hours !", "votes": 2 } ] }, { "id": 1848538, "postDate": "2022-07-08T17:56:00.307Z", "content": "

great work and nice explanation. thank you

", "rawMarkdown": "great work and nice explanation. thank you", "votes": 2 }, { "id": 1847911, "postDate": "2022-07-08T08:48:44.577Z", "content": "

I just shared 3 useful notebooks that we used : https://www.kaggle.com/competitions/foursquare-location-matching/discussion/335873

", "rawMarkdown": "I just shared 3 useful notebooks that we used : https://www.kaggle.com/competitions/foursquare-location-matching/discussion/335873", "votes": 2 }, { "id": 1847768, "postDate": "2022-07-08T06:26:08.260Z", "content": "

Thanks a lot for the nice solution! The 'create some meaningful features' part is very interesting for me. Could i learn more details or get some sample code? Currently i don't fully understand how you did it in practice.

", "rawMarkdown": "Thanks a lot for the nice solution! The 'create some meaningful features' part is very interesting for me. Could i learn more details or get some sample code? Currently i don't fully understand how you did it in practice.", "votes": 2, "replies": [ { "id": 1847838, "postDate": "2022-07-08T07:31:16.423Z", "content": "

Yes, I will soon share one or two notebooks. Moreover, @theoviel will soon add a diagram to illustrate the pipeline.

\n

[EDIT] You can find the notebooks here : https://www.kaggle.com/competitions/foursquare-location-matching/discussion/335873

", "rawMarkdown": "Yes, I will soon share one or two notebooks. Moreover, @theoviel will soon add a diagram to illustrate the pipeline.\n\n**[EDIT] You can find the notebooks here :** https://www.kaggle.com/competitions/foursquare-location-matching/discussion/335873", "votes": 1 }, { "id": 1847957, "postDate": "2022-07-08T09:21:21.400Z", "content": "

Thanks so much, Vincent!

", "rawMarkdown": "Thanks so much, Vincent!", "votes": 1 } ] }, { "id": 1853969, "postDate": "2022-07-13T10:48:03.940Z", "content": "

Finally a clear explanation. I've read other winning solutions, but I think this is the best presentation with an awesome picture. Thank you for your effort to explain your solution!

", "rawMarkdown": "Finally a clear explanation. I've read other winning solutions, but I think this is the best presentation with an awesome picture. Thank you for your effort to explain your solution!", "votes": 1, "replies": [ { "id": 1854246, "postDate": "2022-07-13T14:36:43.793Z", "content": "

Thank you for your kind comment !

", "rawMarkdown": "Thank you for your kind comment !" } ] }, { "id": 1849938, "postDate": "2022-07-10T00:19:16.227Z", "content": "

wonderful,in my opinion

", "rawMarkdown": "wonderful,in my opinion", "votes": 1 }, { "id": 1849937, "postDate": "2022-07-10T00:18:04.973Z", "content": "

wonderful！！

", "rawMarkdown": "wonderful！！", "votes": 1 }, { "id": 1847937, "postDate": "2022-07-08T09:04:29.883Z", "content": "

Congrats to you and your team Finally Master Tier 😎

", "rawMarkdown": "Congrats to you and your team Finally Master Tier 😎", "votes": 1, "replies": [ { "id": 1847942, "postDate": "2022-07-08T09:06:12.317Z", "content": "

Thank you Aman !

", "rawMarkdown": "Thank you Aman !", "votes": 1 } ] }, { "id": 1847736, "postDate": "2022-07-08T05:39:59.653Z", "content": "

Thanks a lot for your solution! I want to ask about zip/url/phone columns - to us they were really bad, features based on them caused potential overfitting, despite a lot of efforts to make them work (special cleaning and such). Did you use them and if so, how?

", "rawMarkdown": "Thanks a lot for your solution! I want to ask about zip/url/phone columns - to us they were really bad, features based on them caused potential overfitting, despite a lot of efforts to make them work (special cleaning and such). Did you use them and if so, how?", "votes": 1, "replies": [ { "id": 1847941, "postDate": "2022-07-08T09:05:43.963Z", "content": "

We used phone to create candidates, since a same phone number was often indicating a true match.

\n

As for model features, we create some of them (LCS, jaro-winkler, count of occurences…) but as you said, most of them were not very relevant.

", "rawMarkdown": "We used phone to create candidates, since a same phone number was often indicating a true match.\n\nAs for model features, we create some of them (LCS, jaro-winkler, count of occurences...) but as you said, most of them were not very relevant.", "votes": 1 } ] }, { "id": 1848201, "postDate": "2022-07-08T12:48:34.047Z", "content": "

Great solution. Any chance of releasing the code?

", "rawMarkdown": "Great solution. Any chance of releasing the code? ", "replies": [ { "id": 1848209, "postDate": "2022-07-08T12:57:34.757Z", "content": "

Working on it ;)

", "rawMarkdown": "Working on it ;)", "votes": 3 }, { "id": 1848221, "postDate": "2022-07-08T13:03:26.370Z", "content": "

Thankyou 🙏🙏🙏

", "rawMarkdown": "Thankyou 🙏🙏🙏" } ] }, { "id": 1849317, "postDate": "2022-07-09T12:16:41.747Z", "content": "

Thanks for sharing

", "rawMarkdown": "Thanks for sharing", "votes": 1 } ], "complete": true, "source": "live", "fetched_at": "2026-10-24T13:20:48Z", "competition_id": 35476, "competition_slug": "foursquare-location-matching", "team_id": 8483051, "solution_url": "/competitions/foursquare-location-matching/writeups/youri-vincent-th-o-4th-place-solution" }