No, a third party tool created the layer. If necessary I can contact
the developer.
That could indeed be interesting to know how they set the CRS to the
layer. From different bug reports, I've the feeling that there are
different aliases in the ESRI CRS world that aren't fully captured in
the
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:312
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"],PARAMETE
Hi,
There is also a brand new option to query pixel values with ogrinfo (sic!) by
using SQL function "gdal_get_pixel_value". See usage example and some
discussion https://lists.osgeo.org/pipermail/gdal-dev/2023-January/056759.html.
Of course the function can be reached without ogrinfo from othe
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
Gesendet: Freitag, 27. Jänner 2023 13:38
An: Simon Gröchenig ; gdal-dev@lists.osgeo.org
Betreff: Re: [gdal-dev] Bad GDB performance
Hi Simon,
fix queued in https:/
This example may be helpful:
https://gis.stackexchange.com/questions/358036/extracting-data-from-a-raster/358058
On Fri, Jan 27, 2023, 12:00 AM karsten wrote:
> Hi All,
>
> in an application I have a user click on a map and I need to
> programmatically clip a raster layer
> to the one raster cel
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 h
Hi Karsten,
An option is to run gdallocationinfo, get the col (P) and row (L) value and
then feed that into
gdal_translate -srcwin P L col -outsize 1 1 in.tif out.tif ##I think
that's right
You otherwise have to do the "grid logic", which (while easy ...) I'd
rather like to see exposed explicit
