[gdal-dev] gdalwarp different behavior for tif and netCDF files

[B H]

I should also have added that original nc has data in Lat Lon, but is not
actually stamped with EPSG:4326 SRS. Here is what I get from gdalinfo.
(I used a tool called grdcut to create the sample, but the behaviour is same

This is what gdalinfo shows on original nc file from which I created a
sample test case.


Driver: netCDF/Network Common Data Format
Files: /tmp/a.nc
Size is 14401, 6001
Origin = (-128.000416666666666,49.000416666666666)
Pixel Size = (0.000833333333333,-0.000833333333333)
Metadata:
  NC_GLOBAL#Conventions=CF-1.4
  NC_GLOBAL#geospatial_lat_max=49
  NC_GLOBAL#geospatial_lat_min=44
  NC_GLOBAL#geospatial_lat_resolution=0.000833
  NC_GLOBAL#geospatial_lat_units=degrees_north
  NC_GLOBAL#geospatial_lon_max=-116
  NC_GLOBAL#geospatial_lon_min=-128
  NC_GLOBAL#geospatial_lon_resolution=0.000833
  NC_GLOBAL#geospatial_lon_units=degrees_east
  NC_GLOBAL#GMT_version=4.5.1 [64-bit]
  NC_GLOBAL#history=xyz2grd -R-128/-116/44/49 -I3c -Gcrm_v8.grd
  NC_GLOBAL#title=crm_v8.grd
  x#actual_range={-128,-116}
  x#long_name=x
  x#units=degrees_east
  x#_CoordinateAxisType=Lon
  y#actual_range={44,49}
  y#long_name=y
  y#units=degrees_north
  y#_CoordinateAxisType=Lat
  z#actual_range={-3114.800048828125,4348}
  z#long_name=z
  z#positive=up
  z#units=meters
  z#_FillValue=-nan
Corner Coordinates:
Upper Left  (-128.0004167,  49.0004167)
Lower Left  (-128.0004167,  43.9995833)
Upper Right (-115.9995833,  49.0004167)
Lower Right (-115.9995833,  43.9995833)
Center      (-122.0000000,  46.5000000)
Band 1 Block=14401x1 Type=Float32, ColorInterp=Undefined
  NoData Value=nan
  Unit Type: meters
  Metadata:
    actual_range={-3114.800048828125,4348}
    long_name=z
    NETCDF_VARNAME=z
    positive=up
    units=meters
    _FillValue=-nan




On Thu, Mar 7, 2024 at 10:06 AM B H <hemantbist at gmail.com> wrote:

> I am trying to reproject a netCDF file which is in Lat Lon (EPSG:4326)
> projection to EPSG:3857 (Google mercator) (on GDAL 3.4.3, released
> 2022/04/22).
> If I reproject to a tif file, it is reprojected correctly. If I reproject
> to a nc file it reproject incorrectly/different location that tif file. I
> am giving the commands I ran below.
> Correctness is determined by viewing them in QGIS: (All tif files show up
> at exactly same location as   a_stamped_latlon.nc. agoog.nc show up at a
> different location ).
>
> I will be happy to post the sample files [The only way I know to send
> files to open a bug, but very likely its some details I don't know about
> different formats].: a.nc is only 42KB.
>
> Here is how to reproduce it.
>
>  gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -co COMPRESS=DEFLATE -r cubic
> a.nc agoog.nc
> gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -co COMPRESS=DEFLATE -r cubic
> -co "GEOTIFF_KEYS_FLAVOR=STANDARD" agoog_std.tif
> gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -co COMPRESS=DEFLATE -r cubic
> -co "GEOTIFF_KEYS_FLAVOR=STANDARD" a.nc  agoog_std.tif
>
> gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -co COMPRESS=DEFLATE -r cubic
> -co "GEOTIFF_KEYS_FLAVOR=ESRI_PE" a.nc  agoog_esri.tif
> gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -co COMPRESS=DEFLATE -r cubic
> -co "GEOTIFF_KEYS_FLAVOR=STANDARD" a.nc  agoog_std.tif
> gdal_translate -a_srs EPSG:4326 a.nc a_stamped_latlon.nc
>
>
> GDAL 3.4.3, released 2022/04/22
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240307/72ee0b00/attachment.htm>