The proposed solution applies to GDAL 3.0.4 going forward and I am working
with 2.2.3. It is weird because I haven't changed anything in my
Dockerfile...
Em qui., 23 de set. de 2021 às 13:56, Even Rouault <
even.roua...@spatialys.com> escreveu:
> Perhaps related to https://github.com/OSGeo/gdal/i
Hi,
At least in this case having INITIAL_REQUEST_PAGE_SIZE=number option would
resolve the practical problem. We have collections with millions of features
and therefore large page size is essential when downloading the whole
collection. On the other hand we have complicated geometries like lak
Jukka,
your analysis is completely correct. Whether this is expected or not
probably depends on situations. Should we have a
INITIAL_REQUEST_PAGE_SIZE=number open option to overload the number of
features to retrieve specifically in the first request... ??
Regarding the spatial filter, it is
Hi,
I tried to read a relatively small BBOX from an OAPIF server but the process
feels rather slow and I do not quite understand what I am seeing in the log.
ogr2ogr -f GPKG test.gpkg
OAPIF:https://avoin-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/?api-key=
-spat 25 65 25.1 6
