HSP API: Occasional mismatch between metrics and details

76 views
Skip to first unread message

sjbri...@gmail.com

unread,
Dec 30, 2016, 6:39:12 AM12/30/16
to A gathering place for the Open Rail Data community
Hello all,

First off thanks for reading. I hope I am not retreading old ground. This is my first post as I did not see an answer to my question on wiki nor here.

I am using the Historical Service Performance (HSP) API to look into historical train delays. Whilst doing so I sometimes seem to encounter a contradiction.

At times the serviceMetrics endpoint will report that a particular service has a num_not_tolerance field with value not equal to 0. However if the serviceDetails endpoint is used with the relevant RID it is revealed that the service in fact does come with the tolerance. I conclude this as actual_ta - gbtt_pda < tolerance for the requested station.

I wanted to check if this was expected behaviour? I can provide an example (see below)

Best regards,

Sam

EXAMPLE OF BEHAVIOUR

Request to https://hsp-prod.rockshore.net/api/v1/serviceMetrics with body:
{
"from_loc": "FPK",
"to_loc": "CBG",
"from_time": "0551",
"to_time": "0600",
"from_date": "2016-12-04",
"to_date": "2016-12-11",
"days": "SATURDAY",
"tolerance": [
30
]
}
Responds with:
{
"header": {
"from_location": "FPK",
"to_location": "CBG"
},
"Services": [
{
"serviceAttributesMetrics": {
"origin_location": "KGX",
"destination_location": "CBG",
"gbtt_ptd": "0551",
"gbtt_pta": "0655",
"toc_code": "GN",
"matched_services": "1",
"rids": [
"201612107170606"
]
},
"Metrics": [
{
"tolerance_value": "0",
"num_not_tolerance": "1",
"num_tolerance": "0",
"percent_tolerance": "0",
"global_tolerance": true
},
{
"tolerance_value": "30",
"num_not_tolerance": "1",
"num_tolerance": "0",
"percent_tolerance": "0",
"global_tolerance": false
}
]
}
]
}
As you can see here, the Metrics for tolerance_value = 30 indicate num_not_tolerance = 1. I.e. there was one service that ran later than 30 minutes. In this case it must be the only service, with RID 201612107170606.

However a request to https://hsp-prod.rockshore.net/api/v1/serviceDetails with body:
{
"rid": "201612107170606"
}

Responds with:
{
"serviceAttributesDetails": {
"date_of_service": "2016-12-10",
"toc_code": "GN",
"rid": "201612107170606",
"locations": [
{
"location": "KGX",
"gbtt_ptd": "0545",
"gbtt_pta": "",
"actual_td": "0544",
"actual_ta": "",
"late_canc_reason": "525"
},
{
"location": "FPK",
"gbtt_ptd": "0551",
"gbtt_pta": "0550",
"actual_td": "0551",
"actual_ta": "0549",
"late_canc_reason": "525"
},
{
"location": "SVG",
"gbtt_ptd": "0609",
"gbtt_pta": "0609",
"actual_td": "0619",
"actual_ta": "0617",
"late_canc_reason": "525"
},
{
"location": "HIT",
"gbtt_ptd": "0614",
"gbtt_pta": "0614",
"actual_td": "0623",
"actual_ta": "0621",
"late_canc_reason": "525"
},
{
"location": "LET",
"gbtt_ptd": "0620",
"gbtt_pta": "0619",
"actual_td": "0629",
"actual_ta": "0627",
"late_canc_reason": "525"
},
{
"location": "BDK",
"gbtt_ptd": "0623",
"gbtt_pta": "0623",
"actual_td": "0631",
"actual_ta": "0631",
"late_canc_reason": "525"
},
{
"location": "AWM",
"gbtt_ptd": "0628",
"gbtt_pta": "0628",
"actual_td": "0635",
"actual_ta": "0635",
"late_canc_reason": "525"
},
{
"location": "RYS",
"gbtt_ptd": "0633",
"gbtt_pta": "0633",
"actual_td": "0642",
"actual_ta": "0640",
"late_canc_reason": "525"
},
{
"location": "MEL",
"gbtt_ptd": "0637",
"gbtt_pta": "0637",
"actual_td": "0646",
"actual_ta": "0644",
"late_canc_reason": "525"
},
{
"location": "STH",
"gbtt_ptd": "0640",
"gbtt_pta": "0640",
"actual_td": "0649",
"actual_ta": "0648",
"late_canc_reason": "525"
},
{
"location": "FXN",
"gbtt_ptd": "0643",
"gbtt_pta": "0643",
"actual_td": "0652",
"actual_ta": "0651",
"late_canc_reason": "525"
},
{
"location": "CBG",
"gbtt_ptd": "",
"gbtt_pta": "0655",
"actual_td": "",
"actual_ta": "0659",
"late_canc_reason": "525"
}
]
}
}

As you can see for the destination (CBG) gbtt_pta = 0655, actual_ta = 0659 so the delay is 4 minutes. 4 minutes is not greater than or equal to 30 (threshold provided in metric request)
Reply all
Reply to author
Forward
0 new messages