<br><br><div class="gmail_quote">On Tue, May 24, 2011 at 1:23 PM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org">frederik@remote.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<div class="im"><br>
<br>
On 05/24/11 12:04, Igor Brejc wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, but is it really? It's a storage format, you need a 3rd party<br>
driver to read it<br>
</blockquote>
<br></div>
Same for anything that uses protocol buffers, or for shapefiles, isn't it?</blockquote><div><br></div><div>Not necessarily the same thing. Writing protobuf reader is still much easier than implementing something like <a href="http://www.sqlite.org/fileformat.html">http://www.sqlite.org/fileformat.html</a> and <a href="http://www.sqlite.org/fileformat2.html">http://www.sqlite.org/fileformat2.html</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and it's optimized for querying, not for storing high<br>
volume of data in an efficient manner. And it's a database without a<br>
standard schema.<br>
</blockquote>
<br></div>
I think that's right (apart fro the "optimized for querying" part perhaps because I think it is very much in the hands of whoever creates the spatiallite file whether it is good for querying or not).</blockquote>
<div><br></div><div>Even without any indices included, the data is still organized for random access, which is not really necessary for a "transmission" file format.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see spatialite as a good way for thick clients to store geo data<br>
without the need for an extra DB installation, but not as a good way to<br>
exchange data files (as opposed to osm.pbf, for example).<br>
</blockquote>
<br></div>
Maybe I misunderstood. I thought that you had said "oh, shapefiles don't do 64 bit IDs, maybe we should write a replacement for shapefiles then", and I pointed out that such replacements IMHO already exist; I didn't claim that they were a good OSM data transport format, and there's no reason to invent a new OSM data transport format either IMHO.<br>
</blockquote><div><br></div><div>I'm not talking about OSM-specific data transport format, just something that would:</div><div><ul><li>not have an issue with 64bit IDs</li><li>be contained in a single file</li><li>be easy to read/write</li>
<li>use efficient binary storage tricks (like the ones PBF uses).</li></ul></div><div>From reading what spatialite's author has to say on the subject, he finds spatialite format to be useful because of its inherent querying abilities but not as a transmission file format: <a href="https://groups.google.com/forum/#!topic/spatialite-users/a1dFsdGUA0A">https://groups.google.com/forum/#!topic/spatialite-users/a1dFsdGUA0A</a></div>
<div><br></div><div>So I presume Geofabrik will switch to providing spatialite extracts instead of shapefiles once the 64bit switch becomes a reality?</div><div><br></div><div>Igor</div></div>