search

spaghetti-open-data / code4health-amianto

Code4Health Amianto esplora nuovi modi per aiutare il data journalism dietro le inchieste sull'amianto in Italia
4 stars 2 forks source link

Stiamo lavorando sul dato più aggiornato? #5

Open dagoneye opened 8 years ago

dagoneye commented 8 years ago

Questa la apro come remind, da verificare. Ovvero, se prendo il dataset dal ministero dell'ambiente, e le cartelle esplose: https://github.com/spaghetti-open-data/code4health-amianto/tree/master/dati/MinAmbiente/PNA_W

Come faccio a sapere che il resto dei dati sul livello regionale sia più aggiornato? Premesso che aggregare e rendere coerenti quei dati (del ministero dell'ambiente), sarebbe già utile di suo.

dagoneye commented 8 years ago

Lo inserisco come nota condivisa, poi vedo di documentarlo meglio nel wiki: https://groups.google.com/d/msg/spaghettiopendata/jVvrNbUE-DE/Big6ybzwAwAJ

Le note di Davide Mancino sul lavoro fatto per Wired sono un pezzo fondamentale della storia.

dagoneye commented 8 years ago

Ho aggiornato il wiki con le note principali segnalate da Davide, da capirne i dettagli e le implicazioni.

scarsellifi commented 8 years ago

Secondo ci sono buone possibilità che i dati del ministero dell'ambiente siano realmente più aggiornati di quelli regionali. Almeno in Toscana i casi Arpat sono più numerosi di quelli del ministero (ultima tabella https://github.com/scarsellifi/code4health-amianto/blob/master/dati/RegioneToscana/Creazione%20database%20Toscana.ipynb ). Bonifiche effettuate fra il 2007 e il 2013? Mancanze nel database del ministero? Qualche edificio comune fra i due database è facilmente individuabile per la combinazione comune - superficie coperta dall'amianto. Sarebbe interessante provare migliorando la geolocalizzazione dei dati toscani da una parte (OSM permette una localizzazione non perfetta del 60% dei casi) e, almeno per me, capire come funziona il WGS84-UTM fuso 32 dei dati ministero (mi manca la normale longitudine e latitudine :) ) Se riesco ad averli con lo stesso riferimento spaziale forse riesco ad individuare qualche caso mancante:)

aborruso commented 8 years ago

ciao @scarsellifi un nota sul WGS84-UTM fuso 32.

Se non sbaglio sei cintura nera di R e con R puoi dialogare con GDAL/OGR, la libreria più importante per gestire dati spaziali.

Il passaggio da WGS84-UTM UTM fuso 32 a Lat Lon WGS 84 lo puoi fare in questo modo.

File input (scusa per i nomi delle colonne, era meglio chiamarle easting e northing e non lat e lon):

ID,lon,lat
1,938176,4530920
2,939167,4530920
3,948248,4533214

comando GDAL/OGR

ogr2ogr -s_srs EPSG:32632 -t_srs EPSG:4326 -lco GEOMETRY=AS_XY -f CSV output.csv  input.csv -oo X_POSSIBLE_NAMES=lon -oo Y_POSSIBLE_NAMES=lat

File di output:

X,Y,ID,lon,lat
14.1943272531235,40.8122846953853,1,938176,4530920
14.2060288413423,40.8117558492993,2,939167,4530920
14.3148881570619,40.8274313354677,3,948248,4533214

Alcune note:

Questo è uno dei modi per avere latitudine e longitudine a partire dai file di input.

scarsellifi commented 8 years ago

Grazie mille @aborruso !! Di R sono solo cintura gialla e lo vorrei usare solo in caso di necessità:) Grazie alle tue indicazioni però ho googlato molto meglio ed ho trovato questa libreria di Python che sembra interessante. https://pypi.python.org/pypi/utm e che nasconde la complessità dell'operazione in una riga di codice.


# esempio `14.1943272531235,40.8122846953853,1,938176,4530920` 
import utm
utm.to_latlon(938176,4530920, 32, 'N')

Out[65]:
(40.812285742451806, 14.194339232964339)

Rispetto al tuo esempio però il risultato comincia a differire alla quinta cifra decimale: è molto (è troppo) come approssimazione per un edificio?

aborruso commented 8 years ago

@scarsellifi dovrebbero essere un paio di metri. Ma in ogni caso chissà quale fosse la procedura di acquisizione dei dati originali.

Quindi usa pure la tua riga di Python al posto della mia riga da shell!

ecor commented 8 years ago

Ciao a tutti,

su R c'e' la funzione spTransform + le tolols del pacchetto sp e rgdal.

http://www.inside-r.org/packages/cran/rgdal/docs/spTransform

un saluto e a piu' tardi

Emanuele

Il giorno 24 maggio 2016 16:07, Marco Scarselli notifications@github.com ha scritto:

Grazie mille @aborruso https://github.com/aborruso !! Di R sono solo cintura gialla e lo vorrei usare solo in caso di necessità:) Grazie alle tue indicazioni però ho googlato molto meglio ed ho trovato questa libreria di Python che sembra interessante. https://pypi.python.org/pypi/utm e che nasconde la complessità dell'operazione in una riga di codice.

esempio 14.1943272531235,40.8122846953853,1,938176,4530920

import utm utm.to_latlon(938176,4530920, 32, 'N')

Out[65]: (40.812285742451806, 14.194339232964339)

Rispetto al tuo esempio però il risultato comincia a differire alla quinta cifra decimale: è molto (è troppo) come approssimazione per un edificio?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/spaghetti-open-data/code4health-amianto/issues/5#issuecomment-221282054

Emanuele Cordano, PhD Environmental Engineer / Ingegnere per l' Ambiente e il territorio nr. 3587 (Albo A - Provincia di Trento) cell: +39 3282818564 email: emanuele.cordano@gmail.com,emanuele.cordano@rendena100.eu, emanuele.cordano@eurac.edu PEC: emanuele.cordano@ingpec.eu URL: www.rendena100.eu

dagoneye commented 8 years ago

Aggiungo un feedback appena arrivato da Davide Mancino sui dati dell'inchiesta di Wired aggiornati a dicembre 2015: dati segnalati via twitter

ll lavoro che ho fatto con i dati del 2013 è stato essenzialmente unire tutti i file excel in un unico database e poi dividere i dati in due tronconi: 1) Quelli per cui erano disponibili coordinate geografiche (comunque una minoranza), che poi sono quelli della mappa pubblicata qui. L'unica altra operazione che ho fatto in QGIS è stata eliminare i punti palesemente assurdi, tipo quelli che comparivano in Tunisia o in Iran, ma per il resto li ho messi su com'erano

2) Quelli per cui non erano disponibili le coordinate, che invece ho usato per le altre visualizzazioni dell'articolo andando a integrare le regioni mancanti del 2010 o aggiungendo i censimenti più dettagliati di piemonte e lombardia.

dagoneye commented 8 years ago

Ho aggiunto una cartella in /dati/Wired-dicembre2015 con il file a cui si riferisce Davide, è sicuramente da guardare: buttando un occhio sulla colonna "Fonte", si capisce che ha integrato l'integrabile.

`csvstat siti_contaminati_da_amianto_aggregati_per_regione-tutti_i\ censimenti.csv

  1. ID <type 'int'> Nulls: False Min: 1 Max: 84906 Sum: 3604556871 Mean: 42453.5 Median: 42453.5 Standard Deviation: 24510.2509762 Unique values: 84906
  2. Comune <type 'unicode'> Nulls: False Unique values: 3241 5 most frequent values: Vercelli: 2300 Alessandria: 1734 Torino: 1367 Casale Monferrato: 1133 Brescia: 1093 Max length: 50
  3. Classe di priorità <type 'unicode'> Nulls: False Unique values: 6 5 most frequent values: Informazione sconosciuta: 59073 Basso: 10693 Medio: 7554 Alto: 5344 Molto basso: 1937 Max length: 24
  4. Fonte <type 'unicode'> Nulls: False Values: Arpa Lombardia, 2015, Ministero dell'Ambiente, mappatura amianto 2013, Arpa Piemonte, dati aggiornati al 21/09/2015, Ministero dell'Ambiente, mappatura amianto 2010
  5. Area di riferimento <type 'unicode'> Nulls: False Unique values: 19 5 most frequent values: Piemonte: 32422 Lombardia: 26006 Marche: 12248 Abruzzo: 2339 Sardegna: 1966 Max length: 29

Row count: 84906`

Oltre 84k righe, rispetto alle 20k e rotti dell'inchiesta di Wired di aprile 2015.

dagoneye commented 8 years ago

Ho aggiornato il file readme del dataset aggregato fatto da Wired in /dati/Wired-dicembre2015, ora è più semplice capire cosa è stato aggregato, e rispondere alla domanda: quali sono i dati aggiornati? :)