<div dir="ltr"><div>I believe that you could try to increase your swap RAM, </div><div>for linux it is pretty straightforward, and having a SSD or NVME it will perform good.</div><div>Free disk space is a must have to this to work,</div><div>as you are going to need about 10 - 20 Gb disk space as swap, according to Even calcs + 8Gb that you have.<br></div><div>Not as fast as true RAM, but may be able to get the job done, <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 28, 2023 at 3:18 PM Scott via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for digging into that Even!<br>
<br>
Can I create my new .fgb in sections?<br>
<br>
If I limit the number of source rows with -sql, doing that multiple <br>
times with -update, will it still build the entire R-tree when writing <br>
to the destination?<br>
<br>
I'm looking for a way to get the desired results.<br>
<br>
On 9/28/23 11:04, Even Rouault wrote:<br>
> ok, that now makes sense. Writing a .fgb files comes into those <br>
> exceptions where RAM consumption might be important, as it involves <br>
> building a packed Hilbert R-Tree in memory. With the current <br>
> implementation, you need at least the number of features times some <br>
> constant amount of RAM, at least to store the list of each feature <br>
> bounding box + their offset in a temporary file. From what I can see <br>
> this constant is at least 40 bytes. So in your particular case this <br>
> requires at least 145459485 * 40 = 5.5 GB of RAM. And probably (not <br>
> totally sure) twice that to store this initial list and the tree itself. <br>
> I guess the implementation could be made smarter and use on-disk <br>
> temporary memory, but that would likely involve serious implementation <br>
> complications. I let Björn comment more on this if he follows this <br>
> discussion.<br>
> <br>
> I've submitted a doc enhancement to mention this requirement: <br>
> <a href="https://github.com/OSGeo/gdal/pull/8490" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/pull/8490</a><br>
> <br>
> Le 28/09/2023 à 19:17, Scott a écrit :<br>
>> USA.fgb is 36 GB. I've renamed it from its original source which can <br>
>> be found here:<br>
>> <a href="https://beta.source.coop/vida/google-microsoft-open-buildings" rel="noreferrer" target="_blank">https://beta.source.coop/vida/google-microsoft-open-buildings</a><br>
>><br>
>> ogr2ogr -sql "select area_in_meters from bfp_USA" -nln footprints <br>
>> footprints.fgb ~/Downloads/USA.fgb<br>
>><br>
>> GDAL 3.7.1<br>
>> OS Debian Buster<br>
>><br>
>> Output from ogrinfo -ro -al USA.fgb<br>
>><br>
>> Layer name: bfp_USA<br>
>> Geometry: Unknown (any)<br>
>> Feature Count: 145459485<br>
>> Extent: (-160.221701, 17.677691) - (-64.583428, 71.360579)<br>
>> Layer SRS WKT:<br>
>> GEOGCRS["WGS 84",<br>
>>     DATUM["World Geodetic System 1984",<br>
>>         ELLIPSOID["WGS 84",6378137,298.257223563,<br>
>>             LENGTHUNIT["metre",1]]],<br>
>>     PRIMEM["Greenwich",0,<br>
>>         ANGLEUNIT["degree",0.0174532925199433]],<br>
>>     CS[ellipsoidal,2],<br>
>>         AXIS["geodetic latitude (Lat)",north,<br>
>>             ORDER[1],<br>
>>             ANGLEUNIT["degree",0.0174532925199433]],<br>
>>         AXIS["geodetic longitude (Lon)",east,<br>
>>             ORDER[2],<br>
>>             ANGLEUNIT["degree",0.0174532925199433]],<br>
>>     USAGE[<br>
>>         SCOPE["unknown"],<br>
>>         AREA["World"],<br>
>>         BBOX[-90,-180,90,180]],<br>
>>     ID["EPSG",4326]]<br>
>> Data axis to CRS axis mapping: 2,1<br>
>> boundary_id: Integer64 (0.0)<br>
>> bf_source: String (0.0)<br>
>> confidence: Real (0.0)<br>
>> area_in_meters: Real (0.0)<br>
>> OGRFeature(bfp_USA):0<br>
>>   boundary_id (Integer64) = 116<br>
>>   bf_source (String) = google<br>
>>   confidence (Real) = 0.906<br>
>>   area_in_meters (Real) = 187.4652<br>
>>   POLYGON ((-64.6399621676723 17.7225504518464,-64.6400377660957 <br>
>> 17.722583049763,-64.6400238635835 17.7226126625647,-64.6400901719124 <br>
>> 17.7226412545727,-64.640104074415<br>
>>  17.722611641767,-64.6401239848718 17.7226202271066,-64.6401528522526 <br>
>> 17.7225587385527,-64.6400955687758 17.7225340380511,-64.6401051288881 <br>
>> 17.7225136746756,-64.640040<br>
>> 1136221 17.7224856402151,-64.640030553504 <br>
>> 17.7225060035881,-64.6399910351014 17.7224889633119,-64.6399621676723 <br>
>> 17.7225504518464))<br>
>><br>
>> OGRFeature(bfp_USA):1<br>
>>   boundary_id (Integer64) = 116<br>
>>   bf_source (String) = microsoft<br>
>>   area_in_meters (Real) = 51.0777955237376<br>
>>   POLYGON ((-64.6398677811851 17.7219759840792,-64.6397939789141 <br>
>> 17.7219853127982,-64.6398020235506 17.7220430591893,-64.6398758258215 <br>
>> 17.7220337304732,-64.63986778118<br>
>> 51 17.7219759840792))<br>
>><br>
>> OGRFeature(bfp_USA):2<br>
>>   boundary_id (Integer64) = 116<br>
>>   bf_source (String) = google<br>
>>   confidence (Real) = 0.8323<br>
>>   area_in_meters (Real) = 178.5448<br>
>>   POLYGON ((-64.6397672401299 17.7220665249078,-64.6397654280552 <br>
>> 17.722041016034,-64.6395789582891 17.7220531822569,-64.6395832735872 <br>
>> 17.7221139302758,-64.639696737462<br>
>> 3 17.7221065273415,-64.639698399651 17.7221299263498,-64.6398064310524 <br>
>> 17.7221228777942,-64.6398022655579 17.7220642396531,-64.6397672401299 <br>
>> 17.7220665249078))<br>
>><br>
>><br>
>> On 9/28/23 10:03, Even Rouault wrote:<br>
>>><br>
>>> Le 28/09/2023 à 18:47, Scott via gdal-dev a écrit :<br>
>>>><br>
>>>> I should have been more specific.<br>
>>>><br>
>>>> One particular machine has 8GB of memory. When I try to do the most <br>
>>>> simple ogr2ogr command on large files, the host runs out of memory <br>
>>>> (vmstat shows this) and ogr2ogr terminates with 'Killed', nothing more.<br>
>>>><br>
>>>> The data formats I have experienced this with are .fgb, .parquet and <br>
>>>> .gpkg. The data files are 10's of GB.<br>
>>><br>
>>> As input ? as output? Which operating system ? Which GDAL version ? <br>
>>> The output of "ogrinfo -al -so the_input" might also be helpful. An <br>
>>> exact ogr2ogr command line invocation that triggers the issue would <br>
>>> certainly be useful.  In general, most GDAL drivers and ogr2ogr <br>
>>> itself operate in streaming mode with low RAM requirements, but there <br>
>>> might be exceptions (some configurations of GeoJSON file may require <br>
>>> full ingestion on reading for example).  I'm also aware of issues <br>
>>> with RAM fragmentation due to how some memory allocators work, but <br>
>>> they seem to be restricted to multithreaded uses <br>
>>> (<a href="https://gdal.org/user/multithreading.html#ram-fragmentation-and-multi-threading" rel="noreferrer" target="_blank">https://gdal.org/user/multithreading.html#ram-fragmentation-and-multi-threading</a>), which current ogr2ogr shouldn't trigger<br>
>>><br>
>>> Even<br>
>>><br>
>>>><br>
>>>> Thanks for the responses!<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><br>
>>><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><br>
</blockquote></div>