Tom hit the nail on the head. Unless ArcGIS reads the format natively, without installing an extension (even free), it's not going to have the reach of a shapefile. And unless Esri truly opens the File Geodatabase spec like they did with Shapefiles, it's never going to succeed either.
I personally like SpatiaLite better than File Geodatabase for one reason: it's just one file. FGDB is a directory of lots of files. There may be performance gains to be had with a directory of lots of files, but I doubt it. The irony is that Esri's Personal Geodatabase was actually more open and was just one MDB. You could manipulate it with MS Access or anything that could read/write Access MDB files. But MDBs have other serious problems (if you've ever tried to use an MS Access application in a production environment with 3+ users, you know what I mean). The first time I encountered SHZ in QGIS, I had to pick my jaw up off the floor. What a stupid-simple solution to a real PITA problem - stuff all the parts of a Shapefile inside an industry standard ZIP file. The problem is not finding the perfect format. The problem is getting everyone on board. Again, irony... This is exactly what OGC is supposed to do - get everyone on board with a standard. But OGC gets caught up in things that are too far reaching and ultimately get disrupted. OGC has had to put a stamp of approval on de facto standards like WMTS and KML. OGC needs to stop trying to predict the future of GIS and look at the simple stuff that needs mediation now. Sure, sensor networks are cool but the market really needs a new Shapefile. A file format that Esri and QGIS can both read and write natively. A file format that makes it easy to share data. <sarcasm>Carl Reed, you're our only hope!</sarcasm> -Eric Wolf -=--=---=----=----=---=--=-=--=---=----=---=--=-=- Eric B. Wolf 720-334-7734 On Mon, Apr 9, 2012 at 9:33 AM, Tom MacWright <[email protected]> wrote: > As far as the whole SQLite thing: > > SQLite by itself has a ton of potential. It's supported easily on a number > of systems, and is even reverse-engineerable with browsers as demonstrated > by the sqlite.js project. Spatialite, while nice, is problematic to talking > about SQLite because its GEOS dependency, restrictive licensing, and > private development strategy bars it from being supported easily > everywhere. That and its ability to 'reproject in-database' should be > implemented outside of a data format, but is always something that a > government client sees and says "I want that!", thus sinking the project. > > GeoJSON & SQLite are the best + dumbest standards out there, and should > essentially 'win'. > > The biggest blocker towards anything becoming the new shapefile is that > ESRI charges $2,500+ for its "Data Interoperability" extension, which > should be part of the core product. They aren't succeeding with > geodatabase, but they are blocking the success of better formats. > > On Mon, Apr 9, 2012 at 11:22 AM, Reed Underwood < > [email protected]> wrote: > >> I began tinkering recently with a non-relational self-contained binary >> format for feature data and indices. The toolkit includes Spidermonkey for >> querying and view generation using Javascript. It's written in C and uses >> tokyocabinet for storage and libgeos for topology/geometry. The idea was to >> build a manager on top of this for distributed, eventually-consistent >> geospatial data storage. >> >> I'd be very interested in talking about alternatives to shapefiles, >> including the very cursory work I did. The project, called "Grist" is on >> github: >> >> https://github.com/runderwood/grist >> >> -R. >> >> On Mon, Apr 09, 2012 at 03:56:28PM +0200, Stefan Keller wrote: >> > Hi >> > >> > A while ago I proposed the idea of SQLite as the "The Shapefile of the >> > future?" - and Im still supporting it, especially the Spatialite >> > extension. >> > As I'm aware that there are webservices, there are still situations >> > where a downloadable, single, binary file format has it's reasons - >> > always having the "Simple Feature Model" in mind. >> > >> > Now, there's also another extension called "SQLite Provider" >> > implemented in FDO [1] and i'd liked to give it a chance. >> > But my impression is that this extension is not used broadly - even >> > not internally, since the project page is rather outdated [2] >> > >> > And even for webservices: When asked which vector geodata file format >> > to choose for the response part to make a project interoperable, I'd >> > answer, it depends... >> > * it could be GML Version 2 (2.1.2, not higher!) if XML is preferred >> > (and if archiving is involed like in gov. data), >> > * or GeoJSON, if it's between (HTML5) webapppliations, >> > * else pseudo-compatible GML Version 3 (especially "3.1.1 Compliance >> > level SF-0"), KML or proprietary. >> > >> > What do you think? >> > >> > Yours, S. >> > >> > [1] http://fdo.osgeo.org/content/fdo-370-downloads >> > [2] http://fdo.osgeo.org/OSProviderOverviews.html >> > >> > _______________________________________________ >> > Geowanking mailing list >> > [email protected] >> > http://geowanking.org/mailman/listinfo/geowanking_geowanking.org >> >> -- >> Reed Underwood | A Real Go-Getter | 617.708.4244 >> >> _______________________________________________ >> Geowanking mailing list >> [email protected] >> http://geowanking.org/mailman/listinfo/geowanking_geowanking.org >> > > > _______________________________________________ > Geowanking mailing list > [email protected] > http://geowanking.org/mailman/listinfo/geowanking_geowanking.org > >
_______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
