[PROJ] [PROJ 6.0.0] proj_create_operation_factory_context behavior

[Even Rouault]

Hi Didier,

> 1.- Despite the fact that the two CRS (Réunion island and French Antilles)
> have disjoint areas an operation is created. The documentation expressed
> that default behavior for areas is "Strict containment", I, then, expected
> to have 0 operations in the end ...

Ah, I was hoping nobody would seriously try to check how all those criteria
exactly work :-) The logic is convoluted, somewhat arbitrary and has been
modified many times to try to "make things work". That is to say: return meaningful results
when possible, make sure existing regressions tests we had still pass,
and no being too pedantic (many people want to be able to do by default
meaningless transformations such as the one you exhibit, hence this concept of
ballpark transformation when we lack information to do datum shifts, etc).

The proj_operation_factory_context_set_spatial_criterion() defines how to compare
the area of use of a candidate coordinate operation with a representative area
of use of the source and target CRS. How that "representive area of use" is computed
is controlled by proj_operation_factory_context_set_crs_extent_use().
This one defaults to PJ_CRS_EXTENT_SMALLEST
That is, given the source CRS and target CRS, we only consider the extent of the
smallest one of those two, when we check the compatibility of coordinate operations
with the CRS area of use. In your case, this will be Réunion. The ballpark transformation
has worldwide coverage, so la Réunion is strictly contained in it,
hence the result you get.

If for example you set set_crs_extent_use() to PJ_CRS_EXTENT_INTERSECTION,
combined with the fix I just pushed per
https://github.com/OSGeo/proj.4/commit/b4a9e65cec051ca3cb16b8cccfa012d70ce10570 ,
then you'll get an empty set.

$ src/projinfo -s IGNF:REUN47GAUSSL -t IGNF:RGAF09UTM20 --crs-extent-use intersection
Candidate operations found: 0

That said PJ_CRS_EXTENT_INTERSECTION is not always the best answer.
For non-ballpark transformations, PJ_CRS_EXTENT_BOTH would be the most pedantic option
because it will return only coordinate operations whose area of use contains at least the
area of use of the source tand target CRS.

The reason for PJ_CRS_EXTENT_SMALLEST being the default is when doing transformation
from a ProjectedCRS with nation extent to WGS84 typically. In the database you'll get
possibly Helmert-based/grid-based transformation for that, whose area of use is the area
of use of the ProjectedCRS. So PJ_CRS_EXTENT_BOTH cannot be used there (because the
transformation is not valid for the whole world.

> 
> 2.- On the latter point, when acc equals 0.0, the candidate operation is
> pipeline containing a Ballpark transformation,
> proj_coordoperation_has_ballpark_transformation() still returns false ...

Good catch. Was indeed a bug. Just fixed per
https://github.com/OSGeo/proj.4/commit/cca27b1fae234a90df42ff5341121759846dc39b

$ src/projinfo -s IGNF:REUN47GAUSSL -t IGNF:RGAF09UTM20 --summary
Candidate operations found: 1
unknown id, [...], unknown accuracy, World, ---> has ballpark transformation <----

Even

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