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