Here is a pad about the development of Open Delays into a more stable structure. Express yourself !

Project page: http://wemove.center/joomla/index.php/projects/open-delays

Code : https://github.com/OpenDelays/opendelays

= = =

Possibilità renderlo accessibile da internet e renderlo riservato con password - open access or restricted access: depends from project situation

Tenere attivo script samuel ->lavorare in parallelo - keep active the initial script -> work parallelly to the initial script

1. GRUPPO PROGETTO - SET UP A PROJECT GROUP

Creare gruppo progetto attorno al lavoro > Raphael

28/4/15: Pareri ottenuti da :Marc, Anthony, Mario, Simone C, Aleksei, Fabrizio, Miguel, Peter

Diffusion on two mailinglists (Spaghetti Open Data, OKFN Transport)

//medium.com/@highsource/reliable-train-connections-app-wins-the-first-deutsche-bahn-hackathon-3419ef275bfc">https://medium.com/@highsource/reliable-train-connections-app-wins-the-first-deutsche-bahn-hackathon-3419ef275bfc>

Deutsche Bahn data, at Hackaton May2015on infrastructure data :

http://www1.deutschebahn.com/dbhackathon-en/hackathon/dbhackathon3.html

Delays data at a former hackaton in April 2015.

 

2. SISTEMARE IL SERVER - SETUP THE SERVER

1. updates and backups of the former server. Former system was running on a OVH server.

Due server diversi / Two different servers : register.it and versio.uk. 

 

Definition of server needs :

unlimited number of databases

unlimited space - di quanto spazio abbiamo bisogno per anno. Cfr calcolo: sotto 10 Giga l'anno per i 3 scripts esistenti

for a convenient price – ok al normale prezzo di mercato (qualità e garanzia > prezzo)

that works well (no down time, correct server updates done by the provider)

that will not get intimidated by any case of undue law threats, in a country with good laws on IT freedom

 

Size calculation :

OpenDelays_it : 59 octets /record;52krecords/day = 1,1 Go/year

Opendelays_be1 : 50 octets /record; 22krecords/day = 400 Mo/year

Opendelays_be2 : 32 octets /record; 17krecords/day = 200 Mo/year (source stopped)

OpenDelays_uk : 79 octets /record; 250krecords/day = 7.2 Go/year

Total : 10 Giga / year

http://wemove.center/joomla/index.php/blog/item/104-open-delays

 

Questions :

dedicated or shared server ? Now : shared server.

 

Discussion on server and database settings

Simone C : importante fare offset dei costi (e fare un backup) pensando a copiare i dati del giorno precedente su altra infrastruttura. Io consiglio di usare Amazon S3 (copiando i dati e azzerando il DB giornaliero/settimanale- http://s3tools.org/s3cmd )

 

Fabrizio : We can use a compression-like schema for older data, for example:

leave untouched data from the last 6 months

from 6 months to 9 months, compact the data with a average delay computed on 2 days

from 9 months to 1 year compact with a average delay on the week

Older then 1 year etc......

It's the schema used in RRD tool http://en.wikipedia.org/wiki/RRDtool

 

Raphael :

Bisogna tenere ben presente le varie componenti non tutte compatibili dell'obiettivo:

- Dati affidabili,

- Dati utilizzabili facilmente,

- un sistema non troppo complesso,ecc.

- Evitare operazioni di aggiornamento

- Prevedere la grande quantità di dati che avremo

 

Fabrizio :

Tabella italiana : Molte informazioni sono duplicate e queste occupano spazio e appesantiscono il db.

Penso che questo schema di database possa andare bene per una ricerca sui treni del giorno, ma passata la mezzanotte occorre compattare e suddividere le tabelle, ad esempio:

- una tabella con il treno,numero,origine e destinazione

- una tabella con numero treno e solo i ritardi

In tal modo si risparmia spazio di archiviazione e si rende piu' facile la ricerca

 

Giuliano: Non sono convinto di questa soluzione. Dobbiamo comunque tenere conto anche della tratta quindi la tabella treno e ritardi dovrebbe contenere anche la tratta, quindi torniamo allo schema attuale. Inoltre bisognerebbe mappare le tratte e stare attenti agli combiamenti eventuali sulle tratte usando degli indici. Abbiamo poi bisogno di poter estrarre dati statistici su tutto il periodo e quindi di un informazione non loseless e rapidamente accessibile. Tenere solo i dati del giorno servirebbe piu per consultazioni da utente mentre noi interessano informazioni per analisi complessive. Anche il datetime comunque è necessario nella seconda tabella. Insomma il database mi sembra già essenziale.

Modificarlo significa perdere informazione. Es come faccio a sapere se tal treno ha compiuto ritardi complessivi superiori a 10 ore negli ultimi sei mesi nel segmento di tratta che volgio prendere in esame ?

 

Best candidate ? (price, location in Europe, data friendly country):

1. Una fase di raccolta dati, in forma sql : periodo buffer

 

2. Una fase di conservazione dati, dopo un primo periodo (settimana ? mese ? anno ?) : Amazon, e un altroserver di backup o di seconda raccolta

o inviare i dati via mail ? sicurezza ma non molto pulito ? UK : 1 mega ogni ora di servizio

 

3. Controllo integrità esterna degli altri 2 server, ogni ora

Un server per controllare che gli altri siano funzionanti

Giuliano: io alla fine ritengo che la migliore soluzione sia quella di register a 18eu/mese spazio e db illimitato. Affiancato da un server straniero equivalente.

Entrambi fanno girare lo script di raccolta e il monitor: si controllano a vicenda.

Trovo invece utile un server con spazio e db illimitati e prezzo contenuto.

Creare piu db spezzettati consultabili e gestibili facilmente

Due server uguali che si controllano

Cost simulation: https://framacalc.org/opendelays

Other candidates : http://www.register.it/hosting/windows-details-platinum.html (Dada, Milano): questo potrebbe andare. Comunque confermando prima mandando loro mail e descrizione del progetto

For the type of db i will prefer to use mysql, just for confidence with this system
 

3. MODIFICARE I DB - UPGRADE THE DB – UPGRADE THE SCRIPTS

Goals :

  1. rewrite the scripts from python into php
  2. change the db structure and scripts access, into several light db's
  3. tranfer the old db into the newstructure
  4. abilitate http access, if useful

 

FARE RICONVERSIONE DATI , FOR UNIFICATION INTO ONE DB

1 script per eseguire travaso, da attivare quando il nuovo sistema è gia partito. cosi da tenere la continuità

Script to make transfer, from former DB into new DB, when new DB already active, so as to keep continuity

 

2 alla frontiera: DB più piccolo. at the frontier : smaller DB

Fabrizio : Molte informazioni sono duplicate e queste occupano spazio e appesantiscono il db.

Penso che questo schema di database possa andare bene per una ricerca sui treni del giorno, ma passata la mezzanotte occorre compattare e suddividere le tabelle, ad esempio:

- una tabella con il treno, numero, origine e destinazione

- una tabella con numero treno e solo i ritardi

In tal modo si risparmia spazio di archiviazione e si rende piu' facile la ricerca

Ogni 6 mesi circa, i treni possono cambiare. Bisogna quindi aggiornare la tabella ogni tanto.

 

Former situation :

Per - by :

Ordine alfabetico - alphabeticalorder

Periodo Temporale (semestre)opzione che mi sembra migliora- time period ? this is the best criteria?

Verificare dimensione totale di ogni pezzo di DB - what is total dimension of each DB ?

Verificare dimensione massima ottimale - what is maximum optimum dimension of each DB ?

Divisione automatica (script)-automatic division of the DB (when reached a specific size)

Nota : source SNCB Railtime (belgium) has officially stopped 17 April 2015. Remains one source from SNCB Belgium.

 

Former tables structure :

opendelays_it

ColonneTypeNullDéfautCommentairesMIME

from_stationvarchar(30)Non

plan_time_arrdatetimeNon

delayint(11)Non

current_stationvarchar(30)Non

id_trainint(11)Non

to_stationvarchar(30)Non

Aucun index n'est défini !

Espace utilisé:TypeEspace

Data552 kKio

Index1 024o

Total552 kKio

Statistiques:InformationValeurFormatdynamique

Lignes9 573 054

Longueur de ligne ø59

Taille enr. ø59 o

CréationJeu 13 Novembre 2014 à 11:25

Last modificationMer 06 Mai 2015 à11:24

Last vérificationSam 28 Mars 2015à23:37

 

opendelays_uk

ColonneTypeNullDéfautCommentairesMIMEdatedateNon

current_stationvarchar(30)Non

plan_time_arrtimeOui NULL

real_time_arrtimeOui NULL

from_stationvarchar(30)Non plvarchar(15)Non

id_trainvarchar(5)Non tocvarchar(5)Non

to_stationvarchar(30)Non

plan_time_deptimeOui NULL

real_time_deptimeOui NULL

Aucun index n'est défini !

Espace utilisé:TypeEspace

Data2 765Mio

Index1 024o

Total2 765Mio

Statistiques:Information

ValeurFormatdynamique

Lignes43 400 085

Longueur de ligne ø66

Taille enr. ø67 o

CréationMar 11 Novembre 2014 à 14:21

Last modificationMer 06 Mai 2015 à11:30

Last vérificationSam 28 Mars 2015à23:40

 

opendelays_be

ColonneTypeNullDéfautCommentairesMIME

datetimedatetimeNon

arrivalStationvarchar(50)Non

delayint(20)Non

type-numvarchar(10)Non

Aucun index n'est défini !

Espace utilisé:Type

EspaceData168 kKio

Index1 024o

Total168kKioStatistiques:InformationValeurFormatdynamique

Lignes5 489 832

Longueur de ligne ø31

Taille enr. ø31 o

CréationMar 04 Novembre 2014 à 13:50

Last modificationMer 06 Mai 2015 à11:12

Last vérificationSam 28 Mars 2015à23:36

opendelays_railtime

stopped by source 17 April

ColonneTypeNullDéfautCommentairesMIMEdeparturetextNon

datetimedatetimeNon

delaytimeNon

destinationtextNon

trackint(11)Non

trainTypevarchar(10)Non

trainNumint(11)Non

Aucun index n'est défini !

Espaceutilisé:TypeEspaceData263kKioIndex1 024o

Total263kKioStatistiques:InformationValeurFormatdynamique

Lignes5 463 392

Longueur de ligne ø49Taille enr. ø49o

CréationMar 28 Octobre 2014 à 15:53

Last modificationVen 17 Avril 2015à05:28

Last vérificationSam 28 Mars 2015à23:37

 

Database Tasks

0 Create an index in each db

1 Creare in ogni DB il campo delay (in UK non c'è) e uniformarli ad uno standard comune: omogeneizzare i campi tra i paesi: calcolarlo al momento meglio che al tempo di query.

Create in each DB a field 'delay' (not in UK), and homogeneize between countries. Delay to be calculated when collected, better than all calculated together at query time

Peter : when you say 'delays', do you mean:

* A change in lateless, i.e. you are capturing the delay event; or

* Trains calling at stations after they were timetabled

Here in Great Britain, every delay event over 3 minutes requires investigation and is attributed to a manager / organisation and a 'cause code'.

2 inserire nel db giorno della settimana / Insert in the DB field 'day of the week'

3 inserire tipo ritardo (? valutare se necessario): caso "treno cancellato", o simbolo specifico. Se no, basta filtro nelle query

Insert maybe the kind of delay, if needed : cases of "cancelled train", or a specif symbol for this. If not, just a filter in the query

4. MASCHERA QUERY - QUERY MASK

Goals :

abilitate mask and structure for requests of query

organize the db for query, and enforce the db performance

 

Come si fa a fare query su 1 anno, per esempio una query su 6 DB di 400 Mo. / How to make query over 1 year data, for ex. a query on 6 DB of 40 Mo ?

Suggerisco di creare dei dati preaggregati (ritardo medio settimanale di un treno, ecc) e poi fare query su quelli. Poi aggiungere indici alle tabelle. - I suggest to create a DB with pre-aggregated data (like medium delay in a week, etc) ad then query this data. And add indexes to the DB tables.

Anche se alcuni dati possono essere reperiti altrove (RFI?) è utile averli in un data base diverso per poterli elaborare e incrociare senza dover chiedere e attendere eventuali autorizzazioni al gestore della rete.

Potrebbe essere anche utile poter incrociare il dato del numero del treno con il giorno della settimana e con il ritardo > di X min.

Inoltre potrebbe essere utile dare un worning di colore rosso sui ritardi che hanno superato i limiti che fanno scattare rimborsi ai passeggeri.

 

Queries :

Train number with weekday and delay.

Warning for delays over refund delay

 

Tappe - tasks:

0 confermare il tipo di query da fare prima > Raphael

double check the list of queries to be done before

1 somma ritardo cumulato per giorno nel paese

sum of days by day in the country

2 ritardo su tratte tipiche (o tutte) per giorno della settimana e treno su varie parti del paese

delay on typical lines (or all),by weekday and train, by region

2.1 menù a tendine partenza /arrivo.unfolding menu departure / arrival

2.1.1 Opzione: seconda lista a tendina che seleziona solo città compatibili con la prima. Cio' necessita trovare liste delle stazioni collegate su una stessa tratta: da trovare o da fare

Option : a 2d list with only arrival cities compatible with departure city. This requires to find a list of stations over a single train line : to find or to create

3 ritardi superiori a 15 min (custom) e categorie ritardo classificabile - delays over 15 mn(custom), or scales of delays (ie: 15-30mn, 30-59mn, ...)

4 query per numero del treno - query by train number

5. MONITOR THE SYSTEM

1. missione: "parametri di vita dei server" - "server life parameters"

1.1 info dati scritti all'ora -info ondata written by hour

1.2 info dati scritti complessivamente-info on data written since project start

1.3 info dati scritti giornalmente e ultimo dato scritto - info data written by day, and last data written

1.4 info sul peso dei dati e sullimite presente - info on size datas and limit

1.5 log / historic (identificare un problema successo in mattinata) - log / history (identify if there was a problem for ex. in early morning)

 

2.1 control stop & blackout : Controllo che il server di fonte sia attivo, altrimenti -> segnala malfunzionamento e non memorizzadati - invia mail alla riattivazione

Check that source server is active, if not > altert, don't register data in main DB - send mail when source server active again

2.2 controllo che il nostro server sia attivo (serve un cron esterno che se non ottiene risposta manda mail) -> intervento di ripristino in questo caso i dati nella finestra vengono persi

check that destination server is active (need external cron, that if do not get answer > sends mail) >human intervention -

2.3 per evitare ciò servirebbero due server su sistemi diversi, o che il controllore di funzionamento memorizzi in sotituzione i dati in caso di problema

The step 2.2 needs 2 different servers (or that ??)

 

3.1 controlla che il formato dei dati sia sempre lo stesso nel server fonte delle ferrovie altrimenti -> segnala (richiede intervento)

check that data format is always the same in source server, if not > altert

3.2 se no i dati nella finestra temporale vengono inesorabilmente persi -> per evitare ciò servirebbe di memorizzarli secchi se c'è il cambiamento ed elaborali dopo (bisogna verificare se possibile)

record the data that are not in the planned source format, so as to reprocess them afterwards

 

4. script per fare back up -potrebbe inviare (mail periodiche con file)

backup script - confirm with email

5. verifica di versione del nostro server, segnala cambio (da studiare ovh - meglio assistito che automatico pericolo). Rischio instabilita con nuove versioni.

check new server version. Risk of unstability with new server versions

6. CROWDFUNDING

> Raphael

1 Scelta piattaforma

2 Scrittura del progetto da sotto mettere al finanziamento

3 Promozione

7. FUTURE STEPS

1. SOAP

Anthony : SOAP, so as to open to a larger integration into various internet websites

Consider maybe a joomla and wordpress plugin, so as to facilitate integration, and involve these 2 CMS communities into the project

 

2. Graphical Visualisation

RRD Tools

other

 

3. plugin joomla and wordpress

To facilitate such integration and involve their communities

8. PLANNED CALENDAR / STIMA IMPLEMENTAZIONE

30 gg lavorativi circa dal 28 aprile al 28 maggio.

10 giorni scelta acquisto configurazione nuovo spazio. Implementazione nuovo db

10 gg realizzazione script, conversione dati precedenti funzioni di partizione in piu db

10 gg realizzazione monitor, configurazioni server pro monitor, test collaudi

i tempi soprattutto al dettaglio sono indicativi ad una stima approssimata, in verità il lavoro è unico e interconnesso poichè ogni parte dipende dall'altra, dal server e la parte più importante del lavoro non consiste nella realizzazione ma nell'affrontare e risolvere ogni eventuale problema incontrabile nella realizzazione.(funzionamento dei server, comunicazione tra i sistemi di controllo etc)

JOURNAL

12/11/14: Open Delays started in Italy,UK, Be

20/02/15: discussione Giuliano Samuel

30/03/15: discussione Giuliano Anthony

30/03/15: discussione Raphael Anthony

15/04/15: progetto generale +discussione Raphael Giuliano

26/04/15 : stima Giuliano sui tempi

28/04/15 : inizio lavoro Giuliano

02/05 : Simone e Raphael :considerare altri servers : hetzner, digital ocean, amazon. Mi mette in contatto con il dream team dei loro progetti.

06-07/05 : contributi Fabrizio e Simone sulla struttura del db, i server.

08/05 : Raphael e Giuliano : esame dei contributi di Fabrizio e Simone, su scelta del server,cambiamentialla struttura del db, rrdtools.

 

10/05: Raphael e Giuliano :riflessioni sulla scelta del server : 2 server (advania e register) che prendono i dati ciascuno, e fanno da monitor l'uno all'altro. Forse non amazon,perché lavoro in più per configurarlo, e perché va bene con server tradizionali. Ma se si può, si fa. Fabrizio e Simone sanno già configurarlo ?

 

21/05 : acquisto del server register.it

 

17/06/2015

calendario futuro:

script italia pronto

script belgio e uk (22 giugno)

cron (23 giugno)

creazione 24 db (eventualealtraripartizione singola) (23 giugno)

funzione valutazione peso ->cambiodb (calibrabile sul tempo) (23 giugno)

maschera ricerca (25 giugno)

monitor (a seguire 1 settimana)

 

Inizio giugno :

Struttura DATABASE scritta suregister,

dopo la discussione ho mantenuto la stessa struttura scelta da Samuel,

ho aggiunto il campo delay e il campoday (of the week) per migliorare

le future query su tutte le tabelle.+index.

Le tabelle mantengono le differenze originari dovute al tipo di dati alla sorgente.

Ad esempio gli inglesi hanno l'orario previsto e l'orario reale.

Questi mi fa propendere per mantenere una struttura dedicat per ogni tabella per

tenere le informazioni e non sprecare spazio allo stesso tempo (creando tabelle che potrebbero rimanere vuote).

Anche il data-time mi sembra (più economico in termini di spazio) ottimizzato.

Decidendo di creare un campo datatime in ogni tabella consumerebbe spazio ulteriore.

Puo essere ricreato a tempo di query opportunamente filtrando i dati con php o mysql.

Chiedo a tutti se condividete lascelta.

 

18/06/2015

script italiano tradotto in php e ottimizzato

script inglese tradotto in php e ottimizzato

script belgio tradotto in php

.....script belgio in ottimizzazione

RICHIESTA file CRON di Samuelpresentesu VPS

DOMANDA lo script inglese viene lanciato ogni 2ore e gli altri ogni ora ?

 

19/06/2015

....prossimo step connessione script al db

....lancio degli script con cron

script italiano tradotto in php e ottimizzato

script inglese tradotto in php e ottimizzato

script belgio tradotto in php e ottimizzato

Ottimizzazione: (guadagno velocità e secuzione)

italiano: formato dati json usolibrerie specializza json_decode

belgio: formato dati xmluso librerie specializza simplexml

inglese: formato dati pagina web parsing migliorato

In tutte e tre gli script il parsing è stato eseguito una sola volta su ogni pagina scaricata.

Nelle versioni su vps veniva eseguito su ogni riga di ogni pagina scarica

La velocità e la leggerezza degli script ne risulta notevolmente aumentata.

 

20/06/2015

script lanciati con cron (fase test)

scaricmento dati storici in corsoperreintegrazione

...prossimo passo fine test script e replicazione database X 25 con funzione trimestrale

...maschera di ricerca

...monitor

su github repereibili presto gli script php

https://github.com/OpenDelays/opendelays

 

25/06/2015

completamento test con cron -coerenzadati con script ovh

- belgio OK

- England OK

- Italia TESTING

rilevati errori in script OVH (non funzionanti tra 22-24 e il primo di ogni mese)

rilevati (rari) valori non attendibili in db ovh date > 2016

TEST di trasferimento file da OVH a REGISTER

 

27/06/2015

-------------------------------------------------------------------

FASE 2 COMPLETED

...................................................................

test TERMINATI SUI TRE SCRIPT e PRONTI A PARTIRE

ERRORI OVH

rilevate incongruenze dati neidati italia ovh (buchi e doppioni) (dovuto a lentezza script > 1h)

rilevata missing information (departure/arrive) in belgio dati ovh

performance attuali <15 min

Prossimo Step:

Definizione con Raphael scelta 2 alternative di db :

A unico db con 4 tabelle per le quattro sorgenti

B un databese per ogni nazione

A - VANTAGGI: risparmio spazio già pronto

SVANTAGGI perfomance basse, disomogenite e non controllo su peso tabelle (belgio = x italia = 2x inghilterra = 9x)

B - VANTAGGI elevate query performance, controllo peso singolo db

SVANTAGGI occupa spazio

morale : bisogna scegliere il giusto livello desiderato tra spazio e performance

domani al telefono decidiamo e in 1-2 possono partire gli script sui 24 db

prossimo step maschera ricerca

trasferimento dati

monitor

 

8/7/2015 : script ottimizzati presentati al gruppo: farne un jelkyll su github ?

22 24 o 23 00 per be e uk

treni it ora in più

circa 5mn dopo ogni ora: treni doppioni o treni saltati ?

10 000 righe ogni ora

come fare ricerche sull'insieme dei vari db ?

 

12/7/15:

decisione di acquisire il server islandese - acquisito

e poi si avvia il nuovo sistema, a giorni