<div dir="ltr"><div dir="ltr"><br>Thanks Even, answers inlined.<br><br><div class="gmail_quote"><div dir="ltr">Den mån 10 dec. 2018 kl 13:19 skrev Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Björn,<br>
<br>
> In my spare time I've been working on a vector file format called<br>
> FlatGeobuf (tentatively). The main reason, besides curiosity and learning,<br>
> I'm putting time into it is that I think shapefile still rules the<br>
> read/query static data performance game, which is kind of sad, and probably<br>
> one of the reasons it is still so widely popular. Also, the main competitor<br>
> (GeoPackage) isn't suitable for streaming access (AFAIK)<br>
<br>
I suspect that you could organize the layout of a sqlite3 file to be streaming <br>
friendly, but the sqlite3 lib itself is probably not ready for that (or you <br>
have to cheat by buffering a sufficiently large number of bytes in memory and <br>
use a custom VFS to read in that buffer. at that point, implementing your own <br>
dedicated sqlite3 reader might be better. likely doable, but not trivial). <br>
Random access is possible (you can use /vsicurl/ etc on a geopackage), but it <br>
might involve a number of seeks and small reads in the B-Tree / R-Tree. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
That raises a major question. Which use case(s) do you want to address <br>
specifically. From what I've understood, for network access:<br>
- streaming access for progressive display as bytes come in<br>
- efficient bbox queries with minimized number of bytes and ranges in the <br>
files to read (minimizing the number of ranges of bytes is probably the most <br>
important criterion since reading 1 byte or 1000 will take the same time)<br></blockquote><div><br></div><div>The use case I had in mind is not the lossy and render optimized one, for that use case I think vector tiles are a good design. What I'm aiming for is essentially something to replace the shapefile i.e a lossless container of simple features with as good as possible performance for bbox query reads or full dataset reads via network or other means of I/O without having to deal with preprocessing into tiles, generalization etc.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I think I'm starting to get somewhere, more details and source is at<br>
> <a href="https://github.com/bjornharrtell/flatgeobuf" rel="noreferrer" target="_blank">https://github.com/bjornharrtell/flatgeobuf</a> and I have an early proof of<br>
> concept driver implementation at<br>
> <a href="https://github.com/bjornharrtell/gdal/tree/flatgeobuf" rel="noreferrer" target="_blank">https://github.com/bjornharrtell/gdal/tree/flatgeobuf</a> and results are<br>
> already quite promising - it can do roundtrip read/write and is already<br>
> quite a bit faster than shapefile. I also have implemented naive read only<br>
> QGIS provider for experimental purposes.<br>
<br>
What are the I and O in the I+O related to the R-Tree index ?<br></blockquote><div><br></div><div>I symbolizes the the R-Tree nodes. O is a separate array with feature offsets (the byte offset of each feature), so that together you can quickly get the byte ranges that needs to be fetched for a spatial query.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Wondering if a 3D index could be an option in case you want to address the <br>
full 3D case at some point. But might be something for later.<br>
<br>
I'm not familiar with flatbuf, but is random access in the Feature table by <br>
feature index is possible (without a preliminary scan pass), similarly to a <br>
.shx file in a shapefile ?<br></blockquote><div><br></div><div>That is the purpose of the O as explained above. Each feature is a separate flatbuffer message and can be accessed directly.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Just a detail: it could be nice to have some global flag in the header that <br>
would mean "index of any feature = its FID, its FID - 1, or no particular <br>
correlation between feature index and feature FID"<br></blockquote><div><br></div><div>Not sure exactly what you mean, but I've considered having an optional FID index to support fast random access by FID in the cases where FID is not the same as the index of the feature and I guess what you are saying it this should be explicit. This is not yet added to the spec.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For completness of the attribute types, you could have date, time and binary. <br>
Can the concept of null value or empty value or both for a field value be <br>
encoded ?<br></blockquote><div><br></div><div>Yes, perhaps it would be useful to have dedicated types for date, time and binary. I recently added datetime.</div><div><br></div><div>The columns/field definition is static for the layer. Values are required to specify a column index. Null/missing values are represented by simply omitting values for column indexes. An empty values array for a feature = all values are null.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The Column structure could also receive more optional info: a long <br>
description, maximum length for string, optional precision/scale formatting <br>
for those nostalgic of decimal formatting <br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you want full genericity to express a SRS, allowing a WKT CRS string as an <br>
alternative for authority+code.<br></blockquote><div><br></div><div>Agreed, I should consider it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Basically I'm fishing for interest in this effort, hoping that others will<br>
> see potential in it even if it's "yet another format" and far from<br>
> final/stable yet. Any feedback is welcome. As I see it, GDAL is a good<br>
> place for a format specification and reference implementation to incubate.<br>
> <br>
> Some additional food for thought that I've had during the experimentation:<br>
> <br>
> 1. The main in memory representations of geometry/coordinates seem to be<br>
> either separate arrays per dimension (GDAL (partially?) and QGIS) or a<br>
> single array with dimension as stride. I've chosen the latter as of yet but<br>
> I'm still a bit undecided. There is of course a substantial involved in<br>
> transforming between the two representations so the situation with two<br>
> competing models is a bit unfortunate. I'm also not sure about which of<br>
> these models are objectively "better" than the other?<br>
<br>
Why not just using WKB encoding since it has likely similar size and <br>
performance characteristics to the flatbuf encoding, with the main advantage <br>
of being widely implemented and supporting other geometry types like <br>
CircularString, PolyhedralSurface, etc..., which you need if you want to fully <br>
compete with GeoPackage ?<br></blockquote><div><br></div><div>I think I've (perhaps prematurely) ruled out WKB because I find it not very well/accessibly specified in it's details and existing implementations rather complex, so you might be right here. I'm however not sure about supporting any other geometry types than the ones I already do (similar as shapefile) to constrain the complexity.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> 2. One could get better space efficiency with protobuf instead of<br>
> flatbuffers, but it has a performance cost. I have not gone far into<br>
> investigating how much though and one could even reason about supporting<br>
> both these encodings in a single format specification but it's taking it a<br>
> bit far I think.<br>
<br>
Contradicts a bit my above point, but if you decide for a custom geometry <br>
encoding, why not allowing int32 for vertex values, with a offset+scale <br>
setting ? (ala OpenStreetmap PBF)<br></blockquote><div><br></div><div>That's what geobuf does for space efficiency but it seems it can cause drift in some corner cases (see <a href="https://github.com/mapbox/geobuf/issues/96">https://github.com/mapbox/geobuf/issues/96</a>) so I decided not to dive into it as I also wanted to try and aim for a zero-copy encoding.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If the main use case you want to address if cloud use, I was wondering if it <br>
would make sense to add a compression layer (ZSTD compress each Feature ?, or <br>
a group of features) to reduce the time spent in waiting for data from the <br>
network. Or perhaps not, and just let the transport layer do the compression <br>
(HTTP Encoding: gzip)<br></blockquote><div><br></div><div>I have thought about it and container / transport layer compression seems preferable to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 4. FlatGeobuf is perhaps a too technical name, not catchy enough and has a<br>
> bad/boring abbreviation. Other candidates I've considered are OpenGeoFile,<br>
> OpenVectorFile or OpenSpatialFile but I'm undecided. Any ideas? :)<br>
<br>
COF = Cloud Optimized Features ?<br></blockquote><div><br></div><div>Hmm, not bad :) I haven't considered cloud use the main/only use case for the format, but also offline applications so I'm not entirely convinced (yet).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></blockquote></div></div></div>