[gdal-dev] Why not netCDF output?

Even Rouault even.rouault at mines-paris.org
Mon Sep 27 16:28:15 EDT 2010


Le lundi 27 septembre 2010 22:11:43, Joaquim Luis a écrit :

> 
> Well, using your own words, and to not extend the wording too much.
> Something like
> 
> ... 'rw+' is read, write and update (ie. supports Create). Note: The
> valid formats for the output of gdalwarp are formats that support the
> Create() method, not just the CreateCopy() method.

Applied. But note that gdalwarp is just a (common) example. There are also 
other utilities that have this restriction.

> 
> > Yes I reproduce it too. I managed to solve it by increasing the
> > SAMPLE_STEPS
> > warping option to 60 for example (input source is 5120 x 2560). See
> > http://gdal.org/structGDALWarpOptions.html for more explanations
> > 
> > gdalwarp world.tif  -t_srs "+proj=ortho +lon_0=-42 +lat_0=40
> > +ellps=WGS84" out.tif -overwrite -wo SAMPLE_STEPS=60
> 
> Thanks. It worked for me too. I have followed this issue that is
> recurrent here in different disguises.
> If it was easy to solve you guys would have done it long ago, but about
> a warning message when this problem arises?
> I mean, is there any doable way to detect a posteriori that the shit
> happened and the SAMPLE_STEPS can help clean it?

Yes, that's probably doable, but clearly not trivial. I add a hard time (look 
at how ugly/complicated the code now looks...) doing something similar in 
GDALSuggestedWarpOutput2() to guess the extent of the target extent when such 
discontinuities in the reprojection occur (and it  probably doesn't solve 100% 
situations). Something similar (in spirit) would probably be needed in 
GDALWarpOperation::ComputeSourceWindow().

> 
> Joaquim


More information about the gdal-dev mailing list