julwil / ccs4dt Goto Github PK

Current behavior:

API request sent with object identifiers all in simple 5 digit int format (e.g. 39712)
API output contains object mapping that only maps object identifier and sensor identifier without any separating characters

Expected behavior:
Option 1 (preferred):
Include sensor as separate object, e.g.
Current implementation:
**"object_identifier_mappings": {
"952ab5a4-b0ed-4e7b-8447-a8380cf01f42": [{
"392226b251d89-8e6c-4280-845c-c70a8bcdf475",
"37957ba334d0e-4593-45ff-b82e-3b96249db901",
"392020995260d-1af0-43f0-bf78-44a6e47f7e65"
} ],

Target implementation:
... "object_identifier_mappings": {
"952ab5a4-b0ed-4e7b-8447-a8380cf01f42": {
"6b251d89-8e6c-4280-845c-c70a8bcdf475": [
"39222"
],
"ba334d0e-4593-45ff-b82e-3b96249db901": [
"37957"
],
"6b251d89-8e6c-4280-845c-c70a8bcdf475": [
"39222"
],
"0995260d-1af0-43f0-bf78-44a6e47f7e65": [
"39202"
],
},...

Option 2:
Object mapping contains original supplied object_identifiers separated by specific character sequence (e.g. "39222///6b251d89-8e6c-4280-845c-c70a8bcdf475" instead of "392226b251d89-8e6c-4280-845c-c70a8bcdf475)

Example:

Input:
[ {
"object_identifier": "39222",
"x": 135,
"y": 283,
"z": -4,
"sensor_type": "RFID",
"sensor_identifier": "ba334d0e-4593-45ff-b82e-3b96249db901",
"timestamp": 1559376000183
}, {
"object_identifier": "37957",
"x": 273,
"y": 231,
"z": -6,
"sensor_type": "RFID",
"sensor_identifier": "ba334d0e-4593-45ff-b82e-3b96249db901",
"timestamp": 1559376001493
}, {
"object_identifier": "39202",
"x": 335,
"y": 101,
"z": -14,
"sensor_type": "RFID",
"sensor_identifier": "ba334d0e-4593-45ff-b82e-3b96249db901",
"timestamp": 1559376003493
}, {
"object_identifier": "39202",
"x": 383,
"y": 136,
"z": 6,
"sensor_type": "RFID",
"sensor_identifier": "ba334d0e-4593-45ff-b82e-3b96249db901",
"timestamp": 1559376005984
}, {
"object_identifier": "39202",
"x": 377,
"y": 131,
"z": -3,
"sensor_type": "RFID",
"sensor_identifier": "ba334d0e-4593-45ff-b82e-3b96249db901",
"timestamp": 1559376006490
}, {
"object_identifier": "37957",
"x": 238,
"y": 222,
"z": -18,
"sensor_type": "RFID",
"sensor_identifier": "ba334d0e-4593-45ff-b82e-3b96249db901",
"timestamp": 1559376007998
}, {
"object_identifier": "39222",
"x": 116.7440062284,
"y": 276.8758878242,
"z": 4.5816163437,
"sensor_type": "WiFi 2.4GHz",
"sensor_identifier": "6b251d89-8e6c-4280-845c-c70a8bcdf475",
"timestamp": 1559376001186
}, {
"object_identifier": "39202",
"x": 358,
"y": 120,
"z": 2,
"sensor_type": "camera",
"sensor_identifier": "0995260d-1af0-43f0-bf78-44a6e47f7e65",
"timestamp": 1559376001186
}]

Output (manually fixed issue related to bug #31 here):

{
"input_batch_id": 159,
"location_id": 122,
"object_identifier_mappings": {
"952ab5a4-b0ed-4e7b-8447-a8380cf01f42": [
"392226b251d89-8e6c-4280-845c-c70a8bcdf475",
"37957ba334d0e-4593-45ff-b82e-3b96249db901",
"392020995260d-1af0-43f0-bf78-44a6e47f7e65"
],
"828605b3-cf12-4707-84dc-5118e33c4165": [
"39202ba334d0e-4593-45ff-b82e-3b96249db901"
],
"fe41ec18-cc58-4d8c-8da4-42a050639cd8": [
"39222ba334d0e-4593-45ff-b82e-3b96249db901"
]
},
"positions": [
{
"object_identifier": "828605b3-cf12-4707-84dc-5118e33c4165",
"confidence": 1,
"timestamp": 1559376006000,
"x": 388.1459152032023,
"y": 133.19277982934898,
"z": 32.78816100649938
},
{
"object_identifier": "952ab5a4-b0ed-4e7b-8447-a8380cf01f42",
"confidence": 1,
"timestamp": 1559376008000,
"x": 243.95018218698942,
"y": 220.7169466717965,
"z": 9.840950865380046
},
{
"object_identifier": "fe41ec18-cc58-4d8c-8da4-42a050639cd8",
"confidence": 1,
"timestamp": 1559376000000,
"x": 140.36806575211685,
"y": 280.5896521185067,
"z": 24.452662945839744
}
]
}

In approx. 5-10% of the API calls, the status of the input batch is 'failed' (in the returned JSON) with HTTP status code 200. There is no regularity that I can see in the requests, see one example in the files attached (location & synthetic measurement data)
location_payload_API-status_failed.txt
synthetic_measurement_payload_API-status_failed.txt
.

When trying to evaluate the accuracy of the prediction positions the issue arises that not for every timestamp in the true positions data frame a according position prediction is generated.

Example data:
Upper table is true positions table
Lower table is position prediction table as generated by API request
https://gist.github.com/mtornow/56cfcbbb16e4e9de8d2ea808406089ec

Suggested solution:
API output should return position prediction for all timestamps with frequency of lowest difference between two measurement points in input file

Downside: Blows up API output

@julwil : Any other suggestions from your side?

Example:

{'input_batch_id': 128, 'location_id': 90,
'object_identifier_mappings': ....

Expected:

{"input_batch_id": 128, "location_id": 90,
"object_identifier_mappings": ....