How to correctly handle coordinates in gradians in GIGS 5102.2

[Kontinuation]

I recently investigated some issues related to coordinate transformations between EPSG:4807 and EPSG:27572 and noticed that the GIGS test 5102.2.gie.failing is failing. For example, the following projection gives 750546.04 4202212.53, while the expected result is 760724.023 3457334.864:

echo "2.9586342556 64.4444444444" | proj +proj=pipeline +step +init=epsg:4807 +inv +step +init=epsg:27572
750546.04	4202212.53

After doing some investigations I found that the EPSG:4807 coordinates in the GIGS tests are in gradians, while proj interprets input coordinates as degrees. Adding a unitconvert to the pipeline made proj produce the expected result:

echo  2.9586342556 64.4444444444 | cct -t 0 -z 0 +proj=pipeline +step +proj=unitconvert +xy_in=grad +xy_out=rad +step +init=epsg:4807 +inv +step +init=epsg:27572
  760724.0227   3457334.8636        0.0000        0.0000

Then we can make the test pass by inserting unitconvert to all the gie operations.

gie ./5102.2.gie.failing
-------------------------------------------------------------------------------
Reading file './5102.2.gie.failing'
-------------------------------------------------------------------------------
total: 57 tests succeeded,  0 tests skipped,  0 tests failed.
-------------------------------------------------------------------------------

Is this a correct fix, or how to handle grads coordinates correctly in proj? This manual unit conversion looks weird since EPSG:4807 coordinates were supposed to be in grads.

[kbevers]

Something doesn't look quite right. The GIGS gie files are quite old and haven't really been updated to the more modern ways of PROJ, so I'm not sure they are the best starting point here.

Trying the conversion using cs2cs gives the same result as shown in the first example above:

> echo 64.44444444 2.9586342556 | cs2cs EPSG:4807 EPSG:27572                    
750546.04       4202212.52 0.00 

If we inspect the transformation we get the following pipeline, which indeed does include the gradian to radian conversion but I suspect it isn't applied correctly for some reason.

> projinfo -s EPSG:4807 -t EPSG:27572 -o PROJ
Candidate operations found: 1
-------------------------------------
Operation No. 1:

EPSG:18082, Lambert zone II, 0 m, France mainland onshore between 50.5 grads and 53.5 grads North (45┬░27'N to 48┬░09'N). Also used over all onshore mainland France.

PROJ string:
+proj=pipeline
  +step +proj=axisswap +order=2,1
  +step +proj=unitconvert +xy_in=grad +xy_out=rad
  +step +inv +proj=longlat +ellps=clrk80ign +pm=paris
  +step +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.99987742 +x_0=600000
        +y_0=2200000 +ellps=clrk80ign +pm=paris

A simple unit conversion confirms that something is fishy:

> echo 64.44444444 2.9586342556 0 0| cct +proj=unitconvert +x_in=grad +x_out=rad
      64.4444         2.9586        0.0000        0.0000

I'm not entirely sure what's going on here, since it seems there are situations where the gradinan->radian conversion works (e.g. the original example) and others were it doesn't.

[Kontinuation]

If we inspect the transformation we get the following pipeline, which indeed does include the gradian to radian conversion but I suspect it isn't applied correctly for some reason.

Yes. I'm also aware of this unitconvert step in the pipeline given by projinfo. I suspect that the unitconvert step was skipped since proj and cs2cs assumes that input geographic data were in degrees, according to the documentation.

The simple unit conversion works when specifying +xy_in and +xy_out. I haven't seen +x_in and +x_out in the documentation so I'm not sure if they should work.

> echo 64.44444444 2.9586342556 0 0 | cct +proj=unitconvert +xy_in=grad +xy_out=rad
 57.9999999960    2.6627708300        0.0000        0.0000

[kbevers]

The simple unit conversion works when specifying +xy_in and +xy_out. I haven't seen +x_in and +x_out in the documentation so I'm not sure if they should work.

That's simply me mistyping and should be disregarded. Good catch!

[rouault]

fix in #3878