[Geowanking] Proposal: Improving on the ESRI Personal Geodatabase?

[Chris Holmes]

Quoting Alex Willmer <alex at moreati.org.uk>:

> In my day job I support an ArcSDE/ArcIMS/ArcGIS infrastructure. The
> GIS
> specialists frequently use Personal Geodatabases for offline editing,
> temporary storage & project archival.
>
> For those unfamiliar a Personal Geodatabase (PGDB) is an MS Access
> database (.mdb) file with some predefined tables and table
> structures. A
> PGDB can store multiple vector and raster layers with attributes,
> upto a
> total size of 2 GiB. An overview can be found here:
>
> http://www.esri.com/software/arcgis/geodatabase/about/personal.html
>
> Recently I've been pondering that a similar concept would be of use
> to
> opensource GIS systems. It could provide a format featuring:
> - a single file able to hold multiple datatypes, and layers with
> indexed
> access
> - a zero-admin, portable implementation of Simple Features for SQL
> - a common transport for moving geodata between disparate databases
> - an alternative to shapefiles with fewer limitations on attributes,
> types, identifiers etc
>
> I don't suggest reverse engineering the PGDB format (although this
> would
> also be of great use). I think something based on SQLite would fit
> the
> bill. A
>
> The SQLite library is already popular as an embedded database in
> opensource software. It smashes the PGDB limit of 2GiB (SQLite 3 can
> potentially address files of 2 TiB). Finally, unlike mdb, SQLite has
> no
> scripting built in - so virus scanners are less likely to interfere
> with
> any file format based upon it (ie mail filters should let it through
> and
> on-access scanners should ignore the potentially large files it would
> support.)
>
> Hoping for comments, suggestions & questions.
One interesting approach could be to use David Blasby's Spatial DB in a
Box: http://docs.codehaus.org/display/GEOS/SpatialDBBox  It
autogenerates all the hardcore spatial operations (buffer, intersect,
crosses, ect.) that one needs from JTS, into a full implementation of
Simple Features for SQL.  It's great for Java databases, but also can
work with non-java databases, using gcj to generate the code.  Could do
Derby, HSQL, maybe berkley db java, or some such for your small
embedded DB.  We have HSQL working in GeoTools, and Derby shouldn't be
too difficult, though both could use Spatial Index support.  Or if you
wanted to do SQLLite, could do that as well.  All I think have ODBC
connections, so could be used with OGR without too much difficulty. 
Using JDBC connections in GeoTools as well would pretty quickly get it
supported in the majority of major OS-GIS projects.  I do like the
idea, would be nice to have a simple open source implementation to
parallel the esri one.  But regardless of the path, would recommend
trying out the spatial db in a box, so you don't have to maintain all
the geometry functions, you just generate from the latest JTS release,
which is probably the best implementation of the sf4sql operations.

best regards,

Chris

>
> Regards
>
> Alex
>
> _______________________________________________
> Geowanking mailing list
> Geowanking at lists.burri.to
> http://lists.burri.to/mailman/listinfo/geowanking
>




----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/