Portale Open Data del Comune di Roma

[Alessio 'Blaster' Biancalana]

Ciao spaghettari,

http://dati.comune.roma.it/

Qui il portale open data del comune di Roma. Che ne pensate? Iniziativa fuffa-based o c'è sotto qualcosa di buono?

Ale

[Alfredo Serafini]

beh è un inizio, quindi guardiamolo con ottimismo!

A me dispiace che tutti sistematicamente pubblichino csv e molto pochi ragionino in prospettiva linked (da cui si potrebbe tornare su un qualche csv, mentre il viceversa è non banale)

[Luca Corsato]

ci sto proprio ora dando un'occhiata.
Intanto non è fatto da CSI Piemonte ;-) a parte le battute, non riesco a capire se dietro c'è ckan o qualche altro datahub.
Interessanti alcune scelte di dataset tra cui i permessi a costruire emessi e non emessi (questo avvalora, spero, quello che si affermava anche qui a Venezia: i permessi a costruire non sono soggetti apprivacy); elemento negativo l'elenco delle ville di proprietà comunale in formato kml (!!)... sto comunque ancora guardando...

il sospetto che tutti questi portali siano un modo per "tamponare" rimane però molto forte: si vedranno le date di aggiornamento dei dataset fra un anno; allora si potrà dire che l'opendata è a regime

[Maurizio Napolitano]

2012/10/3 Alessio 'Blaster' Biancalana <dottor...@gmail.com>:

Io direi proprio di no.
Ti ricordo che doveva uscire a novembre 2011
http://opendatablog.ilsole24ore.com/2011/11/roma-capitale-open-data/
Da tempo al tempo e vedrai che viene fuori qualcosa di buono.
L' importante e' essere presenti e vigilare.

[Maurizio Napolitano]

2012/10/3 Luca Corsato <luc...@gmail.com>:

> ci sto proprio ora dando un'occhiata.
> Intanto non è fatto da CSI Piemonte ;-) a parte le battute, non riesco a
> capire se dietro c'è ckan o qualche altro datahub.

Penso abbiano usato un loro cms, quale esattamente non lo so.
Dal mio punto di vista anche qui mancano le API per interrogare il catalogo,
o un dataset che contenta l'elenco dei dataset, inoltre non mi piace il
fatto che si debba accettare la licenza per il download.
Infine ... capisco che il KML e' facile da capire ma per trasportare dati non
e' proprio il massimo.
Non e' come PDF, ma diciamo che e' d iquella famiglia

[Riccardo Grosso]

Non posso che essere d'accordo con Alfredo Serafini, bisogna
cominciare a dedicarsi piu' approfonditamente ai metadati, alle
correlazioni tra dati, e tra metadati, alla semantica

--
http://www.riuso-pa.piemonte.it/cms/component/k2/item/39-infodir-information-directory-il-catalogo-dei-dati-e-dei-servizi.html
ftp://ftp.cordis.europa.eu/pub/fp7/ict/docs/content-knowledge/ricardo-grosso-csi-bicocca-luxemburg-4-slides_en.pdf
http://www.iseing.org/egov/eGOV05/Source%20Files/Papers/CameraReady-7-P.pdf
http://www.inderscience.com/search/index.php?action=record&rec_id=9601&prevQuery=&ps=10&m=or
http://books.google.it/books?id=kjt5JW6ZSdYC&pg=PA170&lpg=PA170&dq=batini%20grosso&source=web&ots=Z7Vo7jAs8D&sig=70jOYba7eQ_zb-Mf-RK_P87EQB0&hl=it#v=onepage&q=batini%20grosso&f=false
http://www.via-nova-architectura.org/files/EMMSAD2005/Batini.pdf
http://www.semic.eu/semic/view/documents/riccardo-grosso-interoperability-in-piedmonte.pdf
http://conferences.cs.unicam.it/metteg08/files/2008/09/riccardo-grosso.pdf
http://fisica.campusnet.unito.it/cgi-bin/didattica.pl/Search?search=corso%3A7733&corso=7733&format=4&sort=U2&fields=_delete
http://infodir.csi.it/mrmotric/searchidir?qu_ruoliPubblici_idr=8&qu_type=obj&isoptimized=on&public=true&xsl=areesp3&type=search&term_query=
http://intranet.csi.it/notizie/2010/02/10/tutti-i-progetti-del-csi-e-i-relativi-referenti-a-portata-di-click/
http://intranet.csi.it/prog/banchedati/documentazione.htm
http://touchgraph.com/seo

[Luca Corsato]

@napo i file in kml mi sembrano proprio una stupidaggine
unendo poi l'assenza di API (ma qui il discorso vale per quasi tutti) e mischiando con l'assenza di linked, ecco che trovano fondamenta i miei dubbi sull'effetto spot.
Spero di sbagliarmi, anzi voglio proprio sbagliarmi!

Sull'API, c'è da dire che quando ne parli ad un'Amministrazione Pubblica ti guardono come le mucche guardano passare il treno...

[Paolo Mainardi]

E' basato su Drupal :)

2012/10/3 Maurizio Napolitano <napo...@gmail.com>

--
Paolo Mainardi

CTO Twinbit
ILDN: http://www.ildn.net
Blog: http://www.paolomainardi.com

-- Please consider the environment before printing this email --

[Luca Corsato]

@paolo sò che sei cintura nera di drupal ma da cosa l'hai capito?

[Stefano Mainardi]

Ci son molti modi per capirlo, il più banale :-) http://dati.comune.roma.it/user 

 

(ma anche http://dati.comune.roma.it/misc/drupal.js)

2012/10/3 Luca Corsato <luc...@gmail.com>

@paolo sò che sei cintura nera di drupal ma da cosa l'hai capito?

-- 

 

Stefano Mainardi 
Twinbit Founder

www:      twinbit.it 

phone:    0331 924060

mobile:   (+39) 3895122611 
skype:    mainardistefano 
linkedin: stefanomainardi 
twitter:  @stefanomainardi 
blog:     stefanomainardi.com 

---------------------------
"Please consider the environment before printing this email."

"Questo messaggio è destinato unicamente alla/e persona/e sopraindicata/e.
È strettamente personale e può contenere informazioni la cui
riservatezza è tutelata dalla normativa ai sensi del DLgs 196/03.
È espressamente vietato alla/e persona/e non destinataria/e
leggere, copiare o comunque usare questo messaggio o diffonderne
il contenuto senza autorizzazione.
Chi ha ricevuto per errore questo fax o messaggio è pregato di
distruggerlo e di avvertire per telefono o fax o email, il mittente."
---------------------------

[Alfredo Serafini]

@luca:

basta usare wappalyzer! ;-)

[Maurizio Napolitano]

> mischiando con l'assenza di linked

Ora mia la domanda provocatoria:
ma la PA deve veramente fare linked data?
Io non ne sono molto convinto.
Mi spiego: secondo me la PA rilascia i dati come
metadati in relazione alle sue esigenze e lascia
che sia il mercato a prendere i dati e fare quello
che serve.

[Luigi Reggi]

scusate, domanda del policy wonk: perché KML non ci piace?

2012/10/3 Luca Corsato <luc...@gmail.com>

--
Luigi Reggi
+39 328 6785249
www.luigireggi.eu
twitter: @luigireggi

[Luca Corsato]

@stefano e @paolo : elementare watson!!

@napo io parlo di linked tra i dati dell'Amministrazione; se ho una cartografia di base nella quale si innestano svariati tematismi, sarebbe bene che i vari dataset avessero un qualche collegamento a livello di relazione. Forse, mentre scrivo, mi rendo conto che basterebbero dei metadati scritti bene... non so, sto imparando e quindi mi esibisco nell'esercizio del dubbio ;-)

[Luca Corsato]

@luigi io sono ai Sistemi Informativi territoriali del Comune di Venezia e ti posso assicurare che di file kml (o kmz) non ne ho visti e nemmeno vengono usati. Si lavora tutto con shape che sono poi i formati richiesti dalla direttiva INSPIRE (qui però @napo è il riferimento!!). Mettere di file kml significa che o qualcuno li ha composti da file shape (obbligando poi chi li scarica a convertirli) oppure quelle informazioni le hanno prodotte lavorando direttamente su google heart... altri motivi non mi vengono in mente.
Passo la parola agli esperti

[Alfredo Serafini]

beh nessuno è costretto a fare nulla. Però rilasciare i Linked presuppone dare una "direzione" iniziale ai dati, una impronta sia pur vagamente (in molti casi) semantica... personalmente auspicherei qualcosa del genere. Al momento ovviamente vuole dire sbrodolare un po' di rdf di metadati e mi rendo conto che sia faticoso per amministrazioni che già faticano a pubblicare csv :-)

Però c'è un vantaggio oggettivo: i dati non solo sarebbero pubblici, ma essendo pre-elaborati dall'amministrazione avverebbe una selezione naturale: se non puoi identificare le entità e produrre relazioni anche vagamente consistenti, probabilmente stai pubblicando fuffa :-)

Poi a maggior ragione gli sviluppatori possono elaborare i dati.

Invece se mi danno un csv sono costretto  a scegliere (o inventarmi) un vocabolario dove mappare i dati, e fare scelte arbitrarie di mapping non sempre condivisibili: morale della favola produco grossomodo una ennesima nuvoletta di dati grezzi, sia pure vagamente semantizzati.

questi almeno i miei 2 cents... poi ripeto: sarei contento intanto di tanti dati grezzi ed aggiornati, ci mancherebbe :-)

[Riccardo Grosso]

Non voglio fare il precisino e farmi odiare ma cio' che serve sono relazioni semantiche, in una parola... ontologie :) parlo da agricoltore non da ontologo :)

Il giorno 03 ottobre 2012 11:56, Luca Corsato <luc...@gmail.com> ha scritto:

@stefano e @paolo : elementare watson!!

@napo io parlo di linked tra i dati dell'Amministrazione; se ho una cartografia di base nella quale si innestano svariati tematismi, sarebbe bene che i vari dataset avessero un qualche collegamento a livello di relazione. Forse, mentre scrivo, mi rendo conto che basterebbero dei metadati scritti bene... non so, sto imparando e quindi mi esibisco nell'esercizio del dubbio ;-)

[Luca Corsato]

@alfredo e @riccardo ma intanto non basterebbe una compilazione buona dei metadati? le ontologie non partono poi da quelli?
su quello che poi rischiano di fare gli sviluppatori è un altro discorso, ma non trascurabile.
la domandona è: se si vuole porre la base ad una nuova economia e/o settore produttivo perchè non si procede ad una catalogazione dei dati man mano che escono?

domanda, invece, a voi esperti: vista la mole di dati che produce e gestisce già l'ISTAT non potrebbero essere loro a costruire una bozza di ontologia?

[Maurizio Napolitano]

2012/10/3 Luigi Reggi <luigi...@gmail.com>:

> scusate, domanda del policy wonk: perché KML non ci piace?

Il KML e' un formato per visualizzare i dati e per pilotare le
applicazioni google.
E' un formato aperto, ma il modo con cui gli attributi delle geometrie
sono gestite
e' pessimo.
Come ho scritto in una precedente email, il KML assomiglia piu' ad un pdf anche
se e' meno restrittivo.

Alternative?
Gli shape file sono un formato pessimo, ma molto diffusi.
Lo standard sarebbe GML, ma capisco che molte persone non lo conosco.
C'e' chi esporta in CSV usando lat e lon per i dati puntuali o WTK per
line o poligoni.
Altra soluzione e' il geojson

Apprezzabile il lavoro di Vienna (che di fatto costa poco) che esporta
in automatico
in vari formati per tutti i gusti facendo felici tutti

http://data.wien.gv.at/katalog/radfahranlagen.html

[Maurizio Napolitano]

> domanda, invece, a voi esperti: vista la mole di dati che produce e gestisce
> già l'ISTAT non potrebbero essere loro a costruire una bozza di ontologia?

Ci lavorano fra datacube e sdmx hanno molto da fare.


--
Maurizio "Napo" Napolitano
http://de.straba.us

[Luigi Reggi]

grazie, molto chiaro. Capisco che privilegiare il multi formato è sempre la cosa migliore.

2012/10/3 Maurizio Napolitano <napo...@gmail.com>

[Riccardo Grosso]

@lucacorsato: parole sante le tue !!!
E' proprio da una buona (meglio se ottima) compilazione dei metadati
da cui si puo' partire ed arrivare alle ontologie !
Vuoi che ti dica il perche' i miei tools sono rimasti una
sperimentazione in CSI, e non un progetto in produzione ?
Perche' chi doveva metadatare le proprie basi dati non aveva
tempo-voglia-soldi per farlo !
Allora si dava la colpa alla metodologia di inferenza non valida, alle
ontologie povere, tutte balle !
Se i dati sono ben metadatati, l'inferenza funziona, certo devo avere
anche una buona attrezzatura da pesca per pescare la conoscenza, ma da
una base dati non descritta o almeno con nomi tavole e campi parlanti
difficilmente riusciro' mai ad inferire conoscenza.
Inferire conoscenza a volte puo' sembrare come arrivare al maiale
partendo dal salame, ed in effetti solo bottom up e' dura, ma sposare
l'approccio top-down (ontologie da pesca) con il bottom-up (strutture
fisiche dei database) puo' portare a qualcosa, senonaltro a popolare
un foglio bianco con concetti inferiti, poi esaminarli e validarli
rimuovendo o aggiungendo concetti.

[Alfredo Serafini]

@luca: il problema non banale è proprio come compilare i metadati, oltre che quali formati utilizzare. Il secondo è un problema tecnico non banale, il primo è un po' meno tecnico ma è il vero collo di bottiglia se si vuole uscire da un'ottica di artigianato su vasta scala per poter davvero automatizzare un po' i processi.

Poi anche le ontologie non sono affatto una panacea, perché consentono 10000 modi di descrivere le stesse cose, e non è sempre banale ri-mappare una descrizione sulle altre, ma almeno potrebbero costituire una lingua franca.

Riguardo alla bozza di ontologia non è che può farla qualcuno da solo, anche perché l'idea è che ce ne siano tante quanti i domini, e che possano essercene anche più d'una per ogni dominio (ad esempio uno sviluppatore fa elaborazioni su dati aperti già pubblicati usando una ontologia, e li ripubblica usandone un'altra, un po' come avviene con jago+freebase e dbpedia). Insomma è una standardizzazione sul metalinguaggio intermedio se vogliamo (almeno finché si usa RDF), ma in realtà è molto più libero il riutilizzo dei dati (peraltro auto-descrittivo, almeno in parte) di quanto non lo sia con i soli dati grezzi, in cui è difficile capire cosa e come relazionare a cosa.

Questa lameno la mia opinione, poi figuriamoci è un tema più che decennale :-)

[Alfredo Serafini]

In ogni caso io sono ottimista e mi viene da dire: eppur si muove, no? :-)

Come già detto sopra la vera prova del fuoco intanto è se li aggiornano: se davvero vincono l'inerzia e ne fanno manutenzione di qui ad un anno, allora c'è speranza di introdurre ogni sorta di miglioramento che ci piace, altrimenti restano tante zattere alla deriva...

[ilmistra]

a proposito di kml si o kml no...

1) kml registra i dati vettoriali in formato geografico (latitudine e longitudine), superando il problema non banale del passaggio da sistemi di riferimento diversi. Un esempio sui dati open di Milano...sono tutti in Gauss Boaga. Chi volesse visualizzarli so GMaps, GEarth o OSM, dovrebbe farci qualche lavoretto di conversione. La geodesia non è materia per giovani (!)

2) kml ha il vantaggio (o svantaggio) di poter definire le vestizioni delle geometrie. I puristi anche qui saranno contrari perchè ognuno i dati li veste come vuole, però per un immediatezza di visualizzazione, può essere utile conservare anche questo aspetto nel dataset

3) kml non associa facilmente ad una geometria una struttura dati seria

4) leggo ora che Napo lo ha già scritto...repetita juvant

5) concordo sul geoJson che deriva la descrizione vettoriale da standard codificati

...e non dimentichiamoci dell'immenso Ale Furieri con il suo Spatialite rappresenta una valida alternativa di embedding di dati gis che superi i limiti del formato shp!

[Luca Corsato]

Mannaggia a quanto ne sapete!!
@ilmistra: a proposito delle vestizioni, qui centri il problema nodale dei dataset soprattutto urbanistici! io sono in angoscia totale perchè usando arcgis i file sono tutti in formato .mxd e le vestizioni sono in .lyr... a breve (così vi do una news così di sguincio) il Comune di Venezia rilascerà l'intera cartografia e per distribuirla si pensava a shp e sld per le vestizioni... un dramma!!! ho provato un po' di applicativi ma nulla che interpreti bene e che sia opensource (il Comune non ha un euro!) sono in buca totale.....
Si pensava di dirottare tutti i dati cartografici territoriali su software come geonode, ma anche lì le vestizioni sono pubblicabili solo in sld! Geonode, però, rende possibile il download in multiformato

Relativamente al sistema di riferimento, c'è da dire che se importo degli shp in google heart me li converte nel sistema di google, che NON è quello che si usa nelle PA

[Maurizio Napolitano]

In generale consiglio di distribuire i dati in WGS84 (epsg:4326) per
superare la prima barriera.
Penso che KML sia utile per far capire ma inutile per chi lavora sui dati.

Riguardo il papà di Alessandro Furieri, c'e da dire che ora il
personaggio è diventato un membro
dell'Open Geospatial Consortium, questo vuol dire che spatialite sarà
presto una alternativa
di grosso impatto sul mondo dei formati dei geodati.

2012/10/3 ilmistra <p.mist...@gmail.com>:

[Matteo Brunati]

al volo, mi accodo ad alfredo, ma è un tema profondo: ( che io seguo per
passione )
- in linea di massima se usi linked data anche sui vocabolari, possiamo
unire le isole poi per mappare i termini. Ovvio che è un lavoraccio, ma è
cmq un passo avanti.
- sarebbe ideale una best practice per la costruzione delle URI
- sarebbe ideale già descrivere i metadati con vocabolari segnalati da
tempo, per iniziare ( DCAT e VOID a seconda delle necessità )

C'è un bel post dell'autore di "Learning SPARQL" che mostra cosa accade
quando si vuole fare integrazione dati linked, che potrebbe chiarire molte
idee che ritornano spesso:
-> http://www.snee.com/bobdc.blog/2012/04/simple-federated-queries-with.html

Io sarei orientato più alla costruzione dal basso di isole ( pensiamo al
piemonte, firenze e veneto e dati.gov, di fatto sono 2 piattaforme
tecnologiche ckan connected o quasi ), che imparino a condividere e a
linkarsi più che ad un approccio top down oggi complesso.
Una cosa espressa a suo tempo anche da Tim Berners Lee:
->
http://www.semanticommunity.info/%40api/deki/files/12680/nodalities_issue1.pdf

Mentre serve più attenzione a chi sta proseguendo i lavori su questo,
serve maggior discussione e più learning by example forse:
a - https://dvcs.w3.org/hg/gld/raw-file/default/bp/index.html
b - http://www.w3.org/2011/gld/wiki/Main_Page

Aumento del riuso dei dati già pubblicati: peccato che ci siano così pochi
sforzi su questo... ( tempus fugit )

Matt

--
Chi sono:
http://www.dagoneye.it

Cosa penso:
Casual.info.in.a.bottle - http://www.dagoneye.it/blog

[Luca Corsato]

@matteo dati.veneto.it non ha ckan dietro
vorremmo studiarlo ma è proprio bello incasinato ;-)

[Maurizio Napolitano]

maybe
http://www.slideshare.net/napo/ckan-the-open-source-data-portal-platform

[Maurizio Napolitano]

cmq ckan è easy
Ha solo il problema che lo sviluppo va come un treno

[Luca Corsato]

@napo confessa: tu hai almeno 3 controfigure e/o cloni!!

[Alessio 'Blaster' Biancalana]

Raga, Napo scrive in multithreading.

[Matteo Brunati]

@luca: yes è drupal 7 come backend, lo so, ma la tendenza è compatibilità
con ckan per tutti, che è la base del lavoro a livello eu cmq...
e che contribuisce anche al dcat, in effetti:
http://www.w3.org/2011/gld/meeting/2012-07-26
indi indipendenza della piattaforma ma compatibilità con uno standard
condiviso... è un percorso che va raccontanto probabilmente.

@napo: già .)

matt

[Maurizio Napolitano]

Esagerati
Ora sono a Vienna
Ho incontrato le persone del progetto OGD dell'Austria
Grandiose!
Domani ho un workshop con rappresentanti ogd di lingua tedesca

[Maurizio Napolitano]

occhio che data.gov.uk integra drupal 'ad minchiam'
In pratica data.gov.uk/data è ckan con il template di Drupal
Il resto è Drupal
Guardate i sorgenti html

[Alfredo Serafini]

@matteo: sottoscrivo tutto: l'esigenza di puntare alle URI, specie perché prima o poi si potrà usarle direttamente e stabilmente sui dati "grezzi", quindi prima si arriva a delle "ricette" realmente condivise, e meglio è. Idem per l'uso di vocaboolari linked, dcat e void

sottoscrivo in particolar modo l'approccio bottom-up, anche perché nel "mondo reale" secondo me può giocare un ruolo di compromesso tra una conoscenza robusta all'interno del dominio specifico, e la possibilità di costruire relazioni fuori anche in maniera semi-automatica. 

sul riuso dei dati già pubblicati: temo che i limiti attuali siano:

1. tempus fugit come dicevi, ok :-)
2. una a volte eccessiva esigenza di rigore da parte di chi detiene i dati (se li collego esternamente, magari "rialssandone" minimamente a mio discapito la semantica, non è che "sporco" il dataset originale, ma questo non sempre viene percepito opportunamente, specie da addetti ai lavori)
3. la difficoltà a volte di correlazione dovuta alla necessità/voglia di correlarli con dati grezzi in modo opportuno: psono convinto che anche qui se emergessero un minimo di best practice largamente accettate (non prescrittive, per carità) per effettuare le mappature di csv etc (un modo potrebbe essere anche qui appunto la pubblicazione parallela di metadati e vocabolari) sarebbe possibile usare molti dati disponibili in forma "grezza" per collegare alcune isole. Ovviamente è una mia fantasticheria, dato che sui dati grezzi ognuno fa un po' quel che gli pare, e quindi non c'è modo di verificare... :-) 

[Matteo Brunati]

Il 03/10/12 12:14, Maurizio Napolitano ha scritto:

>> domanda, invece, a voi esperti: vista la mole di dati che produce e gestisce

>> gi� l'ISTAT non potrebbero essere loro a costruire una bozza di ontologia?

> Ci lavorano fra datacube e sdmx hanno molto da fare.
>
>

Infatti, a livello di W3C altro draft rilasciato a giugno per il gruppo
GLD sul vocabolario collegato:
http://www.w3.org/2011/gld/wiki/Data_Cube_Vocabulary

Interessante e sul pezzo JSON-Stat, vista la dirompente crescita d'uso
del JSON, e l'importanza collegata della sintassi JSON-LD per RDF:
https://twitter.com/jsonstat ( da seguire per capirne le relazioni )

e siam isole in mezzo al mar :)

Matt

[Alessio 'Blaster' Biancalana]

http://www.opendata.provincia.roma.it/

Questo lo presentano oggi.

Ancora niente API, solo 41 dataset e grafica un po' vecchiotta (ma se avesse le API e potessi ridisegnarne io un frontend sarebbe no problem).

Sono un po' deluso. :)

Ale

Il giorno 03 ottobre 2012 11:01, Alessio 'Blaster' Biancalana <dottor...@gmail.com> ha scritto:

Ciao spaghettari,

http://dati.comune.roma.it/

Qui il portale open data del comune di Roma. Che ne pensate? Iniziativa fuffa-based o c'è sotto qualcosa di buono?

Ale

[Maurizio Napolitano]

Sbagli
Le api ci sono: il portale usa CKAN
http://ckan.readthedocs.org/en/ckan-1.7.1/api.html
Il portale e' su da parecchio tempo.
le API sono restfull e servono ad interrogare il catalogo
con export in json
Es.
Ottenere la lista dei dati
http://www.opendata.provincia.roma.it/api/rest/dataset

Vedere le informazioni di un dataset
http://www.opendata.provincia.roma.it/api/rest/dataset/provinciawifi

Interrogare il catalogo (es. quali dataset hanno la localizzazione?)
http://www.opendata.provincia.roma.it/api/search/dataset?q=localizzazione

Il dataset poi e' esposto anche in rdf (usando DCAT -
http://www.w3.org/egov/wiki/Data_Catalog_Vocabulary )
http://www.opendata.provincia.roma.it/dataset/provinciawifi.rdf

Il giorno 12/ott/2012 10:49, "Alessio 'Blaster' Biancalana"
<dottor...@gmail.com> ha scritto:
>

[Alessio 'Blaster' Biancalana]

Ah buono! Non avevo visto che usasse CKAN, magari ai civil hacker romani come me interesserà :P

Ale
Inviato da Android

[Maurizio Napolitano]

2012/10/12 Alessio 'Blaster' Biancalana <dottor...@gmail.com>:

> Ah buono! Non avevo visto che usasse CKAN, magari ai civil hacker romani
> come me interesserà :P

Essendo CKAN Affero GPL, questo deve essere indicato.
Se guardi il portale, trovi l'informazione in basso a destra

[Alessio 'Blaster' Biancalana]

Sono proprio un niubbo :))

Ale
Inviato da Android

[Jacopo Primavera]

Ciao, cercando informazioni su dati del Comune di Roma ho trovato questa vecchia discussione... chissà magari chi vi partecipò nel lontano 2012 riceve ancora le notifiche... 

Sto cercando dati sugli esercizi commerciali di Roma. Mi piacerebbe individuare categorie particolari di locali come internet cafè e coworking.

Alla voce esercizi commerciali nel portale sono presenti diversi database con le liste degli esercizi per attività, localizzazione ecc. 

Di certo non mi aspetto di trovare la granularità che mi serve, ma comunque sembrano un buon punto di partenza

Qualcuno ha lavorato con questi dati e sa darmi un giudizio sulla loro completezza, pulizia, insomma affidabilità?

Qualcuno conosce altre fonti utili a riguardo per incrociare le informazioni? Camera di commercio, statistiche nazionali, altro?

Grazie!

Jacopo

[mbranco2]

Beh, visto che ho appena pubblicizzato OpenStreetMap, non posso che indicare qui come si cercano i dati in OSM... :-)
(anche se la tua ricerca è molto specifica, vedo per es. che gli internet cafe sono poco mappati in OSM: ce n'è qualcuno nel nord Italia, e nessuno a Roma)

In OSM, gli esercizi commerciali e di servizi sono taggati rispettivamente con "shop" [1] e "amenity" [2] : guardando le due pagine linkate puoi verificare il livello di granularità (ci sono più di 400 tipologie di negozio e più di 100 tipologie di servizi)

Per ricercare ed estrarre i dati OSM, forse il metodo più semplice (per chi non conosce il mondo OSM) è usare overpass-turbo [3] :
- si zoomma nella cartina a destra sull'area che interessa (più è grande l'area e più tempo impiegherà ad estrarre i dati, naturalmente)
- se non hai voglia di imparare la sintassi delle query, premi il pulsante "Wizard" , dove imposterai la ricerca (es. amenity=cafe, o shop=*, ...) e poi selezioni "build and run query"
- Dopo il tempo necessario la mappa si popola con i dati richiesti; con il pulsante "Export" scegli il formato (raw data=json)

Vedo che a Roma sono mappati più di 2000 shop e più di 8000 amenity.

Ciao,

 Marco

[1] http://wiki.openstreetmap.org/wiki/Key:shop
[2] http://wiki.openstreetmap.org/wiki/Key:amenity
[3] http://overpass-turbo.eu/

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Spaghetti Open Data" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a spaghettiopendata+unsubscribe@googlegroups.com.
Visita questo gruppo all'indirizzo https://groups.google.com/group/spaghettiopendata.
Per altre opzioni visita https://groups.google.com/d/optout.

[Jacopo Primavera]

Ciao Marco, grazie per la dritta!

in effetti avevo già provato a smanettare un pò con OSM qualche tempo fa. Se ricordo bene dovrebbe esserci un pacchetto in R per interrogare direttamente la base dati. Ci rimetterò mano, ma anche il wizard suona bene :)

ps. sarebbe bello venire a Genova per il FOSS4G-IT, ho visto che ci sono tanti workshop interessanti anche su OSM. Ci faccio un pensiero 

Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a spaghettiopend...@googlegroups.com.

[mbranco2]

Non so se la Lista si annoia se entriamo nelle technicality, nel caso potremo eventualmente proseguire la discussione inter nos via mail.

Tra i numerosi package R che trattano dati geospaziali [1], io ho usato con soddisfazione osmar (qui un buon articolo [2]).

I dati "nativi" OSM sono in un database PostgreSQL [3], che poi vengono replicati e forniti in vari formati su più siti : se hai banda e spazio su disco ti puoi scaricare tutto il pianeta [4] (54Gb compressi), o solo per le zone che ti interessano [5] .

Il package osmar citato prima lavora sia con API che interrogano il db remotamente, sia in locale se ti sei scaricato i dati.

P.S. Se vieni a Genova fammelo sapere, guarda caso terrò una sessione sull'uso di R per elaborare i dati OSM  :-)
 
[1] https://cran.r-project.org/web/views/Spatial.html
[2] https://journal.r-project.org/archive/2013-1/eugster-schlesinger.pdf
[3] http://wiki.openstreetmap.org/wiki/Database
[4] http://planet.osm.org/
[5] http://download.geofabrik.de/

Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a spaghettiopendata+unsubscribe@googlegroups.com.

[Maurizio Napolitano]

2017-01-18 15:42 GMT+01:00 Jacopo Primavera <j....@hotmail.it>:
> Ciao Marco, grazie per la dritta!
> in effetti avevo già provato a smanettare un pò con OSM qualche tempo fa. Se
> ricordo bene dovrebbe esserci un pacchetto in R per interrogare direttamente
> la base dati. Ci rimetterò mano, ma anche il wizard suona bene :)

Consiglio anche di guardare questo servizio
https://osmaxx.hsr.ch/
che ti impacchetta i dati di osm in vari formati e fornisce anche gli stili
per rappresentarli

Altrimenti prendi gli estratti italiani che trovi qui
http://osm-estratti.wmflabs.org/estratti/Lazio/Roma_Capitale/Roma

se usi R penso che ti convenga usare i dati raw e meglio se tagliati
dentro il confine della città

ergo
http://osm-estratti.wmflabs.org/estratti/comuni/osm_r/058091---Roma.R.osm.zip

Nota che OpenStreetMap archivia le informazioni delle strutture commerciali
in varie geometrie quindi puoi trovare il punto, cosi`come un poligono o insieme
di geometrie.
Interessanti anche i casi dei negozi dei centri commerciali (spesso
rappresentanti
anche su più piani).

Molti studi chiedono di avere il punto, e qui si apre la questione di
quale scegliere
per un poligono. La risposta più naturale è il centroide, ma non
sempre cade sulla
geometria. Una ottima soluzione è data dal fare uso di funzioni come
PointOnSurface


Roma è abbastanza coperta sul fronte OpenStreetMap.
Il Comune però dovrebbe avere in "pancia" anche i dati di tutte le strutture.

[Jacopo Primavera]

grazie napo!

[mbranco2]

ringrazio anch'io Napo, non conoscevo osm-estratti.wmflabs.org  (e neanche PointOnSurface, in casi del genere mi limitavo rozzamente a fare la media di tutte le lat/lon dei nodi interessati.... :-)  )

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Spaghetti Open Data" di Google Gruppi.

Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a spaghettiopendata+unsubscribe@googlegroups.com.

Visita questo gruppo all'indirizzo https://groups.google.com/group/spaghettiopendata.

Per ulteriori opzioni, visita https://groups.google.com/d/optout.