{
  "id": 12850,
  "title": "Trip Matching - our methods",
  "content": "<p>I'm curious how the other teams in the top 5 did it. &nbsp;We received a pretty good boost by matching trips. &nbsp;I did several different methods, I think this was the order I did them in, but I'm sure I'm forgetting some dead ends.</p>\n<p>Approach 0:</p>\n<p>Align the start and end to the x axis.&nbsp;</p>\n<p>Approach 1:</p>\n<p>Simplify trips using RDP (Ramer&#8211;Douglas&#8211;Peucker), then create just a list of the distances between turns over a threshold along with a second list giving the size of the turn - ignore right or left. &nbsp;This is a great first pass - very quick and you can weed out a lot of trips this way &nbsp;I would compare forward and backward (this solved the starting from 0,0 every time bit) just looking at distance between turns, then compare the size of the turn within a threshold (this ignores mirroring) - all together that took care of rotation as well. &nbsp;We used&nbsp;42 sets of tolerances for RDP and angles - at one point I think I was up to 180 tolerance / angle pairs, but found most were redundant and wasted time. &nbsp;</p>\n<p>By setting a minimum number of required turns to match we could generate quickly a set of matches. &nbsp;Testing revealed this worked very well. &nbsp;I can't recall the jump, but when I first teamed up with Ben we went from 11th to 3rd using just an override setting matches to 1.0's &nbsp;- the most basic way of using matches.</p>\n<p>Approach 2:</p>\n<p>Widen the matching angle to find more matches, then use Dynamic Time Warping to score the trips. &nbsp;This worked OK, but not really any better.</p>\n<p>Approach 3:</p>\n<p>Interpolate the trip into points spaced at an even interval, then trip DTW, this just couldn't score better than approach 1.</p>\n<p>Approach 4:</p>\n<p>Align the matched sub-trips based on the locations of the turns, and use Singular Value Decomposition to align the sub-trips and get the RSME error for the points. &nbsp;This worked very well.</p>\n<p>Approach 5:</p>\n<p>Keep track of who matches to whom - an adjacency tree, use it to create clusters of matched trips. &nbsp;Try various features based on the size of the cluster a trip is in, even did a page rank style analysis of the match trip network...maybe I wasn't smart enough but that feature didn't help (though we didn't start using it until the last 2 days or so, not much time to adjust it).</p>\n<p>Approach 6:</p>\n<p>Use use RDP turn / angle approximations and SVD for alignment, score with RSME for the sub-trip, then align the full trip and measure the distance between the start and end of the trip.</p>\n<p>Approach 6a:</p>\n<p>If we know the adjacency tree to walk from one trip to another we can rotate and align all the trips in a cluster to each other! &nbsp;Then by viewing the map of the driver's matches we could adjust the parameters for RSME and the minimum distance between the start and end of a trip (to account for trimming). If the minimum distance between the start or end of the aligned trip is greater than a certain value, ignore the match. &nbsp;It's a really elegant idea (if I do say so myself) and it failed [edit, turns out it failed when used as a feature giving to our ML classifier, however I've done a few more submissions now that the contest is over, with the matches from this approach boosting the classifier's results and turns out this would have worked]....in the end just using an RSME score for the sub-trip alignment found by SVD worked best.</p>\n<p>Take away - RDP to simplify the trip, break up into distances between turns (rounded to the nearest 100 meters), record turn sizes (not directions), look for matches forward, backward and with some allowance for slightly larger / smaller turns, then align using SVD, compare the alignment, keep track of how many matches a trip has, and in the end feed that feature fed into a ML algorithm - worked well.</p>\n<p>The speed of the basic method made it possible to check for matches between all the drivers. &nbsp;Starting with the bottom 50,000 (per our classifier) but in the end I ran it on on all matches paired against each other, on a i7 quad core it would take about 20 hours.</p>\n<p>I would later move onto EC2 clusters which made it possible to iterate over small changes in the algorithm and have the results in 1 to 2 hours for a basic version - last night I had 16 machines running at one time, eleven&nbsp;- 32 core machines and five - 36 core machines - managed to run two different matching algorithms in about 3.5 hours total - one of which helped us to finally climb over 97%.</p>",
  "comments": [
    {
      "id": 66894,
      "author_name": "Rob0",
      "author_url": "",
      "post_date": "2015-03-18T02:18:44.880000",
      "content": "<p>Update - here's an example of the cluster mapping - this is driver 1 - a cluster of 141 trips, they don't all match each other but you can walk a path from one to the other. &nbsp;If you start with the most connected trip you can rotate and align every other trip back that that trip. &nbsp;In this way I was able to create a customized map of the driver's routes. &nbsp;Note the map spans 30 kilometers and the method I used for matching matched on sub portions. So for some of the really long trips (15 km) small initial errors in alignment add up - but it's good for the short trips, and even on the longer ones you can understand the layout. &nbsp;</p>",
      "votes": 7,
      "replies": []
    },
    {
      "id": 66775,
      "author_name": "Cardal",
      "author_url": "",
      "post_date": "2015-03-17T18:26:34.867000",
      "content": "<p>Interestingly, I used a very similar method to approach #1 described by Rob0. When comparing trip parts, my distance metric took into account both the distances between turns and the angles (I didn't ignore left/right, so I checked both the original angles and the angles*(-1) ). I didn't set all matches to 1.0; instead, I compared the match score to the scores obtained when comparing the trip to negative samples (i.e., trips from other drivers), and computed a corresponding probability (p-value).</p>",
      "votes": 6,
      "replies": []
    },
    {
      "id": 66685,
      "author_name": "ajoo",
      "author_url": "",
      "post_date": "2015-03-17T11:37:49.327000",
      "content": "<p>Might aswell share mine :p</p>\n<p>The algorithm went something like this:</p>\n<p>1. After low pass filtering in time, reinterpolate the trip by linearly spaced cord-length to get an approximation of the curve parametrized by arclength instead of time.</p>\n<p>2. Compute a smoothed version of curvature from this k(s) = &nbsp;||X''(s)||^2.</p>\n<p>3. For each 2 curves align their curvatures using cross-correlation function. Then flip one curve and do it again. Take best match. This allows me to get a correspondence of points between&nbsp;the 2 curves. Furthermore it allows partial matching and matching of inverse trips. Since unsigned curvature is independent of the turn direction it won't care if the curve was spatially flipped.</p>\n<p>4. Take the matching points and&nbsp;solve an Orthogonal Procrustes problem which finds the best orthogonal transformation between the 2 sets of points. Take the loss function L as 1 of the metrics in analysing trip matching and information content I as another.</p>\n<p>5. Now I&nbsp;chose how to threshold these 2 quantities (L,I) using an EM algorithm. Initially I was trying to threshold it by hand but eventually decided on this automated approach. I essentially trained a gaussian mixture distribution p0(L,I) on non-matching trips taken from random drivers. Then I took a few drivers and trained a model p(L,I) = n*p0(L,I) + (1-n)*p1(L,I) where p1 is gaussian. This then allows me to compute a probability of matching for any 2 trips.</p>\n<p>(Note in the image that alot&nbsp;of the red points that are scattered in the blue region are actual matches from random drivers doing the same route or part of the same route as confirmed visually)</p>\n<p>I initially tried something more similar to Rob0. I didn't know Ramer&#8211;Douglas&#8211;Peucker existed but I &nbsp;was basically finding the local maxima&nbsp;of the smoothed curvature to get the &quot;corners&quot; of the trip and then aligning them using the cross-correlation of the curvature at said corners or the first differences in total cord length. However checking the results I would sometimes get a point marked in a matching curve with&nbsp;the corresponding point not marked which would totally throw off my results. I thought about matching with DTW instead but never got around to try that when this other approach worked fine and could tackle better the shorter trips.</p>",
      "votes": 4,
      "replies": []
    },
    {
      "id": 66646,
      "author_name": "Benj",
      "author_url": "",
      "post_date": "2015-03-17T06:31:51.920000",
      "content": "<p>Trip matching was also a major boost on my side.</p>\n<p>Main idea : For each trip I created the vector of the instantaneous rotations of every x meters (with different lags - to capture trips where you need 50/100 meters to park).</p>\n<p>Then I implemented a similarity Score between two vectors (based on the variance of the difference of the cumulated angle).</p>\n<p>I compared a group of trips with exactly one trip per driver. At this stage, I had a Score of trips that (a priori) did not match.</p>\n<p>Finally for each driver I computed the Score of the 200 trips and compared it to the distribution I just had... and ajusted the probas in consequence.</p>",
      "votes": 4,
      "replies": []
    },
    {
      "id": 67702,
      "author_name": "Rob0",
      "author_url": "",
      "post_date": "2015-03-23T12:39:06.990000",
      "content": "<p>Derek - we used the results from trip matching as features for the machine learning algorithm. &nbsp;We tried various features, but in the end settled on the number of times a stretch of 5 turns were matched (distance between turns and turn size) with other trips - this worked well for the trip matching done using the approach 1 I described at the top of this thread. &nbsp;For the last approach we used the RSME score to count the number of sub-trip matches and used these as additional features. &nbsp;</p>\n<p>After the competition ended I found that some of our later matching algorithms were able to find some matches that the others missed and if we did a post training boost on those matches it would improve the score &nbsp;(just a simple submission *= 1.1 if a match was found) .</p>",
      "votes": 2,
      "replies": []
    },
    {
      "id": 66811,
      "author_name": "CYR_ISFA",
      "author_url": "",
      "post_date": "2015-03-17T20:30:16.520000",
      "content": "<p>Trip matching was our major track. We also used the RDP algorithm to simplify the trips and considered several tolerances. We got a lot of false trues and we took several weeks to try to eliminate these trips. In particular we developed a modified version of the RDP algorithm that takes into account bends to define starting points. We also considered some statistics based on velocity and acceleration to improve the algorithm. <br>We are not surprised to get similar results as ice9 since we share more or less the same type of methodologies. It was our first experience of Kaggle competitions and it was very enriching. Congratulations to all the competitors. </p>",
      "votes": 2,
      "replies": []
    },
    {
      "id": 66795,
      "author_name": "Cardal",
      "author_url": "",
      "post_date": "2015-03-17T19:20:13.787000",
      "content": "<p>Obviously, the results of the trip matching were only several of the features I used. In addition, I computed various other features, each of which was a combination of several trip attributes - some simple (like speed, acceleration, etc.) and some more complex (e.g., speed before stop). The final model was an ensemble of all the features using Gradient Boosting, which performed slightly better than Random Forest.</p>\n<p>Unfortunately, I didn't have your computing power (or time to code...), so I couldn't experiment with too many parameters/approaches for trip matching. However, I did use neat techniques to make the code quite efficient.</p>",
      "votes": 2,
      "replies": []
    },
    {
      "id": 66787,
      "author_name": "Rob0",
      "author_url": "",
      "post_date": "2015-03-17T19:00:22.267000",
      "content": "<p>Cardal - thanks for posting! &nbsp;Yeah the trip matches contained a lot of data. That now answers a question I had, was there any other information I missed, now I can sleep at night!</p>\n<p>2 questions for you - did you try using trip matching to identify the mixed in trips? &nbsp;If you submit you matches directly without using any other classifier (I.e. using velocity/acceleration etc), what do you score? &nbsp;I'm really curious to compare. &nbsp;</p>\n\n<p>Congratulations, that was very impressive.&nbsp;</p>",
      "votes": 2,
      "replies": []
    },
    {
      "id": 66689,
      "author_name": "nhlx5haze",
      "author_url": "",
      "post_date": "2015-03-17T12:29:45.083000",
      "content": "<p>[quote=Rob0;66615]</p>\n<p>I'm curious how the other teams in the top 5 did it. &nbsp;We received a pretty good boost by matching trips. &nbsp;I did several different methods, I think this was the order I did them in, but I'm sure I'm forgetting some dead ends.</p>\n<p>[/quote]</p>\n<p>First, process RDP algorithm on trips.</p>\n<p>Then, for each trip of driver X,&nbsp;get&nbsp;the maximum&nbsp;consecutives&nbsp;matches this trip has with some others trips which don't belong to X, and in the end feed that feature into a ML algorithm ... worked well too ...</p>\n<p>Actually, a similar method for a similar score !</p>",
      "votes": 2,
      "replies": []
    },
    {
      "id": 67628,
      "author_name": "Scott H",
      "author_url": "",
      "post_date": "2015-03-22T18:46:38.627000",
      "content": "<p>This is what I did</p>\n<p>-&nbsp; In the trip matching find out how many routes each trip matches</p>\n<p>-&nbsp; For routes matching 2 or more trips, set them at the top, ranked by the number of other trips that they matched, and then sorted by the telematics results.&nbsp; For us, this was approx 400,000 trips</p>\n<p>-for the other 147,000 trips, influence the telematics results based on if there was a trip match.</p>\n<p>&nbsp;&nbsp;&nbsp; - If there was a trip match, bump the telematics score up</p>\n<p>&nbsp;&nbsp;&nbsp; -&nbsp; if it was a long run&nbsp;&nbsp; (i.e. not the shortest 20% of runs) and there was no trip match result, bump the result down in the telematics</p>\n\n\n<p>The key ensemble take away is</p>\n<p>-&nbsp; Do not ensemble any probabilities, instead what you are ensembling is their order in the AUC ranking.&nbsp;&nbsp; I.e. sort both sets of results based on their probabilities, and then ensemble if it is ranked 1, 2, 50,000 etc</p>",
      "votes": 1,
      "replies": []
    },
    {
      "id": 66752,
      "author_name": "Javier Tejedor Aguilera",
      "author_url": "",
      "post_date": "2015-03-17T17:29:16.717000",
      "content": "<p>We are completely newbies and used a quite different (...and not very good) approach:</p>\n<p>1) resampling trips, creating a 5 meter segmented trip, using java (R was quite slow)</p>\n<p>2) trips cross-correlation (also with inverted trips) using R ccf function</p>\n<p>Cross-correlation allowed us to identify similar trips, fliped (-1) or not (+1), and small trips that fitted a big one, but obviously we couldn't find partial trip matching.</p>\n\n<p>Did you guys used the &#8216;rgeos&#8217; package in R to implement the Ramer&#8211;Douglas&#8211;Peucker (RDP) or used python?</p>",
      "votes": 1,
      "replies": []
    },
    {
      "id": 66632,
      "author_name": "Gus123",
      "author_url": "",
      "post_date": "2015-03-17T04:45:14.593000",
      "content": "<p>Interesting approach. I used something much simpler which gave decent result when applied as a post model booster.</p>\n<p>I've taken every trip and changed from an xy representation to a dist angle representation. this allows to easily rotate (shift the curve up down). Then for every pair of trips ive adjusted the length of the longest trip by cutting a small portion at the end pieces. &nbsp;</p>\n<p>Then I adjusted the angle (ie rotated the curve) and compared the points of the curve using a correlation coeff. (which has the advantage of being close to -1 if the trips match but are flipped, and close to 1 if the trips match as is)</p>\n<p>a final trick was to test small shifts (along the distance axis) in the pairs of trips to see if a shifted comparison gave stonger correlation scores&nbsp;</p>",
      "votes": 1,
      "replies": []
    },
    {
      "id": 661232,
      "author_name": "NamShik Choi",
      "author_url": "",
      "post_date": "2019-10-30T03:36:04.147000",
      "content": "<p>Can I request the dataset for the purpose of research? ddasik5831@gmail.com\nThanks</p>",
      "votes": 0,
      "replies": []
    },
    {
      "id": 105371,
      "author_name": "Shubham Mankodiya",
      "author_url": "",
      "post_date": "2016-01-22T15:07:31.643000",
      "content": "<p>Hello!\nHow can we measure cornering? From compass or any other device</p>",
      "votes": 0,
      "replies": []
    },
    {
      "id": 67625,
      "author_name": "DerekZH",
      "author_url": "",
      "post_date": "2015-03-22T18:08:07.367000",
      "content": "<p>Hi there, &nbsp;would you top performers share some insights on the ensemble technique to blend trip matching and driver characteristic results? &nbsp;</p>\n<p>Our driver characteristic submission scored about 0.86, and we have a somehow&nbsp;working trip matching algorithm that scored 0.70. &nbsp;I thought there is information in that 0.70 submission, but a simple mean of the two prediction (each with rescaled probabilities based on ranking) did not improve the score.&nbsp;&nbsp;</p>",
      "votes": 0,
      "replies": []
    },
    {
      "id": 66688,
      "author_name": "Jonathan Street",
      "author_url": "",
      "post_date": "2015-03-17T12:25:40.620000",
      "content": "<p>Thanks for sharing your approach for trip matching. At the risk of going slightly off-topic, how do you handle orchestrating multiple servers?</p>",
      "votes": 0,
      "replies": []
    }
  ],
  "comment_count": 16,
  "messages": [
    {
      "id": 66615,
      "postDate": "2015-03-17T02:09:02.800Z",
      "content": "<p>I'm curious how the other teams in the top 5 did it. &nbsp;We received a pretty good boost by matching trips. &nbsp;I did several different methods, I think this was the order I did them in, but I'm sure I'm forgetting some dead ends.</p>\n<p>Approach 0:</p>\n<p>Align the start and end to the x axis.&nbsp;</p>\n<p>Approach 1:</p>\n<p>Simplify trips using RDP (Ramer&#8211;Douglas&#8211;Peucker), then create just a list of the distances between turns over a threshold along with a second list giving the size of the turn - ignore right or left. &nbsp;This is a great first pass - very quick and you can weed out a lot of trips this way &nbsp;I would compare forward and backward (this solved the starting from 0,0 every time bit) just looking at distance between turns, then compare the size of the turn within a threshold (this ignores mirroring) - all together that took care of rotation as well. &nbsp;We used&nbsp;42 sets of tolerances for RDP and angles - at one point I think I was up to 180 tolerance / angle pairs, but found most were redundant and wasted time. &nbsp;</p>\n<p>By setting a minimum number of required turns to match we could generate quickly a set of matches. &nbsp;Testing revealed this worked very well. &nbsp;I can't recall the jump, but when I first teamed up with Ben we went from 11th to 3rd using just an override setting matches to 1.0's &nbsp;- the most basic way of using matches.</p>\n<p>Approach 2:</p>\n<p>Widen the matching angle to find more matches, then use Dynamic Time Warping to score the trips. &nbsp;This worked OK, but not really any better.</p>\n<p>Approach 3:</p>\n<p>Interpolate the trip into points spaced at an even interval, then trip DTW, this just couldn't score better than approach 1.</p>\n<p>Approach 4:</p>\n<p>Align the matched sub-trips based on the locations of the turns, and use Singular Value Decomposition to align the sub-trips and get the RSME error for the points. &nbsp;This worked very well.</p>\n<p>Approach 5:</p>\n<p>Keep track of who matches to whom - an adjacency tree, use it to create clusters of matched trips. &nbsp;Try various features based on the size of the cluster a trip is in, even did a page rank style analysis of the match trip network...maybe I wasn't smart enough but that feature didn't help (though we didn't start using it until the last 2 days or so, not much time to adjust it).</p>\n<p>Approach 6:</p>\n<p>Use use RDP turn / angle approximations and SVD for alignment, score with RSME for the sub-trip, then align the full trip and measure the distance between the start and end of the trip.</p>\n<p>Approach 6a:</p>\n<p>If we know the adjacency tree to walk from one trip to another we can rotate and align all the trips in a cluster to each other! &nbsp;Then by viewing the map of the driver's matches we could adjust the parameters for RSME and the minimum distance between the start and end of a trip (to account for trimming). If the minimum distance between the start or end of the aligned trip is greater than a certain value, ignore the match. &nbsp;It's a really elegant idea (if I do say so myself) and it failed [edit, turns out it failed when used as a feature giving to our ML classifier, however I've done a few more submissions now that the contest is over, with the matches from this approach boosting the classifier's results and turns out this would have worked]....in the end just using an RSME score for the sub-trip alignment found by SVD worked best.</p>\n<p>Take away - RDP to simplify the trip, break up into distances between turns (rounded to the nearest 100 meters), record turn sizes (not directions), look for matches forward, backward and with some allowance for slightly larger / smaller turns, then align using SVD, compare the alignment, keep track of how many matches a trip has, and in the end feed that feature fed into a ML algorithm - worked well.</p>\n<p>The speed of the basic method made it possible to check for matches between all the drivers. &nbsp;Starting with the bottom 50,000 (per our classifier) but in the end I ran it on on all matches paired against each other, on a i7 quad core it would take about 20 hours.</p>\n<p>I would later move onto EC2 clusters which made it possible to iterate over small changes in the algorithm and have the results in 1 to 2 hours for a basic version - last night I had 16 machines running at one time, eleven&nbsp;- 32 core machines and five - 36 core machines - managed to run two different matching algorithms in about 3.5 hours total - one of which helped us to finally climb over 97%.</p>",
      "votes": 24
    },
    {
      "id": 66894,
      "postDate": "2015-03-18T02:18:44.880Z",
      "content": "<p>Update - here's an example of the cluster mapping - this is driver 1 - a cluster of 141 trips, they don't all match each other but you can walk a path from one to the other. &nbsp;If you start with the most connected trip you can rotate and align every other trip back that that trip. &nbsp;In this way I was able to create a customized map of the driver's routes. &nbsp;Note the map spans 30 kilometers and the method I used for matching matched on sub portions. So for some of the really long trips (15 km) small initial errors in alignment add up - but it's good for the short trips, and even on the longer ones you can understand the layout. &nbsp;</p>",
      "votes": 7
    },
    {
      "id": 66775,
      "postDate": "2015-03-17T18:26:34.867Z",
      "content": "<p>Interestingly, I used a very similar method to approach #1 described by Rob0. When comparing trip parts, my distance metric took into account both the distances between turns and the angles (I didn't ignore left/right, so I checked both the original angles and the angles*(-1) ). I didn't set all matches to 1.0; instead, I compared the match score to the scores obtained when comparing the trip to negative samples (i.e., trips from other drivers), and computed a corresponding probability (p-value).</p>",
      "votes": 6
    },
    {
      "id": 66685,
      "postDate": "2015-03-17T11:37:49.327Z",
      "content": "<p>Might aswell share mine :p</p>\n<p>The algorithm went something like this:</p>\n<p>1. After low pass filtering in time, reinterpolate the trip by linearly spaced cord-length to get an approximation of the curve parametrized by arclength instead of time.</p>\n<p>2. Compute a smoothed version of curvature from this k(s) = &nbsp;||X''(s)||^2.</p>\n<p>3. For each 2 curves align their curvatures using cross-correlation function. Then flip one curve and do it again. Take best match. This allows me to get a correspondence of points between&nbsp;the 2 curves. Furthermore it allows partial matching and matching of inverse trips. Since unsigned curvature is independent of the turn direction it won't care if the curve was spatially flipped.</p>\n<p>4. Take the matching points and&nbsp;solve an Orthogonal Procrustes problem which finds the best orthogonal transformation between the 2 sets of points. Take the loss function L as 1 of the metrics in analysing trip matching and information content I as another.</p>\n<p>5. Now I&nbsp;chose how to threshold these 2 quantities (L,I) using an EM algorithm. Initially I was trying to threshold it by hand but eventually decided on this automated approach. I essentially trained a gaussian mixture distribution p0(L,I) on non-matching trips taken from random drivers. Then I took a few drivers and trained a model p(L,I) = n*p0(L,I) + (1-n)*p1(L,I) where p1 is gaussian. This then allows me to compute a probability of matching for any 2 trips.</p>\n<p>(Note in the image that alot&nbsp;of the red points that are scattered in the blue region are actual matches from random drivers doing the same route or part of the same route as confirmed visually)</p>\n<p>I initially tried something more similar to Rob0. I didn't know Ramer&#8211;Douglas&#8211;Peucker existed but I &nbsp;was basically finding the local maxima&nbsp;of the smoothed curvature to get the &quot;corners&quot; of the trip and then aligning them using the cross-correlation of the curvature at said corners or the first differences in total cord length. However checking the results I would sometimes get a point marked in a matching curve with&nbsp;the corresponding point not marked which would totally throw off my results. I thought about matching with DTW instead but never got around to try that when this other approach worked fine and could tackle better the shorter trips.</p>",
      "votes": 4
    },
    {
      "id": 66646,
      "postDate": "2015-03-17T06:31:51.920Z",
      "content": "<p>Trip matching was also a major boost on my side.</p>\n<p>Main idea : For each trip I created the vector of the instantaneous rotations of every x meters (with different lags - to capture trips where you need 50/100 meters to park).</p>\n<p>Then I implemented a similarity Score between two vectors (based on the variance of the difference of the cumulated angle).</p>\n<p>I compared a group of trips with exactly one trip per driver. At this stage, I had a Score of trips that (a priori) did not match.</p>\n<p>Finally for each driver I computed the Score of the 200 trips and compared it to the distribution I just had... and ajusted the probas in consequence.</p>",
      "votes": 4
    },
    {
      "id": 67702,
      "postDate": "2015-03-23T12:39:06.990Z",
      "content": "<p>Derek - we used the results from trip matching as features for the machine learning algorithm. &nbsp;We tried various features, but in the end settled on the number of times a stretch of 5 turns were matched (distance between turns and turn size) with other trips - this worked well for the trip matching done using the approach 1 I described at the top of this thread. &nbsp;For the last approach we used the RSME score to count the number of sub-trip matches and used these as additional features. &nbsp;</p>\n<p>After the competition ended I found that some of our later matching algorithms were able to find some matches that the others missed and if we did a post training boost on those matches it would improve the score &nbsp;(just a simple submission *= 1.1 if a match was found) .</p>",
      "votes": 2
    },
    {
      "id": 66811,
      "postDate": "2015-03-17T20:30:16.520Z",
      "content": "<p>Trip matching was our major track. We also used the RDP algorithm to simplify the trips and considered several tolerances. We got a lot of false trues and we took several weeks to try to eliminate these trips. In particular we developed a modified version of the RDP algorithm that takes into account bends to define starting points. We also considered some statistics based on velocity and acceleration to improve the algorithm. <br>We are not surprised to get similar results as ice9 since we share more or less the same type of methodologies. It was our first experience of Kaggle competitions and it was very enriching. Congratulations to all the competitors. </p>",
      "votes": 2
    },
    {
      "id": 66795,
      "postDate": "2015-03-17T19:20:13.787Z",
      "content": "<p>Obviously, the results of the trip matching were only several of the features I used. In addition, I computed various other features, each of which was a combination of several trip attributes - some simple (like speed, acceleration, etc.) and some more complex (e.g., speed before stop). The final model was an ensemble of all the features using Gradient Boosting, which performed slightly better than Random Forest.</p>\n<p>Unfortunately, I didn't have your computing power (or time to code...), so I couldn't experiment with too many parameters/approaches for trip matching. However, I did use neat techniques to make the code quite efficient.</p>",
      "votes": 2
    },
    {
      "id": 66787,
      "postDate": "2015-03-17T19:00:22.267Z",
      "content": "<p>Cardal - thanks for posting! &nbsp;Yeah the trip matches contained a lot of data. That now answers a question I had, was there any other information I missed, now I can sleep at night!</p>\n<p>2 questions for you - did you try using trip matching to identify the mixed in trips? &nbsp;If you submit you matches directly without using any other classifier (I.e. using velocity/acceleration etc), what do you score? &nbsp;I'm really curious to compare. &nbsp;</p>\n\n<p>Congratulations, that was very impressive.&nbsp;</p>",
      "votes": 2
    },
    {
      "id": 66689,
      "postDate": "2015-03-17T12:29:45.083Z",
      "content": "<p>[quote=Rob0;66615]</p>\n<p>I'm curious how the other teams in the top 5 did it. &nbsp;We received a pretty good boost by matching trips. &nbsp;I did several different methods, I think this was the order I did them in, but I'm sure I'm forgetting some dead ends.</p>\n<p>[/quote]</p>\n<p>First, process RDP algorithm on trips.</p>\n<p>Then, for each trip of driver X,&nbsp;get&nbsp;the maximum&nbsp;consecutives&nbsp;matches this trip has with some others trips which don't belong to X, and in the end feed that feature into a ML algorithm ... worked well too ...</p>\n<p>Actually, a similar method for a similar score !</p>",
      "votes": 2
    },
    {
      "id": 67628,
      "postDate": "2015-03-22T18:46:38.627Z",
      "content": "<p>This is what I did</p>\n<p>-&nbsp; In the trip matching find out how many routes each trip matches</p>\n<p>-&nbsp; For routes matching 2 or more trips, set them at the top, ranked by the number of other trips that they matched, and then sorted by the telematics results.&nbsp; For us, this was approx 400,000 trips</p>\n<p>-for the other 147,000 trips, influence the telematics results based on if there was a trip match.</p>\n<p>&nbsp;&nbsp;&nbsp; - If there was a trip match, bump the telematics score up</p>\n<p>&nbsp;&nbsp;&nbsp; -&nbsp; if it was a long run&nbsp;&nbsp; (i.e. not the shortest 20% of runs) and there was no trip match result, bump the result down in the telematics</p>\n\n\n<p>The key ensemble take away is</p>\n<p>-&nbsp; Do not ensemble any probabilities, instead what you are ensembling is their order in the AUC ranking.&nbsp;&nbsp; I.e. sort both sets of results based on their probabilities, and then ensemble if it is ranked 1, 2, 50,000 etc</p>",
      "votes": 1
    },
    {
      "id": 66752,
      "postDate": "2015-03-17T17:29:16.717Z",
      "content": "<p>We are completely newbies and used a quite different (...and not very good) approach:</p>\n<p>1) resampling trips, creating a 5 meter segmented trip, using java (R was quite slow)</p>\n<p>2) trips cross-correlation (also with inverted trips) using R ccf function</p>\n<p>Cross-correlation allowed us to identify similar trips, fliped (-1) or not (+1), and small trips that fitted a big one, but obviously we couldn't find partial trip matching.</p>\n\n<p>Did you guys used the &#8216;rgeos&#8217; package in R to implement the Ramer&#8211;Douglas&#8211;Peucker (RDP) or used python?</p>",
      "votes": 1
    },
    {
      "id": 66632,
      "postDate": "2015-03-17T04:45:14.593Z",
      "content": "<p>Interesting approach. I used something much simpler which gave decent result when applied as a post model booster.</p>\n<p>I've taken every trip and changed from an xy representation to a dist angle representation. this allows to easily rotate (shift the curve up down). Then for every pair of trips ive adjusted the length of the longest trip by cutting a small portion at the end pieces. &nbsp;</p>\n<p>Then I adjusted the angle (ie rotated the curve) and compared the points of the curve using a correlation coeff. (which has the advantage of being close to -1 if the trips match but are flipped, and close to 1 if the trips match as is)</p>\n<p>a final trick was to test small shifts (along the distance axis) in the pairs of trips to see if a shifted comparison gave stonger correlation scores&nbsp;</p>",
      "votes": 1
    },
    {
      "id": 661232,
      "postDate": "2019-10-30T03:36:04.147Z",
      "content": "<p>Can I request the dataset for the purpose of research? ddasik5831@gmail.com\nThanks</p>",
      "rawMarkdown": "Can I request the dataset for the purpose of research? ddasik5831@gmail.com\nThanks"
    },
    {
      "id": 105371,
      "postDate": "2016-01-22T15:07:31.643Z",
      "content": "<p>Hello!\nHow can we measure cornering? From compass or any other device</p>",
      "rawMarkdown": "Hello!\r\nHow can we measure cornering? From compass or any other device"
    },
    {
      "id": 67625,
      "postDate": "2015-03-22T18:08:07.367Z",
      "content": "<p>Hi there, &nbsp;would you top performers share some insights on the ensemble technique to blend trip matching and driver characteristic results? &nbsp;</p>\n<p>Our driver characteristic submission scored about 0.86, and we have a somehow&nbsp;working trip matching algorithm that scored 0.70. &nbsp;I thought there is information in that 0.70 submission, but a simple mean of the two prediction (each with rescaled probabilities based on ranking) did not improve the score.&nbsp;&nbsp;</p>"
    },
    {
      "id": 66688,
      "postDate": "2015-03-17T12:25:40.620Z",
      "content": "<p>Thanks for sharing your approach for trip matching. At the risk of going slightly off-topic, how do you handle orchestrating multiple servers?</p>"
    }
  ],
  "complete": true,
  "source": "live",
  "fetched_at": "2026-10-24T13:50:52Z",
  "competition_id": 4031,
  "competition_slug": "axa-driver-telematics-analysis",
  "team_id": 136447,
  "solution_url": "/competitions/axa-driver-telematics-analysis/writeups/ice9-trip-matching-our-methods"
}