SL Transport: Vilket mönster följer konvertering mellan Site ID egentligen?
En ändring i SL Transports dokumentation lyder:
"you should convert the values returned by the SL Stop Lookup API, in the form of 3BA1CDEFG, into a
number ABCDEFG"
Tidigare instruktioner för konvertering mellan lång- och kort-id har bl.a. varit:
1. Kapa de fem första tecknen för att få ett kort-id
2. Använd xxxxxxx för kort-id där lång-id är 3xx1xxxxx
3. I andra dokument (Närliggande) som vi borde göra klokt i att inte ignorera har det stått följande: "3FG1EDCBA där FGEDCBA är de 7 sista sifforna i site.number utfyllt med nollor"
...och nu alltså "3BA1CDEFG, into a number ABCDEFG".
Märker ni att alla dessa är olika och motstridiga, förutom att "3xx1xxxxx / xxxxxxx" kommer att tolkas på samma sätt som "3FG1EDCBA / FGEDCBA"? Jag tvivlar på att alla kan vara rätt, och även om vi stryker #1 så är frågan fortfarande ifall siffrorna mellan "3" och "1" ska byta plats eller inte.
Samtidigt undrar man ju varför bokstäverna "FGEDCBA" skrevs i exakt samma ordning två gånger i Närliggande- dokumentationen, när omvänd alfabetiskt (GFEDCBA) är en mer naturlig följd och borde ha förekommit i åtminstone en av de två mallarna.
Kan vi en gång för alla slå fast vad som faktiskt gäller, med en uttrycklig försäkran från den som skriver dokumentationen att de har dubbelkollat ordningen av sina ABCDEFG-variabler, och gärna att det har granskats av någon? Annars känns det som att jag lika gärna kan singla slant mellan dem.
"you should convert the values returned by the SL Stop Lookup API, in the form of 3BA1CDEFG, into a
number ABCDEFG"
Tidigare instruktioner för konvertering mellan lång- och kort-id har bl.a. varit:
1. Kapa de fem första tecknen för att få ett kort-id
2. Använd xxxxxxx för kort-id där lång-id är 3xx1xxxxx
3. I andra dokument (Närliggande) som vi borde göra klokt i att inte ignorera har det stått följande: "3FG1EDCBA där FGEDCBA är de 7 sista sifforna i site.number utfyllt med nollor"
...och nu alltså "3BA1CDEFG, into a number ABCDEFG".
Märker ni att alla dessa är olika och motstridiga, förutom att "3xx1xxxxx / xxxxxxx" kommer att tolkas på samma sätt som "3FG1EDCBA / FGEDCBA"? Jag tvivlar på att alla kan vara rätt, och även om vi stryker #1 så är frågan fortfarande ifall siffrorna mellan "3" och "1" ska byta plats eller inte.
Samtidigt undrar man ju varför bokstäverna "FGEDCBA" skrevs i exakt samma ordning två gånger i Närliggande- dokumentationen, när omvänd alfabetiskt (GFEDCBA) är en mer naturlig följd och borde ha förekommit i åtminstone en av de två mallarna.
Kan vi en gång för alla slå fast vad som faktiskt gäller, med en uttrycklig försäkran från den som skriver dokumentationen att de har dubbelkollat ordningen av sina ABCDEFG-variabler, och gärna att det har granskats av någon? Annars känns det som att jag lika gärna kan singla slant mellan dem.
Följ inlägget
2
följare
Ja det har onekligen varit lite rörigt med alla uppdateringar och förändringar kring detta, vi ber om ursäkt för det. Då vi inte heller var medvetna om denna förändring av SiteId så har vi behövt reda ut i detta själva och ibland kan det ha gått lite fort med att uppdatera dokumentationen när vi trott att vi hittat en lösning.
I alla fall, du kan bortse från dina 3 fall här ovan då de inte stämmer och de ska inte finnas kvar i någon dokumentation. Vi bytte ordning på bokstäverna då det kändes mer intuitivt att se skillnad på om AB har bytt plats än GF.
Det som gäller är det som du hittade i SL Transports dokumentationen:
"you should convert the values returned by the SL Stop Lookup API, in the form of 3BA1CDEFG, into a number ABCDEFG"
Alltså: du ska plocka bort siffrorna 3 och 1 samt byta plats på B och A för att få det korta numret.
Till exempel om du har 300109001 så blir det 0009001 och då det är en siffra blir det tillslut 9001. Och tvärtom när du ska konvertera tillbaka mellan APIer.
Jag har gått igenom all dokumentation vi har om SiteId nu och den bör vara enhetligt mellan APIernas dokumentation. Tack för din input!
Mvh
Sofie
{
"Name": "T-Centralen (Stockholm)",
"SiteId": "300109001",
"Type": "Station",
"X": "18060434",
"Y": "59331376",
"Products": null
},
{
"Name": "Tcentralen (Stockholm)",
"SiteId": "301109001",
"Type": "Station",
"X": "18060434",
"Y": "59331376",
"Products": null
},
{
"Name": "Hjälpmedelscentralen (Stockholm)",
"SiteId": "302101661",
"Type": "Station",
"X": "17970291",
"Y": "59283167",
"Products": null
}
Med algoritmen i dokumentationen blir kompatibla IDn 0009001, 1009001 och 2001661. Men bara det första fungerar att mata in i nya Departures APIt. Det verkar som det nya Departures APIt bara fungerar med IDn som är max fyra siffror. Tar jag istället helt enkelt de fyra sista siffrorna blir det rätt och APIt fungerar som det ska.
En snabb koll mot det som returneras ifrån nya /sites-APIt verkar det snarare som den första siffran i det 7-siffriga IDt representerar index i "alias"-arrayen (som för övrigt är feldokumenterad som en sträng istället för en array av strängar) för en site. Alla sites jag ser har 4-siffriga IDn.