Trasporti a Milano

E' una faccenda complicata. I feed generati dai software di gestione degli orari talvolta sono stati concepiti in modo diverso da come se li aspetta google e quindi talvolta su transit escono errori, soprattutto nei periodi particolari (come i giorni di vacanze scolastiche o i giorni festivi infrasettimanali o nei festivi a circolazione ridotta come Natale). Mettere mano ai gestionali è possibile ma oneroso e spesso si rischia di fare come Cimabue.

Appunto per quello servirebbe avere librerie aggiornate...

E delle due l'una: o le specifiche pubblicate non corrispondono a quanto realmente fa google o il software non le rispetta, provato a scrivere sulla mailing list?

fra74 wrote:Guarda che esistono software per la gestione degli orari in grado di esportare in formato google transit, quindi la fonte è la stessa. È solo un formato diverso per convogliare le informazioni. Poi per carità ci possono essere perdite di informazioni ma non è che i feed GTFS vengano creati indipendentemente dagli orari. Questo per dire che non è detto che in linea generale (nel caso specifico di TN non saprei) i feed siano in qualche modo secondari rispetto all'orario ufficiale

Lo so benissimo che la fonte è la stessa, però secondo me gli orari ufficiali li ricontrollano mentre quello che va su Google mi sembra più difficile.

Cioè, mi viene difficile pensare che qualcuno a Trenord si giri google maps per vedere se ha recepito bene tutti gli orari. Specie un treno che parte alle 5:27 dl mattino

E comunque Google ne combina di cotte e di crude, una volta abbiamo dovuto far cambiare il telefono a un'impiegata a causa dei risultati del motore di ricerca.

Dai smettiamola va bene che ci possono essere bug o che le specifiche magari siano poco chiarer ma che google si inventi che sia una S2 ce ne passa. Ribadisco perché non guardate il feed gtfs?

vi do una mano: trip_id 7719806

e se non sapete dove trovare il feed:

https://www.dati.lombardia.it/Mobilit-e ... /3z4k-mxz9

@fra74: ad esempio, l'esportazione GTFS di IVU.Plan si può solo definire "broken".

Se un software non è in grado di esportare un file (meglio un gruppo di file) con una specifica elementare come quella è colpa di Google?

Assolutamente no, non stavo supportando il discorso di gerryno ma il tuo.

Ah ok, capito male

fra74 wrote:Appunto per quello servirebbe avere librerie aggiornate...

E delle due l'una: o le specifiche pubblicate non corrispondono a quanto realmente fa google o il software non le rispetta, provato a scrivere sulla mailing list?

Non è solo un problema di librerie. Non so come spiegarmi...
I gestionali non sono nati per fare l'esportazione a google, ma per creare orari, corse, turni etc etc.
In alcuni casi, un modo di usare il gestionale perfettamente compatibile con le esigenze interne, genera dei feed che google interpreta male o malissimo.
Non sempre è semplice e banale mettere mano al gestionale per andare appresso a google e l'aggravante è che è praticamente impossibile telefonare a google per cercare di avere indicazioni su come muoversi.
Alle volte uno rinuncia a smontare e rimontare la programmazione perché google canna UNA corsa che circola il venerdì feriale di vacanza scolastica...
Ci si aggiunga che, caricando il feed su google tante volte escono degli error#sarcazzo che è davvero difficile interpretare.

Tralasciamo che poi google prende spesso comunque fischi per fiaschi.
Un esempio a me noto è questo https://goo.gl/maps/eghacCv6hmA2
Per qualche motivo inserendo "Colico" come partenza, google ti vuole far fare per forza 14 minuti a fette per andare alla fermata, con il risultato che poi la gente reclama in questi termini:
"su google voi dite che la corsa parte alle 10.31, poi invece alla palina è scritto 10.45"

Si', ma a volte sembra che pesino le chiappe a fare un lavoro decente... IVU ad esempio genera un ID di corsa diversa per ogni giorno di effettuazione (ovvero, se una corsa è FER5 genera circa 300 corse per un feed di lunghezza 1 anno), che moltiplicato per un centinaio di corse al giorno fanno 30.000 corse anziché 100. Ovviamente GTFS supporta la dicitura "FER5" senza alcun problema, non c'è nemmeno bisogno di associarlo ad un codice numerico. Il risultato è che il feed rappresenta l'orario giorno per giorno, ma tutte le informazioni sulla periodicità non sono presenti.

È anche una questione di librerie. Difficile riuscire a scrivere feed appropriati se la libreria di riferimento non è aggiornata da metà 2015, ha 148 problemi irrisolti (vedi https://github.com/google/transitfeed/issues) e supporta solo vecchie versioni di Python. Io software house per assicurarmi che tutto funziona dovrei fare dei test contro la libreria di riferimento, ma se questa fa schifo non c'è molto da fare.

Quanto all'esempio che poni, perdonami ma non vedo dove sia il problema. Colico è grande (ha una superficie quasi quanto quella di como), se non si è più precisi è abbastanza naturale che nel momento il cui faccia il geocoding possa risultare una coordinata di un punto lontano dalla fermata del bus e che quindi il motore di ricerca propone tratti a piedi (se poi gli utonti non si accorgono che l'ora indicata è l'inizio della catena di trasporto...). Ecco il risultato essendo un attimino più precisi https://goo.gl/maps/Wgg989MDHTF2

E del resto che differenza ci sarebbe tra l'esempio che poni e che so, questo? https://goo.gl/maps/cmcWyaTBQLv

@Astro: quando dici su "FER5" è un po' impreciso però...

Quello che fa testo è la specifica, che è chiara e documentata, non una libreria che implementa tale specifica in un dato linguaggio di programmazione. Se io sviluppo in C++ o in Java non vedo perché dovrei richiedere anche una VM Python solo per usare la libreria ufficiale. Posso capire il commento per robe tipo RailML, ma per GTFS in un paio di giorni (toh, una settimana compreso il testing) partendo da zero puoi tranquillamente scrivere una libreria di conversione.

Peccato che la libreria di riferimento includa anche il validatore dei feed...

Nel momento in cui si scrive una libreria/software che salva in un formato è buona norma validare i file prodotti in modo di assicurarsi di aver rispettato tutte le specifiche, ma se il validatore è buggato/non aggiornato...

E comunque la maggior parte dei progetti finiscono così XD

Scusate, ma ci sono tre pagine di discussione su Google Transit perché l'11606 è classificato S2 e non S4?
Quello è un treno anomalo, parte da Mariano come le S2 ma va a Cadorna come le S4 e sulla loro traccia. Per di più è Fer6 e non giornaliero come le S4. E' chiaro che qualsiasi classificazione è "sbagliata" almeno per qualche verso.
E' per questo che sull'orario ufficiale http://www.trenord.it/it/orari/scarica- ... 81%29.aspx è semplicemente classificato S, senza numero.
Anche sul sito di Trenitalia è S e basta.
Il sito di Trenord purtroppo non mette i numeri delle S per nessuna. Vabbé, ci arriveranno tra qualche anno

Anche le due corse Garbagnate-Pavia sono S e basta, non 13, non 1.
Sarebbe bello avere "proprio tutti" i treni uguali, ma qualche volta non è possibile. Tutti i treni uguali fanno il modello SFM del Piemonte: va a finire che manca quello che serve.

In ogni caso, please, in caso di dubbio, si va a guardare il vecchio buon orario cartaceo. Una volta potevate dire "non spendo 5 euro", adesso il pdf è gratis. Usatelo. Aiuta a sviluppare l'intelligenza, come la Settimana Enigmistica

Mah Giorgio, non era tanto la questione se quella corsa fosse una S2 o una S4, quanto invece, visto che su Google è indicata come S2, attribuire a qualcuno la colpa di questo grave crimine contro l'umanità E qui vabbè si è persa una settimana ad attribuire colpe a google quando bastava (e ho invitato più volte a farlo) guardare il feed visto che è scaricabile liberamente dal sito degli open data regionali per scoprire che no google non ha deciso di complottare per incasinare la vita ai poveri pendolari della Asso XD