Parameter +range in polynomial transformation +horner

[Jochem-L]

I found two problems with the range parameter in the polynomial transformation +horner. I assume the range parameter was added because a polynomial transformation gives terrible results outside its area of validity.

Problem 1

The +range parameter (default value 500 000) applies on the input coordinates in the forward and inverse transformation. I think it should apply on the input coordinates in the forward transformation, but it should apply on the output coordinates in the inverse transformation. That would mean one can use the same range for the forward and inverse transformation. This is currently not the case, which is confusing.

Forward example

(echo 30000.00 100000.00 & echo 30000.00 120000.00) | cct -d 2 -z 0 +proj=horner +deg=3 +fwd_origin=0,0 
+fwd_u=+120025.8705,+0.999986846,-0.0250515e-8,+0.1471965e-14,+0.006918172,-0.0860518e-8,-0.0398590e-14,+0.0011249e-8,+0.4556545e-14,+0.1991105e-14 
+fwd_v=+390181.7849,+0.999993024,-0.0338879e-8,+0.1184845e-14,-0.006907254,-0.0492600e-8,-0.1945916e-14,+0.0222878e-8,+0.9244571e-14,-0.1091684e-14 
+inv_tolerance=0.001
    150717.96      489970.61          0.00           inf
    150857.90      509969.45          0.00           inf

Inverse example

(echo 150717.96 489970.61 & echo 150857.90 509969.45) | cct -d 2 -z 0 +proj=horner +deg=3 +fwd_origin=0,0 
+fwd_u=+120025.8705,+0.999986846,-0.0250515e-8,+0.1471965e-14,+0.006918172,-0.0860518e-8,-0.0398590e-14,+0.0011249e-8,+0.4556545e-14,+0.1991105e-14 
+fwd_v=+390181.7849,+0.999993024,-0.0338879e-8,+0.1184845e-14,-0.006907254,-0.0492600e-8,-0.1945916e-14,+0.0222878e-8,+0.9244571e-14,-0.1091684e-14 
+inv_tolerance=0.001 +inv
     30000.00      100000.00          0.00           inf
#Record 1 TRANSFORMATION ERROR: 150857.90 509969.45
 (Point outside of projection domain)

To solve the error, a different range parameter needs to be specified.

(echo 150717.96 489970.61 & echo 150857.90 509969.45) | cct -d 2 -z 0 +proj=horner +deg=3 +fwd_origin=0,0 
+fwd_u=+120025.8705,+0.999986846,-0.0250515e-8,+0.1471965e-14,+0.006918172,-0.0860518e-8,-0.0398590e-14,+0.0011249e-8,+0.4556545e-14,+0.1991105e-14 
+fwd_v=+390181.7849,+0.999993024,-0.0338879e-8,+0.1184845e-14,-0.006907254,-0.0492600e-8,-0.1945916e-14,+0.0222878e-8,+0.9244571e-14,-0.1091684e-14 
+inv_tolerance=0.001 +range=600000 +inv
     30000.00      100000.00          0.00           inf
     30000.00      120000.00          0.00           inf  

Problem 2

It makes no sense to use a range parameter if the origin is not in the centre of the area of use (e.g. in case of false easting and northing). A bounding box would be more appropriate.

In the example given above the input coordinates for the forward transformation are approximately: -100 000 < x < +200 000 -100 000 < y < +200 000

But the input coordinates in the inverse transformation are: 0 < x < +300 000 +300 000 < y < +600 000

[chikle9090]

Hi, I would like to work on this issue.

To confirm: you want the +range parameter to apply on input for forward transforms and on OUTPUT for inverse transforms. And possibly consider adding +bbox for cases where the origin is off-center?

Can you please guide me on:

• preferred naming for +bbox?
• whether backward compatibility for +range should be preserved?

Thanks!

[Jochem-L]

Hi,

Thanks for taking this a step further.

To confirm: you want the +range parameter to apply on input for forward transforms and on OUTPUT for inverse transforms. And possibly consider adding +bbox for cases where the origin is off-center?

That is correct.

preferred naming for +bbox?

I think +bbox would be an appropriate name. However, there are different conventions for the order of the corner coordinates. Not all software and data formats use bbox=<west>,<south>,<east>,<north>. Is there a logical order for PROJ? Alternatively, you could consider using +range=<distance> +centre=<coordinate 1>,<coordinate 2>.

whether backward compatibility for +range should be preserved?

Keeping +range for backward compatibility would be nice anyway.

Jochem

[busstoptaktik]

Just a few words of explanation: The polynomial shift operator method was introduced in order to implement datum shifts, i.e. typically shifts on the meter to hundred-meter scale. Hence worrying about whether a range (defaulting to 5000 times that scale) applies to input or output coordinates is (was) mostly immaterial

[Jochem-L]

Thanks for the explanation. I use it for a transformation from projected to projected coordinates.

But if it was introduced for latlon to latlon, why is the validity only a range from the origin lat,lon=0,0? That doesn't make sense.

[busstoptaktik]

I don't remember the details, but it was intended for transformation between (old realization of ED50) and (revised realization of ED50), using an intermediate UTM-like projected coordinate system (TC32). Hence geo->tmerc->horner->inv tmerc->geo