Stiamo lavorando sul dato più aggiornato?

[dagoneye]

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]

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]

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

[scarsellifi]

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]

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:

• con -s_srs EPSG:32632 imposti il sistema di coordinate del file di input
• con -t_srs EPSG:4326 quello di output
• con -lco GEOMETRY=AS_XY gli chiedi di avere esportate le colonne geometriche in output
• con -f CSV il formato di output
• con -oo X_POSSIBLE_NAMES=lon -oo Y_POSSIBLE_NAMES=lat imposti quali sono le colonne con le coordinate nel file di input

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

[scarsellifi]

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]

@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]

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
#5 (comment)

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]

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]

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]

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? :)