You mean the HEIGHT_OFFSET parameter in the RPC ? Yes, that can
generally be used as a first-order correction if you don't use a DEM.
I'm not sure using it vs not-using it has been a deliberate choice. One
could say that with the current behavior people know that something is
wrong and must thu
Finally I solved the issue by adding "-to RPC_HEIGHT=XXX" to gdalwarp.
It seems gdalwarp doesn't take this parameter into account even if it is
presented in the RPC *.txt file.
Should I file the ticket or was it done by purpose?
On Tue, May 18, 2021 at 11:26 PM Denis Rykov wrote:
> Thanks!
>
> O
Thanks!
On Tue, May 18, 2021 at 10:57 PM Even Rouault
wrote:
> Denis,
>
> if the view angle is off-nadir, you generally need to use the -to RPC_DEM=
> option with a DEM covering the area of interest (and make sure the values
> it contains are WGS 84 ellipsoidal elevations) to get accurate result
Denis,
if the view angle is off-nadir, you generally need to use the -to
RPC_DEM= option with a DEM covering the area of interest (and make sure
the values it contains are WGS 84 ellipsoidal elevations) to get
accurate results.
Even
Le 18/05/2021 à 22:50, Denis Rykov a écrit :
Hi,
I have
Hi,
I have a GeoTIF file and file with RPC information next to it (*.txt). Is
there a way to transform this raster to a normal geotiff without
displacement (with geotransform inside) or is it fundamentally impossible?
I've tried to achieve it with gdalwarp but in this case the result of the
transf
Surya Prakash:
> Hi ALL, I have some imagery associated with RPC files. The locational
> accuracy of the images defined by the RPCs is quite poor and I would
> like to update the RPCs by using some additional GCPs. How to do this,
> Please guide me.
Hi Surya!
May I ask which kind of imagery? If
Le lundi 18 janvier 2016 08:39:06, Surya Prakash a écrit :
> Hi ALL,
> I have some imagery associated with RPC files. The locational accuracy of
> the images defined by the RPCs is quite poor and I would like to update
> the RPCs by using some additional GCPs. How to do this, Please guide me.
You
Hi ALL,
I have some imagery associated with RPC files. The locational accuracy of the
images defined by the RPCs is quite poor and I would like to update the RPCs by
using some additional GCPs. How to do this, Please guide me.
Thanks & regards
SPR___
g
Le lundi 22 juin 2015 08:29:18, Pablo d'Angelo a écrit :
> Hi Even,
>
> Am 19.06.2015 um 23:53 schrieb Even Rouault:
> > Actually keeping the RPC metadata as it is found in the sources (with the
> > exception of Pleiades and their weird center of pixel (1,1) convention
> > perhaps, as proposed in
Hi Even,
Am 19.06.2015 um 23:53 schrieb Even Rouault:
Actually keeping the RPC metadata as it is found in the sources (with the
exception of Pleiades and their weird center of pixel (1,1) convention
perhaps, as proposed in
https://trac.osgeo.org/gdal/attachment/ticket/5993/fix_PleiadesRPC.patch
Le vendredi 19 juin 2015 23:00:18, Frank Warmerdam a écrit :
> Even,
>
> I feel that the RPC coefficients have well establish meanings from the
> NITF spec, and file formats like _rpc.txt. I assume they are
> center-of-pixel oriented.
I couldn't find anything explicit about that when skimming t
Even,
I feel that the RPC coefficients have well establish meanings from the
NITF spec, and file formats like _rpc.txt. I assume they are
center-of-pixel oriented. I would *not* want the RPC metadata we keep
(ie https://trac.osgeo.org/gdal/wiki/rfc22_rpc) to have a different
meaning for the pixe
Hi,
I think the vendor specific shifts should be accepted to RPC while
reading via mdreader or something same. So the fix_PleiadesRPC.patch
looks good.
Also about changing alg/gdal_rpc.cpp: мaybe the addition config key,
i.e. RPC_SHIFT which will be 0.5 as default value?
Best regards,
Dmi
Le vendredi 19 juin 2015 15:47:54, Pablo d'Angelo a écrit :
> Dear GDAL Developers,
>
> i have recently compared the results of our internal RPC based
> orthorectification software and have found several difference, which I
> think are due to various "corner" vs "center" of pixel issues in the RPC
Dear GDAL Developers,
i have recently compared the results of our internal RPC based
orthorectification software and have found several difference, which I
think are due to various "corner" vs "center" of pixel issues in the RPC
transform code. This lead to significant shifts when using lower
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
Hello,
I have developed a program that compute the RPC of an input tif image.
Now I want to validate this computation. Could you tell me how I can compute
the RPCs of an input image using gdal?
Best Regards,
Jorge
___
gdal-dev mailing list
gdal-de
Hi,
I've tried that, but without any success. I have no problem warping the
image, that works fine. The problem comes in when I try to warp with the
DEM.
Chris
On Fri, Jul 8, 2011 at 1:12 PM, Chaitanya kumar CH
wrote:
> Chris,
>
> This could happen when you try to transform an image that is o
Chris,
This could happen when you try to transform an image that is outside the
defined area of the destination projection.
Cut the raster to the destination projection's extents and try again.
There is a thread with exactly the same error message in the archives[1]. I
am not sure that it can hel
Hi,
I've seen that there are quite a lot of messages on this problem, but none
of them helped. When running the following command:
gdalwarp -rpc raw.tif out.tif
with a raw.tif and raw.rpb file, the image "orthorectifies" correctly. The
moment I run:
gdalwarp -rpc -to RPC_DEM
34 matches
Mail list logo
