Il geodatabase (Argomento vincitore degli ESRIpolls del blog) – Work in progress
domenica, giugno 25, 2006
Ciao a tutti,
dopo aver fatto lo “spoglio” delle schede votate, come avete visto, l’argomento vincitore degli ESRIpools di Giugno è il Geodatabase.
Vorrei che questo post fosse una sorta di work in progress, ovvero:
io comincio e scrivo ciò che conosco sul GeoDB e tutti coloro che vorranno inserire altre notizie o eventuali correzioni a quanto ho detto potranno commentare il mio post.
Per evitare di disperdere notizie nel blog, vi chiedo di postare tutti i vostri commenti sul Geodatabase in questo post.
Chiunque di voi voglia fare esempi pratici e abbia bisogno di condividere dei files con gli altri lettori li mandi al mio indirizzo di posta elettronica che provvederò ad hostarli per voi.
Per scrivere questi appunti ho usato:
• Videocorso “Il Geodatabase” tratto dal DVD di GISITINERA 2006
• Modeling our world “The ESRI Guide to Geodatabase design” – ESRI press
• Appunti redatti dal sottoscritto al Convegno GISITINERA di PD
Credo sia necessario cominciare dalle fondamenta, per cui io comincio dalla teoria del Geodatabase:
Teoria del geodatabase
Per cominciare il GeoDB è un MODELLO DATI e non un FORMATO DATI.
In pratica lo distingue dallo shape (che è un formato dati) il fatto che all’ interno del GeoDB possono essere memorizzate anche regole e relazioni (sulle features o sugli attributi) che intervengono tra gli oggetti del mondo reale che si cerca di rappresentare al suo interno.
Purtroppo non sempre Enti Locali e Aziende pubbliche fanno riferimento al GeoDB (nato se non sbaglio nel 2000 con arcinfo 8) come contenitore di informazioni geografiche e regole, ma ancora fanno riferimento allo shapefile, visto come il formato standard per l’interscambio di dati cartografici.
Basti pensare all’art. A-27 della Legge Regionale 20/00 dell’Emilia Romagna che fa riferimento unicamente allo shape e non al GeoDB, limitandosi così a dare informazioni sul dato e non sul modello del dato cartografico da condividere a livello Regionale.
Riassumendo con il GeoDB si può:
• Creare delle regole per l’inserimento guidato degli attributi (Domini e sottotipi)
• Regole di validazione topologica per quanto riguarda l’editing delle features
• La possibilità di avere un oggetto scalabile, che può essere sia Personal (file ACCESS .mdb) che Enterprise o multiutente se gira su SQL Server, Oracle, Informix, con l’ausilio di ArcSDE. (l’utilizzo di ArcSDE è facoltativo per DB SQL Server e Oracle)
• L’editing multiutente permette a due o più utenti di editare sulla stessa feature class segnalando ad entrambi eventuali operazioni conflittuali.
Immaginate che ci siano due ESRIdipendenti (Silvio e Romano) che stanno editando su uno stessa feature class poligonale:
Romano cambia la forma di un poligono,contemporaneamente, da un’altra postazione, Silvio cancella quel poligono.
Il sistema segnala a Romano e Silvio che hanno commesso due operazioni che vanno in conflitto fra loro.
• Il GeoDB permette anche l’editing disconnesso, ovvero: prendiamo sempre Silvio e Romano come esempio. Romano inizia l’editazione su una feature class in ufficio, mentre Silvio carica sul proprio portatile parte della banca dati perchè vuole lavorare su quei dati nella sua villa in Sardegna.
Una volta tornato in ufficio Silvio “connetterà il proprio pezzetto di banca dati” al GeoDB completo e, se ci saranno ancora anomalie come quella sopradescritta, il sistema lo segnalerà.
Diciamo che per strutture di dati medio piccole si potrà usare un geodatabase personal, mentre per strutture di dati grandi con molti dati raster da immagazzinare è consigliabile un geodatabase enterprise.
Per la gestione sia del GeoDB Personal che Enterprise si usa ArcCatalog.
In un GeoDB possono essere inseriti dati geometrici vector (feature class stand alone od organizzate in feature datasets), tabelle, dati geometrici raster (raster datasets e raster catalog), regole, relazioni topologiche e tool o modelli realizzati con il model builder.
Come mi correggeva giustamente qualche settimana fa un Gissaro anonimo, se vi sono più feature class all’interno di uno stesso feature dataset, esse prendono il riferimento spaziale del feature dataset stesso.
Questa cosa, che avevo dimenticato, è in realtà una delle caratteristiche principali di un feature dataset, perché, di norma contengono feature class che concorrono allo stesso ambiente topologico o rete geometrica.
Il sistema di riferimento può essere importato da un altro feature dataset precedentemente realizzato, oppure selezionato tra i vari files prj che sono presenti nella cartella : \Programmi\ArcGIS\Coordinate Systems
Quali sono quindi i vantaggi nell’ utilizzo del GeoDB:
1. Tutti i dati geografici sono immagazzinati in un unico “contenitore”
2. Il data entry degli attributi e l’editing delle feature è più accurato, in quanto viene validato dai processi del GeoDB stesso.
3. Possono usare ed editare lo stesso GeoDB molte persone contemporaneamente
La gestione degli attributi di un geodatabase:
Sottotipi: è un modo di raggruppare gli elementi di una feature class in sottoinsiemi,sulla base del valore di un attributo (valore di un campo della tabella degli attributi).
I valori dei sottotipi possono essere solo valori numerici (intero o doppia presicione), quindi se il campo per il quale vogliamo fare i sottotipi è testuale dovremmo aggiungere un campo numerico e codificare i valori testuali in valore numerico al fine di utilizzarlo come campo peri sottotipi. (VEDI FIGURA)
Vi faccio notare una roba molto curiosa:
una volta inseriti i sottotipi in una feature class, utilizzando un campo numerico, se vado in ArcMap, o Arc Catalog e guardo la tabella i valori del campo numerico assumono i valori testuali corrispondenti…..forse non sono stato chiaro ?!??!???!...
Ho provato a fare i sottotipi per una feature class lineare di fiumi:
il campo che volevo utilizzare per i sottotipi si chiamava USO: e poteva assumere i 3 valori : NO_CODE, PROMISCUO, IRRIGUO.
Ho creato un nuovo campo short integer (che ho chiamato sottot), al valore NO_CODE ho associato il valore numerico 1, alla stringa PROMISCUO il valore 2 e alla stringa IRRIGUO il valore 3.
Una volta creati i sottotipi anche il campo numerico che prima presentava ovviamente solo valori 1, 2, o 3, ora sembra essere “trasformato” in un campo testo presentandomi i valori testuali dei sottotipi (anche se nelle proprietà del campo rimane uno short integer)……..strano vero? (VEDI FIGURA)
Una volta importata la feature class con sottotipi in ArcMap viene caricata già tematizzata per il campo dei sottotipi, nel mio caso l’uso del corso d’acqua.
Se andiamo ad editare un nuovo corso d’acqua automaticamente si riempiono i campi i cui abbiamo messo valori di defoult inserendo i sottotipi.
Nel mio caso si sono compilati in automatico i campi “Nome, Prenome ed uso" perché avevo precedentemente immesso, nella finestra dei sottotipi dei valori di defoult.
Domini: L’integrità dei dati alfanumerici contenuti in un geodatabase può essere rafforzata con il Dominio.
I Domini sono delle dichiarazioni dei valori accettabili per un determinato campo di una tabella.
Ci sono 2 dipi di domini:
• Range: in cui l’utente dovrà immettere nella cella valori compresi fra due estremi
• Coded Value: in cui l’utente avrà a disposizione un menu a discesa con inserimento guidato da un combo.
Ho importato nel geodatabase che ho creato come demo uno shapefile lineare che rappresenta le ciclabili del mio Comune. Il campo di nome layer (….ebbene sì, le ho digitalizzate in Autocad….adesso mi metto il cilicio) deve assumere solo i due valori “Sede propria” o “Sede promiscua” a seconda della posizione della ciclabile sulla sede stradale.
Attraverso l’uso dei domini si dovrebbe fare in modo che, editando una nuova ciclabile, non ci fosse la possibilità di inserire erroneamente definizioni sbagliate.
L’inserimento del campo che fa da dominio si effettua nella scheda "Domains" delle proprietà del GeoDB, come vedete dalla prima immagine, mentre per associare il dominio al campo bisogna andare nelle proprietà della feature class nella scheda "field" (seconda immagine)
Dopo aver importato la feature class in Arcmap, se vado in editazione ho la possibilità di compilare il campo layer attraverso un semplice menu a discesa, che contiene, prima di farlo scendere, il valore di defoult impostato nella scheda Fields delle proprietà della feature class.
CHIEDO UNA COSA:
A Padova ho visto (o meglio ho intravisto) una cosa che a me sembrava fantascienza, ovvero la possibilità di costruire il modello dati di un geoDB, con relativi domini e sottotipi, con programmi CASE tipo Visio (quella specie di software che si trova nel CD di Office e che nessuno installa perché “porta via dello spazio per niente”e che nessuno si è nemmeno mai sognato di scaricare con emule perché “porta via banda e non serve a niente”)
Ebbene si, Visio serve a qualcosa!
Se qualcuno ha realizzato un GEoDB con Visio, o ci ha provato, o pensa di sapere qualcosa in merito, posti qui le proprie impressioni.
Grazie a tutti,
vi passo la palla
Ciao
Paolo
dopo aver fatto lo “spoglio” delle schede votate, come avete visto, l’argomento vincitore degli ESRIpools di Giugno è il Geodatabase.
Vorrei che questo post fosse una sorta di work in progress, ovvero:
io comincio e scrivo ciò che conosco sul GeoDB e tutti coloro che vorranno inserire altre notizie o eventuali correzioni a quanto ho detto potranno commentare il mio post.
Per evitare di disperdere notizie nel blog, vi chiedo di postare tutti i vostri commenti sul Geodatabase in questo post.
Chiunque di voi voglia fare esempi pratici e abbia bisogno di condividere dei files con gli altri lettori li mandi al mio indirizzo di posta elettronica che provvederò ad hostarli per voi.
Per scrivere questi appunti ho usato:
• Videocorso “Il Geodatabase” tratto dal DVD di GISITINERA 2006
• Modeling our world “The ESRI Guide to Geodatabase design” – ESRI press
• Appunti redatti dal sottoscritto al Convegno GISITINERA di PD
Credo sia necessario cominciare dalle fondamenta, per cui io comincio dalla teoria del Geodatabase:
Teoria del geodatabase
Per cominciare il GeoDB è un MODELLO DATI e non un FORMATO DATI.
In pratica lo distingue dallo shape (che è un formato dati) il fatto che all’ interno del GeoDB possono essere memorizzate anche regole e relazioni (sulle features o sugli attributi) che intervengono tra gli oggetti del mondo reale che si cerca di rappresentare al suo interno.
Purtroppo non sempre Enti Locali e Aziende pubbliche fanno riferimento al GeoDB (nato se non sbaglio nel 2000 con arcinfo 8) come contenitore di informazioni geografiche e regole, ma ancora fanno riferimento allo shapefile, visto come il formato standard per l’interscambio di dati cartografici.
Basti pensare all’art. A-27 della Legge Regionale 20/00 dell’Emilia Romagna che fa riferimento unicamente allo shape e non al GeoDB, limitandosi così a dare informazioni sul dato e non sul modello del dato cartografico da condividere a livello Regionale.
Riassumendo con il GeoDB si può:
• Creare delle regole per l’inserimento guidato degli attributi (Domini e sottotipi)
• Regole di validazione topologica per quanto riguarda l’editing delle features
• La possibilità di avere un oggetto scalabile, che può essere sia Personal (file ACCESS .mdb) che Enterprise o multiutente se gira su SQL Server, Oracle, Informix, con l’ausilio di ArcSDE. (l’utilizzo di ArcSDE è facoltativo per DB SQL Server e Oracle)
• L’editing multiutente permette a due o più utenti di editare sulla stessa feature class segnalando ad entrambi eventuali operazioni conflittuali.
Immaginate che ci siano due ESRIdipendenti (Silvio e Romano) che stanno editando su uno stessa feature class poligonale:
Romano cambia la forma di un poligono,contemporaneamente, da un’altra postazione, Silvio cancella quel poligono.
Il sistema segnala a Romano e Silvio che hanno commesso due operazioni che vanno in conflitto fra loro.
• Il GeoDB permette anche l’editing disconnesso, ovvero: prendiamo sempre Silvio e Romano come esempio. Romano inizia l’editazione su una feature class in ufficio, mentre Silvio carica sul proprio portatile parte della banca dati perchè vuole lavorare su quei dati nella sua villa in Sardegna.
Una volta tornato in ufficio Silvio “connetterà il proprio pezzetto di banca dati” al GeoDB completo e, se ci saranno ancora anomalie come quella sopradescritta, il sistema lo segnalerà.
Diciamo che per strutture di dati medio piccole si potrà usare un geodatabase personal, mentre per strutture di dati grandi con molti dati raster da immagazzinare è consigliabile un geodatabase enterprise.
Per la gestione sia del GeoDB Personal che Enterprise si usa ArcCatalog.
In un GeoDB possono essere inseriti dati geometrici vector (feature class stand alone od organizzate in feature datasets), tabelle, dati geometrici raster (raster datasets e raster catalog), regole, relazioni topologiche e tool o modelli realizzati con il model builder.
Come mi correggeva giustamente qualche settimana fa un Gissaro anonimo, se vi sono più feature class all’interno di uno stesso feature dataset, esse prendono il riferimento spaziale del feature dataset stesso.
Questa cosa, che avevo dimenticato, è in realtà una delle caratteristiche principali di un feature dataset, perché, di norma contengono feature class che concorrono allo stesso ambiente topologico o rete geometrica.
Il sistema di riferimento può essere importato da un altro feature dataset precedentemente realizzato, oppure selezionato tra i vari files prj che sono presenti nella cartella : \Programmi\ArcGIS\Coordinate Systems
Quali sono quindi i vantaggi nell’ utilizzo del GeoDB:
1. Tutti i dati geografici sono immagazzinati in un unico “contenitore”
2. Il data entry degli attributi e l’editing delle feature è più accurato, in quanto viene validato dai processi del GeoDB stesso.
3. Possono usare ed editare lo stesso GeoDB molte persone contemporaneamente
La gestione degli attributi di un geodatabase:
Sottotipi: è un modo di raggruppare gli elementi di una feature class in sottoinsiemi,sulla base del valore di un attributo (valore di un campo della tabella degli attributi).
I valori dei sottotipi possono essere solo valori numerici (intero o doppia presicione), quindi se il campo per il quale vogliamo fare i sottotipi è testuale dovremmo aggiungere un campo numerico e codificare i valori testuali in valore numerico al fine di utilizzarlo come campo peri sottotipi. (VEDI FIGURA)
Vi faccio notare una roba molto curiosa:
una volta inseriti i sottotipi in una feature class, utilizzando un campo numerico, se vado in ArcMap, o Arc Catalog e guardo la tabella i valori del campo numerico assumono i valori testuali corrispondenti…..forse non sono stato chiaro ?!??!???!...
Ho provato a fare i sottotipi per una feature class lineare di fiumi:
il campo che volevo utilizzare per i sottotipi si chiamava USO: e poteva assumere i 3 valori : NO_CODE, PROMISCUO, IRRIGUO.
Ho creato un nuovo campo short integer (che ho chiamato sottot), al valore NO_CODE ho associato il valore numerico 1, alla stringa PROMISCUO il valore 2 e alla stringa IRRIGUO il valore 3.
Una volta creati i sottotipi anche il campo numerico che prima presentava ovviamente solo valori 1, 2, o 3, ora sembra essere “trasformato” in un campo testo presentandomi i valori testuali dei sottotipi (anche se nelle proprietà del campo rimane uno short integer)……..strano vero? (VEDI FIGURA)
Una volta importata la feature class con sottotipi in ArcMap viene caricata già tematizzata per il campo dei sottotipi, nel mio caso l’uso del corso d’acqua.
Se andiamo ad editare un nuovo corso d’acqua automaticamente si riempiono i campi i cui abbiamo messo valori di defoult inserendo i sottotipi.
Nel mio caso si sono compilati in automatico i campi “Nome, Prenome ed uso" perché avevo precedentemente immesso, nella finestra dei sottotipi dei valori di defoult.
Domini: L’integrità dei dati alfanumerici contenuti in un geodatabase può essere rafforzata con il Dominio.
I Domini sono delle dichiarazioni dei valori accettabili per un determinato campo di una tabella.
Ci sono 2 dipi di domini:
• Range: in cui l’utente dovrà immettere nella cella valori compresi fra due estremi
• Coded Value: in cui l’utente avrà a disposizione un menu a discesa con inserimento guidato da un combo.
Ho importato nel geodatabase che ho creato come demo uno shapefile lineare che rappresenta le ciclabili del mio Comune. Il campo di nome layer (….ebbene sì, le ho digitalizzate in Autocad….adesso mi metto il cilicio) deve assumere solo i due valori “Sede propria” o “Sede promiscua” a seconda della posizione della ciclabile sulla sede stradale.
Attraverso l’uso dei domini si dovrebbe fare in modo che, editando una nuova ciclabile, non ci fosse la possibilità di inserire erroneamente definizioni sbagliate.
L’inserimento del campo che fa da dominio si effettua nella scheda "Domains" delle proprietà del GeoDB, come vedete dalla prima immagine, mentre per associare il dominio al campo bisogna andare nelle proprietà della feature class nella scheda "field" (seconda immagine)
Dopo aver importato la feature class in Arcmap, se vado in editazione ho la possibilità di compilare il campo layer attraverso un semplice menu a discesa, che contiene, prima di farlo scendere, il valore di defoult impostato nella scheda Fields delle proprietà della feature class.
CHIEDO UNA COSA:
A Padova ho visto (o meglio ho intravisto) una cosa che a me sembrava fantascienza, ovvero la possibilità di costruire il modello dati di un geoDB, con relativi domini e sottotipi, con programmi CASE tipo Visio (quella specie di software che si trova nel CD di Office e che nessuno installa perché “porta via dello spazio per niente”e che nessuno si è nemmeno mai sognato di scaricare con emule perché “porta via banda e non serve a niente”)
Ebbene si, Visio serve a qualcosa!
Se qualcuno ha realizzato un GEoDB con Visio, o ci ha provato, o pensa di sapere qualcosa in merito, posti qui le proprie impressioni.
Grazie a tutti,
vi passo la palla
Ciao
Paolo
Etichette: ArcGIS
