Si Renzo, c'è parecchia sovrapposizione di ruoli e di competenze, con poca compartecipazione sugli aspetti tecnici. In alcune occasioni mi è capitato di sentire che il ruolo del Comitato (quello di cui CNIPA gestisce la segreteria tecnica) discende direttamente dalla riforma del Titolo V della Costituzione<http://www.quirinale.it/costituzione/costituzione.htm> : art. 117 - "*Lo Stato ha legislazione esclusiva nelle seguenti materie ... r)* pesi, misure e determinazione del tempo; coordinamento informativo statistico e informatico dei dati dell'amministrazione statale, regionale e locale; opere dell'ingegno;
Quanto esposto sul sito CNIPA<http://www.cnipa.gov.it/site/it-IT/Attivit%25c3%25a0/Sistemi_Informativi_Territoriali/>ribadisce questo ruolo: Il Comitato opera sulla base delle direttive del Ministro ed è finalizzato a sostenere la formazione, l'interscambio e la fruizione dei dati territoriali tra le diverse pubbliche amministrazioni. In sintesi i suoi compiti: proporre la normativa primaria e secondaria e le regole tecniche e standard di riferimento in materia di formazione, gestione, diffusione, interscambiabilità ed utilizzazione dei dati geografici informatici; In un momento "caldo" come quello verso cui stiamo andarndo (adozione direttiva INSPIRE, messa in opera delle Implementing Rules, adozione di norme EN-ISO-19100, trasposizione in leggi e norme italiane, ...) credo sia necessario fare molta chiarezza su chi è deputato a far cosa. Per esempio: nell'allegato del Manifesto della proposta per un'Authority geodetica italiana ( http://www.commissionegeodetica.it/compiti.html) si parla di "Rappresentanza internazionale, per le obbligazioni da assumere collegialmente sia a livello europeo che mondiale": questa frase è sbagliata, poichè questo ruolo, almeno in sede ISO e CEN, è già riconosciuto ufficialmente a UNI, che per le informazioni geografiche delega UNINFO (--> vedi http://www.cnipa.gov.it/site/_files/Standard.pdf pag. 2). Il problema vero è interfacciare tutti i diversi soggetti coinvolti in attività di normazione (Commissione geodetica, Comitato per le Regole Tecniche, CNIPA, UNINFO, IntesaGIS, Centro Interregionale, ...) in modo che inizino a collaborare non solo formalmente ma anche su aspetti di contenuto. Questo è possibile solo se: 1. si definiscono in maniera chiara i reciproci ruoli, i compiti, i programmi di lavoro, e se ne definiscono insieme i diversi contenuti, in modo da evitare accavallamenti o lacune; 2. si instaura uno scambio virtuoso e reciproco di informazioni sulle attività dei diversi soggetti (soprattutto per quanto riguarda attività in ambito internazionale); questo attraverso partecipazione reciproca ai diversi working group, attraverso contatti email, forum, etc (es. a livello ISO/TC211 e CEN/TC287 è normale che, oltre agli enti nazionali di standardizzazione vi siano liaison esterni: OGC è un liaison esterno del TC211: http://www.isotc211.org/organizn.htm) pg On 7/24/07, Renzo Carlucci <[EMAIL PROTECTED]> wrote:
Certo ci troviamo in una situazione un pò paradossale. Basare la realizzazione di specifiche di lavorazione cartografica su gruppi che in pratica devono agire come "volontariato" potrebbe creare un danno considerevole alla nostra comunità. Le specifiche di creazione dei contenuti geometrici e qualitativi della cartografia fino a ieri si sono basati sulle specifiche realizzate dalla Commissione Geodetica Italiana che era stata investita per questo dalla Legge quadro degli organi cartografici dello Stato. Per questo è nata l'iniziativa che ha portato al Manifesto http://www.commissionegeodetica.it per guidare una proposta parlamentare che colmi il vuoto creato sia a livello di contenuti che a livello legislativo dalla abolizione di tale Commissione. -- Renzo Carlucci ([EMAIL PROTECTED]) > Grazie mille Giovanni. > Continuo ad avere dubbi sulla natura di questi documenti: sul sito > vengono definiti "specifiche", ma in ambito ISO, CEN e UNI non mi è > mai capitato di vedere cose simili (mi riferisco ai commenti generali > inviati come AMFM). > A proposito: se siete ancora interessati all'idea di scrivere ... ho > appena notato che sul sito > < http://www.cnipa.gov.it/site/it-IT/Attivit%25c3%25a0/Sistemi_Informativi_Territoriali/DB_25K/ > > di CNIPA è ancora presente questa indicazione: > "Tali documenti, *in versione draft*, vengono pubblicati al fine di > consentire, una seconda fase di condivisione e revisione allargata a > tutti i soggetti interessati (Amministrazioni, comunità scientifiche, > esperti e aziende di settore, …). > Pertanto, al fine di consolidare il documento per la successiva > approvazione da parte del Comitato, sarà possibile inviare commenti, > integrazioni e osservazioni direttamente alla segreteria della > Direzione Lavori, Ricerca e Sviluppo dell'I.G.M. al seguente indirizzo > e-mail: > [EMAIL PROTECTED] > <mailto: [EMAIL PROTECTED]> indicando l'oggetto > "Specifiche DB25 ". > > Pronti con carta, penna e calamaio ? > > > > On 7/23/07, *G. Allegri* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > wrote: > > Risposta dall'IGM: > > "All'interno dell'IGM si usa solo software Intergraph per la > produzione delle > carte (MDB di Geomedia per la creazione del dato, vestizione grafica e > stampa csempre con la solita Società). Capisco la domanda, che sorge > spontanea, ma non si ci voleva impelagare in troppe difficoltà ed > avere > quale consegna un unico formato da parte delle ditte, quello con > cui ogni > operatore ha una certa familità. Le ditte che fanno restituzione > spesso > usano il software GCARTO (software italiano) che permette di > uscire con tuti > i formati più comuni. Quindi nessun problema per nessuno in ambito > cartografico. Chi parte dai dati e crea GeoDB può invece > utilizzare solo > ArcGIS ma questo non accade per chi fa fotogrammetria. > Fino a poco tempo fa l'IGM cedeva i dati in VPF, poi in MDB; fra > poco sarà > possibile ricevere i dati nei formati più comuni (compreso Shape). > Un pò di > pazienza e si renderà la vita meno difficile a tutti gli utenti. > Ad esempio > il nuovo software Verto (convrsione coordinate nei vari sistemi) potrà > essere utilizzato direttamente su shape file. Pochi mesi e le cose > miglioreranno.....stiamo lavorando per voi" > > Giovanni > > Il 19/07/07, *Piergiorgio Cipriano* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED] >> ha scritto: > > Ragazzi, > senza polemica ... ma credo ve ne siete accorti un po' in > ritardo! > CNIPA aveva pubblicato questi documenti > < http://www.cnipa.gov.it/site/it-IT/Attivit%25c3%25A0/Sistemi_Informativi_Territoriali/DB_25K/ > > all'inizio del 2006 e aveva chiesto osservazioni e commenti. > AMFM aveva mandato le osservazioni qui sotto (non mi sembra > siano state recepite ...): NON è solo un problema di FORMATO > DI INTERSCAMBIO !! > Scrivere a CNIPA?? Attenzione: i documenti non sono stati > "prodotti" da CNIPA in sè, ma da un Comitato > <http://www.cnipa.gov.it/site/it-IT/Attivit%25c3%25a0/Sistemi_Informativi_Territoriali/I_lavori_del_Comitato/ > > in cui, oltre CNIPA in funzione di segreteria tecnica, vi > erano Ministeri vari, IGM, rappresentanti di Regioni, UPI, > ANCI, UNCEM, etc. > A quel tempo, il Comitato di cui sopra era "temporaneo", nel > senso che doveva ancora essere emanato il Decreto di > istituzione del " Comitato per le regole tecniche sui > dati territoriali delle pubbliche amministrazioni > < http://www.cnipa.gov.it/site/_files/DECRETO%25202%2520Maggio%25202006%2520n.%2520237_.pdf >". > > In ogni caso, se interessa, nella pagina di presentazione > < http://www.cnipa.gov.it/site/it-IT/Attivit%25c3%25a0/Sistemi_Informativi_Territoriali/ > > trovate questo indirizzo mail: comitato.sit[at]cnipa.it > > (Osservazioni AMFM) > > Dal punto di vista di una "specifica" NON è pertinente > dettagliare informazioni di carattere implementativo, > riferendosi ad una particolare soluzione software (Geomedia), > che dovrebbe rimanere quanto più slegata dal modello dati. > Come scritto il documento è una esemplificazione del formato > BLOB di Geomedia, quindi nemmeno una specifica descrittiva > tale formato. > > I documenti sono tutti del 2003 (uno solo del 2004): già > questo impedisce DI FATTO un confronto con la specifica 1n1007 > sui db Topografici dell'IntesaGIS, la cui "versione definitiva > per la sperimentazione" è del 2004. > In generale, non è chiaro lo scopo di questi documenti: non > sembra raggiungere gli "obiettivi di consolidamento delle > specifiche tecniche relative alla produzione e organizzazione > dei dati territoriali di base in modalità informatica" > indicati nella presentazione di tali specifiche. > In particolare non è chiaro il rapporto tra i documenti IGM e > la specifica 1n1007_6 (Specifiche di contenuto – La > derivazione del DB25) > > Non ci sono riferimenti né relazioni con le altre specifiche > pubblicate dal Comitato (metadati e ortofoto). > In particolare, per i metadati è opportuno che una specifica > DB25 recepisca in maniera chiara ed esplicita gli elementi > essenziali di metadato (fonte, aggiornamento, qualità, …) > > I documenti hanno carattere di specifica tecnica, ma sono > privi delle necessarie indicazioni per poter essere > considerate specifiche di livello nazionale; alcuni motivi: > • manca un'adeguata introduzione, uno scopo, un campo di > applicazione > • mancano riferimenti a standard e specifiche relativi a DB > topografici (es. ISO, CEN, UNI, ... specifiche IntesaGIS, …) > • mancano riferimenti incrociati tra i documenti > > In particolare non sono presenti riferimenti a standard che > hanno un impatto diretto su implementazioni di DB25, quali > • ISO19110 (feature catalogue) > • ISO19114 (quality) > • ISO19115 (metadata) > • ISO19117 (portrayal) > • ISO19136 (GML) > > Il paragrafo descrive un'implementazione esistente, fortemente > dipendente dalla tecnologia utilizzata, e riporta indicazioni > precise sul numero di tabelle, sulla decodifica usata (FACC), > sui sistemi di riferimento. > Questa è una descrizione implementativi, che potrebbe non > essere utile e utilizzata se non all'interno di IGM, o di un > altro ente dotato dei medesimi strumenti software. > La codifica utilizzata nel documento non è quella FACC. > > Si fa riferimento esplicito a Microstation (Bentley) come > soluzione software per l'acquisizione di elementi geometrici e > per la generazione di oggetti areali. > In una specifica tecnica, ed in particolare per specifiche di > livello nazionale, è SBAGLIATO riferirsi a modelli > implementativi o a soluzioni software predefinite. > > Il documento focalizza di più l'attenzione sulle tecniche > messe a punto per rappresentare oggetti territoriali a scale > minori, quindi più dal punto di vista di chi/ cosa/ come deve > raffigurare tematicamente che non di chi deve costruire il > dato per il 25K partendo da quello "Intesa" (es. DBTopo 10K). > > Si parla di suddivisione in fogli 50K. > Sono convenzioni che NON riguardano né il modello concettuale > né il modello implementativi di una base dati, bensì criteri > finalizzati all'organizzazione ed alla gestione di > allestimenti cartografici, specifiche del contesto IGM. > > Dal punto di vista di una "specifica" NON è pertinente > dettagliare informazioni di carattere implementativo, > riferendosi ad una particolare soluzione software, che > dovrebbe rimanere quanto più slegata dal modello dati. > > Si parla di acquisizione tramite restituzione fotogrammetrica, > e non di derivazione. > Questo contrasta con i principi e gli obiettivi di > derivabilità di DB 25 a partire da DB di scale maggiori (10K, 5K). > Non c'è relazione con il documento 1n1007_6 del WG1 IntesaGIS > > Non c'è relazione con il documento 1n1007_5 (La codifica di > contenuto in GML) del WG1 IntesaGIS > > > > > > > > > On 7/19/07, *Paolo Cavallini* <[EMAIL PROTECTED] > <mailto: [EMAIL PROTECTED]>> wrote: > > concordo. > procedura: > - un (gruppo di) volontari(o) scrive la lettera sul wiki > - un volontario cerca l'indirizzo a cui mandarlo > - il presidente verifica ed invia. > Ale, cominci tu? > pc > > Alessandro Sarretta ha scritto: > > Intanto si potrebbe chiedere qualche spiegazione > ufficiale al CNIPA come > > GFOSS.it, magari insieme a FreeGIS-Italia, tanto per > essere sicuri che è > > come sembra... > > Ale > -- > Paolo Cavallini > http://www.faunalia.it/pc > > > _______________________________________________ > Gfoss mailing list: 234 iscritti (13-07-2007) > [email protected] <mailto:[email protected]> > http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss > > > > > > -- > Piergiorgio Cipriano > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > -- > Piergiorgio Cipriano > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > ------------------------------------------------------------------------ > > _______________________________________________ > Forumigt mailing list > [EMAIL PROTECTED] > http://lists.forumigt.it/mailman/listinfo/forumigt > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19/07/2007 18.10 > -- Renzo Carlucci A&C2000 s.r.l. Via E. D'onofrio 212 00155 Rome Italy Phone: +39 06 62279431 Fax: +39 06 83391180
-- Piergiorgio Cipriano [EMAIL PROTECTED]
_______________________________________________ Gfoss mailing list: 235 iscritti (23-07-2007) [email protected] http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
