Qual è la differenza tra copertura, Shapefile e geodatabase in ArcGIS?

Mi chiedevo quale fosse la differenza nella metodologia di archiviazione dei dati spaziali utilizzata da Coverages, Shapefile e Geodatabase in ArcGIS. La copertura era il formato iniziale, seguito da Shape Files e ora Geodatabase. Quindi, cosa è migliorato in questi nuovi formati di Shapefile e Geodatabase?

Sarebbe bello se qualcuno potesse spiegarlo con esempi.

Questa è un'ottima domanda. Coverages, Shapefile e Geodatabase sono archivi di dati geospaziali fondamentalmente diversi sia dal punto di vista dell'implementazione che da quello filosofico. Proverò a riassumere senza approfondire troppo.

1. Coperture:

Le coperture sono interessanti strutture di dati geospaziali . Si concentrano sulla memorizzazione della topologia. Quindi vedrai che l'enfasi sta nel memorizzare prima gli elementi geometrici, cioè i nodi, i bordi che compongono tutte le geometrie. Vedrai quindi un insieme separato di tabelle che mettono in relazione tali geometrie con gli attributi (e quindi "diventano" caratteristiche).

Una copertura "pulita" garantisce alcune regole, ad esempio che ci sono nodi ad ogni intersezione dei nodi, non avrai due (o più) nodi uno sopra l'altro (o anche entro una distanza di tolleranza sfocata), che non ci sono due bordi uno sopra l'altro, ecc. Hanno anche un senso della direzione (da-> a) e possono distinguere tra ciò che è sul lato sinistro e destro.

Le copertine funzionano davvero bene per le modifiche che richiedono consapevolezza delle relazioni topologiche (immagina di modificare un limite di pacchi). Inoltre, le coperture si comprimono molto bene poiché rimuovono la ridondanza geometrica in base al design. In effetti, vedrai che al giorno d'oggi, formati moderni come TopoJSON hanno iniziato a utilizzare le stesse tecniche apprese dalle coperture diversi decenni fa.

Le coperture possono essere un po 'più complicate con cui lavorare quando si hanno a che fare con dati 3D (ad esempio modellare un ponte che ha un lato superiore e uno inferiore in basso a destra) perché gli algoritmi che abbiamo usato per gestirli erano intrinsecamente intesi per la matematica dei grafici planari 2D .

Quindi perché ci siamo allontanati da esso? Ciò richiederebbe una risposta più lunga, ma forse dovremmo spiegare un po 'di più ciò che ha reso popolari gli Shapefile ESRI per primi.

2. Shapefile ESRI:

Arrivò lo Shapefile. Probabilmente la caratteristica più importante che aveva era che era / è una specifica aperta che era (relativamente) semplice da implementare. Gli attributi sfruttavano i file DBF , quindi c'erano già molte librerie che implementavano gran parte delle specifiche. Non esisteva il concetto di "pulito", il che significava che ogni singola geometria doveva preoccuparsi solo di rappresentarsi senza prendere in considerazione le geometrie intorno a loro o che si intersecavano. Ciò significava che non dovevamo fare alcuna matematica complicata per assicurarci che uno shapefile fosse corretto (diversamente dalla controparte della copertura).

Hai più geometrie che si incrociano? Certo, perché no. Due punti uno sopra l'altro? Essere mio ospite.

A volte, il formato (probabilmente) "migliore" non è quello che vince, ma quello che viene adottato. Se un formato è facile da implementare, ha maggiori possibilità di essere adottato rispetto a uno complicato. Quello era lo Shapefile.

All'improvviso hai avuto diverse librerie (open source e proprietarie) e fornitori di software che lo hanno supportato. Quindi è stato tutto fantastico.

La domanda ovvia è quindi: perché i geodatabase?

3. Database geografici:

Credo che i database geografici siano uno degli archivi di dati geospaziali più fraintesi. Le persone di solito li considerano solo come "un formato geospaziale". Qualche anno fa qualcuno ha chiesto "Cosa sono i database geografici ESRI?" . Invece di ripetere quale fosse la mia risposta allora, ti do il benvenuto a leggerlo prima. Aspetterò :)

Ora che hai letto quella risposta e sai cos'è un Geodatabase, posso espandere un po 'di più su quella risposta. All'epoca, c'erano molte ricerche sull'ottimizzazione di SQL e sulla scrittura di ottimizzatori di query che utilizzavano indici, archivi di colonne, ecc. (Esiste ancora). Costruendo il Geodatabase sopra un archivio dati SQL, possiamo sfruttare tutta questa ricerca gratuitamente. Dobbiamo solo concentrarci sui concetti geospaziali e, man mano che gli archivi di dati SQL migliorano, anche il Geodatabase migliora anche gratuitamente . Non è una cattiva proposta eh?

Oggi ci sono diverse specifiche per i dati geospaziali che vengono fuori. La giuria è ancora là fuori su ciò che sta per sostituire queste tecnologie (semmai). Tuttavia, se sei interessato a questo argomento, ti consiglio di leggere la risposta a una domanda posta qui in GIS.SE alcuni anni fa: "Ci sono tentativi di sostituire il file di forma"

Spero che aiuti!

La maggior parte delle informazioni sono disponibili nella Guida di Esri e in alcune ricerche, quindi ho appena compilato alcune letture.

Come vengono conservate le coperture? Dal momento che è un formato proprietario, non troverai alcuna specifica tecnica su come vengono implementati gli algoritmi (a meno che @Vince non faccia luce).

Gli Shapefile sono arrivati ​​in seguito e sono stati implementati come standard che ha fornito un certo livello di interoperabilità. La descrizione tecnica di Shapefile ESRI contiene una descrizione completa.

I database geografici sono stati introdotti in seguito. Sono arrivati ​​prima i database di dati personali (MS Access), poi i file di geodatabase (formato binario crittografato) e quelli di impresa (o ArcSDE) che hanno sfruttato la tecnologia ArcSDE e DBMS. Puoi leggere di più sui geodatabase qui: Tipi di geodatabase e L'architettura di un geodatabase .

Una buona lettura su GIS.SE: se utilizzare File Geodatabase (* .gdb), Personal Geodatabase (* .mdb) o shapefile?

Per quanto riguarda le prestazioni, sono stati eseguiti molti benchmark e i file geodatabase mostrano che sono i più veloci in termini di lettura / scrittura delle informazioni. I database e gli shapefile personali sono di gran lunga più lenti e probabilmente l'unica ragione per usarli è supportare sistemi più vecchi che sono stati costruiti tenendo conto della logica aziendale di MS Access o della lettura / conversione di shapefile.

Il geodatabase basato su ArcSDE spesso esegue quasi come geodatabase di file quando il DBMS è ottimizzato, ma tutto dipende dal tipo di dati memorizzati, reti e hardware. Per ulteriori informazioni sui parametri di riferimento, consultare le risorse sulle strategie di progettazione del sistema Esri (e qui ).

La differenza principale tra questi formati è il modo in cui le caratteristiche si riferiscono alle geometrie. Nel periodo di massimo splendore delle coperture, il linguaggio di codifica era FORTRAN, che significava dimensioni di buffer fisse nei blocchi COMMON. Il più restrittivo di questi era di 500 vertici per linea primitiva ("arco"). Questa restrizione ha introdotto il concetto di "pseudo-nodi" (luoghi in cui gli archi si uniscono solo con un altro arco) e ha complicato molte altre operazioni di accesso ai dati.

Il modello di copertura utilizzava un "elenco di poligoni ad arco" (PAL) per descrivere i poligoni, che richiedeva un algoritmo di ombreggiatura poligonale per leggere un file per ottenere l'elenco di archi, quindi leggere gli archi stessi per ottenere il conteggio dei vertici, quindi allocare RAM sufficiente per memorizzare tutti i vertici, quindi tornare indietro per leggere nuovamente gli archi, questa volta copiando i vertici in ordine avanti o indietro per assemblare un poligono completo. Solo dopo due visite al file ARC è stato possibile descrivere adeguatamente il poligono e quindi è necessario accedere a molti degli stessi archi (in una direzione opposta) per ombreggiare i vicini poligonali.

In confronto, lo shapefile e vari formati di geodatabase memorizzano la geometria completa come un singolo oggetto (con vari dettagli di implementazione su come l'oggetto viene fisicamente implementato). Ciò ha degli inconvenienti quando si tenta di modificare i confini condivisi, ma tale operazione è significativamente meno frequente dell'ombreggiatura poligonale.

Il modello di archiviazione "intera forma" è la differenza chiave tra il formato di copertura e quelli nuovi, e questa differenza è così fondamentale che è difficile vedere una reale differenza tra lo shapefile e i vari formati di geodatabase. In effetti, il formato dello shapefile è stato utilizzato per accedere alle geometrie FGDB tramite l'API FGDB, anche se FGDB non utilizza quel formato esatto, solo perché era più semplice dell'introduzione di un nuovo layout di vertici.

Un'altra differenza tra i formati è che un geodatabase può modellare le relazioni tra le classi di caratteristiche . Come notato da Ragi,

Le copertine funzionano davvero bene per le modifiche che richiedono consapevolezza delle relazioni topologiche (immagina di modificare un limite di pacchi).

Ma questa consapevolezza esiste solo all'interno di una singola copertura : se si desidera modellare le relazioni tra 2 o più coperture, è responsabilità dell'utente scrivere il codice che verifica eventuali relazioni topologiche "illegali".

Ad esempio, se i poligoni dei pacchi non possono avere spazi vuoti e i confini dei pacchi devono allinearsi esattamente con le strade, con coperture o file di forma, spetta a voi verificare che ciò avvenga e correggere manualmente eventuali errori in cui queste regole non vengono rispettate.

Un geodatabase può facoltativamente supportare un oggetto Topologia , che consente di definire le regole topologiche consentite per i dati. È importante sottolineare che queste regole possono verificarsi sia all'interno che tra le classi di caratteristiche nel geodatabase.

Gli strumenti di modifica della topologia in ArcMap ti aiutano a trovare violazioni topologiche e, in alcuni casi, a risolverle automaticamente .

Prima dell'introduzione della topologia del geodatabase ("i bei vecchi tempi"), era comune scrivere script AML lunghi e complicati per rilevare violazioni topologiche, quindi modificare manualmente le coperture in ArcEdit (non molto divertente).