[gdal-dev] Bad GDB performance

[Even Rouault]

Hi Simon,

the GDB is fine. GDAL struggles because it tries to identify the CRS 
definition from the GDB ( 
'PROJCS["GK_31",GEOGCS["GCS_MGI",DATUM["D_MGI",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Gauss_Kruger"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",-5000000.0],PARAMETER["Central_Meridian",13.3333333333333],PARAMETER["Scale_Factor",1.0],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]' 
) with a known one (EPSG, ESRI) in PROJ CRS database. But there is no 
match for the GK_31 name so it has to go to slower methods.

Do you know how that CRS was attributed to the layers ? (through some 
choice in a list of predefined CRS ? no idea how Arc stuff works)

I believe this CRS should be identified as EPSG:31255, which in the 
current ESRI CRS database, is called MGI_Austria_GK_Central:

PROJCS["MGI_Austria_GK_Central",GEOGCS["GCS_MGI",DATUM["D_MGI",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",-5000000.0],PARAMETER["Central_Meridian",13.3333333333333],PARAMETER["Scale_Factor",1.0],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

Which version of ArcMap / ArcGIS was used to produce this GDB ?

Even

Le 27/01/2023 à 14:34, Simon Gröchenig a écrit :
>
> Hi Even,
>
> great, thank you!
>
> Is the GDB itself fine? Or is there something I can do to fix the 
> database?
>
> Simon
>
> *Von:*Even Rouault <even.rouault at spatialys.com>
> *Gesendet:* Freitag, 27. Jänner 2023 13:38
> *An:* Simon Gröchenig <groechenig at zt-gis.at>; gdal-dev at lists.osgeo.org
> *Betreff:* Re: [gdal-dev] Bad GDB performance
>
> Hi Simon,
>
> fix queued in https://github.com/OSGeo/gdal/pull/7131
>
> Even
>
> Le 27/01/2023 à 06:49, Simon Gröchenig a écrit :
>
>     Hi all,
>
>     I am struggling with a bad performance at reading FileGeodatabases
>     in QGIS. I hope, this is the place where I can find someone to
>     help me find the bottleneck.
>
>     I have uploaded a sample dataset here:
>     https://mega.nz/file/nnxVULyC#QcuGJEHedayIC7b1i14J0X8OBExVfhcb55DnnVtGzuc
>
>     Loading a QGIS project containing this GDB (layer Kataster/GST)
>     results in a layer loading time of 5+ seconds according to the
>     QGIS Debugging/Development Tools. I expect less than 1 second to
>     load this dataset.
>
>     I appreciate any help to find if it is a GDAL or a dataset issue?
>
>     Simon
>
>     ------------------------------------------------
>
>     Vermessungskanzlei Neumayr
>
>     Simon Gröchenig - Geoinformation
>
>     Albin Egger-Str. 10
>
>     9900 Lienz
>
>     Tel: +43 4852-68568-31
>
>     Email: groechenig at zt-gis.at
>
>     Web: http://www.zt-gis.at/
>
>
>
>     _______________________________________________
>
>     gdal-dev mailing list
>
>     gdal-dev at lists.osgeo.org
>
>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230127/8e5079f6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1879 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230127/8e5079f6/attachment-0001.jpg>