Re: [gdal-dev] GOES-16 Projection Issue
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 gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GOES-16 Projection Issue
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: simon.pr...@physics.ox.ac.uk Twitter: @simon_sat ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] mbtiles open failed
On mercredi 4 avril 2018 11:03:34 CEST weskerji...@sina.cn wrote: > i download the gdal from osgeo4w,and i write a demo to open mbtiles file,my > code is below > > > QString uri = "c:/test.mbtiles"; > > CPLErrorRest(); You probably lack a call to GDALAllRegister(); here -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Just want to do simple batch compression...
srygonic wrote > I have a lot of geotiffs which are quite large at times (meaning they have > quite a bit of unnecessary white space between) and I would like to run a > batch script to just do a simple compression on them as I believe that > they > are not compressed because the files that just contain a lot of white > space > are still unnecessarily huge. Hi, If you run gdalinfo about your image you will notice that it is already compressed: Metadata: TIFFTAG_SOFTWARE=OrbitGIS 17.0.0 Image Structure Metadata: COMPRESSION=YCbCr JPEG INTERLEAVE=PIXEL SOURCE_COLOR_SPACE=YCbCr However, one of your commands which is using actually the same parameters does shrink the image from 465 MB into 170 MB. gdal_translate GTIFF_RAW:GAPS_2017-02-23.tif test2.tif -co PHOTOMETRIC=YCBCR -co TFW=YES -co TILED=YES -co BIGTIFF=IF_SAFER -co COMPRESS=JPEG -a_srs EPSG:3414 For saving disk space I would consider cutting those areas which do have real data into individual files and then combine them into a virtual mosaic with gdalbuildvrt. Empty space does compress rather well but not having any pixels from areas with no data is most savvy option of all. -Jukka Rahkonen- -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
