On Wed, Jan 16, 2013 at 1:49 PM, Frank Warmerdam wrote:
> Folks,
>
> As I often seem to do, I exactly stated my point. I meant write:
Garr, once again missing a keyword.
I meant to say "I exactly stated my point *wrong*."
> "On the other hand, I am *not* denying the possibility that the RPC
>
Folks,
As I often seem to do, I exactly stated my point. I meant write:
"On the other hand, I am *not* denying the possibility that the RPC
DEM interpolation is always off by half a pixel in all cases."
Sorry for that.
On Wed, Jan 16, 2013 at 1:35 PM, Ivan Lucena
wrote:
> Hi Frank,
>
>> On
Hi Frank,
> On the other hand, I am denying the possibility that the RPC DEM
> interpolation is always off by half a pixel. I haven't actually
> looked closely at that code lately and the RPC code is not so very well
> tested and validated.
That is exactly what I understood from Yehiyam on
Hi Frank,
I only want to note that the default is bilinear interpolation of the DEM.
Part of the code: const char *pszDEMInterpolation =
CSLFetchNameValueDef( papszOptions, "RPC_DEMINTERPOLATION", "bilinear" );
Best regards,
Dmitriy
16.01.2013 22:47, Frank Warmerdam ?:
Yehiyam,
I d
Yehiyam,
I do not see why you think the AREA_OR_POINT value ought to have any
influence on how DEM values are interpolated.
Note that a PixelIsPoint GeoTIFF file will already result in a GDAL
GeoTransform that is offset by half a pixel. The GDAL GeoTransform always
treats pixels as areas, and GD
Hi Ivan,
Look here:
http://www.gdal.org/gdal__alg_8h.html#af4c3c0d4c79218995b3a1f0bac3700a0
You can find such options:
*
RPC_HEIGHT: a fixed height offset to be applied to all points passed
in. In this situation the Z passed into the transformation function
is assumed to be height a
Yehiyam,
For that kind of issue my advise is to run in debugging mode. The GDAL
transformation engine must have an internal pixel geolocation defined.
It is probably CENTER of the pixel, as in AREA. I am not sure. In that
case the returning pixel/line refers to AREA and you might need to do
t
Hi
I have a question about the RPC transform implemented in gdal_rpc.cpp.
If a dem file is specified in the transform options (RPC_DEM) the file is
sampled to retrieve the elevation of the transformed point.
In the case where the dem file is a DTED file (which defines AREA_OR_POINT to
POINT), sh
Yes, I am sure I entered the -te parameters correctly. When I also
use -tr to specify the output pixel size, I get the correct result in
this one test case. Is there no other option than this work around?
It seems like some sort of systematic issue with RPCs that would be
good to address at the s
The error you get can usually be avoided when you set the output
bounds correctly. Are you sure the -te options you use are correct?
ERROR 1: Too many points (441 out of 441) failed to transform, unable
to compute output bounds
On Mon, Apr 9, 2012 at 1:57 PM, Claire Porter wrote:
> Etienne,
>
Etienne,
When I set the extents using -te, I get an output of size 0. I think
the problem is not in the warping itself, but in the transformation
using the RPCs.
Thanks,
Claire
On Mon, Apr 9, 2012 at 10:04 AM, Etienne Tourigny
wrote:
> Claire,
>
> You may have to set the output extents manual
Claire,
You may have to set the output extents manually with the -te option.
This has been the solution to many problems with gdalwarp.
Etienne
On Mon, Apr 9, 2012 at 11:12 AM, Claire Porter wrote:
> Dmitry (and the list),
>
> Using the warp options you suggested does not make a difference.
Dmitry (and the list),
Using the warp options you suggested does not make a difference. Even
SAMPLE_GRID does not significantly change the output. I also tried using
wgs84 as the output coordinate system in case it was an issue of being
projected into Polar Stereographic: no luck.
I copied the
08.04.2012 0:08, Claire Porter ???:
I sometimes get the error message "ERROR 1: latitude or longitude
exceeded limits" when using gdalwarp with Quickbird, Worldview and
Geoeye images using RPCs, both with and without a DEM. Sometimes I
also get the error message "ERROR 1: Too many points (
I sometimes get the error message "ERROR 1: latitude or longitude exceeded
limits" when using gdalwarp with Quickbird, Worldview and Geoeye images
using RPCs, both with and without a DEM. Sometimes I also get the error
message "ERROR 1: Too many points (441 out of 441) failed to transform,
unable
15 matches
Mail list logo
