When querying journeys, you can find a set of identifiers for the queried transport's line in the fields .svcResL[].res.common.prodL[].prodCtx.lineId, .svcResL[].res.common.prodL[].prodCtx.admin that are (hopefully, come on hafas, please) globally unique if taken together with the operator name stored in .svcResL[0].res.common.opL[].name.
I was looking into https://github.com/traewelling/line-colors and wound up very, very confused why the line IDs they report (say, 4-a6s4-4 for the KVV S4) were different from the ones actually generated by HAFAS (4_A6S4___4) — it turns out the javascript HAFAS library runs the ID through a slug algorithm:
Having the as-is line IDs accessible through the Journey object would be useful, for compatibility reasons (optionally?) running it through the same or a simplification of the same slug algorithm might be worth considering.
deingithub
commented
3 months ago
When querying journeys, you can find a set of identifiers for the queried transport's line in the fields
.svcResL[].res.common.prodL[].prodCtx.lineId,.svcResL[].res.common.prodL[].prodCtx.adminthat are (hopefully, come on hafas, please) globally unique if taken together with the operator name stored in.svcResL[0].res.common.opL[].name. I was looking into https://github.com/traewelling/line-colors and wound up very, very confused why the line IDs they report (say,4-a6s4-4for the KVV S4) were different from the ones actually generated by HAFAS (4_A6S4___4) — it turns out the javascript HAFAS library runs the ID through a slug algorithm:https://github.com/public-transport/hafas-client/blob/66d9fb51944e8ad0eb7619324409b469feec9a2e/parse/line.js#L8-L19
Having the as-is line IDs accessible through the Journey object would be useful, for compatibility reasons (optionally?) running it through the same or a simplification of the same slug algorithm might be worth considering.