Re: [gdal-dev] Trouble with French Ecw map

That is fine. Could you then show me the output of NCSFileReporter.exe ? This file is part of the APOLLO Essentials Utilities: http://download.intergraph.com/downloads/erdas-apollo-essentials-utilities-2015 Please provide the output on both files. Regards. Jacek Tomaka -Original Message

Re: [gdal-dev] Trouble with French Ecw map

Le 16/04/2015 00:25, Nicolas Ragg a écrit : On 15/04/2015 07:59, Jean-Claude Repetto wrote: Please run the command : gdalinfo -mdd ECW file.ecw What are the metadata (ECW) : PROJ= ? DATUM= ? Jean-Claude Hello Thank for your support, here they are : PROJ=epsg:27592 DATUM=epsg:27592 Do you

Re: [gdal-dev] Trouble with French Ecw map

Hello Jacek I'm using gdal 1.11, binaries downloaded from gisinternals with the ref 1600 gdal_translate -formats gives me that for ECW: ECW (rov): ERDAS Compressed Wavelets (SDK 5.0) In Qgis valmiera i have several gdal dll, so i'm not sure which one they use And in worldwind it's a custom

Re: [gdal-dev] Trouble with French Ecw map

Nicolas, What version of ECW library are you using? Is there any chance I could see the file(s)? Regards. Jacek Tomaka -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Nicolas Ragg Sent: Friday, 17 April 2015 7:32 AM To: g

Re: [gdal-dev] Trouble with French Ecw map

On 15/04/2015 07:59, Jean-Claude Repetto wrote: Please run the command : gdalinfo -mdd ECW file.ecw What are the metadata (ECW) : PROJ= ? DATUM= ? Jean-Claude Still looking into this problem, i've run gdalinfo with -mdd VERSION, output is : Metadata: COLORSPACE=RGB COMPRESSION_RATE_TARGET

Re: [gdal-dev] RGB to Grayscale

Tomer, On 04/16/2015 03:03 PM, Tomer wrote: Hello, I want to change a rgb image to a grayscale image. Is there a way to make it through the gdal_translate.exe utility or through other utilities. Best regards, Tomer. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/RGB-t

[gdal-dev] RGB to Grayscale

Hello, I want to change a rgb image to a grayscale image. Is there a way to make it through the gdal_translate.exe utility or through other utilities. Best regards, Tomer. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/RGB-to-Grayscale-tp5201726.html Sent from the GDAL -

Re: [gdal-dev] Boundary Artifact with ChunkAndWarpImage

Some good ideas, thanks for the suggestions. I added padfDstNoDataReal, as well as the imaginary values. I also set INIT_DEST to NODATA, although from what I read that was more of an option that affected speed. Unfortunately my output was identical to the previous run and the artifacts remain pr

Re: [gdal-dev] Boundary Artifact with ChunkAndWarpImage

Mike, Are you setting padfDstNoDataReal as well? Because GDAL performs the warp in chunks I'm wondering if previously written data, that should be NoData, is not recognized as such with later chunks. However, I'm still not clear on the exact details of how that works internally, Even would ha

Re: [gdal-dev] Boundary Artifact with ChunkAndWarpImage

Thanks for your reply. I'm using gdal 1.10.1. I'm using cubic resampling, but i have noticed the dark line artifact with bilinear as well. I unfortunately do not reproduce the problem with a basic gdalwarp with cubic resampling. I have written this code to do some registration. It's hard to tel

Re: [gdal-dev] Boundary Artifact with ChunkAndWarpImage

Le jeudi 16 avril 2015 19:01:57, Michael Aschenbeck a écrit : > Hello, > > I'm using ChunkAndWarpMulti to warp an image. The warping is working > nicely, however, at the boundary I seem to be getting some artifacts. > > The first artifact i see is a DARK boundary of pixels in some location. My

[gdal-dev] Boundary Artifact with ChunkAndWarpImage

Hello, I'm using ChunkAndWarpMulti to warp an image. The warping is working nicely, however, at the boundary I seem to be getting some artifacts. The first artifact i see is a DARK boundary of pixels in some location. My guess is that the interpolator is interpolating with blackfill (intensity

Re: [gdal-dev] baseline tiff and rpb file

Le jeudi 16 avril 2015 18:02:21, Ivan Lucena a écrit : > Hi Even, > > Thank you very much for fixing that. Those options are a little trick. I > understand. > > So now what is the default to deal with RPC on a baseline tiff (-co > profile=baseline) is: > > a) Create the RPC on a .tif.aux.xml if

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

On 2015-04-16 12:07, Even Rouault wrote: - All formulations that try to expand the definition with ProjCoordTransGeoKey = CT_Mercator, its projection parameters and GCS parameters aren't really appropriate, since there's no way of capturing that its a spherical mercator that must be used. Well

Re: [gdal-dev] baseline tiff and rpb file

Hi Even, Thank you very much for fixing that. Those options are a little trick. I understand. So now what is the default to deal with RPC on a baseline tiff (-co profile=baseline) is: a) Create the RPC on a .tif.aux.xml if there is a "RPB=NO" and when there is no RPB. - That means that for b

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

> > - All formulations that try to expand the definition with > > ProjCoordTransGeoKey = CT_Mercator, its projection parameters and GCS > > parameters aren't really appropriate, since there's no way of capturing > > that its a spherical mercator that must be used. > > Well, I agree that most read

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

On 2015-04-16 07:08, Even Rouault wrote: Le mercredi 15 avril 2015 22:48:45, Even Rouault a écrit : The way I see it, there are two different ways to model Google Mercator: 1. As a WGS84 datum/ellipsoid with a custom Mercator-based projection which uses only the semi-major axis, as seems to be

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

> Ranges: > [1, 1000] = Obsolete EPSG/POSC Projection System Codes > [2, 32760] = EPSG Projection System codes > 32767= user-defined > [32768, 65535] = Private User Implementations > > But there's a big hole for ]1000,2[, and 3857 is in it. And even if it >

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Hi Pepijn, > > How does this relate to http://trac.osgeo.org/geotiff/wiki/RefiningGeoTIFF? > Very much (although I'm foolishly attempting to reach interoperability with existing implementations) > > Frank wrote there that > > > accepted i

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Hi Even, How does this relate to http://trac.osgeo.org/geotiff/wiki/RefiningGeoTIFF? Frank wrote there that > accepted industry practice has been to accept newer EPSG PCS and GCS codes > even though they are not explicitly listed in the Geo

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Le mercredi 15 avril 2015 22:48:45, Even Rouault a écrit : > > The way I see it, there are two different ways to model Google Mercator: > > 1. As a WGS84 datum/ellipsoid with a custom Mercator-based projection > > which uses only the semi-major axis, as seems to be currently done in > > EPSG: http: