On Sat, Apr 19, 2008 at 7:05 PM, Hamish <<a href="mailto:hamish_b@yahoo.com">hamish_b@yahoo.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Rob:<br>
<div class="Ih2E3d">> There's no reason we couldn't collectively get Spatialite into<br>
> GDAL/OGR, GRASS, uDig, QGIS, and the others...<br>
<br>
</div>Once GDAL/OGR has support for SpatiaLite, other things fall into place<br>
quickly. Would SpatiaLite scale to the level of massive country-wide<br>
datasets in the same way as PostGIS? You can read about some SQLite<br>
downsides here:<br>
<a href="http://gdal.osgeo.org/ogr/drv_sqlite.html" target="_blank">http://gdal.osgeo.org/ogr/drv_sqlite.html</a></blockquote><div><br>I don't see any particular downsides there that aren't just OGR's support (ie. no spatialite+indexing)... ? The 'no datatypes' thing doesn't apply in the same way to SQLite v3 as it did to v2 (more at <a href="http://www.sqlite.org/datatype3.html">http://www.sqlite.org/datatype3.html</a>).<br>
<br>I'm not suggesting it as a replacement for PostGIS, but as a replacement for Shapefiles - portable, single file, compact, efficient, relational, "just works", etc. While someone non-technical might fire up QGIS and open a spatialite db, its a completely different thing to get postgis running and a dataset loaded, and thats before getting QGIS to connect to it. If you're using large datasets then a DB server solution will be necessary - you'll have the same problems today trying to run everything off Shapefiles - but that level is simply not required for many people and problem classes. And SQLite should kick Shapefiles in nearly every metric by a significant amount.<br>
<br>As you said, getting it into OGR is the first step - but it'd be great for the desktop apps to pick up and run with it as well, not just as another import/export option.<br><br></div></div>Rob :)<br>