In attesa che sia deciso il formato con cui scambiare i dati dei monumenti, facendo una ricerca esplorativa su Albano (provincia di Roma) risulta che il db OSM presenta 16 voci, di cui 5 senza descrizione, mentre il db MIBAC ne riporta 61 e le descrizioni dello stesso monumento sono diverse (ad esempio: Sepolcro detto degli Orazi e Curiazi per OSM e Tomba degli Orazi e Curiazi per MIBAC) il che rende difficoltoso integrare i due db, a meno che non si faccia una pura e semplice somma e poi si vadano a scartare i doppioni a mano; anche questa ipotesi è però percorribile per comuni piccoli ma sarebbe, credo, molto complessa per comuni tipo Roma o Napoli. Per quanto riguarda il codice unico va bene utilizzare come prima parte il codice ISTAT, ma per la seconda parte (identificativo del singolo monumento) forse sarebbe meglio utilizzare quello MIBAC in modo da avere, per il futuro, un codice che ci consenta di fare query e integrazioni con i db ufficiali, altrimenti avremo sempre la necessità di andare a verificare a mano le coincidenze.
Massimo
Ragazzi... 'sta cosa di scambiarsi file con dentro database (siano Access o anche altro) mi fa un po' accapponare la pelle. Sappiatelo.
In ogni caso, per chi avesse Linux consiglio l'installazione di Kexi[1]... ho avuto in passato la necessità di aprire file Access ;-)
Detto questo, con tanta simpatia e stima, Saverio, invia un altro file Access su questa lista e secondo le mie regole di ingaggio sarò costretto a spararti a vista (con tanta simpatia e stima, ti ho avvisato) :P.
Cristian
Il 07 marzo 2012 18:20, massimo.palmieri1@libero.it massimo.palmieri1@libero.it ha scritto:
In attesa che sia deciso il formato con cui scambiare i dati dei monumenti, facendo una ricerca esplorativa su Albano (provincia di Roma) risulta che il db OSM presenta 16 voci, di cui 5 senza descrizione, mentre il db MIBAC ne riporta 61 e le descrizioni dello stesso monumento sono diverse (ad esempio: Sepolcro detto degli Orazi e Curiazi per OSM e Tomba degli Orazi e Curiazi per MIBAC) il che rende difficoltoso integrare i due db, a meno che non si faccia una pura e semplice somma e poi si vadano a scartare i doppioni a mano; anche questa ipotesi è però percorribile per comuni piccoli ma sarebbe, credo, molto complessa per comuni tipo Roma o Napoli. Per quanto riguarda il codice unico va bene utilizzare come prima parte il codice ISTAT, ma per la seconda parte (identificativo del singolo monumento) forse sarebbe meglio utilizzare quello MIBAC in modo da avere, per il futuro, un codice che ci consenta di fare query e integrazioni con i db ufficiali, altrimenti avremo sempre la necessità di andare a verificare a mano le coincidenze.
Grazie della segnalazione. È effettivamente un problema, se non da risolvere automaticamente, da limitare il più possibile.
Cristian
Ragazzi, due ore che mi assento dal pc, e quando apro la casella email, una valanga di posta! Perdindirindina! Bello caldo, il tema! Dunque, rispondiamo un po' (vado a memoria dopo aver letto le mail)
a) il db che ho creato è consultivo, non definitivo: come ha detto Cristian, il modello ultimo sta venendo ultimato in questi giorni. Il db che ho allegato serve soltanto a prendere coscienza del lavoro da fare, non tanto sulla natura dei campi (che saranno quelli stabiliti da WLM Internazionale più qualche aggiunta), quanto sul contenuto che vi andrà memorizzato (coordinate, comuni, ecc.). Finora ne avevamo parlato sempre teoricamente, sono contento che il db sia servito a puntualizzare diverse questioni, ma ricordiamoci che non sarà *mai* usato un db Access nella versione finale;
b) ne deriva che o Access o MySQL o Postgre, avranno comunque gli stessi dati: non importa il contenitore, ma il contenuto, ed il contenuto presenta vari problemi, perciò concentriamoci su questi ultimi;
c) chiedo umilmente venia per Access, ma non ho avuto tempo di resuscitare Ubuntu (Cristian, grazie della dritta, ma la versione che ho è la 10.04, ancora non ha Unity, che trovo un po' irritante...), ed installare altro sulla partizione winzozz, già spremuta alla goccia in questi giorni avendo sempre attivo AutoCAD - che purtroppo non ha alternative eguali in x - e PhotoShop per lavoro, avrebbe significato l'impallo totale :(
d) giuro solennemente che per un'eventuale versione 2.0 utilizzerò altro, così da evitare la punizione (...e pensare che quando posso uso software open, sarebbe il colmo morire per Access) :D
Dunque, se qualcuno può convertire il db Access in altro (non .xls, che permette la visualizzazione dei dati, ma elimina del tutto le relazioni tra tabelle: consultare oltre 30.000 record in celle di Excel è davvero scomodo) lo faccia e lo renda disponibile per chi, come Lucadelu, non può aprire il famigerato .mdb (al momento non posso farlo io).
Per quanto riguarda la coerenza dei dati, non c'è problema: si può effettuare una join di controllo tra il db OSM e l'eventuale db MIBAC utilizzando come campo unione il comune in cui è sito il monumento: in tal modo le differenze diverranno esplicite nell'immediato.
Come ha giustamente notato Cruck poco tempo fa, non si possono controllare 30 o 120 mila record da soli, quindi, con una query, potremmo dividerci il *necessario* lavoro di controllo dei dati (basta vedere i primi 20 record del db OSM per capire cosa dico) suddividendocelo ad esempio per province.
Attendo feedback :D
Saverio
http://saveriog.altervista.org/
________________________________ Da: Cristian Consonni kikkocristian@gmail.com A: "massimo.palmieri1@libero.it" massimo.palmieri1@libero.it; Lista dedicata all'organizzazione di WLM wlm@wikimedia.it Inviato: Mercoledì 7 Marzo 2012 18:23 Oggetto: Re: [WLM] Database WLM OSM (Massimo Palmieri)
Il 07 marzo 2012 18:20, massimo.palmieri1@libero.it massimo.palmieri1@libero.it ha scritto:
In attesa che sia deciso il formato con cui scambiare i dati dei monumenti, facendo una ricerca esplorativa su Albano (provincia di Roma) risulta che il db OSM presenta 16 voci, di cui 5 senza descrizione, mentre il db MIBAC ne riporta 61 e le descrizioni dello stesso monumento sono diverse (ad esempio: Sepolcro detto degli Orazi e Curiazi per OSM e Tomba degli Orazi e Curiazi per MIBAC) il che rende difficoltoso integrare i due db, a meno che non si faccia una pura e semplice somma e poi si vadano a scartare i doppioni a mano; anche questa ipotesi è però percorribile per comuni piccoli ma sarebbe, credo, molto complessa per comuni tipo Roma o Napoli. Per quanto riguarda il codice unico va bene utilizzare come prima parte il codice ISTAT, ma per la seconda parte (identificativo del singolo monumento) forse sarebbe meglio utilizzare quello MIBAC in modo da avere, per il futuro, un codice che ci consenta di fare query e integrazioni con i db ufficiali, altrimenti avremo sempre la necessità di andare a verificare a mano le coincidenze.
Grazie della segnalazione. È effettivamente un problema, se non da risolvere automaticamente, da limitare il più possibile.
Cristian _______________________________________________ Wlm mailing list Wlm@wikimedia.it http://mailman.wikimedia.it/listinfo/wlm
Il 07 marzo 2012 18:45, Saverio dyskephalos@yahoo.it ha scritto:
Dunque, se qualcuno può convertire il db Access in altro (non .xls, che permette la visualizzazione dei dati, ma elimina del tutto le relazioni tra tabelle: consultare oltre 30.000 record in celle di Excel è davvero scomodo) lo faccia e lo renda disponibile per chi, come Lucadelu, non può aprire il famigerato .mdb (al momento non posso farlo io).
See that, done that: * formato SQL: http://dl.dropbox.com/u/11865418/DB_WLM_OSM.sql * formato kexi (è una versione simile a SQLite usats, appunto, da Kexi): http://dl.dropbox.com/u/11865418/DB_WLM_OSM.kexi
Divertitevi. ;-)
Cristian
See that, done that:
- formato SQL: http://dl.dropbox.com/u/11865418/DB_WLM_OSM.sql
- formato kexi (è una versione simile a SQLite usats, appunto, da
Kexi): http://dl.dropbox.com/u/11865418/DB_WLM_OSM.kexi
Divertitevi. ;-)
Evviva Cristian! (Captatio benevolentiae per evitare fucilationem!)
:D
Saverio
http://saveriog.altervista.org/
________________________________ Da: Cristian Consonni kikkocristian@gmail.com A: Saverio dyskephalos@yahoo.it; Lista dedicata all'organizzazione di WLM wlm@wikimedia.it Inviato: Mercoledì 7 Marzo 2012 19:21 Oggetto: Re: [WLM] Database WLM OSM
Il 07 marzo 2012 18:45, Saverio dyskephalos@yahoo.it ha scritto:
Dunque, se qualcuno può convertire il db Access in altro (non .xls, che permette la visualizzazione dei dati, ma elimina del tutto le relazioni tra tabelle: consultare oltre 30.000 record in celle di Excel è davvero scomodo) lo faccia e lo renda disponibile per chi, come Lucadelu, non può aprire il famigerato .mdb (al momento non posso farlo io).
See that, done that: * formato SQL: http://dl.dropbox.com/u/11865418/DB_WLM_OSM.sql * formato kexi (è una versione simile a SQLite usats, appunto, da Kexi): http://dl.dropbox.com/u/11865418/DB_WLM_OSM.kexi
Divertitevi. ;-)
Cristian
2012/3/7 Saverio dyskephalos@yahoo.it:
Ragazzi, due ore che mi assento dal pc, e quando apro la casella email, una valanga di posta! Perdindirindina! Bello caldo, il tema! Dunque, rispondiamo un po' (vado a memoria dopo aver letto le mail)
Benvenuto nel mondo wiki, dove si passa dal deserto a 200 messaggi in niente!
a) il db che ho creato è consultivo, non definitivo: come ha detto Cristian, il modello ultimo sta venendo ultimato in questi giorni. Il db che ho allegato serve soltanto a prendere coscienza del lavoro da fare, non tanto sulla natura dei campi (che saranno quelli stabiliti da WLM Internazionale più qualche aggiunta), quanto sul contenuto che vi andrà memorizzato (coordinate, comuni, ecc.). Finora ne avevamo parlato sempre teoricamente, sono contento che il db sia servito a puntualizzare diverse questioni, ma ricordiamoci che non sarà *mai* usato un db Access nella versione finale;
Domanda scema: sui database si può/potrà lavorare online e senza dover installare programmi (stile GoogleDocs)?
Come ha giustamente notato Cruck poco tempo fa, non si possono controllare 30 o 120 mila record da soli, quindi, con una query, potremmo dividerci il *necessario* lavoro di controllo dei dati (basta vedere i primi 20 record del db OSM per capire cosa dico) suddividendocelo ad esempio per province.
Non ho guardato il file - esiste un campo "provincia" che permetta di può suddividere automaticamente il dbase, vero?
Il 07 marzo 2012 18:45, Saverio dyskephalos@yahoo.it ha scritto:
b) ne deriva che o Access o MySQL o Postgre, avranno comunque gli stessi dati: non importa il contenitore, ma il contenuto, ed il contenuto presenta vari problemi, perciò concentriamoci su questi ultimi;
se fosse possibile postgresql + postgis sarebbe un'ottima cosa :-)
Per quanto riguarda la coerenza dei dati, non c'è problema: si può effettuare una join di controllo tra il db OSM e l'eventuale db MIBAC utilizzando come campo unione il comune in cui è sito il monumento: in tal modo le differenze diverranno esplicite nell'immediato.
Come ha giustamente notato Cruck poco tempo fa, non si possono controllare 30 o 120 mila record da soli, quindi, con una query, potremmo dividerci il *necessario* lavoro di controllo dei dati (basta vedere i primi 20 record del db OSM per capire cosa dico) suddividendocelo ad esempio per province.
se il db MIBAC ha le coordinate possiamo fare query spaziali che potrebbero semplificare il lavoro segnalando i doppioni nel raggio di tot metri. Inoltre penso sia possibile fare qualche query per cercare nomi simili, non ho idea della query precisa ma ci posso ragionare su L'unica cosa che non ho capito, il bd del MIBAC è disponibile al progetto perchè a quel punto potremmo inserire i dati in OSM :-)
Saverio
Il 07 marzo 2012 21:37, Luca Delucchi lucadeluge@gmail.com ha scritto:
se il db MIBAC ha le coordinate possiamo fare query spaziali che potrebbero semplificare il lavoro segnalando i doppioni nel raggio di tot metri. Inoltre penso sia possibile fare qualche query per cercare nomi simili, non ho idea della query precisa ma ci posso ragionare su L'unica cosa che non ho capito, il bd del MIBAC è disponibile al progetto perchè a quel punto potremmo inserire i dati in OSM :-)
Immaginavo la stessa cosa.
C
Su questo punto, che è un quesito legale ed importantissimo, ci stiamo lavorando.
Abbiamo chiesto aiuto a degli avvocati e stiamo aspettando una risposta.
Aubrey
Il giorno 07 marzo 2012 21:51, Cristian Consonni kikkocristian@gmail.comha scritto:
Il 07 marzo 2012 21:37, Luca Delucchi lucadeluge@gmail.com ha scritto:
se il db MIBAC ha le coordinate possiamo fare query spaziali che potrebbero semplificare il lavoro segnalando i doppioni nel raggio di tot metri. Inoltre penso sia possibile fare qualche query per cercare nomi simili, non ho idea della query precisa ma ci posso ragionare su L'unica cosa che non ho capito, il bd del MIBAC è disponibile al progetto perchè a quel punto potremmo inserire i dati in OSM :-)
Immaginavo la stessa cosa.
C _______________________________________________ Wlm mailing list Wlm@wikimedia.it http://mailman.wikimedia.it/listinfo/wlm
Questa cosa è di cruciale importanza anche per OSM. Se fosse veramente disponibile con licenza open, sarebbe un grande passo avanti.
Il mibac si è sempre dimostrato molto poco interessato alla diffusione dei propri dati.
2012/3/7 Andrea Zanni aubreymcfato@gmail.com:
Su questo punto, che è un quesito legale ed importantissimo, ci stiamo lavorando.
Abbiamo chiesto aiuto a degli avvocati e stiamo aspettando una risposta.
Aubrey
Il giorno 07 marzo 2012 21:51, Cristian Consonni kikkocristian@gmail.com ha scritto:
Il 07 marzo 2012 21:37, Luca Delucchi lucadeluge@gmail.com ha scritto:
se il db MIBAC ha le coordinate possiamo fare query spaziali che potrebbero semplificare il lavoro segnalando i doppioni nel raggio di tot metri. Inoltre penso sia possibile fare qualche query per cercare nomi simili, non ho idea della query precisa ma ci posso ragionare su L'unica cosa che non ho capito, il bd del MIBAC è disponibile al progetto perchè a quel punto potremmo inserire i dati in OSM :-)
Immaginavo la stessa cosa.
C _______________________________________________ Wlm mailing list Wlm@wikimedia.it http://mailman.wikimedia.it/listinfo/wlm
-- http://aubreymcfato.wordpress.com
Wlm mailing list Wlm@wikimedia.it http://mailman.wikimedia.it/listinfo/wlm
Ho reso disponibile il database OSM in versione sql a questo indirizzo:
(wml è frutto di un errore di digitazione, ma preferisco credere nell'acronimo WikilovesmonumentsMailingList's db). Si può lavorare su di esso grazie all'interfaccia Adminer, per alcune cose migliore del ben più famoso phpMyAdmin
Per motivi di sicurezza, l'accesso è riservato con password. Chi fosse interessato a lavorarci su, mi invii una mail in privato, che sarò felice di dargliela.
Cristian, potresti creare una mailing list temporanea, a parte, per la gestione del db?
Saverio
Il 08 marzo 2012 12:36, Saverio dyskephalos@yahoo.it ha scritto:
Ho reso disponibile il database OSM in versione sql a questo indirizzo:
[...]
Cristian, potresti creare una mailing list temporanea, a parte, per la gestione del db?
Credo che sia un po' "overkill" per il momento. Però penso che valga la pena fare una chiacchierata (via Skype)
Chi fosse interessato si può segnare qua: http://www.doodle.com/dxssuv46zr3827zp#table
Cristian
Il 07 marzo 2012 18:20, massimo.palmieri1@libero.it massimo.palmieri1@libero.it ha scritto:
In attesa che sia deciso il formato con cui scambiare i dati dei monumenti, facendo una ricerca esplorativa su Albano (provincia di Roma) risulta che il db OSM presenta 16 voci, di cui 5 senza descrizione, mentre il db MIBAC ne riporta 61 e le descrizioni dello stesso monumento sono diverse (ad esempio: Sepolcro detto degli Orazi e Curiazi per OSM e Tomba degli Orazi e Curiazi per MIBAC) il che rende difficoltoso integrare i due db, a meno che non si faccia una pura e semplice somma e poi si vadano a scartare i doppioni a mano; anche questa ipotesi è però percorribile per comuni piccoli ma sarebbe, credo, molto complessa per comuni tipo Roma o Napoli. Per quanto riguarda il codice unico va bene utilizzare come prima parte il codice ISTAT, ma per la seconda parte (identificativo del singolo monumento) forse sarebbe meglio utilizzare quello MIBAC in modo da avere, per il futuro, un codice che ci consenta di fare query e integrazioni con i db ufficiali, altrimenti avremo sempre la necessità di andare a verificare a mano le coincidenze.
si può risolvere parte del problema con qualche query...
Massimo
-
Andrea Zanni -
Cristian Consonni -
Luca Delucchi -
Marco Chiesa -
massimo.palmieri1＠libero.it -
Saverio -
Simone Cortesi