[PROJ] [PROJ 6.0.0] Different behaviors for creating a transformation of type EPSG:9616

[Didier Richard]

Ok, in that case, two more questions :

1.- why not returning a PROJ_OBJ_LIST for proj_create_crs_to_crs to get a clearer API (and let the user choose amongst transformations) ?

2.- how to get the inner projections (proj_crs_get_coordoperation does not seem the right one) ?

--
RICHARD Didier - Chef du Centre de Compétences Technologies des Systèmes d'Information
http://fr.linkedin.com/pub/didier-richard/98/2a3/a8/ - https://www.osgeo.org/member/didier/
IGN/Direction des Sciences et Technologies de l'Information/ENSG Géomatique
6/8 avenue Blaise Pascal - BP Champs-sur-Marne - 77455 MARNE-LA-VALLÉE CEDEX 2
Tél : +33 (0) 1 43 98 83 23


________________________________________
De : Even Rouault [even.rouault at spatialys.com]
Envoyé : mardi 30 avril 2019 19:25
À : Didier Richard
Cc : proj at lists.osgeo.org
Objet : Re: [PROJ] [PROJ 6.0.0] Different behaviors for creating a transformation of type EPSG:9616

> 2.- Tested on IGNF:NTFLAMB2E.NGF84 to IGNF:ETRS89LCC.EVRF2000
> but the final type is PJ_TYPE_UNKNOWN, not
> PJ_TYPE_OTHER_COORDINATE_OPERATION :

>
>     obj = proj_create_crs_to_crs(c, "IGNF:NTFLAMB2E.NGF84",
> "IGNF:ETRS89LCC.EVRF2000", NULL);

Ah, another subtelty here...
If you look at the projinfo -s -t output, you'll see several candidate
operations.
proj_create_crs_to_crs() in that case stores them inside a "wrapper" PJ
object. So in that situation where you have the wrapper PJ returned, its type
is PJ_TYPE_UNKNOWN.

(When proj_trans() is called, then one of the candidates is selected
dependending on the input coordinates.)

--
Spatialys - Geospatial professional services
http://www.spatialys.com