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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Didier Richard
Hi all,

Still on library testing, I try to create using different methods a transformation that exists in the proj.db, in other_transformation table (IGNF:TSG1250 which is EPSG:9616 method) :

1.- using proj_create : fails ;
2.- using proj_create_from_database : succeed but got a type different from the one given to the function ;
3.- using proj_create_from_name : succeed but got a type which is not PJ_TYPE_OTHER_COORDINATE_OPERATION (expected).

Any thoughts on these differences between function calls and return transformation types ?

The code :

#include <stdio.h>
#include <string.h>
#include "proj.h"

int main ( int argc, char *argv[] ) {
    PJ_CONTEXT *c;
    PJ_OBJ_LIST *list;
    PJ_TYPE types[] = { PJ_TYPE_CONVERSION, PJ_TYPE_TRANSFORMATION, PJ_TYPE_CONCATENATED_OPERATION, PJ_TYPE_OTHER_COORDINATE_OPERATION };
    PJ *obj;
    PJ_PROJ_INFO info;
    int i, n;
    const char *wkt;

    fprintf(stderr,"PJ_TYPE_CONVERSION = %d\n", PJ_TYPE_CONVERSION);
    fprintf(stderr,"PJ_TYPE_TRANSFORMATION = %d\n", PJ_TYPE_TRANSFORMATION);
    fprintf(stderr,"PJ_TYPE_CONCATENATED_OPERATION = %d\n", PJ_TYPE_CONCATENATED_OPERATION);
    fprintf(stderr,"PJ_TYPE_OTHER_COORDINATE_OPERATION = %d\n", PJ_TYPE_OTHER_COORDINATE_OPERATION);
    c = proj_context_create();

    obj = proj_create(c, "IGNF:SG1250");
    if ( obj != NULL ) {
        fprintf(stderr,"IGNF:TSG1250 created as %d\n", proj_get_type(obj));
        info = proj_pj_info(obj);
        fprintf(stderr,"Info :\nID:%s\nDesc:%s\nDef:%s\nInv:%d\nAcc:%f\n", info.id, info.description, info.definition, info.has_inverse, info.accuracy);
        proj_destroy(obj);
    }

    for ( i = 0; i < 4 ; i++) {
        obj = proj_create_from_database(c, "IGNF", "TSG1250", types[i], 0, NULL);
        if ( obj != NULL ) {
            fprintf(stderr,"IGNF:TSG1250 created as %d but has type %d ?!\n", types[i], proj_get_type(obj));
            info = proj_pj_info(obj);
            fprintf(stderr,"Info :\nID:%s\nDesc:%s\nDef:%s\nInv:%d\nAcc:%f\n", info.id, info.description, info.definition, info.has_inverse, info.accuracy);
            proj_destroy(obj);
        }
    }

    list = proj_create_from_name(c,"IGNF","NGF-IGN 1969 vers EVRF2000",types,4,1,0,NULL);
    if (list == NULL) {
        fprintf(stderr,"Error : %s\n", proj_errno_string(proj_context_errno(c)));
        return 1;
    }
    n = proj_list_get_count(list);
    fprintf(stderr, "found %d object(s) :\n", n);
    for ( i = 0; i < n; i++) {
        obj = proj_list_get(c, list, i);
        fprintf(stderr,"found %s of type %d\n", proj_get_name(obj), proj_get_type(obj));
        info = proj_pj_info(obj);
        fprintf(stderr,"Info :\nID:%s\nDesc:%s\nDef:%s\nInv:%d\nAcc:%f\n", info.id, info.description, info.definition, info.has_inverse, info.accuracy);
        proj_destroy(obj);
    }
    proj_list_destroy(list);
    proj_context_destroy(c); /* may be omitted in the single threaded case */
    return 0;
}

The output :

PJ_TYPE_CONVERSION = 21
PJ_TYPE_TRANSFORMATION = 22
PJ_TYPE_CONCATENATED_OPERATION = 23
PJ_TYPE_OTHER_COORDINATE_OPERATION = 24
proj_create: crs not found
IGNF:TSG1250 created as 21 but has type 0 ?!
Info :
ID:(null)
Desc:ISO-19111 object
Def:
Inv:0
Acc:-1.000000
IGNF:TSG1250 created as 22 but has type 0 ?!
Info :
ID:(null)
Desc:ISO-19111 object
Def:
Inv:0
Acc:-1.000000
IGNF:TSG1250 created as 23 but has type 0 ?!
Info :
ID:(null)
Desc:ISO-19111 object
Def:
Inv:0
Acc:-1.000000
IGNF:TSG1250 created as 24 but has type 0 ?!
Info :
ID:(null)
Desc:ISO-19111 object
Def:
Inv:0
Acc:-1.000000
found 1 object(s) :
pj_ellipsoid - final: a=6378137.000 f=1/298.257, errno=0
pj_ellipsoid - final:    ellps=GRS80
found NGF-IGN 1969 vers EVRF2000 (UELN-95/98)(EUROPEAN VERTICAL REFERENCE FRAME) of type 22
Info :
ID:geogoffset
Desc:NGF-IGN 1969 vers EVRF2000 (UELN-95/98)(EUROPEAN VERTICAL REFERENCE FRAME)
Def:proj=geogoffset dh=-0.486 ellps=GRS80
Inv:1
Acc:-1.000000

Regards,
--
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

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

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

Even Rouault-2
On mardi 30 avril 2019 13:06:43 CEST Didier Richard wrote:
> Hi all,
>
> Still on library testing, I try to create using different methods a
> transformation that exists in the proj.db, in other_transformation table
> (IGNF:TSG1250 which is EPSG:9616 method) :
>
> 1.- using proj_create : fails ;

Yes, expected. See
https://proj4.org/development/reference/functions.html#c.proj_create

Short syntax AUTH:CODE in proj_create() will try only CRS objects.
Use urn:ogc:def:coordinateOperation:AUTH::CODE for coordinate operations

> 2.- using proj_create_from_database : succeed but got a type different from
> the one given to the function ;

Misuse of the API. You should pass a PJ_CATEGORY value, not a PJ_TYPE one;
Unfortunately a C compiler doesn't warn about that, wheras a C++ errors out.
So use PJ_CATEGORY_COORDINATE_OPERATION
(the fact that it returned something is completely undefined behavior. it
might have crashed as well)

> 3.- using proj_create_from_name : succeed
> but got a type which is not PJ_TYPE_OTHER_COORDINATE_OPERATION (expected).

Yes, returns PJ_TYPE_TRANSFORMATION=22 as expected

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

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

Didier Richard

1.- Does not work either with "urn:ogc:def:coordinateOperation:IGNF::SG1250". I guess because of the authority ?

2.- My bad. It works with PJ_CATEGORY_COORDINATE_OPERATION and returns PJ_TYPE_TRANSFORMATION ! Thx a lot

3.- Ok, I thought that operations located in other_transformation table were of type PJ_TYPE_OTHER_COORDINATE_OPERATION. Do you have an example of an operation for which the type is PJ_TYPE_OTHER_COORDINATE_OPERATION ? I found nothing in the test/ directory checking this.

--
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 [[hidden email]]
Envoyé : mardi 30 avril 2019 15:50
À : [hidden email]
Cc : Didier Richard
Objet : Re: [PROJ] [PROJ 6.0.0] Different behaviors for creating a transformation of type EPSG:9616

On mardi 30 avril 2019 13:06:43 CEST Didier Richard wrote:
> Hi all,
>
> Still on library testing, I try to create using different methods a
> transformation that exists in the proj.db, in other_transformation table
> (IGNF:TSG1250 which is EPSG:9616 method) :
>
> 1.- using proj_create : fails ;

Yes, expected. See
https://proj4.org/development/reference/functions.html#c.proj_create

Short syntax AUTH:CODE in proj_create() will try only CRS objects.
Use urn:ogc:def:coordinateOperation:AUTH::CODE for coordinate operations

> 2.- using proj_create_from_database : succeed but got a type different from
> the one given to the function ;

Misuse of the API. You should pass a PJ_CATEGORY value, not a PJ_TYPE one;
Unfortunately a C compiler doesn't warn about that, wheras a C++ errors out.
So use PJ_CATEGORY_COORDINATE_OPERATION
(the fact that it returned something is completely undefined behavior. it
might have crashed as well)

> 3.- using proj_create_from_name : succeed
> but got a type which is not PJ_TYPE_OTHER_COORDINATE_OPERATION (expected).

Yes, returns PJ_TYPE_TRANSFORMATION=22 as expected

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

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

Even Rouault-2
On mardi 30 avril 2019 14:02:50 CEST Didier Richard wrote:
> 1.- Does not work either with
> "urn:ogc:def:coordinateOperation:IGNF::SG1250". I guess because of the
> authority ?

no just a typo. Missing T before SG1250

> 3.- Ok, I thought that operations located in other_transformation table were
> of type PJ_TYPE_OTHER_COORDINATE_OPERATION. Do you have an example of an
> operation for which the type is PJ_TYPE_OTHER_COORDINATE_OPERATION ? I
> found nothing in the test/ directory checking this.

For example, if you would do a transformation from a CompoundCRS to another
CompoundCRS (or a Geographic3D CRS) with both horizontal and vertical
transformations, there is nothing in ISO:19111 to model the composite of both.
So there's an internal PROJ C++ class, PROJBasedOperation, whose type would be
exposed as PJ_TYPE_OTHER_COORDINATE_OPERATION

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

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

Martin Desruisseaux-3
Le 30/04/2019 à 16:19, Even Rouault a écrit :
For example, if you would do a transformation from a CompoundCRS to another CompoundCRS (or a Geographic3D CRS) with both horizontal and vertical transformations, there is nothing in ISO:19111 to model the composite of both.

Actually this is modeled with PassThroughOperation + ConcatenatedOperation. So a transformation between two CompoundCRS with a vertical component would be like below:

ConcatenatedOperation (a 3D operation in this example)
    PassThroughOperation (a 3D operation in this example)
        coordOperation = the operation on the horizontal component
        modifiedCoordinate = {0, 1}
    PassThroughOperation (a 3D operation in this example)
        coordOperation = the operation on the vertical component
        modifiedCoordinate = 2

Martin



_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

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

Even Rouault-2
On mardi 30 avril 2019 16:40:55 CEST Martin Desruisseaux wrote:

> Le 30/04/2019 à 16:19, Even Rouault a écrit :
> > For example, if you would do a transformation from a CompoundCRS to
> > another CompoundCRS (or a Geographic3D CRS) with both horizontal and
> > vertical transformations, there is nothing in ISO:19111 to model the
> > composite of both.
>
> Actually this is modeled with PassThroughOperation +
> ConcatenatedOperation. So a transformation between two CompoundCRS with
> a vertical component would be like below:
>
>     ConcatenatedOperation (a 3D operation in this example)
>         PassThroughOperation (a 3D operation in this example)
>             coordOperation = the operation on the horizontal component
>             modifiedCoordinate = {0, 1}
>         PassThroughOperation (a 3D operation in this example)
>             coordOperation = the operation on the vertical component
>             modifiedCoordinate = 2

Ah, I had forgotten about that beast indeed !
Well, too late/no need to introduce it now. It has also the slight
inconvenient of not having a WKT2 representation, so this concept remains
mostly an implementation detail for non-super-ISO:19111-aware users.
When exporting to WKT2, the PROJBaseOperation is translated into a somewhat
hacky COORDINATEOPERATION but which explains a bit what is done.

$ src/projinfo -s EPSG:7406 -t EPSG:5500

[...]

COORDINATEOPERATION["Transformation from NGVD29 height (ftUS) to NAVD88 height
(ballpark vertical transformation) + NAD27 to WGS 84 (79) + Inverse of
NAD83(NSRS2007) to WGS 84 (1)",
    SOURCECRS[
        COMPOUNDCRS["NAD27 + NGVD29 height (ftUS)",
            GEOGCRS["NAD27",
                DATUM["North American Datum 1927",
                    ELLIPSOID["Clarke 1866",6378206.4,294.978698213898,
                        LENGTHUNIT["metre",1]]],
                PRIMEM["Greenwich",0,
                    ANGLEUNIT["degree",0.0174532925199433]],
                CS[ellipsoidal,2],
                    AXIS["geodetic latitude (Lat)",north,
                        ORDER[1],
                        ANGLEUNIT["degree",0.0174532925199433]],
                    AXIS["geodetic longitude (Lon)",east,
                        ORDER[2],
                        ANGLEUNIT["degree",0.0174532925199433]]],
            VERTCRS["NGVD29 height (ftUS)",
                VDATUM["National Geodetic Vertical Datum 1929"],
                CS[vertical,1],
                    AXIS["gravity-related height (H)",up,
                        LENGTHUNIT["US survey foot",0.304800609601219]]],
            ID["EPSG",7406]]],
    TARGETCRS[
        COMPOUNDCRS["NAD83(NSRS2007) + NAVD88 height",
            GEOGCRS["NAD83(NSRS2007)",
                DATUM["NAD83 (National Spatial Reference System 2007)",
                    ELLIPSOID["GRS 1980",6378137,298.257222101,
                        LENGTHUNIT["metre",1]]],
                PRIMEM["Greenwich",0,
                    ANGLEUNIT["degree",0.0174532925199433]],
                CS[ellipsoidal,2],
                    AXIS["geodetic latitude (Lat)",north,
                        ORDER[1],
                        ANGLEUNIT["degree",0.0174532925199433]],
                    AXIS["geodetic longitude (Lon)",east,
                        ORDER[2],
                        ANGLEUNIT["degree",0.0174532925199433]]],
            VERTCRS["NAVD88 height",
                VDATUM["North American Vertical Datum 1988"],
                CS[vertical,1],
                    AXIS["gravity-related height (H)",up,
                        LENGTHUNIT["metre",1]]],
            ID["EPSG",5500]]],
    METHOD["PROJ-based operation method (approximate): +proj=pipeline +step
+proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +z_in=us-ft
+xy_out=rad +z_out=m +step +proj=hgridshift +grids=conus +step
+proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1"],
    USAGE[
        SCOPE["unknown"],
        AREA["USA - CONUS including EEZ"],
        BBOX[23.81,-129.17,49.38,-65.69]]]

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

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

Didier Richard
In reply to this post by Even Rouault-2
1. - Shame on me, it is working !

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);
    if (obj != NULL) {
        fprintf(stderr,"%s is of type %d\n", proj_get_name(obj), proj_get_type(obj));
        proj_destroy(obj);
    }

outputs :

(null) is of type 0

$ projinfo -o PROJ -s IGNF:NTFLAMB2E.NGF84 -t IGNF:ETRS89LCC.EVRF2000
Candidate operations found: 3
-------------------------------------
Operation n°1:

unknown id, Inverse of LAMBERT II ETENDU + Transformation from NGF-LALLEMAND to EVRF2000 (UELN-95/98)(EUROPEAN VERTICAL REFERENCE FRAME) (ballpark vertical transformation) + NTF geographiques Paris (gr) vers NTF GEOGRAPHIQUES GREENWICH (DMS) + NOUVELLE TRIANGULATION DE LA FRANCE (NTF) vers WGS 84 + Inverse of ETRS 89 vers WGS 84 + ETRS89 LAMBERT CONFORMAL CONIC, unknown accuracy, FRANCE METROPOLITAINE, has ballpark transformation

PROJ string:
+proj=pipeline +step +inv +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 +step +proj=push +v_3 +step +proj=cart +ellps=clrk80ign +step +proj=helmert +x=-168 +y=-60 +z=320 +step +inv +proj=cart +ellps=GRS80 +step +proj=pop +v_3 +step +proj=lcc +lat_0=52 +lon_0=10 +lat_1=35 +lat_2=65 +x_0=4000000 +y_0=2800000 +ellps=GRS80

-------------------------------------
Operation n°2:

unknown id, Inverse of LAMBERT II ETENDU + Transformation from NGF-LALLEMAND to EVRF2000 (UELN-95/98)(EUROPEAN VERTICAL REFERENCE FRAME) (ballpark vertical transformation) + NTF geographiques Paris (gr) vers NTF GEOGRAPHIQUES GREENWICH (DMS) + NOUVELLE TRIANGULATION DE LA FRANCE (NTF) vers WGS 84 + Inverse of ETRS 89 vers WGS 84 + ETRS89 LAMBERT CONFORMAL CONIC, unknown accuracy, FRANCE METROPOLITAINE, has ballpark transformation

PROJ string:
+proj=pipeline +step +inv +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 +step +proj=push +v_3 +step +proj=cart +ellps=clrk80ign +step +proj=helmert +x=-168 +y=-60 +z=320 +step +inv +proj=cart +ellps=WGS84 +step +proj=pop +v_3 +step +proj=lcc +lat_0=52 +lon_0=10 +lat_1=35 +lat_2=65 +x_0=4000000 +y_0=2800000 +ellps=GRS80

-------------------------------------
Operation n°3:

unknown id, Inverse of LAMBERT II ETENDU + Transformation from NGF-LALLEMAND to EVRF2000 (UELN-95/98)(EUROPEAN VERTICAL REFERENCE FRAME) (ballpark vertical transformation) + Inverse of Transformation from ETRS89 geographiques (dms) to NTF geographiques Paris (gr) altered to use prime meridian of ETRS89 geographiques (dms) + Ballpark geographic offset from NTF geographiques Paris (gr) altered to use prime meridian of ETRS89 geographiques (dms) to ETRS89 geographiques (dms) + ETRS89 LAMBERT CONFORMAL CONIC, unknown accuracy, World, has ballpark transformation

PROJ string:
+proj=pipeline +step +inv +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 +step +proj=lcc +lat_0=52 +lon_0=10 +lat_1=35 +lat_2=65 +x_0=4000000 +y_0=2800000 +ellps=GRS80


--
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 [[hidden email]]
Envoyé : mardi 30 avril 2019 16:19
À : Didier Richard
Cc : [hidden email]
Objet : Re: [PROJ] [PROJ 6.0.0] Different behaviors for creating a transformation of type EPSG:9616

On mardi 30 avril 2019 14:02:50 CEST Didier Richard wrote:
> 1.- Does not work either with
> "urn:ogc:def:coordinateOperation:IGNF::SG1250". I guess because of the
> authority ?

no just a typo. Missing T before SG1250

> 3.- Ok, I thought that operations located in other_transformation table were
> of type PJ_TYPE_OTHER_COORDINATE_OPERATION. Do you have an example of an
> operation for which the type is PJ_TYPE_OTHER_COORDINATE_OPERATION ? I
> found nothing in the test/ directory checking this.

For example, if you would do a transformation from a CompoundCRS to another
CompoundCRS (or a Geographic3D CRS) with both horizontal and vertical
transformations, there is nothing in ISO:19111 to model the composite of both.
So there's an internal PROJ C++ class, PROJBasedOperation, whose type would be
exposed as PJ_TYPE_OTHER_COORDINATE_OPERATION

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

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

Even Rouault-2
> 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
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: [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 [[hidden email]]
Envoyé : mardi 30 avril 2019 19:25
À : Didier Richard
Cc : [hidden email]
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
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

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

Even Rouault-2
On mardi 30 avril 2019 17:53:13 CEST Didier Richard wrote:
> 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) ?

To be honest, the new behaviour of having several candidate coordinate
operations is a late addition. Initially, it picked up only one, but that was
not ideal.
Another reason is that want proj_create_crs_to_crs() to remain the "easy" way
of using the PROJ API, so returning a PJ* object directly usable by
proj_trans() and friends, so it is not a bad thing that this complexity
remains hidden from the user point of view.

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

Basically proj_create_crs_to_crs() is a high level function over
proj_create_operations(). So if you need fine grained control of which
coordinate operation you want to use exactly, use proj_create_operations()

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj