[gdal-dev] How to build py-gdal using the C++ compiler

Hello, I'm a developer with MacPorts. We have this problem: py-gdal is written in C++ but it gets compiled using the C compiler and CFLAGS and linked using the C++ compiler and LDFLAGS. We would like it to be compiled using the C++ compiler and CXXFLAGS. How can this be accomplished? We have a n

Re: [gdal-dev] Source SRS is a compound CRS but lacks +geoidgrids

Thanks Even, really helpful! Patrick On Tue, Jun 16, 2020 at 3:45 PM Even Rouault wrote: > On mardi 16 juin 2020 15:17:54 CEST Patrick Young wrote: > > > Is this a special case for EPSG:5773, or is it a bad idea to express the > > > vertical datum via EPSG codes in general? > > > > This could g

Re: [gdal-dev] Source SRS is a compound CRS but lacks +geoidgrids

On mardi 16 juin 2020 15:17:54 CEST Patrick Young wrote: > Is this a special case for EPSG:5773, or is it a bad idea to express the > vertical datum via EPSG codes in general? This could go in a lengthy geodesy lesson, but bascially a CRS definition and its transformation to another one are two

Re: [gdal-dev] Source SRS is a compound CRS but lacks +geoidgrids

Is this a special case for EPSG:5773, or is it a bad idea to express the vertical datum via EPSG codes in general? Patrick On Tue, Jun 16, 2020 at 2:34 PM Even Rouault wrote: > On mardi 16 juin 2020 20:22:57 CEST Comer, Alex wrote: > > > Hello, I'm having trouble using gdalwarp to adjust the he

Re: [gdal-dev] Source SRS is a compound CRS but lacks +geoidgrids

On mardi 16 juin 2020 20:22:57 CEST Comer, Alex wrote: > Hello, I'm having trouble using gdalwarp to adjust the heights in a DEM from > EGM96 heights to ellipsoidal heights. > > There is an example in the GDAL documentation > (https://gdal.org/programs/gdalwarp.html#examples

[gdal-dev] Source SRS is a compound CRS but lacks +geoidgrids

Hello, I'm having trouble using gdalwarp to adjust the heights in a DEM from EGM96 heights to ellipsoidal heights. There is an example in the GDAL documentation (https://gdal.org/programs/gdalwarp.html#examples

Re: [gdal-dev] c# bindings - osr SpatialReference constructor

Cool, thanks! On Tue, 16 Jun 2020, 19:12 Tamas Szekeres, wrote: > You should use null in the constructor if you don't want to specity a wkt > during the initialization, something like: > > > *SpatialReference srs = new > SpatialReference(null);srs.ImportFromEPSG(2927);* > > Best regards, > > Tam

Re: [gdal-dev] c# bindings - osr SpatialReference constructor

You should use null in the constructor if you don't want to specity a wkt during the initialization, something like: *SpatialReference srs = new SpatialReference(null);srs.ImportFromEPSG(2927);* Best regards, Tamas Paul Harwood ezt írta (időpont: 2020. jún. 16., K, 19:01): > A common patte

[gdal-dev] c# bindings - osr SpatialReference constructor

A common pattern for creating a SpatialReference is this : from osgeo import osr spatialRef = osr.SpatialReference() spatialRef.ImportFromEPSG(2927) # from EPSG ( this example is from the Python Cookbook and is just used to illustrate the pattern) But - when I try to do the equivalent in

Re: [gdal-dev] Creating Geotiff is slow

Thank you Even for your prompt answer, -co NBITS=16 solved my problem! Thomas Le mar. 16 juin 2020 à 17:37, Even Rouault a écrit : > > I am puzzled by this behavior... Is there something wrong with my GDAL > > > settings ? > > > Is there a way to speed up the GeoTIFF creation ? Why is it faster

Re: [gdal-dev] Creating Geotiff is slow

> I am puzzled by this behavior... Is there something wrong with my GDAL > settings ? > Is there a way to speed up the GeoTIFF creation ? Why is it faster using > python ? There might be several factors: - if with rasterio you read completely the image into memory, and then write it, parallel d

Re: [gdal-dev] Reading a double from file

Thanks to you both. On Tue, 16 Jun 2020, Even Rouault wrote: On mardi 16 juin 2020 11:02:55 CEST Mateusz Loskot wrote: On Tue, 16 Jun 2020 at 10:08, Andrew C Aitchison wrote: Does gdal have a standard, endian-independent, way to read floating point values from file ? Specifically IEEE-754 l

[gdal-dev] Creating Geotiff is slow

Hello, I am trying to convert a full JPEG2000 image (Sentinel 2) to a GeoTIFF (1x1 pixels). My config is the following: GDAL 3.1.0, released 2020/05/03, freshly compiled on my computer (Ubuntu 18.04). I use the following env variables: OPJ_NUM_THREADS=8 GDAL_NUM_THREADS=1 GDAL_CACHEMAX=

Re: [gdal-dev] Reading a double from file

On mardi 16 juin 2020 11:02:55 CEST Mateusz Loskot wrote: > On Tue, 16 Jun 2020 at 10:08, Andrew C Aitchison > wrote: > > Does gdal have a standard, endian-independent, > > way to read floating point values from file ? > > Specifically IEEE-754 little-endian 64bit values. > > > > So far my drive

Re: [gdal-dev] Reading a double from file

On Tue, 16 Jun 2020 at 10:08, Andrew C Aitchison wrote: > > Does gdal have a standard, endian-independent, > way to read floating point values from file ? > Specifically IEEE-754 little-endian 64bit values. > > So far my driver has used a union to "cast" 8 bytes to a double, > but I now discover t

[gdal-dev] Reading a double from file

Does gdal have a standard, endian-independent, way to read floating point values from file ? Specifically IEEE-754 little-endian 64bit values. So far my driver has used a union to "cast" 8 bytes to a double, but I now discover that, whilst this is valid C, it is not valid C++. I am looking for a