[Aust-NZ] Portable geospatial file formats (was: Live CDs for the FOSS4G conference and DebianGIS)

[Chris Tweedie]

Completely agree on the SQLite front however the lack of a robust spatial
indexing scheme really puts a downer on an otherwise awesome solution.

If you were a delegate at FOSS4G, performance should always reign supreme
even if it comes at the expense of truncated DBF columns and limited
datatypes (eg. Shp). That said, i wouldn't be surprised if the spatial
indexing comes in very, very soon so i'm all for it. I have used sqlite many
times in the past mainly for portability ... the missing link would be out
the box support for it in desktop apps. Although again, critical mass seems
to be almost here.

Chris

-----Original Message-----
From: aust-nz-bounces at lists.osgeo.org
[mailto:aust-nz-bounces at lists.osgeo.org] On Behalf Of Robert Coup
Sent: Friday, 18 April 2008 1:02 PM
To: Aust-NZ at lists.osgeo.org
Subject: [Aust-NZ] Portable geospatial file formats (was: Live CDs for the
FOSS4G conference and DebianGIS)

On Fri, Apr 18, 2008 at 3:52 PM, Hamish <hamish_b at yahoo.com> wrote:
>  It is good news that we don't have to start from shapefiles, they may be
>  universal but parts of the format (DBF) are lossy and unnice.

I think we're all agreed on that. What are the alternatives?

We can represent data nicely and openly in:
 - GML
 - SQL - oracle, mysql, postgres, mssql, ...
 - KML (ish)

But people can't *use* raw SQL or GML/KML - they're
transfer/interchange formats. (well, you can use GML/KML but you don't
get spatial/attribute indexing or efficient access unless your system
RAM >>> data-size)

Postgres and/or SHP seem to be the 'native' formats of most OSSG apps
- where they work most efficiently. But it seems unreasonable for
everyone to need a PG server to do some work.

This was brought up on the PostGIS lists this week:
http://www.gaia-gis.it/spatialite/

Basically SpatiaLite adds a geometry type to SQLite via an extension:
 - sqlite DBs are just a single file. easy to transfer and portable across
OSs
 - WKT & WKB, core of the SFSQL functionality, and they're working on more.
 - reprojection via proj4
 - LGPL
There's some other people looking at spatial indexes based on R-Trees
for sqlite, but the link escapes me right now.

I see the benefits of using SQLite as a 'single-compact-data-store' format:
 - open
 - efficient (indexing)
 - portable (cross platform, supported by every development language alive)
 - supports multiple layers
 - relational - this may be a drawback depending on your POV ;)
 - can mix spatial and non-spatial data tables
 - compact

It wouldn't have the performance of Postgis/Oracle but could provide a
modern replacement for the Shapefile.

What am i missing? What do you all think?

Rob :)
_______________________________________________
Aust-NZ mailing list
Aust-NZ at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/aust-nz