[gdal-dev] GOES-16 Projection Issue

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] GOES-16 Projection Issue

Simon Proud-2
Hello,
I am trying to visualise GOES-16 data, but the output projection from gdal_translate appears faulty.
This is the command I use:
gdal_translate -a_srs "+proj=geos +a=6378137. +units=m +no_defs +b=6356752.31414 +x_0=0.0 +y_0=0.0 +ellps=GRS80 +lon_0=-75.0 +f=.00335281068119356027 +h=35786023. +sweep=x" -a_ullr $ulx $uly $lrx $lry [input_file] [output_file]

For East Coast USA the results look fine, the output image matches a coastline shapefile. However, for the West coast the shapefile and image appear offset by tens of km. The problem is even worse on the East side of the image (West Africa). An example is available here: https://www2.physics.ox.ac.uk/sites/default/files/profiles/proud/goesr-proj-42831.png

I've also tried without +f, without +sweep=x, with various difference +a and +b values and with different +ellps settings. All result in a problematic projection.

Any ideas what is happened? I've already asked NOAA about this, their tool (WCT) displays the projection properly. GDAL and NASA's panoply tool do not.

All the best,
Simon

-- 
Dr Simon R Proud
NERC Post-doctoral fellow in Aviation Meteorology,
Department of Atmospheric, Oceanic and Planetary Physics,
University of Oxford,
Clarendon Lab,
Parks Road,
OX1 3PU,
Oxford,
UK

Tel (office): +44 (0) 1865 282431
Tel (mobile): +44 (0) 7563 639685
Email: [hidden email]
Twitter: @simon_sat
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: GOES-16 Projection Issue

Even Rouault-2
On mercredi 4 avril 2018 11:13:29 CEST Simon Proud wrote:
> Hello,
> I am trying to visualise GOES-16 data, but the output projection from
> gdal_translate appears faulty.
> This is the command I use:
> gdal_translate -a_srs "+proj=geos +a=6378137. +units=m +no_defs
> +b=6356752.31414 +x_0=0.0 +y_0=0.0 +ellps=GRS80 +lon_0=-75.0
> +f=.00335281068119356027 +h=35786023. +sweep=x" -a_ullr $ulx $uly $lrx
> $lry [input_file] [output_file]
>

Simon,

This has been discussed recently on the list. Basically the issue is that GeoTIFF encoding has
no way to represent this projection properly.

Long version at
http://geotiff.maptools.narkive.com/3CqwNeMd/geos-projection-sweep-parameter

A potential workaround is to have a .tif + .tif.aux.xml file and forcing a baseline TIFF to be produced

In GDAL master, I've just committed a fix so that

gdal_translate input.tif output.tif -co PROFILE=BASELINE -a_srs "+proj=geos +a=6378137. +units=m +no_defs +b=6356752.31414 +x_0=0.0 +y_0=0.0 +ellps=GRS80 +lon_0=-75.0  +f=.00335281068119356027 +h=35786023. +sweep=x"

works

With currently released versions, you have to do a more convoluted approach

1) Create a baslilne TIFF file
gdal_translate input.tif output.tif -co PROFILE=BASELINE

2) Create a dummy png file (1x1) with the projection info in .aux.xml
gdal_translate -of PNG test.tif output.png -a_srs "+proj=geos +a=6378137. +units=m +no_defs +b=6356752.31414 +x_0=0.0 +y_0=0.0 +ellps=GRS80 +lon_0=-75.0  +f=.00335281068119356027 +h=35786023. +sweep=x" -srcwin 0 0 1 1

3) Rename output.png.aux.xml to output.tif.aux.xml

4) Check with "gdalinfo output.tif" that you get the right projection info

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev