[gdal-dev] ogr2ogr: debugging slow performance when converting .e00 to other formats

[Even Rouault]

Jed,

There isn't much to debug. AFAIR, this is a limitation of the AVCE00 driver when 
reconstructing linear or polygonal geometries. It has to do lots of seeking in the file, which is 
super slow.

You might possibly try the avcimport utility (
http://avce00.maptools.org/avce00/index.html ) to convert the Ascii coverage to a binary 
one. I would expect the AVCBIN driver to be faster when using binary coverages as input 
dataset of ogr2ogr, but I'm not sure I've even tried this before.

Even

> Hello all,
> 
> I am new to this list, apologies if this type of question has already been
> asked. I’m using GDAL/OGR version 3.0.4 on a brand new server with 256GB
> ram.
> 
> I have a moderately sized (~110MB) .e00 file I would like to convert to
> another format. The original file appears to be clean; ogrinfo gives no
> problems opening the file.
> 
> I’ve tried converting this .e00 to shapefile, sqlite, and gpkg and in all
> cases it appears to create a file (or files depending on the output format)
> at the beginning but then little appears to happen after that. After
> several hours the conversion operation is still running, but the files only
> grow very, very slowly.
> 
> Is there any way to monitor the progress of the ogr2ogr operation or debug
> what is happening? I feel like there is not a lot more I can do except
> wait, but the time ogr2ogr is taking seems excessive given the input file
> size and the slow growth of the output file.
> 
> Thanks for your help,
> 
> Jed
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20201012/5222e66c/attachment.html>