Tussen het starten van een nieuwe functie en het genieten van de zomer is het een tijd geleden sinds ik voor het laatst heb geblogd. Hoewel ik van plan ben de Iterable Cursor-serie af te maken, liep ik recht tegen een beperking aan, en een daaropvolgende bug, van de file geodatabase die ik het waard vond om te delen. Eerst de beperking....<\/EM><\/P><\/P>Toen de file geodatabase (FGDB) in 2006 werd geïntroduceerd, werd deze geprezen als een verbeterd, hoogwaardig alternatief voor de personal geodatabase (PGDB). Het is waar dat grote datasets en grote verzamelingen van datasets uitdagingen vormen voor de personal geodatabase. Ten eerste zijn Microsoft Access-gegevensbestanden (*.mdb;*.accdb) beperkt tot 2 GB in grootte, wat in 2006 niet veel was maar tegenwoordig praktisch niets is. Naast de bestandsgroottebeperking begint de prestaties van de personal geodatabase af te nemen rond 500 MB aan totale data (zie Soorten geodatabases<\/A>). Een andere waarschijnlijke factor, maar waar Esri niet op ingaat, is het verouderd raken van de Jet-database-engine halverwege de jaren 2000.<\/P><\/P>Als we even terugkijken, of Esri Blogs zoals het ook mag heten, vinden we Vijf redenen waarom je de File Geodatabase zou moeten gebruiken<\/A>:<\/P>Grootte<\/STRONG><\/P>De databasegrootte wordt alleen beperkt door de beschikbare schijfruimte. Standaard kunnen individuele tabellen en feature classes tot 1 TB groot zijn. Met behulp van configuratietrefwoorden kan dit worden uitgebreid tot 256 TB.<\/P><\/P>Veelzijdigheid<\/STRONG><\/P>Werkt op veel verschillende besturingssystemen, waaronder Windows en UNIX (Solaris en Linux)<\/P><\/P>Snelheid<\/STRONG><\/P>Biedt uitstekende prestaties en schaalbaarheid. Bijvoorbeeld om individuele datasets te ondersteunen met meer dan 300 miljoen features en datasets die kunnen opschalen tot meer dan 500 GB per bestand met zeer snelle prestaties....<\/P><\/P>Bewerkingsmodel<\/STRONG><\/P>De File Geodatabase gebruikt een bewerkingsmodel vergelijkbaar met shapefiles, waarbij één editor en meerdere lezers worden ondersteund. Elke zelfstandige feature class, tabel en feature dataset kan tegelijkertijd door verschillende editors worden bewerkt, maar er kan slechts één editor tegelijk bewerkingen uitvoeren....<\/P><\/P>Compressie<\/STRONG><\/P>File Geodatabases stellen gebruikers ook in staat om feature classes en tabellen te comprimeren naar een alleen-lezen formaat om opslagvereisten nog verder te verminderen. Dit verkleint de totale schijfruimte van de Geodatabase zonder de prestaties te verminderen.<\/P><\/BLOCKQUOTE><\/P>Ik kan geen bezwaar maken tegen een van de vijf redenen die in het blogbericht worden gepredikt, ik denk dat elk accuraat is en een goede reden voor Esri om te werken aan het creëren van een nieuw (destijds), op bestandssysteem gebaseerd geodatabaseformaat. Maar zoals sommige acht jaar oude reacties in het blog aangeven, was de file geodatabase toen niet perfect en heeft hij vandaag nog steeds zijn tekortkomingen. <\/P><\/P>Voor sommigen is het grootste nadeel van de file geodatabase het eigendom. Dit is eigenlijk geen verandering ten opzichte van personal geodatabases, aangezien Access\Jet ook propriëtair is, maar het vertegenwoordigt wel een gemiste kans. Na enkele jaren bracht Esri uiteindelijk wel de file geodatabase API uit (<\/EM><A href="https:\/\/blogs.esri.com\/esri\/arcgis\/2010\/12\/13\/file-geodatabase-api-details\/\
<\/P>
Als we even terugkijken, of Esri Blogs zoals het ook mag heten, vinden we
Grootte<\/STRONG><\/P>De databasegrootte wordt alleen beperkt door de beschikbare schijfruimte. Standaard kunnen individuele tabellen en feature classes tot 1 TB groot zijn. Met behulp van configuratietrefwoorden kan dit worden uitgebreid tot 256 TB.<\/P><\/P>Veelzijdigheid<\/STRONG><\/P>Werkt op veel verschillende besturingssystemen, waaronder Windows en UNIX (Solaris en Linux)<\/P><\/P>Snelheid<\/STRONG><\/P>Biedt uitstekende prestaties en schaalbaarheid. Bijvoorbeeld om individuele datasets te ondersteunen met meer dan 300 miljoen features en datasets die kunnen opschalen tot meer dan 500 GB per bestand met zeer snelle prestaties....<\/P><\/P>Bewerkingsmodel<\/STRONG><\/P>De File Geodatabase gebruikt een bewerkingsmodel vergelijkbaar met shapefiles, waarbij één editor en meerdere lezers worden ondersteund. Elke zelfstandige feature class, tabel en feature dataset kan tegelijkertijd door verschillende editors worden bewerkt, maar er kan slechts één editor tegelijk bewerkingen uitvoeren....<\/P><\/P>Compressie<\/STRONG><\/P>File Geodatabases stellen gebruikers ook in staat om feature classes en tabellen te comprimeren naar een alleen-lezen formaat om opslagvereisten nog verder te verminderen. Dit verkleint de totale schijfruimte van de Geodatabase zonder de prestaties te verminderen.<\/P><\/BLOCKQUOTE><\/P>Ik kan geen bezwaar maken tegen een van de vijf redenen die in het blogbericht worden gepredikt, ik denk dat elk accuraat is en een goede reden voor Esri om te werken aan het creëren van een nieuw (destijds), op bestandssysteem gebaseerd geodatabaseformaat. Maar zoals sommige acht jaar oude reacties in het blog aangeven, was de file geodatabase toen niet perfect en heeft hij vandaag nog steeds zijn tekortkomingen. <\/P><\/P>Voor sommigen is het grootste nadeel van de file geodatabase het eigendom. Dit is eigenlijk geen verandering ten opzichte van personal geodatabases, aangezien Access\Jet ook propriëtair is, maar het vertegenwoordigt wel een gemiste kans. Na enkele jaren bracht Esri uiteindelijk wel de file geodatabase API uit (<\/EM><A href="https:\/\/blogs.esri.com\/esri\/arcgis\/2010\/12\/13\/file-geodatabase-api-details\/\
Joshua, are there workflows you have migrated to GeoPackage to take advantage of its SQL support in any 3rd party software or Data Interoperability/FME?
Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
