Just wanted to point out that ESRI's Data Interoperability extension
includes a third-party product (Safe Software's FME workbench), so they
can't really add it to the core product without hiking the price
accordingly.
-Malcolm Williamson
CAST - University of Arkansas
On 4/9/2012 10:33 AM, Tom MacWright 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] <mailto:reed%[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] <mailto:[email protected]>
> http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
--
Reed Underwood | A Real Go-Getter | 617.708.4244 <tel:617.708.4244>
_______________________________________________
Geowanking mailing list
[email protected] <mailto:[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
