{
  "id": 215456,
  "title": "Timestamp phone data missing for timestamp to predict???",
  "url": "/competitions/indoor-location-navigation/discussion/215456",
  "author_name": "",
  "post_date": "2021-01-29T22:30:45.594666200Z",
  "votes": 5,
  "comment_count": 5,
  "views": 0,
  "content": "<p>In the submission file, the first column is site_path_timestamp - so the first number is the site ID, the path is the test TXT file name (???) and the last part is the timestamp for the location and floor to be predicted.  But there are many of the timestamps that we are supposed to predict that have no phone data for the timestamp in the test file.</p>\n<p>Am I missing something?</p>\n<p>Example:</p>\n<p>First entry in example submission is:</p>\n<p>file - 046cfa46be49fc10834815c6.TXT<br>\ntimestamp - 0000000000009</p>\n<p>In that text file there is not data for timestamp 9 - the file starts at timestamp 136.</p>\n<p>Any help is appreciated…</p>",
  "messages": [
    {
      "id": "1176923",
      "postDate": "01/29/2021 22:30:45",
      "content": "<p>In the submission file, the first column is site_path_timestamp - so the first number is the site ID, the path is the test TXT file name (???) and the last part is the timestamp for the location and floor to be predicted.  But there are many of the timestamps that we are supposed to predict that have no phone data for the timestamp in the test file.</p>\n<p>Am I missing something?</p>\n<p>Example:</p>\n<p>First entry in example submission is:</p>\n<p>file - 046cfa46be49fc10834815c6.TXT<br>\ntimestamp - 0000000000009</p>\n<p>In that text file there is not data for timestamp 9 - the file starts at timestamp 136.</p>\n<p>Any help is appreciated…</p>",
      "rawMarkdown": "In the submission file, the first column is site_path_timestamp - so the first number is the site ID, the path is the test TXT file name (???) and the last part is the timestamp for the location and floor to be predicted.  But there are many of the timestamps that we are supposed to predict that have no phone data for the timestamp in the test file.\n\nAm I missing something?\n\nExample:\n\nFirst entry in example submission is:\n\nfile - 046cfa46be49fc10834815c6.TXT\ntimestamp - 0000000000009\n\nIn that text file there is not data for timestamp 9 - the file starts at timestamp 136.\n\nAny help is appreciated...",
      "votes": null
    },
    {
      "id": "1178186",
      "postDate": "01/30/2021 17:56:54",
      "content": "<p>I'm pretty sure this is to be expected. The submission rows will be graded against a TYPE_WAYPOINT signal from the corresponding trace (which is hidden from us for the test set).</p>\n<p>But if you look at the TYPE_WAYPOINT timestamps in the train files, they are 'unique' in the sense that none of the other rows in the file will have a matching timestamp.</p>",
      "rawMarkdown": "I'm pretty sure this is to be expected. The submission rows will be graded against a TYPE_WAYPOINT signal from the corresponding trace (which is hidden from us for the test set).\n\nBut if you look at the TYPE_WAYPOINT timestamps in the train files, they are 'unique' in the sense that none of the other rows in the file will have a matching timestamp.",
      "votes": null
    },
    {
      "id": "1178499",
      "postDate": "01/30/2021 23:19:32",
      "content": "<p>Thanks. Understand the grading, but if the phone data doesn't start until timestamp 136 - really hard to predict where the person was on timestamp 9 - almost minus 130…</p>",
      "rawMarkdown": "Thanks. Understand the grading, but if the phone data doesn't start until timestamp 136 - really hard to predict where the person was on timestamp 9 - almost minus 130...",
      "votes": null
    },
    {
      "id": "1178623",
      "postDate": "01/31/2021 03:03:09",
      "content": "<p>Note that the timestamps are in milliseconds. So 136 is about 1/10th a second.  </p>\n<p>We will be missing data before timestamp 9, yes, but we have all of the data after it (which is something that concerns me about the realistic nature of this competition).</p>",
      "rawMarkdown": "Note that the timestamps are in milliseconds. So 136 is about 1/10th a second.  \n\nWe will be missing data before timestamp 9, yes, but we have all of the data after it (which is something that concerns me about the realistic nature of this competition).",
      "votes": null
    },
    {
      "id": "1181425",
      "postDate": "02/01/2021 21:44:08",
      "content": "<p>Thanks for clarifying Nicolas - I was confusing a step with a timestamp - thinking it was movements not milliseconds. Much appreciated.</p>",
      "rawMarkdown": "Thanks for clarifying Nicolas - I was confusing a step with a timestamp - thinking it was movements not milliseconds. Much appreciated.",
      "votes": null
    },
    {
      "id": "1255740",
      "postDate": "03/29/2021 06:40:29",
      "content": "<p>Thanks for the input <a href=\"https://www.kaggle.com/npa02012\" target=\"_blank\">@npa02012</a> . I too am skeptical about practical method of using future data for predicting the position coordinates. I haven't gone through the entire dataset, but i think the beacon data is available before the first waypoint information (not verified, manually went through 5-10 path files)</p>",
      "rawMarkdown": "Thanks for the input @npa02012 . I too am skeptical about practical method of using future data for predicting the position coordinates. I haven't gone through the entire dataset, but i think the beacon data is available before the first waypoint information (not verified, manually went through 5-10 path files)",
      "votes": null
    }
  ],
  "comments": [
    {
      "id": 1178186,
      "author_name": "npa02012",
      "author_url": "",
      "post_date": "01/30/2021 17:56:54",
      "content": "<p>I'm pretty sure this is to be expected. The submission rows will be graded against a TYPE_WAYPOINT signal from the corresponding trace (which is hidden from us for the test set).</p>\n<p>But if you look at the TYPE_WAYPOINT timestamps in the train files, they are 'unique' in the sense that none of the other rows in the file will have a matching timestamp.</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1178499,
      "author_name": "mlconsult",
      "author_url": "",
      "post_date": "01/30/2021 23:19:32",
      "content": "<p>Thanks. Understand the grading, but if the phone data doesn't start until timestamp 136 - really hard to predict where the person was on timestamp 9 - almost minus 130…</p>",
      "votes": null,
      "replies": [
        {
          "id": 1178623,
          "author_name": "npa02012",
          "author_url": "",
          "post_date": "01/31/2021 03:03:09",
          "content": "<p>Note that the timestamps are in milliseconds. So 136 is about 1/10th a second.  </p>\n<p>We will be missing data before timestamp 9, yes, but we have all of the data after it (which is something that concerns me about the realistic nature of this competition).</p>",
          "votes": null,
          "replies": [
            {
              "id": 1255740,
              "author_name": "suryajrrafl",
              "author_url": "",
              "post_date": "03/29/2021 06:40:29",
              "content": "<p>Thanks for the input <a href=\"https://www.kaggle.com/npa02012\" target=\"_blank\">@npa02012</a> . I too am skeptical about practical method of using future data for predicting the position coordinates. I haven't gone through the entire dataset, but i think the beacon data is available before the first waypoint information (not verified, manually went through 5-10 path files)</p>",
              "votes": null,
              "replies": []
            }
          ]
        },
        {
          "id": 1181425,
          "author_name": "mlconsult",
          "author_url": "",
          "post_date": "02/01/2021 21:44:08",
          "content": "<p>Thanks for clarifying Nicolas - I was confusing a step with a timestamp - thinking it was movements not milliseconds. Much appreciated.</p>",
          "votes": null,
          "replies": []
        }
      ]
    }
  ],
  "raw_markdown_by_id": {
    "1176923": "In the submission file, the first column is site_path_timestamp - so the first number is the site ID, the path is the test TXT file name (???) and the last part is the timestamp for the location and floor to be predicted.  But there are many of the timestamps that we are supposed to predict that have no phone data for the timestamp in the test file.\n\nAm I missing something?\n\nExample:\n\nFirst entry in example submission is:\n\nfile - 046cfa46be49fc10834815c6.TXT\ntimestamp - 0000000000009\n\nIn that text file there is not data for timestamp 9 - the file starts at timestamp 136.\n\nAny help is appreciated...",
    "1178186": "I'm pretty sure this is to be expected. The submission rows will be graded against a TYPE_WAYPOINT signal from the corresponding trace (which is hidden from us for the test set).\n\nBut if you look at the TYPE_WAYPOINT timestamps in the train files, they are 'unique' in the sense that none of the other rows in the file will have a matching timestamp.",
    "1178499": "Thanks. Understand the grading, but if the phone data doesn't start until timestamp 136 - really hard to predict where the person was on timestamp 9 - almost minus 130...",
    "1178623": "Note that the timestamps are in milliseconds. So 136 is about 1/10th a second.  \n\nWe will be missing data before timestamp 9, yes, but we have all of the data after it (which is something that concerns me about the realistic nature of this competition).",
    "1181425": "Thanks for clarifying Nicolas - I was confusing a step with a timestamp - thinking it was movements not milliseconds. Much appreciated.",
    "1255740": "Thanks for the input @npa02012 . I too am skeptical about practical method of using future data for predicting the position coordinates. I haven't gone through the entire dataset, but i think the beacon data is available before the first waypoint information (not verified, manually went through 5-10 path files)"
  },
  "source": "meta"
}