Ci sono tentativi di sostituire lo shapefile? [chiuso]


67

Di recente ho trascorso molto tempo a convertire nomi di campi perfettamente validi come "Percentuale di cittadini di età pari o superiore a 25 anni con un diploma di laurea o superiore" in cose come "edbchogtr" per rispettare il limite di 10 caratteri del campo di DBF.

In un altro thread ( "Stranezze" nella specifica tecnica di Shapefile ), geospatialpython ha commentato che "Nonostante i difetti, le stranezze e le limitazioni del formato shapefile persiste ostinatamente dentro e intorno al campo di GIS. Ogni altro tentativo di sostituirlo è stato troppo gonfiato per archiviazione vettoriale semplice o troppo proprietaria ".

Questa attività unita al commento di Mr. Lawhead mi fa chiedere:

  • sono mai stati fatti tentativi espliciti di sostituire lo shapefile come l'onnipresente formato di archiviazione e scambio di dati di GIS?
  • Ci sono contendenti?
  • Se ci sono stati formati concorrenti, perché hanno fallito?
  • Esri ha rifiutato di sostenerli o la storia è semplicemente una questione di inerzia tecnologica?
  • Se non ci sono stati tentativi ... perché no?

Sembra che potremmo fare un po 'meglio per noi stessi, sia come sviluppatori GIS che come utenti.


2
@Mapperz Oltre all'API Geodatabase recentemente rilasciata, non vedo alcuno strumento per scrivere un geodatabase gratuito. Non penso che questo possa essere considerato un rimpiazzo se non nella parte ESRI del mondo.
Canisrufus,

2
Puoi scrivere e leggere geodatabase (tramite API) utilizzando GDAL gdal.org/ogr/drv_filegdb.html utilizzando resources.arcgis.com/content/geod
Database

1
Vorrebbe vedere l'API Python per leggere / scrivere File Geodatabase (almeno Funzionalità semplici) senza licenza ArcGIS - sarebbe Open.
PolyGeo

2
@PolyGeo tu e tutti gli altri :)
Ragi Yaser Burhum,

3
@celenius Da gdal.org/ogr/drv_shapefile.html "Geometria: il formato Shapefile utilizza esplicitamente offset a 32 bit e quindi non può superare gli 8 GB (in realtà utilizza offset a 32 bit per parole a 16 bit). Pertanto, non è consigliabile utilizzare un file dimensioni superiori a 4 GB. Attributi: il formato dbf non ha offset, quindi può essere arbitrariamente grande. " Quindi puoi avere dbfs piuttosto grandi, ma devi stare attento con il tuo shp che supera i 4 GB. Quindi stai giocando con il fuoco.
Ragi Yaser Burhum,

Risposte:


50

Questo è un argomento che emerge sempre. Potrei non avere la risposta giusta, ma posso darti la mia opinione personale .

Il motivo per cui sono supportati, può essere attribuito a diverse caratteristiche su di essi, quindi vorrei menzionarne alcuni.

  • Innanzitutto, c'è una specifica . Voglio dire, ho circa trent'anni e questa cosa esisteva da quando ero un adolescente. Quindi è sicuro di dire che questa specifica è in circolazione da un po 'di tempo. Naturalmente, ci sono anche molti altri formati pubblicati, ma la differenza su questo è che ...

  • È relativamente semplice! È basato sul formato DBF , che al momento esisteva già ed era ampiamente supportato su diverse piattaforme / sistemi operativi. Esistevano già parser in grado di leggere la metà di questo formato (la parte DBF), quindi rendeva più semplice supportare l'aggiunta aggiuntiva. Hai una geometria? Certo, basta serializzarlo e scriverlo. Hai fatto. Contrastare questo con una copertura ! Cerca di spiegare a qualcuno in termini semplici cosa fa una topologia pulita . Non è banale scrivere una copertura topologicamente pulita.

  • Ancora più importante, penso che il motivo numero 1 per cui gli shapefile siano ancora popolari è che sono supportati sia nei sistemi Open Source che proprietari . Quale GIS sai che non supporta gli shapefile?!? Inaudito.

In sostituzione, sentiamo parlare di File GeoDatabase e Spatialite . Entrambi i formati sono notevolmente superiori in termini di funzionalità, flessibilità, velocità, ecc. Rispetto ai Shapefile. A modo loro, hanno alcune cose che le rendono migliori l'una dell'altra in diverse aree, ma un confronto tra spazialite e FileGDB è certamente fuori dall'ambito di questa domanda.

Penso che uno di questi formati sostituirà Shapefile? Non nelle loro attuali incarnazioni .

Perché?

Non a causa di un argomento tecnologico (ho detto che dopo tutto erano superiori in quell'aspetto), ma a causa di qualcos'altro: la licenza.

Quindi quali sono i loro problemi?

FileGDB :

FileGDB fornisce interoperabilità attraverso la nuova API FileGDB. Tuttavia, questa API è fornita in formato binariodall'ESRI. Questa non è una specifica. Avendo lavorato nel team di GeoDatabase in passato, posso dirti che, contrariamente a tutti i teorici della cospirazione che indossano un cappello di stagnola, questo non è affatto malevolo. È perché le parti interne del GeoDatabase cambiano ad ogni versione. Pubblicare una specifica completa implicherebbe sostanzialmente fornire tutti i dettagli su come dovrebbe essere gestito tutto e quindi documentare attentamente le modifiche al formato ad ogni versione annuale. Non ha senso. Quindi l'API FileGDB, anche se non è una specifica, estrae tutte quelle piccole modifiche. E ora può essere utilizzato multipiattaforma! Intendiamoci, questo è un enorme passo avanti! Considerando la natura conservatrice dell'ESRI, questa è sicuramente una reazione nella giusta direzione.

Eppure, il supporto solo binario non rende troppo felice nessuno nel mondo Open Source. Come trarre vantaggio dal porting del codice per dire a qualche altra versione di Linux se ESRI non lo supporta. Non puoi. Questo è ciò che rende potente l'Open Source e ora non puoi trarne vantaggio. Se ESRI decide di smettere di supportare Debian, questo è tutto. Hai fatto. E non c'è niente che tu possa fare per cambiarlo.

Spazialità :

Spatialite è eccezionale perché ottiene tutte le funzionalità gratuite da SQLite . SQLite è usato ovunque. È sul tuo telefono Android, sul tuo iPhone / iPad, su Firefox, su Google Chrome, su diversi dispositivi commerciali incorporati - può andare avanti per sempre. Per trasformarlo davvero in un Geoformat (e non solo fare stupide operazioni con i box di delimitazione), deve sfruttare la stessa libreria di geometrie utilizzata da PostGIS: GEOS . Purtroppo, GEOS si basa su un'altra libreria di geometria ancora più straordinaria conosciuta come JTS . Tutti gli algoritmi in JTS sono estremamente potenti, quindi qual è il problema?

Bene, JTS è concesso in licenza come LGPL Open Source e LGPL è una licenza virale . JTS è LGPL, significa che GEOS è LGPL, significa che spazialite collegata staticamente con GEOS è LGPL. Questo fa schifo. Perché? Senza spiegare troppo le licenze open source , posso dirti che, ad esempio, non posso usare spatialite su un'app per iPhone perché ciò renderebbe la mia intera app automaticamente open source (iOS consente solo collegamenti statici). Qualsiasi tipo di licenza GPL (ragionevolmente) spaventa l'ESRI e quindi non la toccheranno con un palo da 10 piedi. Quindi, ArcGIS, il sistema GIS più popolare al mondo non supporta (e probabilmente non potrà mai) supportare nativamente la spazialite. Questo lo uccide automaticamente come un formato praticabile.

E così torniamo a shapefile scadenti che sono supportati ovunque.

Aggiornamento :

Apparentemente la mia risposta è stata abbastanza controversa che qualcuno ha deciso che era OK modificare liberamente e cambiare l'intero significato della mia risposta per esprimere il loro punto di vista. Per favore, non farlo. Se non sei d'accordo con me, va benissimo, pubblica la tua opinione in una risposta diversa e lascia decidere alla community. Ho eseguito il rollback delle modifiche alla mia risposta per mostrare il significato originale. Sto aggiungendo questo aggiornamento nel caso in cui leggessi la risposta modificata che affermava che sqlite era un formato praticabile.


Il problema con SQLite / Spatialite è che non è un formato, è un motore di database relazionale con sopra una libreria spaziale. Mentre fa ciò che fa molto bene, impone che i dati vengano archiviati in modo relazionale, il che non è sempre il modo più adatto. Inoltre, la complessità del formato file SQLite ( sqlite.org/fileformat2.html ) rende difficile l'accesso ai dati senza il motore SQLite e non è quindi adatto per essere un formato file aperto e facilmente accessibile per lo scambio di dati. Non è stato progettato per questo.
Igor Brejc,

8
In realtà, LGPL non è una licenza virale, è stata appositamente progettata per evitarlo. Inoltre, Spatialite è concesso in licenza in base alla licenza tri MPL ( fonte ), il che significa tra l'altro che è possibile scegliere la Licenza pubblica Mozilla come la licenza più adatta e operare in base ai suoi termini (molto deboli). La mia lettura almeno è che ESRI non ha motivo di non supportare Spatialite a causa della licenza - se lo faranno (dato che compete quasi nello stesso spazio di FileGDB) è un'altra storia ...
om_henners,

3
@Ragi, esegui il mix utilizzando una libreria e il porting . Ovviamente il porting dovrà essere LGPL, dal momento che si tratta essenzialmente di un'opera derivata. Ma se lo colleghi dinamicamente, non è considerato un lavoro derivato, è "lavoro che utilizza la libreria" e riesci a conservare la tua licenza ( en.wikipedia.org/wiki/GNU_Lesser_General_Public_License ). Quindi dire "LGPL è virale" senza ulteriori spiegazioni non è accurato.
Igor Brejc,

2
Ma ancora una volta, questo è un punto controverso, poiché Spatialite è concesso in licenza secondo uno schema con licenza ad albero ( groups.google.com/forum/?fromgroups#!topic/spatialite-users/… ), quindi puoi scegliere la licenza adatta più di te - MPL consente il collegamento statico.
Igor Brejc,

2
@ bugmenot123 Bene, quindi correggilo se lo desideri, ma non accusarmi di diffondere FUD sul sistema operativo perché è offensivo. Sto scrivendo il codice OS da oltre un decennio (non sarei sorpreso che tu abbia usato alcuni dei miei in realtà) e che non fosse una collera arrabbiata. Era vero - e lo è ancora. Collegamento dinamico in iOS di LGPL (beh, per essere precisi, i framework erano consentiti in iOS 8). Questo non è mai stato un problema tecnico, ma legale. La distribuzione nell'Appstore richiede la firma del codice - e purtroppo per tutti gli amanti del sistema operativo come me - LGPL è una licenza fuzzy per questo. Nessun precedente in tribunale.
Ragi Yaser Burhum,

18

La parte SHP + SHX in sé non è poi così male. Il vero problema sta nella parte DBF. Ciò potrebbe avere a che fare con un nuovo formato, che supporta unicode e tutti i tipi di campi moderni. Il problema è che è ben supportato da tutto il software disponibile.


6
+1 Anche il miglioramento da parte di DBF non è affatto difficile: si tratta in realtà di convincere gli sviluppatori di software a concordare qualcosa.
whuber

1
C'è stato un tentativo?
Canisrufus,

5
Ho spesso chiesto un emendamento a Shapefile che ha semplicemente sostituito un file CSV UTF-8 per il DBF. Sarebbe semplice da supportare e richiedere modifiche minime ai pacchetti software esistenti.
scw,

1
@canis Fox Software ha fatto un piccolo tentativo (proprietario) alla fine degli anni '80. Dopo che MS li acquistò (c. 1990), fu quello. La community ha creato uno standard DBF 3 e questo ha praticamente bloccato tutto lo sviluppo. MS ha rilasciato Access; FoxPro si estinse; il mondo è andato avanti.
whuber

1
Al contrario, @Uffe, i file CSV sono accessibili in modo casuale: hai solo bisogno di un indice, proprio come fanno i file DBF per ricerche efficienti. Il problema più grande che vedo è che modifiche apparentemente minori che accadono naturalmente ai file CSV, come la citazione di stringhe o conversioni CR / LF, rovineranno tutti gli offset di byte. La struttura dei record a lunghezza fissa di un file DBF, sebbene meno efficiente nell'archiviazione, non presenta questo problema.
whuber


7

Almeno spatialite ha l'intenzione, vedi ad esempio questa presentazione http://www.sourcepole.ch/assets/2010/9/10/foss4g2010_spatialite.pdf

D'altra parte, credo che il motivo principale del fallimento sia che shp è ben supportato da molte applicazioni e presenta solo lievi carenze.

Anche altri condividono questa opinione:

Ciò non è dovuto al fatto che il progetto SpatiaLite non ci ha fornito strumenti per implementarlo, è stato alla comunità che potrebbe interessarsene di meno. SHP funziona per loro e non c'è motivo di cambiare.

http://www.spatiallyadjusted.com/2010/09/16/spatialite-is-not-the-shapefile-of-the-future/

Altre riflessioni sul file geodatabase Esri, spatialite e autodesk sdf qui: http://www.spatialdbadvisor.com/blog/121/the-shapefile-manifesto


Per quanto sia bello spatiaLite, sono ~ 3 megabyte di sovraccarico in funzioni, sistemi di riferimento, ecc. Che gli impediscono di essere un buon formato di scambio completo.
Scro,

In realtà, la licenza per spatialite è tutt'altro che ideale - non ha nulla a che fare con gli strumenti.
Ragi Yaser Burhum,

@Scro, 3 megabyte è troppo grande? Certamente non è troppo grande per il desktop. Devi considerare i dispositivi mobili. Inoltre, esiste un'altra API spaziale, con funzionalità equivalenti, di dimensioni inferiori rispetto a Spatialite?
Klewis,

@klewis - non è di per sé troppo grande, è solo molto inefficiente se si considera che ci sono molti set di dati piccoli (si pensi a <200kb) là fuori. Questo è un sacco di sovraccarico, soprattutto alla luce del fatto che, una volta ricevuto, in genere lasceresti ogni set di dati nel suo file 3mb o lo arrotoleresti in un database esistente. Per essere chiari, io <3 spatiaLite - ma stiamo parlando della trasmissione dei dati, dove una sorta di file flat / xml / wkb sarebbe molto più efficiente.
Scro,

6

Esri promuove File Geodatabase da diversi anni ormai in sostituzione di shapefile.

Più recentemente hanno fornito un'API che nasconde eventuali stranezze.


Non ho lavorato molto con i database geografici. Wikipedia afferma che sono uno standard "chiuso", ad esempio le specifiche del geodatabase non sono state pubblicate. Sembra difficile ottenere un'adozione molto ampia senza pubblicare gli interni del formato. Mentre sono troppo giovane per conoscere la storia, credo che gli shapefile siano in parte così popolari a causa della parte pubblica delle specifiche. L'API sembra un buon passo.
Canisrufus,

1
@canis hai ragione. All'epoca nessuno avrebbe adottato gli shapefile tranne che ESRI li aveva promossi specificamente come un formato di scambio di dati GIS aperto. Anche con gli strumenti software limitati disponibili al momento, con il rilascio di ESRI di una chiara specifica .shp / .shx (e l'impegno a rispettarlo), è diventato solo un lavoro di poche ore per scrivere codice da leggere e scrivere shapefile: non è necessario il reverse engineering.
whuber

Finché l'API è un BLOB binario a scatola nera, FGDB non vedrà la stessa adozione di SHP. Anche se Esri convince tutti i suoi clienti a passare a FGDB da SHP, l'API non è realmente compatibile con l'open source.
Dericke,

3

Un dialetto XML, come GML, non è sicuramente ottimizzato per gestire enormi set di dati, ma può essere utilizzato come formato di scambio tra software o tra piattaforme.

Non credo che ci siano problemi con le licenze (vedi il post di Ragi Yaser Burhum sulle caratteristiche virali di Spatialite) ed è abbastanza facile adattare i parser esistenti, se necessario.


1
Penso che non sia stato menzionato solo per il motivo per cui stai presentando, che non è ottimizzato per grandi set di dati. XML è gonfio. I formati menzionati qui sono binari, in cui GML memorizza i punti come stringhe. La dimensione può essere superiore a un ordine di grandezza diverso.
Canisrufus,

3
Canisrufus ha ragione. Esistono diversi problemi con GML. L'Infoset può essere navigato usando XPath, ma chiunque abbia tentato di implementare l'indicizzazione spaziale su XML ti dirà quanto questo sia irrazionale e quanto male si associ ai tradizionali database relazionali. Senza entrare in molti dettagli, se qualcosa di semplice come l'indicizzazione e l'interrogazione non diventa banale, il formato è gonfio e in pratica richiede di avere l'intero set di dati in memoria per fare qualcosa con esso, quindi questa non è una buona opzione.
Ragi Yaser Burhum,

4
XML è gonfio se archiviato come testo normale. Esistono librerie xml binarie disponibili gratuitamente (sia gratuite che modificabili e ridistribuibili) che possono fungere da drop in sostituzione dei lettori xml, offrendo alle persone la libertà di utilizzare sia la leggibilità umana di xml sia l'efficienza delle prestazioni e dell'archiviazione dei binari . L'unica ragione a cui riesco a pensare perché non è mai stato ripreso in larga misura è come osserva Johandvw sopra : a nessuno importa, .shp è stato "abbastanza buono" come lo è.
Matt Wilson

1

Giusto per giungere a questo punto di vista da un'altra prospettiva, non sono sicuro che l'uso di "Percentuale di cittadini di età pari o superiore a 25 anni con un diploma di laurea o superiore" sia un nome di campo perfettamente valido. Mentre è possibile gestire la miscelazione di spazi e apostrofi, se si sta scrivendo codice o query è più probabile introdurre bug.

A mio avviso, il futuro della distribuzione dei dati spaziali dovrebbe concentrarsi sul web e sui servizi web e la specifica WFS (che utilizza GML) è aperta e consolidata. GeoJSON è più piccolo e può essere più facile lavorare con JavaScript. Tuttavia con la compressione le dimensioni sono comparabili.

Vorrei anche votare per i database geografici personali dell'ESRI . Può essere un formato Microsoft spesso diffamato, ma supporta ODBC, query SQL, viste e consente ai non sviluppatori di creare semplici moduli di immissione dati e includere almeno un certo livello di controlli di integrità dei dati (tipi di dati, lunghezze, valori univoci) .


Questo è un punto valido. La cosa buona di loro è che data la conoscenza della lingua inglese, si può capire cosa significano i campi.
Canisrufus,

Questo è davvero il ruolo dei metadati dei set di dati. Lo shapefile può usare un file XML con lo stesso nome per archiviarlo.
geographika,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.