16/05/2020 @23:00 - P.A. Trento e P.A. Bolzano - modifica/change codice_regione

[umbros]

[IT]
Ciao,
attualmente P.A. Trento e P.A. Bolzano hanno lo stesso codice_regione (04) - Trentino Alto Adige, la prossima modifica prevederà il cambio codice_regione da 04 a 21 per P.A. Bolzano e da 04 a 22 per P.A. Trento assumendo, di fatto, il codice provincia come da elenchi ISTAT (https://www.istat.it/it/archivio/6789).

File impattati: json regioni, province, note e dataset dati-regioni, dati-province e note.

La modifica sarà applicata alle 23:00 di sabato 9 maggio allineando tutti i dati ai nuovi codici.

Vi chiediamo, quindi, di allineare i vostri sistemi qualora facciano uso del codice_regione.

[EN]
Hi,
currently P.A. Trento and P.A. Bolzano have the same region_code (04) - Trentino Alto Adige Region, but in Italy they are trated as region (Autonomous Province), the next change will change the region_code from 04 to 21 for P.A. Bolzano and from 04 to 22 for P.A. Trento assuming, in fact, the province code as per ISTAT lists (https://www.istat.it/it/archivio/6789).

Impacted files: json regioni, province, note e dataset dati-regioni, dati-province e note.

The change will be applied at 23:00 on Saturday 9 May, aligning all data with the new codes.

We ask you to align your systems if they use the region_code.

[paxtibi]

Grazie dell'avviso :)

[miccoli]

Capisco il desiderio di correggere una scelta iniziale infelice, ma cambiare il formato dei dati in corsa è sempre una pessima idea: si romperanno inutilmente gli script di tanti sviluppatori, che ormai si erano adattati formato.

Il nuovo formato è inoltre inconsistente, perché mescola nella stessa colonna due codici ISTAT differenti: il "Codice Regione" con il "Codice Provincia".

[umbros]

@miccoli daccordissimo ma abbiamo riscontrato che se si dovesse mettere una chiave lavorare con la descrizione non è cosa opportuna e la doppia chiave basterebbe codice + data. Abbiamo dato in anticipo l'informazione, purtroppo salta comunque il match perchè a quel codice corrispondo, di fatto, 2 regioni (P.A. Trento e P.A. Bolzano). Speriamo prima o poi si risolva tale situazione.

[downFast]

Personalmente avevo risolto unificando le due in Trentino alto adige e ho tagliato corto, grazie comunque. Lavorando dal nome e non sul codice.

Una domanda @umbros mi pare di capire che le note da stasera saranno quindi inserite come oggetto in ogni json, ho capito bene? E queste note saranno disponibili anche nello storico e non solo nell'ultimo latest? Grazie mille

[umbros]

@downFast sarà tutto allineato con i codici comprese le note

[downFast]

@downFast sarà tutto allineato con i codici comprese le note

Ok grazie. Ripeto, nel mio caso non fa niente, perchè avevo già risolto nel bene e nel male. Per le note vediamo più tardi. Confido in voi. Grazie

[umbros]

Ciao le note sono sia in csv che json già ora, il json oltre la rilasciare questa versione ne stiamo preparando una più ottimizzata che rispecchia le API su cui stiamo lavorando

[downFast]

Ciao le note sono sia in csv che json già ora, il json oltre la rilasciare questa versione ne stiamo preparando una più ottimizzata che rispecchia le API su cui stiamo lavorando

Ciao, nel mio caso il csv non è importante, mi riferisco al json. Qui le note si ci sono ma sono sempre vuote o sbaglio? https://github.com/pcm-dpc/COVID-19/blob/master/dati-json/dpc-covid19-ita-regioni.json

[miccoli]

@miccoli daccordissimo ma abbiamo riscontrato che se si dovesse mettere una chiave lavorare con la descrizione non è cosa opportuna e la doppia chiave basterebbe codice + data.

Non capisco. Per ISTAT il "codice regione" è il "codice regione" e il "codice provincia" è il "codice provincia". La nuova codifica che state introducendo è unica di questa repo. Sarebbe fondamentale a questo punto cambiare intestazione e farla diventare "codice_regione_provincia" o qualcosa di simile.

Abbiamo dato in anticipo l'informazione, purtroppo salta comunque il match perchè a quel codice corrispondo, di fatto, 2 regioni (P.A. Trento e P.A. Bolzano). Speriamo prima o poi si risolva tale situazione.

Quattro giorni di preavviso è nulla.

La best practice vorrebbe che se si cambia formato si dichiara quello vecchio obsoleto e lo si lascia vivo e attivo per un tempo sufficiente (almeno 30 giorni) perché tutti si accorgano che è stato deprecato e si abbia tempo per la transizione verso il nuovo formato, che deve avere un nome diverso da quello vecchio.

Comunque a me state provocando grossi problemi, proprio perché essendoci uno switchover il sabato alle 23:00 senza un overlap tra il vecchio formato e quello nuovo mi costringete a modifiche al volo in un timeframe strettissimo.

[umbros]

ciao @downFast ci sono i codici note in Regione.
Ciao @miccoli, possiamo tranquillamente spostarla alla settimana prossima non è un problema, ma se le due province (Trento e Bolzano) agiscono come due regioni, motivo per cui viene dato il dato per P.A. Trento e P.A. Bolzano e non come Trentino Alto Adige in qualche modo bisogna operare. Quindi per noi ok a spostarla di una settimana ma l'attività la riteniamo utile da farsi, rispetto a creare due versioni la cosa è fattibile ma avrebbe due naming diversi.

[miccoli]

@umbros Grazie per la considerazione delle mie osservazioni. Adesso non ho tempo, ma domani posso scrivere per esteso come potrebbe essere organizzata la repo.

PS: come tutti ritengo il servizio che fornite molto importante. GRAZIE.

[umbros]

Grazie a te per la collaborazione! :-)

[miccoli]

Per questa issue, ecco alcuni punti che secondo me potrebbero essere utili.

• definire un numero di versione formato, possibilmente secondo il semantic versioning in modo che sia più facile verificare la compatibilità. Il formato attuale potrebbe essere 1.0.0, quello nuovo 2.0.0

• riportare il numero di versione formato nei file json.

• i file csv potrebbero essere identificati dal nome della cartella, per esempio

  dati-province-v1_0_0
  dati-province-v2_0_0
  

  la cartella dati-province dovrebbe essere un link simbolico al formato corrente.

• non prevedere uno switch-off netto del formato 1.0.0 ma prevedere uno switch-over nel quale entrambi i formati sono supportati e aggiornati.

• se lo switch-over è troppo oneroso, pubblicare almeno alcuni file di esempio per testare gli script prima dello switch-off definitivo.

• da ultimo trattandosi di una scelta non retro-compatibile, la colonna nel nuovo formato deve avere un nome differente da quella vecchia per evitare confusioni. Dunque codice_regione potrebbe diventare codice_regione_provincia o qualcosa di simile.

Se posso esprimere un parere, un'altra possibilità per il formato 2.0.0 potrebbe essere:

data,stato,codice_regione,codice_provincia,denominazione_regione,...
2020-05-11T17:00:00,ITA,13,,Abruzzo,...
2020-05-11T17:00:00,ITA,17,,Basilicata,...
2020-05-11T17:00:00,ITA,04,21,P.A. Bolzano,...
...
2020-05-11T17:00:00,ITA,04,22,P.A. Trento,...
...

cioè una nuova colonna, vuota per tutte le regioni e con il codice provincia per le province autonome. Questo formato, cambiando il numero di colonne, ha lo svantaggio di non essere compatibile con tutti quegli script che assumono una posizione prefissata dei vari campi, e non leggono le intestazioni di colonna.

(E comunque, il formato attuale è andato bene fino ad adesso: quello nuovo non mi sembra porti vantaggi così decisivi da giustificare tutto questo lavoro per la transizione.)

[anbened]

Per questa issue, ecco alcuni punti che secondo me potrebbero essere utili.

• definire un numero di versione formato, possibilmente secondo il semantic versioning in modo che sia più facile verificare la compatibilità. Il formato attuale potrebbe essere 1.0.0, quello nuovo 2.0.0

• riportare il numero di versione formato nei file json.

• i file csv potrebbero essere identificati dal nome della cartella, per esempio

  dati-province-v1_0_0
  dati-province-v2_0_0
  

  la cartella dati-province dovrebbe essere un link simbolico al formato corrente.

• non prevedere uno switch-off netto del formato 1.0.0 ma prevedere uno switch-over nel quale entrambi i formati sono supportati e aggiornati.

• se lo switch-over è troppo oneroso, pubblicare almeno alcuni file di esempio per testare gli script prima dello switch-off definitivo.

• da ultimo trattandosi di una scelta non retro-compatibile, la colonna nel nuovo formato deve avere un nome differente da quella vecchia per evitare confusioni. Dunque codice_regione potrebbe diventare codice_regione_provincia o qualcosa di simile.

Se posso esprimere un parere, un'altra possibilità per il formato 2.0.0 potrebbe essere:

data,stato,codice_regione,codice_provincia,denominazione_regione,...
2020-05-11T17:00:00,ITA,13,,Abruzzo,...
2020-05-11T17:00:00,ITA,17,,Basilicata,...
2020-05-11T17:00:00,ITA,04,21,P.A. Bolzano,...
...
2020-05-11T17:00:00,ITA,04,22,P.A. Trento,...
...

cioè una nuova colonna, vuota per tutte le regioni e con il codice provincia per le province autonome. Questo formato, cambiando il numero di colonne, ha lo svantaggio di non essere compatibile con tutti quegli script che assumono una posizione prefissata dei vari campi, e non leggono le intestazioni di colonna.

(E comunque, il formato attuale è andato bene fino ad adesso: quello nuovo non mi sembra porti vantaggi così decisivi da giustificare tutto questo lavoro per la transizione.)

Ciao @miccoli
Ragionamenti interessanti però, forse, l'effort diventa davvero più oneroso per tutti rispetto al solo cambio di codice

Ogni meccanismo di ingestion dei dati deve essere rivisto e da subito (se viene a modificarsi anche il nome file della prima versione)

Grazie per gli scambi di opinione
Andrea

[Rabelaiss]

Per chi usa matlab basta fare

data = readtable('dpc-covid19-ita-regioni.csv');
bolzano = strcmp(data.denominazione_regione, 'P.A. Bolzano');
trento  = strcmp(data.denominazione_regione, 'P.A. Trento');
casi_trentino = data.totale_casi(bolzano) + data.totale_casi(trento);

analogamente per decessi ecc.

[paxtibi]

@Rabelaiss Nel mio caso ho messo in chiave della tabella sia data, codice e nome della regione.
Estraggo i dati sommati e raggruppati per codice regione. Con sql ancora meno sbattimento.

Leggo il commento di @miccoli che definisce errata la scelta iniziale. Non concordo con la sua opinione. La scelta è basata sui codici Istat. Quelli sono. Che poi Bolzano e Trento facciano diversamente perchè ... (mi vengono in mente solo cose che non posso scrivere) non è responsabilità di @umbros o della protezione civile, ma delle due amministrazioni che fanno come meglio comoda a loro.

Se posso contribuire, dopo mesi, le metodologie di caricamento dei dati della protezione civile da parte di altri sviluppatori sono rodate e funzionanti. Immagino che non sia un problema adattarsi ad un eventuale nuovo formato dei dati, qualora fosse introdotto.

Al posto di introdurre codici forzati (visto che si promuove il codice provincia a codice regione) o introdurre un sacco di omossis per tutti i record eccetto due, si portebbe usare la il codice catastale del comune capoluogo. Per quelli l'Istat assegna un codice (e nel link iniziale si possono trovare).
Esempio

data,stato,codice_regione,codice_fiscale_capoluogo_regione,denominazione_regione,...
2020-05-11T17:00:00,ITA,13,A345,Abruzzo,...
2020-05-11T17:00:00,ITA,17,F052,Basilicata,...
2020-05-11T17:00:00,ITA,04,A952,P.A. Bolzano,...
2020-05-11T17:00:00,ITA,04,L378,P.A. Trento,...
...

In questo modo si eviterebbe di inserire dati "forzati" (perdonate il termine), e usare codici che Istat emette senza snaturarli o lasciare un sacco di "buchi".

Altra opzione. Mettere il codice della provincia che ospita il capoluogo di regione. Penso a Milano, Venezia, Torino per citarne alcune. (Detesto gli omissis nei record, credo si sia notato) :)

data,stato,codice_regione,codice_provincia_con_capoluogo_di_regione,denominazione_regione,...
2020-05-11T17:00:00,ITA,13,66,Abruzzo,...
2020-05-11T17:00:00,ITA,17,77,Basilicata,...
2020-05-11T17:00:00,ITA,04,21,P.A. Bolzano,...
2020-05-11T17:00:00,ITA,04,22,P.A. Trento,...
...

[miccoli]

Leggo il commento di @miccoli che definisce errata la scelta iniziale. Non concordo con la sua opinione. La scelta è basata sui codici Istat. Quelli sono. Che poi Bolzano e Trento facciano diversamente perchè ... (mi vengono in mente solo cose che non posso scrivere) non è responsabilità di @umbros o della protezione civile, ma delle due amministrazioni che fanno come meglio comoda a loro.

Alcuni commenti.

• Non ho detto scelta errata, ho detto "infelice". Mi sembra di capire che quello che non piace è avere due righe con lo stesso codice numerico. Se non piace oggi, vuol dire che la scelta è stata infelice ieri. Se il formato attuale andasse bene, perché cambiarlo? Ribadisco per l'ennesima volta che secondo me a questo punto è molto meglio lasciare tutto come sta, visto che il miglioramento è solo marginale, ma con ripercussioni potenzialmente pesanti su chi ha già organizzato i propri script sul formato attuale.

• Le province non sono più l'unica divisione amministrativa intermedia tra regioni e comuni. Ci sono le "Città Metropolitane", i "Liberi consorzi", le "Province", le "Province Autonome". In Friuli Venezia Giulia le province non esistono più a livello amministrativo, ma solo a livello statistico... vedi https://www.istat.it/it/archivio/6789 La confusione è totale e non è colpa di nessuno di quelli che lavorano qui.

Concordo però con @paxtibi quando dice

Al posto di introdurre codici forzati (visto che si promuove il codice provincia a codice regione) o introdurre un sacco di omossis per tutti i record eccetto due, si portebbe usare la il codice catastale del comune capoluogo.

Alla fine la codifica numerica da utilizzare per questo elenco eterogeneo di sistemi sanitari decentrati autonomi l'uno dall'altro è solo una questione di gusto.

Secondo me però è importante capire che la proposta ibrida regioni-province di questa issue (anche se apparentemente quella a costo minore) è quella che causa maggiore confusione. La mia esperienza è che quando bisogna cambiare un formato in maniera non retro-compatibile, la modifica deve essere "forte". Con modifiche minime il rischio è che alcuni programmi continuino a funzionare, ma producendo risultati sbagliati. Se la modifica è abbastanza forte, invece, succede che tutto si ferma, tutti si arrabbiano, ma almeno dopo poco tutti hanno di nuovo risultati corretti.

La decisione di come procedere è ovviamente degli amministratori di questa repo... noi ci adegueremo; vorrei solo capire quale è il motivo di questi cambiamenti.

[miccoli]

@anbened Io pensavo a questa sequenza:

switch over

dati-regioni-v1_0_0
dati-regioni-v2_0_0
dati-regioni → dati-regioni-v1_0_0

Tutto funziona come prima; abbiamo tempo per testare il nuovo formato e per passare ai formati versioned.
Viene definita una data di switch-off.

switch off

dati-regioni-v2_0_0
dati-regioni → dati-regioni-v2_0_0

Molto lavoro? Sì, molto lavoro. Ma è un modo per evitare lo switch-off diretto e senza pietà.

[umbros]

Ciao @miccoli
corretta e ti ringrazio per la segnalazione,
la proposta è la seguente:

• directory legacy
• dati regioni
• dati province
• dati andamento nazionale
• dati json

da sabato a venerdì prossimo (22/05/2020) terremo la cartella legacy che conterrà i codici "regione" su P.A. Trento e P.A. Bolzano (gli attuali dataset) con gli stessi nomi e stesse cartelle, in sostanza negli script basterà aggiugere la cartella davanti al file.

Che ne pensate?

[miccoli]

Ciao @miccoli
corretta e ti ringrazio per la segnalazione,
la proposta è la seguente:

• directory legacy
• dati regioni
• dati province
• dati andamento nazionale
• dati json

da sabato a venerdì prossimo (22/05/2020) terremo la cartella legacy che conterrà i codici "regione" su P.A. Trento e P.A. Bolzano (gli attuali dataset) con gli stessi nomi e stesse cartelle, in sostanza negli script basterà aggiugere la cartella davanti al file.

Che ne pensate?

@umbros quello che decidi tu va bene, l'importante è tenere il feed di dati vivo. Grazie per l'attenzione ai miei commenti.

[anbened]

Ciao @miccoli
corretta e ti ringrazio per la segnalazione,
la proposta è la seguente:

• directory legacy
• dati regioni
• dati province
• dati andamento nazionale
• dati json

da sabato a venerdì prossimo (22/05/2020) terremo la cartella legacy che conterrà i codici "regione" su P.A. Trento e P.A. Bolzano (gli attuali dataset) con gli stessi nomi e stesse cartelle, in sostanza negli script basterà aggiugere la cartella davanti al file.
Che ne pensate?

@umbros quello che decidi tu va bene, l'importante è tenere il feed di dati vivo. Grazie per l'attenzione ai miei commenti.

@miccoli @umbros ok per la proposta, c'è tutto il tempo di adeguarsi

Grazie a tutti

[umbros]

Modifiche effettuate - fino al 22 maggio 2020, nella cartella legacy-data, saranno caricati i dati giornalieri con i codice_regione 04 per P.A. Bolzano e P.A. Trento che da oggi assumeranno il nuovo valore codice_regione 21 per P.A. Bolzano e 22 per P.A. Trento

Changes made - until 22 May 2020, in the legacy-data folder, the daily data will be loaded with the codice_regione 04 for P.A. Bolzano and P.A. Trento. From now on they will assume the new value codice_regione 21 for P.A. Bolzano and 22 for P.A. Trento

Grazie a tutti - Thanks to all

[miccoli]

La modifica non è ancora stata registrata in CHANGELOG.md

[umbros]

Aggiornamento caricato su changelog, da oggi i dati legacy non verranno aggiornati in beta come da timeline definita. La cartella data-legacy verrà tenuta fino a domani 24 maggio 2020, da lunedì la cartella non sarà più accessibile.

Grazie a tutti per la collaborazione