A partire da uno dei prossimi feed (prevedibilmente a settembre o più tardi), abbiamo in programma alcune novità in GTFS RT Service Alerts.
Feed separati
Per soddisfare meglio le esigenze dei nostri utenti e ridurre la quantità di dati, introdurremo quattro feed separati per i dati degli eventi:
| Feed | Tipo
(Planned) |
Prospettiva
(Prospettiva) |
Tipo
(Progress) |
|---|---|---|---|
| Feed 1 | pianificato | Informazioni sull’orario (whileplanningtrip) | Annunci principali (published) |
| Feed 2 | non pianificato | Informazioni sull’orario (whileplanningtrip) | Annunci principali (published) |
| Feed 3 | pianificato | Indicatori delle fermate
(atStopPoint) |
Messaggi principali e finali
(published|closing) |
| Feed 4 | non pianificato | Indicatori delle fermate
(atStopPoint) |
Messaggi principali e finali
(published|closing) |
Un evento viene pubblicato non appena è disponibile, quindi anche a prescindere dal fatto che sia già attivo (la data di inizio è nel futuro).
Sostituzione di active_period con impact_period e communication_period
Allo stesso tempo, pianifichiamo, active_period a cura di impact_period e communication_period per chiarire la relazione temporale tra le segnalazioni:
communication_period
Durante questo intervallo di tempo il messaggio è visibile. I valori corrispondono alla struttura SIRI-SX PublicationWindow.
communication_period vengono visualizzate solo nella prospettiva degli indicatori delle fermate (atStopPoint) e serve a controllarne la pubblicazione. Il produttore di dati può, ad esempio, stabilire che un evento venga visualizzato alla fermata prima dell’inizio dell’evento.
impact_period
Durante questo intervallo di tempo l’evento segnalato è attivo. I valori corrispondono alla struttura SIRI-SX ValidityPeriod.
informedEntity: Segnalazioni relative a viaggi con restrizione a determinate fermate
Le segnalazioni relative a Trip possono ora essere visualizzate su Stop (stop_id). Questo può essere inserito nel campo informedEntity come nell’esempio seguente:
"informedEntity": [
{
"agencyId": "11",
"stopId": "ch:1:sloid:3000",
"trip": {
"tripId": "115.TA.91-2G-Y-j26-1.28.R",
"startTime": "19:32:00",
"startDate": "20250310",
"originalTripId": "ch:1:sjyid:100001:719-001"
},
},
{
"agencyId": "11",
"stopId": "8102336",
"trip": {
"tripId": "115.TA.91-2G-Y-j26-1.28.R",
"startTime": "19:32:00",
"startDate": "20250310",
"originalTripId": "ch:1:sjyid:100001:719-001"
}
}
]
informedEntity: stopId ora corrisponde al GTFS stopId del bordo fermata
Ora il campo stopId all’interno di informedEntity con la stopId del bordo fermata (in base a GTFS Static) anziché con lo SLOID della fermata. Nel campo originalStopId è disponibile anche la SLOID del bordo fermata.
Con un riferimento alla linea o alla corsa, la stopId e/o originalStopId dei bordi fermata percorsi.
Gli URL non vengono più trasmessi
Gli URL nel campo url non vengono più emessi. Gli URL continuano a essere emessi come parte del descriptionText.
Priorità
La priorità degli avvisi è rappresentata dalla sequenza in JSON. I messaggi con la priorità più alta vengono visualizzati in cima all’elenco.
La priorità viene determinata in base ai seguenti criteri:
| Posto | Criterio | Descrizione |
|---|---|---|
| 1 | Priorità dal sistema sorgente | Priority o ActionPriority di SIRI-SX (ActionPriority ha la priorità) |
| 2 | Stato («Progress» nel sistema sorgente) | Published prima della chiusura |
| 3 | Data di inizio (impact_period oppure communication_period) |
Il più piccolo valore «start» di impact_period o communication_period |
