[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