[gdal-dev] gdal translate/warp goes16

Thu Mar 29 12:05:34 PDT 2018

Interesting. Its working fine for me and some other people using the cli tools.

Zac

> On Mar 27, 2018, at 9:44 AM, Beale, Steven <steven.beale at woodplc.com> wrote:
> 
> I never did resolve this issue, but using the python libraries instead worked out fine.
> -s
>  
> From: Beale, Steven [mailto:steven.beale at woodplc.com] 
> Sent: Wednesday, March 21, 2018 3:39 PM
> To: Zachary Flamig <zac at weatherwary.com>; Steven Beale <steven.beale at woodplc.com>
> Cc: gdal-dev at lists.osgeo.org
> Subject: RE: [gdal-dev] gdal translate/warp goes16
>  
> Hi Zac,
> I tried to be as explicit as possible setting the source srs, including the semi-major/minor axes:
> gdalwarp -s_srs "+proj=geos +a=6378137 +b=6356752.31414 +lon_0=-75 +h=35786023 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs  +sweep=x" -t_srs EPSG:4326 -dstnodata -999.0 -tr 0.009 0.009 -te 290 40 320 65 -r near <in> <out>
>  
> But I still have the longitude shifting.
> Out of curiosity I tried +sweep=y, just to see what would happen, and that didn’t do anything either… could the sweep be getting ignored entirely?
> Just to verify that the srs was being interpreted at all, I tried adjusting lon_0, which did work. Not very helpful though.
> Thinking there could possibly be some conflict in setting ellps=GRS80 and setting parameters by hand, I omitted that the +ellps. Same result.
> Any other thoughts?
>  
> Thanks,
> Steve
>  
> From: Zachary Flamig [mailto:zac at weatherwary.com <mailto:zac at weatherwary.com>] 
> Sent: Wednesday, March 21, 2018 4:04 AM
> To: Steven Beale <steven.beale at woodplc.com <mailto:steven.beale at woodplc.com>>
> Cc: gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] gdal translate/warp goes16
>  
> Hi Steven,
>  
> So the issue here is that gdal_translate doesn’t properly store the +sweep=x in the geotiff.
>  
> See http://geotiff.maptools.narkive.com/3CqwNeMd/geos-projection-sweep-parameter <https://urldefense.proofpoint.com/v2/url?u=http-3A__geotiff.maptools.narkive.com_3CqwNeMd_geos-2Dprojection-2Dsweep-2Dparameter&d=DwMFaQ&c=ZWY66qCYUTYUcOev9C2GlDEcKuYKzoWDVNR_L93Z9mQ&r=xGAbC1Ogv9duClaR3TChYqg_fGB4xrhak7uN1kZcfR8&m=zVXU4kc36wijhVLYDg1WghqZOoFePzeG6PQfNC150tU&s=f466QSOBNcqeD3kETK3-K2-4KeUmCONhKlY6J9t4dMU&e=> for some relevant discussion. I believe the best solution right now is to specify the s_srs in the gdalwarp command like -s_srs "+proj=geos +lon_0=-75 +h=35786023 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs  +sweep=x"
>  
> This is a bit of a mess, sorry about that.
>  
> Zac
>  
> 
> On Mar 20, 2018, at 9:37 PM, Steven Beale <steven.beale at woodplc.com <mailto:steven.beale at woodplc.com>> wrote:
>  
> Hi gdalers, 
> 
> I'm a little out of my field here, usually I work with weather/climate data,
> but I need to warp some goes16 satellite data. (source is aws s3:
> https://noaa-goes16.s3.amazonaws.com/ABI-L2-CMIPF/2018/079/12/OR_ABI-L2-CMIPF-M3C01_G16_s20180791200447_e20180791211214_c20180791211280.nc <https://urldefense.proofpoint.com/v2/url?u=https-3A__noaa-2Dgoes16.s3.amazonaws.com_ABI-2DL2-2DCMIPF_2018_079_12_OR-5FABI-2DL2-2DCMIPF-2DM3C01-5FG16-5Fs20180791200447-5Fe20180791211214-5Fc20180791211280.nc&d=DwMFaQ&c=ZWY66qCYUTYUcOev9C2GlDEcKuYKzoWDVNR_L93Z9mQ&r=xGAbC1Ogv9duClaR3TChYqg_fGB4xrhak7uN1kZcfR8&m=zVXU4kc36wijhVLYDg1WghqZOoFePzeG6PQfNC150tU&s=wpMH3kBCq917DTkCCXLtN0FpDoYrz6Xbmh4KZvNmrSM&e=>
> - the link should work for a few months then it will be glaciered and
> unavailable) 
> 
> source data is netcdf, I'm using nco tools & gdal for the processing. 
> 
> My work flow is: 
> 1. clip the data to the region of interest (north atlantic): 
> ncks -d x,5424,8678 -d y,0,2170 <raw.nc> step1.nc 
> 2. deflate & unscale 
> gdal_translate -ot float32 -unscale -CO COMPRESS=deflate NETCDF:step1.nc:CMI
> step2.tiff 
> 3. warp (in this case data is 1km resolution : ~0.009 degrees) 
> gdalwarp -t_srs EPSG:4326 -dstnodata -999.0 -tr 0.009 0.009 -te 290 40 320
> 65  -r near step2.tiff step3.tiff 
> 4. convert back to nc 
> gdal_translate -ot float32 -of NETCDF step3.tiff output.nc 
> 
> The problem i have is that the output has the longitude shifted to the west
> by about 10 degrees. 
> The issue seems related to the ncks clipping, if I exclude the x clip,
> everything works out fine, but takes significantly longer. 
> Here's an example once it's loaded into an erddap server; 
> <http://osgeo-org.1560.x6.nabble.com/file/t382897/GOES16_L2CMIPF_M3C01_201803201200.png <https://urldefense.proofpoint.com/v2/url?u=http-3A__osgeo-2Dorg.1560.x6.nabble.com_file_t382897_GOES16-5FL2CMIPF-5FM3C01-5F201803201200.png&d=DwMGaQ&c=ZWY66qCYUTYUcOev9C2GlDEcKuYKzoWDVNR_L93Z9mQ&r=xGAbC1Ogv9duClaR3TChYqg_fGB4xrhak7uN1kZcfR8&m=0691hAhg8moDDDi0i-csopQGwl9LCy8yuefXjalO0vQ&s=cn4pjYjeC3jugb7R5Knazy7vp4bkXq-VhoKI6CAQhVs&e=>> 
> You can see greenland to the west of it's map underlay. 
> 
> I'm using gdal v2.3.0, netcdf v4.4.1.1, nco v4.7.3 & proj4 v5.0.0 
> 
> 
> 
> 
> 
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__osgeo-2Dorg.1560.x6.nabble.com_GDAL-2DDev-2Df3742093.html&d=DwMGaQ&c=ZWY66qCYUTYUcOev9C2GlDEcKuYKzoWDVNR_L93Z9mQ&r=xGAbC1Ogv9duClaR3TChYqg_fGB4xrhak7uN1kZcfR8&m=0691hAhg8moDDDi0i-csopQGwl9LCy8yuefXjalO0vQ&s=-fnlaXGCZBUsGk7PEYpsRh26l-qFT1E4lJ9u8ZkH0vo&e=>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/gdal-dev <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.osgeo.org_mailman_listinfo_gdal-2Ddev&d=DwMGaQ&c=ZWY66qCYUTYUcOev9C2GlDEcKuYKzoWDVNR_L93Z9mQ&r=xGAbC1Ogv9duClaR3TChYqg_fGB4xrhak7uN1kZcfR8&m=0691hAhg8moDDDi0i-csopQGwl9LCy8yuefXjalO0vQ&s=zDMkCvDbctF6dQi2AA6bN6zdwY_AkV-EsH495ySbCRE&e=>
>  
>  
> 
> 
> This message is the property of John Wood Group PLC and/or its subsidiaries and/or affiliates and is intended only for the named recipient(s). Its contents (including any attachments) may be confidential, legally privileged or otherwise protected from disclosure by law. Unauthorised use, copying, distribution or disclosure of any of it may be unlawful and is strictly prohibited. We assume no responsibility to persons other than the intended named recipient(s) and do not accept liability for any errors or omissions which are a result of email transmission. If you have received this message in error, please notify us immediately by reply email to the sender and confirm that the original message and any attachments and copies have been destroyed and deleted from your system.
> 
> 
> 
> If you do not wish to receive future unsolicited commercial electronic messages from us, please forward this email to: unsubscribe at woodplc.com <mailto:unsubscribe at woodplc.com>and include “Unsubscribe” in the subject line. If applicable, you will continue to receive invoices, project communications and similar factual, non-commercial electronic communications.
> 
> 
> 
> Please click http://www.woodplc.com/email-disclaimer <http://www.woodplc.com/email-disclaimer> for notices and company information in relation to emails originating in the UK, Italy or France.
> 
> 
> 
>  
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/gdal-dev <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20180329/d38c3807/attachment-0001.html>