Omogeneità dell’id all’interno dei servizi GTFS

GTFS parte dal presupposto che gli «id» siano coerenti all’interno dei diversi servizi GTFS Static, GTFS-RT e GTFS-SA. Nella creazione di GTFS-SA siamo un po’ preconcetti:

  • stopId è lo SLOID della fermata o del binario
  • tripId è lo SJYID (cioè il nuovo ID ufficiale della corsa).

Purtroppo, questo non corrisponde a ciò che c’è in GTFS Static:

  • stop_id è un ID generato artificialmente che ci permette di mappare le piattaforme (ad es. 41/42) e i gruppi di settori (ad es. 12A-D, 12A) quando appaiono così nell’orario.
  • Anche trip_id è creato artificialmente e dipende da linee e varianti di linea.

Inoltre, non possiamo semplicemente utilizzare gli SLOID e SJYID, perché il formato GTFS richiede l’unicità e al momento non esiste:

  • Uno SLOID può essere utilizzato sia per la piattaforma sia per il binario o anche per il gruppo settori (per es. ch:1:sloid:7000:0:41 varrebbe anche per 41/42, 41A, 41E-H). In questo modo verrebbero visualizzate più righe con lo stesso SLOID.
  • Uno SJYID è univoco solo insieme al giorno di esercizio. In GTFS deve essere univoco a livello globale.

Proposte di soluzioni

  • In trips.txt lo SJYID è già stato inserito in una nuova colonna «original_trip_id». In questo modo i GTFS SA possono essere mappati almeno indirettamente.
  • In stops.txt aggiungiamo le SLOID anche in una colonna aggiuntiva («original_stop_id»). Per i marciapiedi (bordi fermata) viene aggiunta la SLOID, se disponibile. Se non disponibile, il campo rimane vuoto. Per le fermate vengono aggiunte le SLOID, per le fermate estere talvolta i numeri UIC.
  • In GTFS-SA stiamo ampliando la «informed_entity» per trasmettere tutti gli stopID interessati (Service Alerts – General Transit Feed Specification).

Link

#AutoTranslate