Testare il feed statico in un'anteprima privata

Dopo aver caricato un feed General Transit Feed Specification (GTFS) valido nella Dashboard Partner di Google Transit, puoi attivare un'anteprima privata per testare la pianificazione del feed e l'elaborazione dei percorsi in un ambiente di gestione temporanea prima di renderlo pubblico.

Ti consigliamo di testare i dati dell'anteprima con persone che hanno familiarità con il tuo servizio di trasporto pubblico, ad esempio i rappresentanti dell'assistenza clienti.

Visualizzare l'anteprima dei dati GTFS in Google Maps

1. Accedi all'Account Google associato alla tua Dashboard Partner di Google Transit. (Crea un nuovo Account Google.)
2. Visita Google Maps.
3. Testa varie query nella tua area (ad es. stazioni, orari e aree dei percorsi).

Se hai chiesto a diverse persone di testare l'anteprima, ti consigliamo di creare un account Gmail generico (ad esempio <nome_agenzia.gt>@gmail.com) da condividere con tutti oppure di associare un Account Google all'alias email interno del gruppo.

Testa i tuoi feed

Dopo avere effettuato l'accesso all'ambiente di prova dell'anteprima privata, puoi testare i dati del feed direttamente dall'interfaccia utente "Ottieni le indicazioni stradali" di Google Transit.

Ogni query "Ottieni le indicazioni stradali" genererà alcune opzioni per la corsa, riconoscibili grazie all'etichetta "Informazioni riservate di Google" in rosso accanto ai risultati. Queste opzioni utilizzano solo i dati del tuo feed.

Potresti trovare alcune opzioni prive dell'etichetta "Informazioni riservate di Google"; queste opzioni provengono dai dati attivi di altri feed. 

Ogni volta che aggiorni il feed, devi attendere qualche giorno prima di poter visualizzare i dati in anteprima. Pertanto, è importante correggere il maggior numero di problemi possibile. 

Oltre ai normali scenari di test, puoi anche verificare la tua anteprima privata per essere certo che:

• Le aree dei percorsi per le corse si associno correttamente alle strade su Google Maps.

• Il tempo totale delle corse sia pertinente (ad es. l'autobus non si muove troppo velocemente o troppo lentamente).

• Vengano testate sia le corse festive sia quelle feriali, utilizzando il menu a discesa Partenza ora.

• I cambi avvengano nei luoghi appropriati.

Testa opzioni di elaborazione del percorso differenti

Lo strumento di pianificazione delle corse di Google è progettato per fornire soluzioni diverse per ogni richiesta di elaborazione del percorso. Tuttavia, non può generare risultati identici a quelli di altri strumenti di pianificazione. L'algoritmo di Google cerca di trovare la combinazione più rapida per raggiungere la destinazione desiderata, applicando una lieve penalità ai cambi e ai tratti a piedi supplementari.

Se trovi una richiesta in cui i tuoi dati mostrano un'opzione di gran lunga migliore rispetto a quella dello strumento di pianificazione delle corse di Google, segnalala al team di assistenza per i Partner di Google Transit. Quando segnali problemi a Google, includi il link alla corsa facendo clic sul pulsante  nell'angolo in alto a sinistra di Google Maps e selezionando "Condividi o incorpora mappa". Poiché non conosciamo l'area locale, inserisci il maggior numero possibile di informazioni dettagliate.

Tieni presente che i dati di elaborazione del percorso che sono già pubblicati e disponibili per gli utenti vengono visualizzati come prima alternativa anche se uno dei percorsi nell'anteprima è più adatto.

Testa corse con cambio

Quando testi l'anteprima del feed, verifica che i trasferimenti tra le corse abbiano senso. Prova a inviare delle richieste di cambio tra i punti di cambio principali nella rete e verifica che i risultati abbiano una logica.

Durante le prove per la verifica dei cambi ricorda che:

• Il nostro algoritmo di elaborazione del percorso considera le opportunità di cambio dalla stessa fermata e le opportunità di cambio che prevedono un tragitto a piedi da una fermata all'altra.

• In entrambi i casi, il nostro algoritmo stima un tempo di cambio minimo (prevedendo un buffer di sicurezza) tra l'arrivo e la partenza e tiene conto di eventuali percorsi a piedi (se necessari). Potrebbe essere necessario adattare le stime a dati particolari.

Inoltre, verifica i tempi di cambio nelle principali stazioni di scambio o di arrivo di più linee, considerando in particolar modo la differenza tra gli orari di partenza e di arrivo. Se ti accorgi che il tempo di cambio minimo stimato è troppo basso (eventualità rara) o troppo alto, puoi correggerlo fornendo il file transfers.txt (così come spiegato nelle specifiche GTFS) che descrivono le opportunità di cambio nella rete.

Testare il feed con query casuali

Un altro metodo per testare il tuo feed è quello di utilizzare le query casuali trovate nel report di convalida GTFS. La scheda Query del report di convalida include le query sulle indicazioni stradali generate in maniera casuale da Google Maps tra coppie di fermate presenti nel tuo feed. Utilizza queste query per testare e verificare i risultati di elaborazione del percorso per il tuo feed, aumentando i tuoi test.

Revisione per garantire la qualità

Una volta che avrai risolto tutti gli avvisi problematici e una volta soddisfatto della versione di anteprima del feed GTFS, contatta il team Google per richiedere la revisione al fine di garantire la qualità del tuo feed. Ti segnaleremo tutti gli eventuali problemi rilevati nel feed e lavoreremo insieme per risolverli.

Google richiede una revisione finale e l'approvazione prima del lancio del feed GTFS.

Best practice per il test dell'anteprima privata

Verificare i percorsi in anteprima su Google Maps

Dopo aver verificato le query casuali, puoi pianificare manualmente le corse su Maps utilizzando le coordinate geografiche delle fermate.

Generare una corsa casuale

Puoi generare un esempio di corsa che contenga i dati inclusi nella scheda Query del report di convalida.

Pianificare una corsa

Assicurati di avere eseguito l'accesso alla Dashboard Partner di Google Transit con il tuo Account Google prima della verifica manuale.

Per verificare manualmente una corsa, procedi come segue:

1. Apri Maps.
2. Fai clic su Indicazioni stradali .
3. Fai clic su Trasporto pubblico.
4. Utilizza i valori latitudine/longitudine delle fermate per pianificare una corsa. Tieni presente quanto segue:
   • Per l'anteprima non sono disponibili i nomi delle stazioni e delle fermate.
   • Non sono disponibili collegamenti con servizi esistenti di autobus, di traghetto o ferroviari forniti da altre aziende di trasporto pubblico
5. Verifica le query utilizzando le opzioni Partenza adesso e Partenza.

Dopo la pianificazione di una corsa

I risultati di elaborazione del percorso relativi alla corsa vengono visualizzati su uno sfondo rosa chiaro. Questi dati sono riservati e non vengono mostrati agli utenti finali.

Dopo aver pianificato la corsa, verifica i seguenti dettagli:

• Nome di percorso abbreviato/Nome di percorso esteso
• Orario della fermata
• Nome della fermata
• Durata del viaggio
• Aree (se presenti)
• Nome dell'azienda
• URL dell'azienda
• Telefono dell'azienda (se presente)
• Informazioni sulle tariffe (se presenti)
• URL delle tariffe

Assicurati che tutte le entità corrispondano ai dati forniti sul tuo sito web e siano riconoscibili agli utenti finali.

I risultati di elaborazione del percorso costituiscono una rappresentazione visiva dei campi mostrati agli utenti finali.

Verificare i feed GTFS

Test preliminari

• Periodo di servizio: assicurati che il periodo di servizio sia superiore a 28 giorni e inferiore a 3 anni.
• Copertura: fornisci una copertura completa. Se stai offrendo una copertura limitata, segnalacelo fornendo una spiegazione valida nel modulo dell'elenco di controllo.
• Avvisi di convalida: verifica e risolvi gli avvisi di convalida nella scheda Errori del report di convalida generato più di recente.

Dettaglio dei test (file GTFS)

• Agency.txt: le informazioni fornite sull'azienda sono corrette e corrispondono a quelle sul relativo sito web.
  • Il numero di telefono dell'azienda e gli URL delle tariffe sono consigliati per migliorare l'esperienza utente.
• Calendar.txt: tutti i servizi con giorni attivi della settimana inclusi.
• Calendar_dates.txt: 
  • Le date con eccezioni corrispondono al periodo di servizio definito in calendar.txt.
  • Sono incluse tutte le date in cui i servizi funzionano in modo diverso (servizio ridotto o straordinario) rispetto alle date abituali (come giorni festivi o festività ufficiali).
  • Se i tuoi servizi vengono eseguiti senza eccezioni, ignora l'avviso "Il feed non ha eccezioni per le date del calendario".
• Routes.txt: 
  • I nomi e il colore dei percorsi corrispondono a quelli del sito web dell'azienda e sono riconoscibili agli utenti finali.

  • Quando vengono forniti sia route_short_name che route_long_name, gli utenti finali troveranno route_short_name.

  • I percorsi non sono suddivisi per direzione.
  • I Route_urls sono specifici per ciascun percorso o non sono forniti affatto.
• Trips.txt: 
  • I Trip_headsigns forniti indicano la direzione corretta della corsa e sono riconoscibili agli utenti finali.
  • I Trip_headsigns non duplicano i nomi dei percorsi.
  • I Trip_headsigns sono definiti solo per percorsi lineari.
  • I Trip_short_names sono definiti solo per route_type: linea ferroviaria extraurbana.
  • I valori per i nomi di percorso abbreviati sono definiti solo per linee ferroviarie extraurbane o treni a lunga percorrenza.
• Stops.txt: 
  • I nomi delle fermate sembrano plausibili e corrispondono a quelli sul sito web dell'azienda.
  • I nomi delle fermate non includono stop_codes (ad esclusione del Brasile).
  • I nomi delle fermate possono includere abbreviazioni, ma devono essere coerenti.
  • Le posizioni delle fermate sono precise (sul lato corretto della strada, vicino al marciapiede).
  • Gli Stop_codes, se presenti, sono disponibili sul sito web dell'azienda e gli utenti finali devono esserne a conoscenza.
  • Gli URL delle fermate sono specifici.
• Shapes.txt (facoltativo, ma vivamente consigliato):
  • Le aree seguono con precisione le strade/ferrovie.
  • Le aree vengono fornite per tutte le corse e indicate nel file trips.txt.
  • Risolvi eventuali avvisi di convalida relativi al file shapes.txt.
• Stop_times.txt: 
  • Gli orari delle fermate definiti nel feed devono essere disponibili sul sito web e riconoscibili agli utenti finali.

  • Se definito, verifica il tipo di fermata salita o discesa.

    Gli attributi pickup_type e pickup_type 2 (è necessario chiamare l'azienda di trasporto) e 3 (è necessario coordinarsi con il conducente) non sono supportati.
  • Per i percorsi ad anello, è necessario definire stop_headsign a ogni fermata.
• Feed_info.txt:
  • Lingua del feed definita in questo file o in agency.txt.
  • Confronta la data di inizio e di fine con i file del calendario.
• Avvisi di convalida.
  • Nessun avviso "Fermata troppo lontana dall'area".
  • Nessun avviso "Le corrispondenze tra le fermate e l'area sono nell'ordine errato".
  • Nessun avviso "Troppe fermate consecutive con orari uguali".
  • Nessun avviso "Orari delle fermate sovrapposti per corse dello stesso blocco".
  • Nessun avviso "Intervallo di date nel servizio feed".
  • Avvisi "Fermate nel fuso orario errato".
  • Avvisi "Contrasto colore del percorso".
  • Avvisi "Tempo di cambio minimo non presente".
  • Avvisi "L'indicatore della destinazione duplica il nome della fermata".
  • Avvisi "Posizione del punto troppo vicina all'origine (0,0)".

Inviare l'elenco di controllo pre-lancio

Se hai verificato il feed seguendo le linee guida riportate sopra e i risultati di elaborazione del percorso su Maps ti soddisfano, puoi proseguire completando il modulo dell'elenco di controllo pre-lancio. Una volta inviato, il tuo feed verrà sottoposto a un controllo di qualità.