Den mån 11 mars 2019 kl 15:07 skrev Darafei "Komяpa" Praliaskouski <
m...@komzpa.net>:
>
>
> On Mon, Mar 11, 2019 at 1:08 AM Björn Harrtell
> wrote:
>
>> It would probably be possible to get substantial gains on existing
>> formats that have spatial indexing by making them more optimal/balanced
>
On Mon, Mar 11, 2019 at 1:08 AM Björn Harrtell
wrote:
> It would probably be possible to get substantial gains on existing formats
> that have spatial indexing by making them more optimal/balanced however I
> see the following major issues:
>
> * Not sure how by convention deal with non-updatable
We see significant performance boost when clustering a large PostGIS
table on the spatial index. This will rewrite the table in spatial index
order.
CLUSTER USING
My understanding is that you need to periodically recluster the table
when updated, which is an atomic exclusive rewrite of the co
It would probably be possible to get substantial gains on existing formats
that have spatial indexing by making them more optimal/balanced however I
see the following major issues:
* Not sure how by convention deal with non-updatable indexes
(packing/sorting on hilbert or sort-tile-recursive seem
Hi Björn,
Would it make sense to implement it not as a separate format, but as a
special convention on top of any of already existing ones?
What happens if you sort by Hilbert curve a shapefile or geopackage, and
tweak the internals to build indexes in flattish manner?
For example, here is a bran
I've now implemented so that the traversal of the R-tree reads nodes on
demand and as suspected it gives a significant boost:
> time for i in {1..10}; do ogrinfo -qq -spat 10 56 10.2 56.2
gis_osm_roads_free_1.fgb gis_osm_roads_free_1; done
real 0m0,378s (~ 20% improvement)
> time for i in {1..10}
I've now implemented spatial filtering (at GDAL fork
https://github.com/bjornharrtell/gdal/tree/flatgeobuf) and results are
promising, for two test cases about 3,5-4 times faster than shapefile with
the same content. I've used these command lines to measure total time over
10 iterations for each fo
After posting about my experimental format I realized that I lack numbers
on the potential performance, so I tried to make some more or less
scientific measuring. The results was disappointing, reaching similar
performance as shapefile for full sequential reads and so I lost interest
for a while. B
Hi Benjamin,
Very interesting to read that you have experimented in similar things and
of your positive experiences with flatbuffers.
Den mån 10 dec. 2018 kl 18:18 skrev Benjamin Stadin <
benjamin.sta...@bridging-it.de>:
> Björn,
>
> Interesting to see there is some progress in this area. We've
Thanks Even, answers inlined.
Den mån 10 dec. 2018 kl 13:19 skrev Even Rouault :
> Björn,
>
> > In my spare time I've been working on a vector file format called
> > FlatGeobuf (tentatively). The main reason, besides curiosity and
> learning,
> > I'm putting time into it is that I think shapefile
Björn,
> In my spare time I've been working on a vector file format called
> FlatGeobuf (tentatively). The main reason, besides curiosity and learning,
> I'm putting time into it is that I think shapefile still rules the
> read/query static data performance game, which is kind of sad, and probably
Hi GDAL/OGR folks,
In my spare time I've been working on a vector file format called
FlatGeobuf (tentatively). The main reason, besides curiosity and learning,
I'm putting time into it is that I think shapefile still rules the
read/query static data performance game, which is kind of sad, and prob
12 matches
Mail list logo
