On lundi 11 novembre 2019 04:49:49 CET jratike80 wrote:
> rns lots of features but perhaps you could do even better by combining
> ranges when possible.
I suspect those requests come from sequential reading of features. /vsicurl/
reads by chunks of 16 KB, and when it detects a sequential reading
Hi Björn,
Much faster now. The version that I used for testing includes
https://github.com/OSGeo/gdal/pull/1993.
The amount of http range requests is already rather low even when quory
returns lots of features but perhaps you could do even better by combining
ranges when possible. These three requ
Improvements have hit master. I suspect there are some remaining
bottlenecks though, but I currently lack the tests/means to investigate
further in short term and will appreciate feedback.
Den tors 31 okt. 2019 02:17Björn Harrtell skrev:
> Thanks for trying out accessing FlatGeobuf via http.
>
>
Thanks for trying out accessing FlatGeobuf via http.
For the record I've been slightly aware of this particular efficiency
problem and I aim to improve it when I can get to it, because this is a use
case I definitely want FlatGeobuf to grab the first place. :)
/Björn
Den tors 24 okt. 2019 kl 20:
On jeudi 24 octobre 2019 17:42:23 CEST Rahkonen Jukka (MML) wrote:
> Hi,
>
> I was experimenting with accessing some vector files through http (same data
> as FlatGeoBuffers, GeoPackage, and shapefile). The file size in each format
> was about 850 MB and the amount of data was about 24 linestr
Hi,
I was experimenting with accessing some vector files through http (same data as
FlatGeoBuffers, GeoPackage, and shapefile). The file size in each format was
about 850 MB and the amount of data was about 24 linestrings. I made
ogrinfo request with spatial filter that selects one feature
