NeTEx Regional Static och Siri quotes
Hej
Bygger en iOS app för att bl.a. visa bussars positioner i realtid. Har använt mig av en kombination av NeTEx Regional Static data samt SIRI för realtidsdata för att visa position och data om bussarna.
Hur är tanken att och best practice kring NeTEx data? Den quota man får för statisk data är 50 förfrågningar per månad (brons). Men om data uppdateras 1 gång per dag och man vill ha flera operatörer än 1 så äts den quota upp fort. Eller behöver man inte uppdatera statisk data varje dag? Hur ofta uppdateras den?
Vad gäller best practice för SIRI? Hur ofta uppdateras denna data? För det är samma fråga här, säg att man vill få realtidsdata var 5:e sekund. Då räcker inte heller 30000 förfrågningar per månad. Uppdateras data olika beroende på tid av dygn? Även om man trimmar in och har säg var 5:e sekund under rusningstid (6-8 och 16-18) och 15s övrig tid så räcker inte det många dagar.
Sen kanske inte appen frågar dygnet runt om det inte är några användare. Men vad är best practice? Jag bygger en egen backend tjänst som cachar frågorna var X s. Så även om det är många användare av appen så bör det inte mot Trafiklab vara förfråganingar mer än som för 1 användare om flera använder samtidigt.
Bygger en iOS app för att bl.a. visa bussars positioner i realtid. Har använt mig av en kombination av NeTEx Regional Static data samt SIRI för realtidsdata för att visa position och data om bussarna.
Hur är tanken att och best practice kring NeTEx data? Den quota man får för statisk data är 50 förfrågningar per månad (brons). Men om data uppdateras 1 gång per dag och man vill ha flera operatörer än 1 så äts den quota upp fort. Eller behöver man inte uppdatera statisk data varje dag? Hur ofta uppdateras den?
Vad gäller best practice för SIRI? Hur ofta uppdateras denna data? För det är samma fråga här, säg att man vill få realtidsdata var 5:e sekund. Då räcker inte heller 30000 förfrågningar per månad. Uppdateras data olika beroende på tid av dygn? Även om man trimmar in och har säg var 5:e sekund under rusningstid (6-8 och 16-18) och 15s övrig tid så räcker inte det många dagar.
Sen kanske inte appen frågar dygnet runt om det inte är några användare. Men vad är best practice? Jag bygger en egen backend tjänst som cachar frågorna var X s. Så även om det är många användare av appen så bör det inte mot Trafiklab vara förfråganingar mer än som för 1 användare om flera använder samtidigt.
Följ inlägget
1
följare
Brons-nivån på NeTEx är som du säger till för att hämta data för en operatör. När man har behov av data för fler operatörer kan man begära en uppgradering på nyckeln så att man kan ladda ner data för fler operatörer. Anledningen till att begränsningen finns är för att undvika att man av misstag laddar ner filer oftare än 1 gång per dag, då det skapar onödig belastning på systemet. Samma sak gäller realtidsdata, där standardnivån är till för 1 operatör där man kanske endast behöver förseningsinformation, eller inte behöver ha positioner dygnet runt. Det går dock fint att uppgradera nyckeln när det finns behov av fler anrop.Till exempel skulle silvernivån passa bra för statiskt data, och silvernivån på SIRI data skulle räcka till 2 operatörer inklusive positioner. Alla brons/silver/guld nivåer är kostnadsfria, så det är bara ansöka om det man har behov av.
Det blir bra med 1 central server, på det sättet undviker du även att appen måste ta emot stora mängder data utan kan du välja exakt vad som ska skickas till appen. På det sättet kan man även, som du nämner, cacha data för alla användare. Detta är best practice och kommer funka fint. Sen kan du, beroende på systemets arkitektur, välja att pausa inhämtning av realtidsdata när det inte har kommit anrop under en viss tid. Vanligtvis brukar den centrala servern dock vara igång och hämtar datat dygnet runt.
Hälsningar,
Bert
Typiskt söker man baserat på en beräknad last, tex att man förväntar sig behöva åtminstone silver för att klara x antal användare. Sen kan man följa upp användningen för att se om man behöver söka om ytterligare höjningar när antalet användare ligger högre än väntad.
Hälsningar,
Bert