[gdal-dev] gdalinfo -stats on Int64 raster: confusing warning

When I run gdalinfo with -stats options on an Int64 raster, I get the following warning: $ gdalinfo -json -stats zzz.tif Warning 1: GetNoDataValue() returns an approximate value of the true nodata value = 9223372036854775807. Use GetNoDataValueAsInt64() instead As an end user, what am I actually

Re: [gdal-dev] gdalinfo -stats on Int64 raster: confusing warning

Thanks so much for the super quick fixes, amazing work! And sorry for the noise. I often hesitate to open an issue when I'm not sure it's really a bug, so the mailing list felt like a safer place to ask. On Sun, Jun 22, 2025 at 12:27 AM Even Rouault wrote: > Answering your 4 emails at once: > >

Re: [gdal-dev] gdalinfo -stats on Int64 raster: confusing warning

Answering your 4 emails at once: What’s the purpose of including the band number in the |gdalinfo| JSON output? Since the |"bands"| key is a list, the band number is already implied by the index. Doesn’t this make the explicit band number redundant? Kind of, but not really. Given that JSON b

Re: [gdal-dev] gdalinfo and WMT_MS_Capabilities: how to get Dimension and its Extent?

Andrea, if I run "gdalinfo -json WMSURL -sd 1", I can read a lot of info about it, but I do not see Dimension and its Extent in the json output (below an example from WMS request). default="2024-03-01T00:00:00Z">2024-01-01T00:00:00.000Z,2024-01-02T00:00:00.000Z,2024-01-03T00:00:00.000Z,2024-0

[gdal-dev] gdalinfo and WMT_MS_Capabilities: how to get Dimension and its Extent?

Hi, if I run "gdalinfo -json WMSURL -sd 1", I can read a lot of info about it, but I do not see Dimension and its Extent in the json output (below an example from WMS request). 2024-01-01T00:00:00.000Z,2024-01-02T00:00:00.000Z,2024-01-03T00:00:00.000Z,2024-01-04T00:00:00.000Z I would like to hav

Re: [gdal-dev] gdalinfo and WMS: is there a way to pass credentials via CLI?

Thank you, it works great On Fri, 23 Feb 2024 at 18:27, Even Rouault wrote: > Hi, > > I haven't tested but you should be able to use any of the env variable > listed for CPLHTTPFetch() at > https://gdal.org/api/cpl.html#_CPPv412CPLHTTPFetchPKc12CSLConstList > > so here GDAL_HTTP_USERPWD > > gdal

Re: [gdal-dev] gdalinfo and WMS: is there a way to pass credentials via CLI?

Hi, I haven't tested but you should be able to use any of the env variable listed for CPLHTTPFetch() at https://gdal.org/api/cpl.html#_CPPv412CPLHTTPFetchPKc12CSLConstList so here GDAL_HTTP_USERPWD gdalinfo "WMS:http://wms.geobase.ca/wms-bin/cubeserv.cgi"; --config GDAL_HTTP_USERPWD user:pa

[gdal-dev] gdalinfo and WMS: is there a way to pass credentials via CLI?

Hi, is there a way to pass UserPwd parameter via a gdalinfo command? Is there a way to pass it, without creating an XML file? Something like this gdalinfo "WMS:http://wms.geobase.ca/wms-bin/cubeserv.cgi"; -UserPwd user:password Thank you -- ___ Andrea Borruso website: https://

Re: [gdal-dev] gdalinfo on large vrt takes a long time

Le 19/07/2023 à 15:47, William Kyngesburye a écrit : macos has lldb, once I figured that out, I got: * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7ff81eefdeb2 libsystem_kernel.dylib`stat$INODE64 + 10 frame #1: 0x00010140c669 GDAL`VSISt

Re: [gdal-dev] gdalinfo on large vrt takes a long time

macos has lldb, once I figured that out, I got: * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7ff81eefdeb2 libsystem_kernel.dylib`stat$INODE64 + 10 frame #1: 0x00010140c669 GDAL`VSIStatExL + 96 frame #2: 0x00010164 GDAL`VRTSimple

Re: [gdal-dev] gdalinfo on large vrt takes a long time

(sorry, my email sorting rules missed your reply somehow, just found it) The env var didn't help, and the vrt does have statistics. Pathnames in the vrt are relative to the vrt, if that might be a problem in this situation. I turned on CPL_DEBUG. gdalinfo is doing whatever is taking time aft

Re: [gdal-dev] gdalinfo on large vrt takes a long time

Can you run under gdb and break when it takes a long time and display the stack trace ? Something along (best with a debug build): gdb --args gdalinfo your.vrt run hit ctrl-c when it takes some time bt Le 19/07/2023 à 00:17, William Kyngesburye a écrit : (sorry, my email sorting rules m

Re: [gdal-dev] gdalinfo on large vrt takes a long time

William, it might be perhaps related to the GetMinimum() call done by gdalinfo. Cf https://trac.osgeo.org/gdal/ticket/5444 But normally it should only try to open the first source, and not all of them. At least that's what I could confirm on a quick testing. But I do see that the CanUseSourc

[gdal-dev] gdalinfo on large vrt takes a long time

I'm writing a script that needs some info from a vrt raster, and one has thousands of files. When reading the vrt over the internet (vpn to our server) it takes a long time. I think it's looking at every file of the vrt. What is gdal reading from the files that's not in the vrt itself? I used a

Re: [gdal-dev] gdalinfo: symbol lookup error: /usr/local/lib/libgdal.so.31: undefined symbol: _ZN3NCS9CIOStream17GetStreamCountersB5cxx11Ev

It is a gcc abi issue. Fixed by forcing the the compiler to use the cpp11abi/x64 version of the ECW library. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdalinfo: symbol lookup error: /usr/local/lib/libgdal.so.31: undefined symbol: _ZN3NCS9CIOStream17GetStreamCountersB5cxx11Ev

Hi, I have recently built gdal-3.5.0 with cmake and with the latest ECW 5.5 update. The build went fine and did not show any errors. However when I try to run gdalinfo it fails with error shown in the title shown above. I have seen the threads on similar ECW related problems, but nothing on th

Re: [gdal-dev] GDALinfo 3.1.4 gives segmentation fault error

Hi Slav, You have a local build of gdal, right? Somewhere in /Users/vskorole/opendap/hyrax/. gdal and proj libraries are picked from /Users/vskorole/opendap/hyrax/build/deps/ Do have any other gdal installed from packages around? If you have more than one gdal, seems like a library mismatch issu

Re: [gdal-dev] GDALinfo 3.1.4 gives segmentation fault error

On macOS that would be otool -L /path/to/gdalinfo - William Kyngesburye Don't Panic > On Dec 10, 2020, at 9:01 AM, Jorge Gustavo Rocha wrote: > > Hi Slav, > > Libraries might be the problem. Can you provide more info, please? > > Tell us which libraries are

Re: [gdal-dev] GDALinfo 3.1.4 gives segmentation fault error

Hi Slav, Libraries might be the problem. Can you provide more info, please? Tell us which libraries are being used by gdalinfo. Something like: ldd `which gdalinfo` Regards, Jorge Às 14:31 de 10/12/20, korol...@msn.com escreveu: > What could be a reason why on MacOS Catalina 10.15.6(19G2021)

[gdal-dev] GDALinfo 3.1.4 gives segmentation fault error

What could be a reason why on MacOS Catalina 10.15.6(19G2021) galindo http://download.osgeo.org/geotiff/samples/other/erdas_spnad83.tif gives error segmentation fault but galindo http://download.osgeo.org/geotiff/samples/usgs/o410

[gdal-dev] gdalinfo not working on Mageia

Hi, On Mageia we have an issue with gdalinfo (and some others scripts), during build it creates a bash script instead of a real binary, I checked what is going wrong but without success: $ gdalinfo --version /usr/bin/gdalinfo: error: '/usr/bin/.libs/gdalinfo' does not exist Mageia7 and Mageia Ca

Re: [gdal-dev] gdalinfo not reading vertical datum information?

On jeudi 15 août 2019 09:52:22 CEST Greif, Jeremiah wrote: > I recently had a situation where i needed to add a vertical crs to a raster > file. I did what have done many times and use *gdal_translate -a_srs > epsg:6350+5703 *to add the navd88 vertical datum to the raster file. When > I read the

[gdal-dev] gdalinfo not reading vertical datum information?

I recently had a situation where i needed to add a vertical crs to a raster file. I did what have done many times and use *gdal_translate -a_srs epsg:6350+5703 *to add the navd88 vertical datum to the raster file. When I read the file to double check my work using gdalinfo i get the folllowing re

Re: [gdal-dev] gdalinfo of a WMS layer

On mardi 26 février 2019 09:42:32 CET Andrew C Aitchison wrote: > On Tue, 26 Feb 2019, Ari Jolma wrote: > > I'm wondering why > > > > gdalinfo > > "WMS:http://tiles.kartat.kapsi.fi/taustakartta?layers=taustakartta"; > > > > and > > > > gdalinfo > > "WMS:http://tiles.kartat.kapsi.fi/taustakartta?

Re: [gdal-dev] gdalinfo of a WMS layer

On Tue, 26 Feb 2019, Ari Jolma wrote: I'm wondering why gdalinfo "WMS:http://tiles.kartat.kapsi.fi/taustakartta?layers=taustakartta"; and gdalinfo "WMS:http://tiles.kartat.kapsi.fi/taustakartta?layers=taustakartta&srs=epsg:3857"; both report corner coordinates in degrees although the secon

[gdal-dev] gdalinfo of a WMS layer

I'm wondering why gdalinfo "WMS:http://tiles.kartat.kapsi.fi/taustakartta?layers=taustakartta"; and gdalinfo "WMS:http://tiles.kartat.kapsi.fi/taustakartta?layers=taustakartta&srs=epsg:3857"; both report corner coordinates in degrees although the second one reports EPSG 3857? What am I mi

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

On Sun, Jun 17, 2018 at 7:51 PM, Even Rouault wrote: > > > It would be nice if gdalinfo -stats would also trigger forced recomputation > > of exact statistics. Currently there is no difference between gdalinfo with > > and without -stats if statistics already exist in metadata and > > STATISTICS_A

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

> It would be nice if gdalinfo -stats would also trigger forced recomputation > of exact statistics. Currently there is no difference between gdalinfo with > and without -stats if statistics already exist in metadata and > STATISTICS_APPROXIMATE=YES is absent (standard case for existing data): > -s

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

On Sat, Jun 16, 2018 at 10:00 PM, Even Rouault wrote: > > > > > I checked, results with gdalinfo -stats are wrong because existing > > STATISTICS_* metadata are reported even if approximate statistics are not > > allowed. > > No, if STATISTICS_APPROXIMATE=YES and is set in .aux.xml (because initia

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

> > I checked, results with gdalinfo -stats are wrong because existing > STATISTICS_* metadata are reported even if approximate statistics are not > allowed. No, if STATISTICS_APPROXIMATE=YES and is set in .aux.xml (because initial computation was done with -approx_stats) and you do gdalinfo -st

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

On Fri, Jun 15, 2018 at 10:43 PM, Even Rouault wrote: > > > Thinking about it, I do not want to support approximate statistics, > > therefore something like STATISTICS_VALID_RATIO does not work for me, only > > something like STATISTICS_N_VALID which requires exact statistics. > > STATISTICS_VALID

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

On Sat, Jun 16, 2018 at 6:38 PM, jratike80 < jukka.rahko...@maanmittauslaitos.fi> wrote: > > Markus Metz-3 wrote > > My workaround is to use GRASS r.external to get correct raster band > > statistics. > > Hi, > > Wouldn't it be good to have an option in GDAL to force it to re-compute > statistics?

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

Markus Metz-3 wrote > My workaround is to use GRASS r.external to get correct raster band > statistics. Hi, Wouldn't it be good to have an option in GDAL to force it to re-compute statistics? After all, statistics is just metadata and they can be all wrong if you have touched the image with a thi

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

> Thinking about it, I do not want to support approximate statistics, > therefore something like STATISTICS_VALID_RATIO does not work for me, only > something like STATISTICS_N_VALID which requires exact statistics. STATISTICS_VALID_RATIO makes more sense to me that absolute number of pixels. I a

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

On Thu, Jun 14, 2018 at 10:55 PM, Even Rouault wrote: > > > > Wanna take a crack at implementing this ? > > > > Too many API changes required, starting with GDALGetRasterStatistics(), > > GDALComputeRasterStatistics() and all else following. There must be an > > easier solution. But thanks for you

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

> > Wanna take a crack at implementing this ? > > Too many API changes required, starting with GDALGetRasterStatistics(), > GDALComputeRasterStatistics() and all else following. There must be an > easier solution. But thanks for your offer:-) We don't necessary need to change the API. The functio

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

On Wed, Jun 13, 2018 at 11:03 PM, Even Rouault wrote: > > On mercredi 13 juin 2018 22:14:07 CEST Markus Metz wrote: > > Many raster bands contain nodata, therefore it would be helpful if the > > number of non-nodata grid cells could be reported by gdalinfo in some way. > > > > The number of non-no

Re: [gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

On mercredi 13 juin 2018 22:14:07 CEST Markus Metz wrote: > Many raster bands contain nodata, therefore it would be helpful if the > number of non-nodata grid cells could be reported by gdalinfo in some way. > > The number of non-nodata grid cells is not available through > GDALGetRasterStatistics

[gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

Many raster bands contain nodata, therefore it would be helpful if the number of non-nodata grid cells could be reported by gdalinfo in some way. The number of non-nodata grid cells is not available through GDALGetRasterStatistics() / GDALRasterBand::GetStatistics(), probably because approximation

Re: [gdal-dev] gdalinfo error and subsequent segfault with proj-5.0.x

On Sun, Apr 15, 2018 at 10:07 PM, Even Rouault wrote: > > > OK, I recompiled gdal-2.2.4 --with-static-proj4 and got > > > > ldd libgdal.so | grep proj > > libproj.so.13 => /usr/local/lib64/libproj.so.13 (0x7fe2ff181000) > > libproj.so.12 => /lib64/libproj.so.12 (0x7fe2f31c7000) > >

Re: [gdal-dev] gdalinfo error and subsequent segfault with proj-5.0.x

> OK, I recompiled gdal-2.2.4 --with-static-proj4 and got > > ldd libgdal.so | grep proj > libproj.so.13 => /usr/local/lib64/libproj.so.13 (0x7fe2ff181000) > libproj.so.12 => /lib64/libproj.so.12 (0x7fe2f31c7000) > ??? > > gdalinfo now runs fine and produces expected results. > >

Re: [gdal-dev] gdalinfo error and subsequent segfault with proj-5.0.x

Even, On Sun, Apr 15, 2018 at 8:17 PM, Even Rouault wrote: > > Markus, > > From a quick test generating a GeoTIFF in EPSG:25832, I can't reproduce. > > I suspect you may link at runtime against different proj versions. You are right. I compiled GDAL with libproj.so -> libproj.so.13.0.1 there is

Re: [gdal-dev] gdalinfo error and subsequent segfault with proj-5.0.x

Markus, From a quick test generating a GeoTIFF in EPSG:25832, I can't reproduce. I suspect you may link at runtime against different proj versions. How did you build GDAL ? I'd strongly recommend you use --with-static-proj4 (whose name is a bit misleading since it can actually link against a li

[gdal-dev] gdalinfo error and subsequent segfault with proj-5.0.x

I observed a segfault in gdalinfo (2.2.3, 2.2.4, 2.3.0dev-71e2ada881) when compiled against proj-5.0.0/proj-5.0.1 The dataset is a GeoTIFF with EPSG:25832, and I get Corner Coordinates: ERROR 1: illegal axis orientation combination Upper Left ( 375000.000, 5631000.000) ERROR 1: illegal axis ori

Re: [gdal-dev] gdalinfo dont see the overview of tiffs listed in a virtual-datasource

On Thursday 20 August 2015 22:26:34 Andrea Peri wrote: > Hi, > I notice that the gdalinfo of a vrt datasource dont report the > overview or stats of a set of tiff (that have stats and overvies) > listed inside it. > > Instead is I create an overview of the vrt himself it is reported by > gdalinfo.

[gdal-dev] gdalinfo dont see the overview of tiffs listed in a virtual-datasource

Hi, I notice that the gdalinfo of a vrt datasource dont report the overview or stats of a set of tiff (that have stats and overvies) listed inside it. Instead is I create an overview of the vrt himself it is reported by gdalinfo. Is correct this or could be an issue ? Thx. -- -

Re: [gdal-dev] gdalinfo: fix metadata output

Hi, yes, I'm talking about metadata in a custom domain. I hacked up a driver to return additional metadata I want to use; since that metadata is driver specific I put it into a custom domain named after the driver. If you guessed MSG driver you'd be correct; but the SVN version doesn't retur

Re: [gdal-dev] gdalinfo: fix metadata output

Christian, I guess you are talking about metadata in domains other than the default and IMAGE_STRUCTURE metadata domains ? With which driver did you experiment that issue ? Would you mind attaching your patch as an attachment to a ticket in Trac ( http://trac.osgeo.org/gdal/newticket ) ? For that

[gdal-dev] gdalinfo: fix metadata output

Hello, I tried getting a driver to return some useful metadata from the files, but gdalinfo never displayed any of it. As it turns out, the culprit was gdalinfo. It will never report metadata from the bands, even if explicitely requested in the command line. So I set out to rewrite the metad

Re: [gdal-dev] gdalinfo coordinates problem?

Am 17.01.2014 23:37, schrieb Even Rouault: You should likely create a GDAL Trac ticket with your report and the patch, but I'm not sure who will dare hurting his head against this wall... This ticket should have the same issue already: https://trac.osgeo.org/gdal/ticket/4954 For the QGIS p

Re: [gdal-dev] gdalinfo coordinates problem?

Am 18.01.2014 21:52, schrieb Hermann Peifer: As far as I can see: lon_0 is the same in both cases and there is also no actual difference between +datum=NAD83 (gdal) and +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 (qgis). I am not sure where +x_0=60 (qgis) comes from, but gdal's +x_0 value is simply

Re: [gdal-dev] gdalinfo coordinates problem?

As far as I can see: lon_0 is the same in both cases and there is also no actual difference between +datum=NAD83 (gdal) and +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 (qgis). I am not sure where +x_0=60 (qgis) comes from, but gdal's +x_0 value is simply 6458320.41666 * 0.3048006096012192 =

Re: [gdal-dev] gdalinfo coordinates problem?

I noticed that qgis-2.0 also has a problem with this file, but places it around 54 degrees west longitude (if using on-the-fly reprojection to WGS84). The CRS is different from that identified by gdal (the lon_0, units and datum are different) qgis: +proj=lcc +lat_1=40.97 +lat_2=39.93

Re: [gdal-dev] gdalinfo coordinates problem?

Le vendredi 17 janvier 2014 21:28:35, Reynolds, Scott a écrit : > Hi, > > I've downloaded several DEMs (e.g 27002570PAS_dem.zip) from > ftp://pamap.pasda.psu.edu/pamap_lidar/cycle1/DEM/South/2008/2000/. > Gdalinfo is reporting the corner coordinates to be in the vicinity of 91 > degrees 31 m

Re: [gdal-dev] gdalinfo coordinates problem?

Hi, yes, this is a bug. The same error on last trunk gdal and also QGIS. I think the problem is in reprojection (lost linear units). The file have linear unit as us_survey_feet (0.304801). It's interesting does gdal support such projection? May be is is unsupported. Best regards, Dmitry

Re: [gdal-dev] gdalinfo coordinates problem?

Hi, yes, this is a bug. The same error on last trunk gdal and also QGIS. I think the problem is in reprojection (lost linear units). The file have linear unit as us_survey_feet (0.304801). It's interesting does gdal support such projection? May be is is unsupported. Best regards, Dmitry

[gdal-dev] gdalinfo coordinates problem?

Hi, I've downloaded several DEMs (e.g 27002570PAS_dem.zip) from ftp://pamap.pasda.psu.edu/pamap_lidar/cycle1/DEM/South/2008/2000/. Gdalinfo is reporting the corner coordinates to be in the vicinity of 91 degrees 31 minutes west longitude which should be more like 75 degrees 36 minutes we

Re: [gdal-dev] Gdalinfo does not print into file on Windows

Il 18/09/2013 01:34, lpinner ha scritto: Disabling the ECW plugin also enables setting a non-zero exit code (http://trac.osgeo.org/gdal/ticket/4830) Hi all, it seems that this issue disappears updating to ECW 5.0 SDK, as Tamas Szekeres suggests in this ticket [1]. I've discovered it doing some

Re: [gdal-dev] Gdalinfo does not print into file on Windows

Am 17.09.2013 17:02, schrieb Even Rouault: Hi Jukka, This reminds me a lot the following ticket : http://trac.osgeo.org/gdal/ticket/5128 Could you confirm that the analysis done (i.e. the cause of the problem would be the ECW plugin) also applies to you ? I'm not sure if you must completely uni

Re: [gdal-dev] Gdalinfo does not print into file on Windows

Yes, redirection and exit code setting works when the gdal_ECW_JP2ECW.dll is built against ECW/JP2 v.5.0 SDK (didn't test v.4x). Luke -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Gdalinfo-does-not-print-into-file-on-Windows-tp5078239p5078379.html Sent fro

Re: [gdal-dev] Gdalinfo does not print into file on Windows

Selon Andre Joost : > Am 17.09.2013 17:02, schrieb Even Rouault: > > Hi Jukka, > > > > This reminds me a lot the following ticket : > > http://trac.osgeo.org/gdal/ticket/5128 > > > > Could you confirm that the analysis done (i.e. the cause of the problem > would be > > the ECW plugin) also applies

Re: [gdal-dev] Gdalinfo does not print into file on Windows

Disabling the ECW plugin also enables setting a non-zero exit code (http://trac.osgeo.org/gdal/ticket/4830) Luke -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Gdalinfo-does-not-print-into-file-on-Windows-tp5078239p5078377.html Sent from the GDAL - Dev mailing

Re: [gdal-dev] Gdalinfo does not print into file on Windows

Hi, Yes, it is the same issue. After removing the plugin "gdal_ECW_JP2ECW" the output can be directed into file. Setting GDAL_SKIP=ECW did not help. -Jukka- Even Rouault wrote: > Hi Jukka, > This reminds me a lot the following ticket : > http://trac.osg

Re: [gdal-dev] Gdalinfo does not print into file on Windows

Hi Jukka, This reminds me a lot the following ticket : http://trac.osgeo.org/gdal/ticket/5128 Could you confirm that the analysis done (i.e. the cause of the problem would be the ECW plugin) also applies to you ? I'm not sure if you must completely uninstall (or rename) the gdal_ECW.dll, or if sp

Re: [gdal-dev] Gdalinfo does not print into file on Windows

On 09/17/2013 05:07 AM, Jukka Rahkonen wrote: Hi, I noticed that gdalinfo and gdallocationinfo tools do not print into file with command gdalinfo test.tif >report.txt The file report.txt is created but it remains empty. With ogrinfo printing into file goes well. I also had a try with some old F

[gdal-dev] Gdalinfo does not print into file on Windows

Hi, I noticed that gdalinfo and gdallocationinfo tools do not print into file with command gdalinfo test.tif >report.txt The file report.txt is created but it remains empty. With ogrinfo printing into file goes well. I also had a try with some old FWTools and with that I could redirect also gdali

Re: [gdal-dev] gdalinfo and ogrinfo file formats

Thanks Even, I'll have a look at your suggestions. BTW for MapWindow we don't use the GDAL C# API. >From our C#/Winforms we 'talk' to our MapWinGIS wich is a C++ ActiveX control. MapWinGIS does the communication with GDAL. This is much faster and more stable than using C# bindings. Thanks, Pa

Re: [gdal-dev] gdalinfo and ogrinfo file formats

Selon Paul Meems : > Hi Even, > > I'm not sure why I shouldn't use --format. If I can't use it why is it > provided? > Can I use --formats? My message was that the output format of gdalinfo is primarly for humans, not to be fed into other software. Well, this is my vision. You can do whatever you

Re: [gdal-dev] gdalinfo and ogrinfo file formats

Hi Even, I'm not sure why I shouldn't use --format. If I can't use it why is it provided? Can I use --formats? Perhaps I should not handle this in my C#/WinForms but do this in our C++ core. I think we can make a method that would return what I need based on gcore/gdal_misc.cpp but that would rely

Re: [gdal-dev] gdalinfo and ogrinfo file formats

> We're now in the progress of creating C#/WinForms tools on top of these > functionality to be used in MapWindow. We are going to use *gdalinfo > --formats* and *gdalinfo --format the_format *to get the relevant data we > need to create for example a file open box. This works fine since the > ext

[gdal-dev] gdalinfo and ogrinfo file formats

Hi all, First I wish everybody a happy 2013! With MapWindow GIS we're using gdal and ogr and we are now in the process of include the functionality of the utility programs, like gdalinfo.exe, ogrinfo.exe, gdal_translate.exe, ogr2ogr.exe, etc. This functionality is added to our core C++ base call

Re: [gdal-dev] GDALINFO cannot pipe to text file

Hi, Same problem for me. I try to use gdalinfo.exe to read metadata from .tif images. Here's an example for shell command : C:\gdalinfo.exe test.tif>test.txt Everything works very well on windows xp pro 32 bits but with on windows seven 64 bits, the result file text.txt is empty. What's solutio

Re: [gdal-dev] gdalinfo on PostGIS rasters (GDAL 1.9)

Dear Even, This works now perfectly! I didn't have time to install GDAL trunk until now. The installation went almost smoothly (see below if it is any useful). If I run the exact same gdalinfo command as before , I now have relevant information: $ gdalinfo "PG:dbname=mydb host=localhost user

Re: [gdal-dev] gdalinfo on PostGIS rasters (GDAL 1.9)

> Even, that's what I was afraid of... I think I will give it a try. Is there > a preferred solution between sources from Subversion and the nightly > snapshots? up to you > Second, do I understand it correctly that I need to 1) install GDAL from > sources, yes > and 2) recompile PostGIS on thi

Re: [gdal-dev] gdalinfo on PostGIS rasters (GDAL 1.9)

Dear James and Even, Thank you for you fast answers! James, I do have the raster properly referenced (at least from what I understand). For example: mydb=# SELECT st_georeference(rast) FROM myraster WHERE rid=1; st_georeference - 0.167000 + 0.00 + 0.000

Re: [gdal-dev] gdalinfo on PostGIS rasters (GDAL 1.9)

> Detailed set-up: > * PostGIS 2.1.0SVN (r10597) > * GDAL 1.9.0, released 2011/12/29 > * OS: Debian Wheezy There have been significant fixes done in the PostGISRaster driver in GDAL trunk a few weeks ago. You might want to try it. ___ gdal-dev mailing

Re: [gdal-dev] gdalinfo on PostGIS rasters (GDAL 1.9)

Mathieu, Might be a couple things going on, but have you properly set the georeferencing properties of your raster? What is the output of SELECT st_georeference([raster_column]) from myraster If they're not set, then you essentially just have a picture in your database (which is why it display

[gdal-dev] gdalinfo on PostGIS rasters (GDAL 1.9)

Dear GDAL developers, I am currently working with a PostGIS data base, which contains a few rasters imported from .img raster files. The rasters work properly in PostGIS, and are displayed properly in QGIS. They are projected as WGS84 (SRID 4326). They were imported using raster2pgsql, such as

Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

Hello, Good news. Removing the '.aux.xml ' file and again running gdalinfo -statsindeed fixes the problem. I now get the expected statistics values. Thank you for your help. Best Regards, Peter Le vendredi 19 octobre 2012 23:57:01, Peter Willis a écrit : > Hello, > > At step #6,

Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

Le vendredi 19 octobre 2012 23:57:01, Peter Willis a écrit : > Hello, > > At step #6, gdalinfo -stats reports data stats with the -999 values > calculated into the min/max/mean/stdev. > > > Band 2 Block=2178x1 Type=Float32, ColorInterp=Undefined > Description = Band 2 > Min=-999.000 Max=12.

Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

Hello, I am seeing that you are correct that the 'no data value' is being read in each case. Perhaps my interpretation of the problem appears incorrect. Look, however at the 'Metadata:' statistics. Both files have assigned -999 to 'No Data Value' but'STATISTICS_MINIMUM' for one file shows

Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

ault [mailto:even.roua...@mines-paris.org] Sent: October-19-12 2:08 PM To: gdal-dev@lists.osgeo.org Cc: Peter Willis Subject: Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header Le vendredi 19 octobre 2012 22:57:13, Peter Willis a écrit : > Hello, > > The one listed as &#

Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

Le vendredi 19 octobre 2012 22:57:13, Peter Willis a écrit : > Hello, > > The one listed as 'failed' actually fails for me as it is sent . Just to be sure we are talking about the same thing, what do you call "fail" exactly ? Is it that gdalinfo doesn't report "NoData Value=-999" for the bands

Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

o.org Cc: Peter Willis Subject: Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header Le vendredi 19 octobre 2012 22:23:49, Peter Willis a écrit : > Hello, > > I am providing the failed example followed by a working example. > Let me know if there is any additional infor

Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1998_269 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band

Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

.0], PARAMETER["Central_Meridian", -123.0], PARAMETER["Scale_Factor", 0.9996], PARAMETER["Latitude_Of_Origin", 0.0], UNIT["Meter", 1.0]]} -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: October-19-12 11:53 AM

Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

Le vendredi 19 octobre 2012 20:41:16, Peter Willis a écrit : > Hello, > > I have a curious problem with 'gdalinfo' (gdal version 1.9.0 ). > > I have an input ENVI file with the following .HDR entry: > > data ignore value = -9.9900e+002 > > gdalinfo for the IMG file provides stats that ex

[gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header

Hello, I have a curious problem with 'gdalinfo' (gdal version 1.9.0 ). I have an input ENVI file with the following .HDR entry: data ignore value = -9.9900e+002 gdalinfo for the IMG file provides stats that exclude all values -999.0 as expected. I then create a masked output file using

Re: [gdal-dev] Gdalinfo is missing documentation for -approx_stats

Ari Jolma gmail.com> writes: > > Jukka, > > Make a ticket as emails to the list are not as sticky as tickets. I do make tickets too but if I do not understand the issue I prefer to use the list first instead of creating possibly invalid tickets right away. -Jukka- __

Re: [gdal-dev] Gdalinfo is missing documentation for -approx_stats

Jukka, The option -approx_stats is useful if you want less precise statistics in less time. Updated the dox in the revision 24905 and 24906. Thanks for the notice Jukka. On Tue, Sep 4, 2012 at 6:33 PM, Piotr Tracz wrote: > W dniu 2012-09-04 14:53, Jukka Rahkonen pisze: > > I was reading from

Re: [gdal-dev] Gdalinfo is missing documentation for -approx_stats

W dniu 2012-09-04 14:53, Jukka Rahkonen pisze: I was reading from Quantum GIS mailing list that there exists an -approx_stats option in gdalinfo utility but it is not documented in http://www.gdal.org/gdalinfo.html It looks like the author did not bother to report the issue here so I did even I

Re: [gdal-dev] Gdalinfo is missing documentation for -approx_stats

Jukka, Make a ticket as emails to the list are not as sticky as tickets. Ari On 09/04/2012 03:53 PM, Jukka Rahkonen wrote: Hi, I was reading from Quantum GIS mailing list that there exists an -approx_stats option in gdalinfo utility but it is not documented in http://www.gdal.org/gdalinfo.htm

[gdal-dev] Gdalinfo is missing documentation for -approx_stats

Hi, I was reading from Quantum GIS mailing list that there exists an -approx_stats option in gdalinfo utility but it is not documented in http://www.gdal.org/gdalinfo.html It looks like the author did not bother to report the issue here so I did even I do not know what is the purpose of this appr

Re: [gdal-dev] Gdalinfo slow with big Rasterlite tables

Le mardi 21 août 2012 09:53:50, Rahkonen Jukka a écrit : > Even Rouault wrote: > > Selon Rahkonen Jukka : > > > Even Rouault wrote: > > > >> Better after doing these. 4 minutes and 10 seconds for the biggest > > > >> layer, record before this was 6 minutes. Big enough difference for > > > >> being

Re: [gdal-dev] Gdalinfo slow with big Rasterlite tables

> Yes, that makes gdalinfo fast. With my biggest layer the time went down > from 3 minutes to 3 seconds. However, my gdal_translate test fails. It > used to take three minutes before the zero appeared into the progress bar > but after that translation itself took only few seconds. After updating

Re: [gdal-dev] Gdalinfo slow with big Rasterlite tables

Even Rouault wrote: > Jukka, >> >> Is gdalinfo perhaps walking through every single tile in the >> rasterlite table for gathering the image layer info? Could >> there be any other way to do it in more effective way on the >> GDAL side? > The Rasterlite driver needs to fetch the extent of the "XX

Re: [gdal-dev] Gdalinfo slow with big Rasterlite tables

Jukka, > > Is gdalinfo perhaps walking through every single tile in the > rasterlite table for gathering the image layer info? Could > there be any other way to do it in more effective way on the > GDAL side? The Rasterlite driver needs to fetch the extent of the "_metadata" layers to estab

[gdal-dev] Gdalinfo slow with big Rasterlite tables

Hi, I converted 153600 x 249600 pixels of rasterdata into a Rasterlite table. After creating overviews the result behaves well in Quantum GIS once the table is opened. Unfortunatly opening the table with QGis installed on a mini PC takes ages. I do not know what QGis is really doing but I guessed

[gdal-dev] gdalinfo on win 7 64-bit

Please disregard my question on this topic. I was able to resolve this issue on my own. For the record what I did was open the OSGeo4W installer and re-install all of the libraries which seems to have cleaned on some dll conflict I am guessing. Thanks and I am digging this forum. -- JD Morga

[gdal-dev] gdalinfo on win 7 64-bit

Hello, I am running gdal on windows 7 64-bit which I installed via OSGeo4W. When I run gdalinfo on a raster GeoTiff file I get the following runtime error: RS6034 An application has made an attempt to load the C runtime library incorrectly. Any ideas one why this might be occuring, or how I

  1   2   >