CC0 e CC-BY
On Fri, 14 Oct 2011 11:09:52 +0200, Maurizio Napolitano wrote
CC0 e CC-BY
Che bello 
evidentemente la giornata di lavoro sugli Open Data
organizzata da GFOSS.it il 13 Aprile u.s. a Bologna
c/o Regione Emilia Romagna alla fine ha prodotto
frutti buoni, sani, succosi e saporiti.
Un bel GRAZIE in primis a Marica Landini ed a
Francesco Marucci che tanto si sono dati da fare
per organizzare l'incontro di Bologna e per
seguire pazientemente nei mesi tutto il processo.
Ma anche a tutti quei Soci di GFOSS che si sono
rimboccati le maniche ed hanno contribuito attivamente:
ovviamente Napo in primis (che ha saputo giocare
ottimamente un ruolo di assoluto rilievo), ma anche
Luca Delucchi, Ivan Marchesini, Flavio Rigolon e
Piergiovanna Grossi.
Infine voglio anche ringraziare i rappresentanti
delle associazioni "sorelle" che pure hanno portato
un contributo significativo e di rilievo: in
particolar Marco Ciurcina e Lorenzo Benussi.
Oggi è sicuramente un giorno felice e di gioia
per il movimento italiano del sw libero, ed in
particolare per la nostra associazione.
Ok, ora abbiamo la conferma che il "metodo Bologna"
funziona: la strada è ancora sicuramente lunga e
complessa, ma intanto abbiamo stabilito un precedente
significativo di successo.
ciao Sandro
(Presidente GFOSS.it)
Il 14/10/2011 11.38, a.furieri@lqt.it ha scritto:
On Fri, 14 Oct 2011 11:09:52 +0200, Maurizio Napolitano wrote
CC0 e CC-BY
Che bello
evidentemente la giornata di lavoro sugli Open Data
organizzata da GFOSS.it il 13 Aprile u.s. a Bologna
c/o Regione Emilia Romagna alla fine ha prodotto
frutti buoni, sani, succosi e saporiti.Un bel GRAZIE in primis a Marica Landini ed a
Francesco Marucci che tanto si sono dati da fare
per organizzare l'incontro di Bologna e per
seguire pazientemente nei mesi tutto il processo.Ma anche a tutti quei Soci di GFOSS che si sono
rimboccati le maniche ed hanno contribuito attivamente:
ovviamente Napo in primis (che ha saputo giocare
ottimamente un ruolo di assoluto rilievo), ma anche
Luca Delucchi, Ivan Marchesini, Flavio Rigolon e
Piergiovanna Grossi.Infine voglio anche ringraziare i rappresentanti
delle associazioni "sorelle" che pure hanno portato
un contributo significativo e di rilievo: in
particolar Marco Ciurcina e Lorenzo Benussi.Oggi è sicuramente un giorno felice e di gioia
per il movimento italiano del sw libero, ed in
particolare per la nostra associazione.Ok, ora abbiamo la conferma che il "metodo Bologna"
funziona: la strada è ancora sicuramente lunga e
complessa, ma intanto abbiamo stabilito un precedente
significativo di successo.ciao Sandro
(Presidente GFOSS.it)
Davvero una gran bella notizia! Complimenti a tutti coloro che hanno
contribuito in qualche modo al successo dell'iniziativa.
ciao
Antonio
--
Antonio Falciano
http://www.linkedin.com/in/antoniofalciano
Il 10/14/2011 11:38 AM, a.furieri@lqt.it ha scritto:
On Fri, 14 Oct 2011 11:09:52 +0200, Maurizio Napolitano wrote
CC0 e CC-BY
Che bello
evidentemente la giornata di lavoro sugli Open Data
organizzata da GFOSS.it il 13 Aprile u.s. a Bologna
c/o Regione Emilia Romagna alla fine ha prodotto
frutti buoni, sani, succosi e saporiti.
Concordo con quello che dice Alessandro, pero' credo
ci siano da fare due precisazioni.
Sicuramente RER aveva gia' in mente questa operazione
ma lo hanno fatto con i giusti passi.
Prima hanno guardato chi ha fatto esperienze simili
nella P.A. (se fate attenzione il portale e' quello
del Piemonte), e poi ha dialogato con le associazioni
che si interessano della tematica.
Inoltre sono partiti con dei dati veramente "potenti",
ovvero i geodati.
Aggiungo una informazione:
ho fatto due considerazioni sul mio blog in seguito
alla scelta delle licenze RER (ottima scelta).
Onde evitare scene di "divismo" scrivo qui due
riferimenti.
A livello europeo c'e' una direttiva sul riuso
dell'informazione del settore pubblico, la nota
direttiva PSI (recepita poi dal C.A.D. italiano)
Su questa direttiva ci sono molti progetti europei.
Fra questi epsi platform.
Quest'ultimo organizza una serie di Workshop.
Fra questi uno sulle licenze open data e questa
direttiva.
Jordan Hatcher (di OKFN e autore della licenza
ODbL - quella che sara' adottata da osm) ha
fatto cosi' questa presentazione
http://www.slideshare.net/epsiplatform/hatcher
Consiglio di prendere visione della slide 17
e della slide 18
La slide 17 presenta lo schema delle licenze
opendata dove - grazie ai dialoghi fra okfn
e creative commons - le licenze CC vengono
messe sullo stesso piano anche per il
problema del diritto sui generis (questione
che sara' risolta nella versione 4 delle cc).
Lo schema presenta le 3 categorie di licenze
che rientrano nella definizione di open data
quindi:
- pubblico dominio
- attribuzione
- condivisione allo stesso modo
La slide 18 mette in evidenza quali sono
le licenze che meglio interpretano il
concetto di riuso della direttiva PSI
e ... la terza categoria e' esclusa.
Di questo ne sono molto convinto.
Il concetto di "condivisione allo stesso modo"
si applica benissimo al software e ai dati che
devono proteggere la comunità che e' andata a
produrli (es. osm), ma per il resto i dati sono
un qualcosa di completamente diverso dal software
e difficili da tracciare.
Il mutamento di un dato non e' cosi' complesso
come quello di un software.
... so che potremmo discuterne assai, quindi mi fermo qui.
dopo tanti complimenti, ora è l'ora delle
prime critiche (costruttive) 
A) lo SHP "edifici" è una vera balenottera
il DBF eccede la "taglia critica" di 2GB
probabilmente sarebbe più opportuno spezzarlo
in più parti distinte (p.es. per provincia)
B) nelle Rilevazioni Annuali della Popolazione
non trovo traccia del 1992; c'è il '91 e pure
il '93, ma il '92 manca
inoltre la distribuzione consiste in uno zip
che contiene una ventina di ulteriori zip:
per nulla pratico 
infine la domanda da un milione di dollari:
bene i confini amministativi e le impronte dei
centri abitati, decisamente ottimi e dettagliatissimi
gli edifici.
ma le curve di livello ?
e l'idrografia ?
e le strade e ferrovie ?
[si, lo so, me lo dico da solo: sono un gran
rompi..glioni, magari anche un po' antipatico ...]
ciao Sandro
On Fri, 14 Oct 2011 15:27:53 +0200, a.furieri wrote
dopo tanti complimenti, ora è l'ora delle
prime critiche (costruttive)
altre due segnalazioni (sperando che servano):
C) tra i dati della Popolazione per il 2003 invece del file CSV ci
trovo un "fregno buffo" binario assolutamente inutilizzabile.
dal suffisso "strano" sembrerebbe un file per SAS 
D) il mega-SHP "edifici" viene distribuito compresso come RAR:
scelta quanto mai poco opportuna.
è vero che RAR è largamente diffuso e ben supportato:
resta il fatto che è un formato proprietario e chiuso.
7Zip è completamente free ed è aperto dall'A alla Z:
non è meno supportato, ed in compenso è pure
più efficiente ("strizza" qualcosina in più)
perchè usare un formato chiuso quando ce n'è a
disposizione uno aperto equivalente se non migliore ?
ciao Sandro
On Fri, 14 Oct 2011 15:27:53 +0200, a.furieri wrote
dopo tanti complimenti, ora è l'ora delle
prime critiche (costruttive)A) lo SHP "edifici" è una vera balenottera
il DBF eccede la "taglia critica" di 2GB
probabilmente sarebbe più opportuno spezzarlo
in più parti distinte (p.es. per provincia)
Ulteriori problemi con gli Edifici:
- il loader di SpatiaLite segnala errore
(e si pianta)
- ma anche ogr2ogr segnala oltre 1.000
errori severi nel DBF (però prosegue)
- QGIS sembra che visualizzi tutte le features:
ma la quasi totalità degli edifici di Parma
e Piacenza appaiono con gli attributi
completamente vuoti
insomma, direi che questo SHP andrebbe
verificato in modo più approfondito: così
com'è nello stato attuale pare abbastanza
problematico e decisamente poco utilizzabile
ciao Sandro
On Fri, 14 Oct 2011 21:39:55 +0200, a.furieri wrote
dopo tanti complimenti, ora è l'ora delle
prime critiche (costruttive)
mi accorgo solo ora che in tutti gli SHP c'è una
gran bella "farfallona" grossa come una casa
[fesso io a non avere controllato subito]
A) per ogni SHP c'è il corrispondente .PRJ che recita;
"ETRS_1989_UTM_Zone_32N": quindi SRID=25832
B) poi c'è anche un file "metadata.xml", che invece recita:
...
<gmd:RS_Identifier>
<gmd:code>
<gco:CharacterString>ROMA40/OVEST</gco:CharacterString>
</gmd:code>
<gmd:codeSpace>
<gco:CharacterString>...EPSG::3003</gco:CharacterString>
</gmd:codeSpace>
</gmd:RS_Identifier>
...
quindi parrebbe SRID=3003
Sorpresa finale (spiacevole): ma le coordinate fisicamente
presenti in effetti sono GEOGRAFICHE (lat/long), quindi
parrebbe apparentemente SRID=4326
Insomma, quale è il Sistema di Riferimento Spaziale "vero"
utilizzato per produrre gli Shapefile ???
direi che si tratta di un'anomalia abbastanza grave, e che
andrebbe sanata al più presto.
ciao Sandro