So this (https://github.com/OSGeo/gdal/pull/6804) optimization by Even
might be helpful here.
In any case nice to see the limits of current FlatGeobuf impl. being put to
the test.
I suppose one could do an on disk sorting implementation but I'm not sure
it's worth the complexity of it and
Le 24/11/2022 à 19:18, michael.smith.e...@gmail.com a écrit :
I don’t believe these are huge features, its OSM building for the
world. Must be the memory constraint since it is a lot of features.
This doesn’t happen (i think, am retesting now) if created from the
osm pbf file directly but
I don’t believe these are huge features, its OSM building for the world. Must be the memory constraint since it is a lot of features. This doesn’t happen (i think, am retesting now) if created from the osm pbf file directly but does from the fgb created from the pbf. Do either of the columnar
Mike,
Le 24/11/2022 à 18:56, michael.smith.e...@gmail.com a écrit :
Basically, can one create a spatial index in a flatgeobuf file if the
source does not have one?
yes, through ogr2ogr by creating a new file, as you did
Also, when trying to just create a new flatgeobuf with a spatial
Basically, can one create a spatial index in a flatgeobuf file if the source
does not have one?
Also, when trying to just create a new flatgeobuf with a spatial index from one
without (using ogr2ogr), I get a lot of
ERROR 2: ICreateFeature: Too big feature
Mike
--
Michael Smith
US
