[Gfoss] FOSS per metadati applicativi/GeoDB

[aperi2007]

Il 04/06/2011 09:46, Luca Mandolesi ha scritto:
> Quello che obiettavo a Comune e Soprintendenza è la totale mancanza di 
> un sistema e un metodo di gestione dei dati archeologici a livello 
> informatizzato per farli dialogare con dati di tipo urbanistico. Il 
> comune dice che non è lui che deve insegnare a noi archeologi il 
> metodo, la Soprintendenza idem....e gli archeologi che non hanno uno 
> straccio di ordine professionale sanno solo quello che gli dice il 
> prof in aula: voi starete con un panama e un bastone a ciglio scavo a 
> dirigere gli operai!!! 8 )
>
> Quando abbiamo fatto la carta archeologica ci siamo ritrovati a dover 
> inventare l'ennesimo modo di schedare i dati archeologi, creando un db 
> ad hoc, un sistema di layer ad hoc, ecc....
>


> Una gran fatica che alla fine rischiava di non portare a nulla, perchè 
> nessuno  (Soprintendenza o Comune) ci aveva informato che ci sono 
> codici ben precisi nei PTR, PTCP e PSC per poter segnalare una 
> geometria e quindi chi fa il documento di destinazione urbanistica non 
> può usare i dati.
>

L'esigenza di soddisfare le esigenze di piu' branche della scienza e' 
infatti una delle ragioni che mette in crisi (secondo me) il modello del 
DB universale.
Io sono convinto che occorre invece puntare a mantenere degli 
imparentamenti agili tra vari databases che esprimo delle specializzzioni.
In questo senso il DBT serve per fornire dei punti di riferimento (gli 
oggetti che definisce appunto) a cui i vari DB specialistici possono 
riferirsi .
L'idea se vuoi è che basti a mantenere la compatibilita' tra i vari DBs 
specialistici che fanno singolarmente riferimento al DBT per la parte 
geometrica e
per l'identificazione degli oggetti.

La storia del nostro db-edifici va proprio in questa direzione.
Ma certamente anche le altre esperienze citate e che traggono spunto dal 
DBT siano di uguale estrazione.

Secondo me , piuttosto che tentare di mantenere allineati due DB 
specialistici tra di loro, o fonderli ottenendo un super-DB è piu' 
conveniente tenerli riferiti rispetto a un DBT che per sua natura e' 
neutrale (o dovrebbe esserlo) proprio perche' descrive il territorio 
topograficamente.


> Leggendo poi la definizione che mi hai scritto, mi sembra che sia 
> stata scritta non da un archeologo oppure da un archeologo abituato a 
> lavorare nel sud italia e di estrazione classica. Nella gestione 
> urbanistica odierna per quello che ho potuto vedere dai PTR, PTCT e 
> PSC, non si ha mai la percezione che l'archeologia parte appena da 
> sotto la nostra suola nella maggior parte delle aree urbanizzate o 
> rurali. I paesaggi stessi sono "manufatti archeologici", vedi la 
> centuriazione romana.
>

Appunto.
Sarebbe interessante pensare a un db-archeologia che partendo dagli 
oggetti del DBT li specializzi alla luce della visione archeologica del 
mondo.
Per cui un oggetto "scarpata " del DBT, oppure un oggetto "sentiero" del 
medesimo potrebbe anche assumere altri tipi di connotazione in un 
ipotetico DB-archeologia.
Oltre ai piu' ovvi e scontati oggetti di tipo Edificio e EdificioMinore.

Dai una occhiata al plugin RT-Omero, li' si parla di edifici in tutte le 
salse, a partire dagli oggetti che DBT che per loro natura rappresentano 
o potrebbero rappresentare porzioni di un edificio.
Unita-Volumetriche, VolumetrieInAggetto e Manufatti-Di-Arredo-Urbano.
Con possibilità di evoluzione se dovesse emergere che tali tipologie di 
oggetti non sono sufficienti allo scopo.
Poi la base dati e' legata a specifiche esigenze di chi ha avviato 
questa sperimentazione.
Pero l'idea di base puo' essere riciclata anche ad altri contesti.

Inoltre se hai qualche suggerimento su qualche campo che potrebbe 
mancare fai pure presente.

Andrea.