Är det tänkt att SL Transports /sites kan ersätta SL Platsuppslag? Hur?
I SL Transports dokumentation står "In order to use values returned by the SL Stop Lookup API, you should convert the values [...]. It is however strongly recommended to keep to the site ids returned by the /sites endpoint"
Sista meningen antyder att det är att föredra att använda "the /sites endpoint" framför SL Platsuppslag. Jag ser inte riktigt hur de två fyller samma funktion? När man anropar /sites får man en 1,3 MB mastodontfil med alla hållplatser, vilken kanske är praktiskt om man bygger en server, men väl inte för en lättviktig klientapp som vill söka fram en hållplats.
Hur är det tänkt att /sites ska användas? Vilka användarfall är den skapad för?
Sista meningen antyder att det är att föredra att använda "the /sites endpoint" framför SL Platsuppslag. Jag ser inte riktigt hur de två fyller samma funktion? När man anropar /sites får man en 1,3 MB mastodontfil med alla hållplatser, vilken kanske är praktiskt om man bygger en server, men väl inte för en lättviktig klientapp som vill söka fram en hållplats.
Hur är det tänkt att /sites ska användas? Vilka användarfall är den skapad för?
Följ inlägget
1
följare
Jag tonade ner rekommendationen lite grann så att det inte tolkas som ett måste, men det går utmärkt att implementera client-side platsuppslag och sökning för närliggande hållplatser i applikationer, och även på webbsidor om localStorage används.
Svaret som man får tillbaka är 1.3MB, men överföringen är bara 227kb och behövs bara 1 gång, sen behöver man bara uppdatera data någon gång i varje vecka eller liknande. Offline-sökningar brukar vara snabbare vilket leder till en ökat användarvänlighet, då man inte har någon fördröjning och kan göra hur många sökningar som helst. När det kommer till närliggande hållplatser finns det ingen begränsning på radius och koordinaterna behöver inte lämna användarens telefon.
Samma sak kan man även göra med Resrobot och GTFS Sverige 2s stops.txt fil, fast där handlar det om 70.000 hållplatser vilket börjar bli lite tuffare.
Det är inte alltid möjligt att implementera en hållplatsmatchning som jag beskrev, tex om apparaten inte klarar av det eller om det inte passar användningsfallet. Tex om man bara behöver hämta en hållplats 1 gång för att konfigurera en app är det inte värd det, och då kan man köra den översättningsmetoden som också är dokumenterat på sidan.
Hälsningar,
Bert
Tack! Du säljer in det bra tycker jag. Där fanns ju ett par fördelar. Jag tittade på överföringsstorleken, men jag reflekterade aldrig över det -- bra poäng.
Det man behöver veta (som i alla fall jag undrade när jag läste dokumentationen) för att ta ett beslut blir alltså:
- Hur är /sites tänkt att användas
- Hur stor är hämtningen
- Hur många hållplatser måste bearbetas
- Hur ofta borde jag upprepa hämtning och bearbetning
Jag har nog allt jag behöver veta