Minska belastningen på Resrobot API
Jag har gjort en "Proof of concept" på en web för jobbsök.
Den använder Arbetförmedlingens API för jobbsök och kombinerar det med trafiklabs resrobot reultat så att jobbsökaren får sökresultat med pendlingsavstånd.
https://github.com/mats-nk/Jobbpendla
Och det fungerar bra.
Men så börjar jag analysera detta och iner att det finns systembegränsningar. Den främsta begränsningen är API belastning, ex ett jobbsök genererar 10 st jobbträffar och så göts det reseruttssök mot reserobot API för alla de 100 träffarna. Det blir många API anrop väldigt fort.
Jag ser att det finns flera alternativa sätt att motverka dessa,
- Be den sökande om att söka mer specifikt vid sök som gerererar många träffar från AF's API.
- Lokal kopia på resrobbot API
- Mellanlagra resultat från svaren från rerobbot och försöka återanvända dessa.
Så jag vill höra med er om råd och om ni ser fler alternativ än de tre jag har räknat upp och om möjligheten för en lokal resrobot kopia?
Den använder Arbetförmedlingens API för jobbsök och kombinerar det med trafiklabs resrobot reultat så att jobbsökaren får sökresultat med pendlingsavstånd.
https://github.com/mats-nk/Jobbpendla
Och det fungerar bra.
Men så börjar jag analysera detta och iner att det finns systembegränsningar. Den främsta begränsningen är API belastning, ex ett jobbsök genererar 10 st jobbträffar och så göts det reseruttssök mot reserobot API för alla de 100 träffarna. Det blir många API anrop väldigt fort.
Jag ser att det finns flera alternativa sätt att motverka dessa,
- Be den sökande om att söka mer specifikt vid sök som gerererar många träffar från AF's API.
- Lokal kopia på resrobbot API
- Mellanlagra resultat från svaren från rerobbot och försöka återanvända dessa.
Så jag vill höra med er om råd och om ni ser fler alternativ än de tre jag har räknat upp och om möjligheten för en lokal resrobot kopia?
Följ inlägget
1
följare
Det går att ladda ner dataset i GTFS format som kan användas för att köra en lokal reseplanerare som OpenTripPlanner. Det finns dock bättre alternativ för dig, eftersom du egentligen inte är ute efter detaljerad resesök utan i restider från 1 punkt till många punkter.
Om du laddar ner vår GTFS data kan du välja 1 startpunkt (vi kallar den hållplats A) och tid. Sen kan du kolla vilka fordon som avgår från detta punkt, då vet du restiden för alla direktförbindelser. Nu kan du, för varje hållplats som har upptäckts, kolla hur lång tid det tar att nå hållplatser med direktförbindelser därifrån. På det sättet kan du upptäcka nya hållplatser, en längre väg till redan upptäckta hållplatser, eller en ny lägsta restid till en redan upptäckt hållplats.
Enklaste sättet att tillämpa det i praktiken är att räkna ut alla avgångar på en specifik dag baserat på GTFS datat, och sortera dem i en lång lista.
Tex "08:00 A->B 5 minuter", "08:00 C->D 4 minuter", "08:02 B->C 10 minuter", "08:07 B->C 10 minuter". Genom att sen gå genom denna lista kan man se att B kan nås i 5 minuter, C kan nås i 17 minuter från A, ...
Fördelen med denna teknik är att du inte behöver göra något resesök för varenda resa, utan 1 sökning ger alla resultat på en gång. Sen kan du göra analysen i förväg, och spara ner resultaten för att få ett bättre användarupplevelse med minskade väntetider. Totalt sett finns det drygt 5 miljarder olika kombinationer, men du kan begränsa sökning till tex högst 4 timmar restid och högst 4 byten för att begränsa mängden data som du behöver spara ner.
Hälsningar,
Bert
Det du beskriver ska jag se hur jag kan bygga upp logiken runt. Fast just nu så har jag ingen "kund" så det är på hobby basis.
Logiken du beskriver är klockren och jag tänkte också använda en adress till koordinat och filtrera "långt bort träffar" och också använda län/kommun filter på platsbanken vid för många träffar.
Tack för hjälpen
/Mats