[PROJ] Some (probably dumb) questions about cs2cs and projinfo

[Even Rouault]

Le 24/02/2026 à 17:55, Greg Troxel via PROJ a écrit :
> Andrea Giudiceandrea via PROJ <proj at lists.osgeo.org> writes:
>
>> Anyway, my concerns and doubts were firstly related to just
>> understanding the reason why (although they all use the same PROJ and
>> proj.db), cs2cs (and PostGIS and SpatiaLite) uses a particular
>> (better) transformation, whereas QGIS another (worst) one, regardless
>> of the fact that any of such transformations could be considered the
>> right one.
>>
>> For that transformation, however, all the 5 available Helmert
>> operations, the first one of which is used by cs2cs (and PostGIS and
>> SpatiaLite), are much better than the ballpark operation used by QGIS
>> (which can only choose between the grid shift operation and the
>> ballpark one), since the ballpark is more than 100 metres off.
> This seems like a good question to me.  I would (without any real
> undertanding) expect qgis to offer the same set of pipelines with same
> preference.
>
> I've long had a concern that the EPSG database entries may not be
> entirely right, and that when people talk about errors, etc., it's
> always unclear if they mean the stated error in the EPSG entry, the best
> believed error in the literature, or the actual error, compared to
> something that is (validly!) believed to be better.  I really don't know
> what's up here, but I suspect looking at it all carefully might turn up
> some surprises.   If it doesn't, that's great, but it feels like news.

The database might have errors (anything bigger than one byte has a 
potential for bugs), but I believe most of the practical issues are more 
in the overall consistency, the lack of some recorded transformations, 
and the ambiguities when there are several potential paths. PROJ also 
likely does suboptimal computation of accuracy from individual 
accuracies (but records in the EPSG database don't share the same 
definition of accuracies, depending on how each producer computes it, so 
hard to do much better than the simple addition we d).

I use to say that PROJ CRS to CRS logic is basically a routine engine in 
a graph, with some bits of geodesy to decide if all edges of the graph 
are valid, and the cost they have, and heuristics to cut the 
computations when easy to compute paths have been found. Sometimes your 
GPS makes you try unpredictable roads that are thought to be the best 
ones but are just muddy. PROJ is similar :-)

QGIS could very much change its logic in qgscoordinatetransform_p.cpp 
and qgsdatumtransform.cpp from

     // We want to check ALL grids, not just those available for use
     proj_operation_factory_context_set_grid_availability_use( context, 
operationContext, PROJ_GRID_AVAILABILITY_IGNORED );

to doing it once with that parameter and another one 
with  PROJ_GRID_AVAILABILITY_DISCARD_OPERATION_IF_MISSING_GRID (what is 
used in cs2cs) and merge the results to replicate what cs2cs does, while 
still offering the possibility to users to download known locally 
missing grids (what its PROJ_GRID_AVAILABILITY_IGNORED does). The user 
might get overwhelmed by non relevant paths however.

-- 
http://www.spatialys.com
My software is free, but my time generally not.