Hi,

ok, thanks.

> 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)

No, a third party tool created the layer. If necessary I can contact the 
developer.

> I believe this CRS should be identified as EPSG:31255

Yes, that is the correct code.

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

Simon


Von: Even Rouault <even.roua...@spatialys.com>
Gesendet: Freitag, 27. Jänner 2023 15:23
An: Simon Gröchenig <groeche...@zt-gis.at>
Cc: gdal-dev@lists.osgeo.org
Betreff: Re: AW: [gdal-dev] Bad GDB performance


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.roua...@spatialys.com><mailto:even.roua...@spatialys.com>
Gesendet: Freitag, 27. Jänner 2023 13:38
An: Simon Gröchenig <groeche...@zt-gis.at><mailto:groeche...@zt-gis.at>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@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

[cid:image001.jpg@01D93264.4D30EA30]

Albin Egger-Str. 10
9900 Lienz
Tel: +43 4852-68568-31
Email: groeche...@zt-gis.at<mailto:groeche...@zt-gis.at>
Web: http://www.zt-gis.at/





_______________________________________________

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to