Nuovo motore di ricerca regionale

[fra74]

Mah per il momento no, ho fatto una ricerca da San Giuliano via Emilia ang Tolstoj a San Donato... mi indica Z420 con tempo di percorrenza ed orari, e pure 130, ma solo con tempo di percorrenza e non orari

Ripeto ci sono alcune cose sicuramente ottime, altre invece assolutamente discutibili (come il casino sulle linee ferroviarie tipo S9). Quanto a generare un unico PDF insomma dipende... su linee con non tantissime corse la cosa è gestibile, ma su linee con tante corse poi si arriva a PDF monstre come per la Z221...

Difficile al momento dare un giudizio definitivo su un sistema che al momento non è ancora maturo... c'è anche da capire in un momento di cambi orari quanto sia dovuto magari al fatto che alcune società non abbiano comunicato i nuovi orari...

[msr.cooper]

Anche su linee con poche corse si crea una discreta confusione...
Es: z231 http://www.muoversi.regione.lombardia.i ... Linea=z231

Bisognerebbe trovare il modo di non replicare le corse comuni a più di una periodicità.

[brianzolo]

mah chissà come facevano gli svizzeri a stampare gli orari cartacei con gli orari di tutte le linee e di tutti i mezzi...
e pure prima dell'entrata in vigore dei nuovi orari; esattamente come da noi

[fra74]

msr.cooper: Niente che non si possa fare sbattendosi un po' con il DB... ma forse qua la colpa è alla radice che senso ha una corsa con periodicità "SAB" e una con periodicità "FER5" con gli stessi orari?

Il problema è come vengono trasmessi gli orari in regione. C'è un formato universale o ogni ditta trasmette come capita e poi si deve ricorrere agli scriba? (alias addetti al data entry)

[Slussen]

Beh a me pare che ci sia una codifica della periodicita' ... e una spiegazione dei codici sull'ultima pagina ... che nella fattispecie e' la pagina 130 ...

... era proprio necessario un pdf di 130 pagine per una linea, o con una impaginazione diversa si poteva compattare ?

E' totalmente incomprensibile in questo modo.
Occorre produrre degli orari separati per periodicità (invernale/estivo; lunedì venerdì / sabato /festivo).
Ci sono sicuramente software che lo fanno basta dargli in pasto i dati.

In generale, il sito sarebbe più completo con una base cartografica e con la possibilità di effettuare ricerche per indirizzo (non solo per fermata).

@FRA74: C'è un formato universale codificato in un software

[Lucio Chiappetti]

3) assolutamente falso, questi cosa sono? http://www.trenord.it/it/biglietti-e-ab ... iario.aspx

C'erano anche prima del 10 giugno ?
Perche' se uno trova un sito buono da subito lo usa (e si lamenta se cambia, vedi vecchissimo ATM, FNM, vecchio Regione), se uno trova un sito mal fatto nella versione iniziale, finisce che "se lo segna" e non lo usa (vedi FS, Trenitalia, ecc.) anche se poi migliora.

Per orari della linea non è assolutamente vero.

E questo lo dicevo pure io, dopo che mi avevate detto di farlo da li'. Psro' sta di fatto che la stessa cosa (ricerca per gestore e citta') da' risultati diversi partendo da form diversi, di cui uno sbagliato.

[fra74]

ci sono almeno dalla scorsa estate. al massimo erano un po' troppo infognati mentre ora esiste un link diretto dalla pagina di ricerca degli orari.

le due pagine sul sito della regione NON servono allo stesso scopo

[Lucio Chiappetti]

Occorre produrre degli orari separati per periodicità (invernale/estivo; lunedì venerdì / sabato /festivo).
Ci sono sicuramente software che lo fanno basta dargli in pasto i dati.

Oppure strutturando i dati in modo opportuno (tre database diversi - in mysql parliance - per lu-ve, sa, do). Pero' avere un PDF unico per linea con la periodicita' di ogni corsa non e' cosa cosi' inusuale (vecchi Grippaudo !) ne' scomoda (il Rejseplan danese consentiva di comporsi orari pdf personalizzati - molto tradizionali e leggibili come layout - con le note di periodicita' ... siccome la personalizzazione includeva il fatto di stabilire una data di inizio e di fine, poteva gestire anche intervalli a cavallo di eventuali cambi di orario !)

Ma 130 pagine ... le compiante BR (British Rail neh !) producevano orarietti stampati tascabili per linea. E per tasche piccole !

[fra74]

3 database? poi mantenerli consistenti diventa un incubo...

[Slussen]

Sì ma una cosa è il ferro, una cosa la gomma.
Fermo restando che le aziende di bus giocano un po' troppo con le periodicità, però la necessità di redigere orari diversi per periodi dell'anno e della settimana deriva anche dal mutare dei tempi di percorrenza, oltre che delle frequenze.
Quindi, salvo sistemi interamente in sede protetta, è difficile produrre un orario annuale leggibile in un unico file.

[fra74]

capisco il tuo punto di vista ma spesso capita di vedere corse con periodicità differente i cui orari differiscono di 1-2 minuti. ha senso? per non parlarsi casi in cui gli orari sono esattamente identici

[Slussen]

E però, nel caso di orari identici, è di nuovo il software regionale che non compie l'operazione inversa a quella che proponevo io, cioè non assembla le corse identiche inserite con periodicità diverse.

[Lucio Chiappetti]

3 database? poi mantenerli consistenti diventa un incubo...

Ho detto "database in mysql parliance" che sostanzialmente sono dei directories. N database tables (una per linea) con lo stesso nome in ciascuno dei 3 directories. Cosi' l'interfaccia di accesso e' la stessa, basta riassegnare la variabile che setta il database.

Perlomeno cosi' farei io se dovessi farlo (ho in mente un progettino a tempo perso ...). Cosi' facciamo noi astronomi se dobbiamo gestire release successive dello stesso set di cataloghi, o dare accesso a consorzi diversi a insiemi di dati simili... magari con dei softlink o delle VIEW per quelle parti identiche per evitare di duplicarle e moltiplicare gli errori. Non e' detto che sia l'unico modo ...

[Slussen]

Ad esempio, questo orario francofortese (allegato) non mi fa impazzire, con le sue note "a" e "b", pur di non pubblicare un separato orario estivo (soppressioni ed effettuazioni riguardano il periodo 2 luglio-10 agosto).

[fra74]

Slussen: non sono per niente d'accordo. è pessima progettazione delegare ad un front end la correzione di pasticci/inconsistenze in una base di dati. Il dB deve essere corretto sin dall'inizio.

Lucio: complicazioni inutili. La periodicità è facilmente codificabile in un campo e l'orario opportuno può essere generato con una query. inoltre quanto proponi complica notevolmente certe ricerche (pensa ad una soluzione di viaggio a cavallo tra veverdi e sabato). inoltre nei DB che mi sono capitati sotto mano quasi mai c'è una corrispondenza 1:1 tra tabella e linea