On Wed, 30 Oct 2019 at 06:16, Even Rouault wrote:
>
> > I realise this too, but to permit legacy results to be replicated,
>
> Some legacy behaviour was just plain wrong/inaccurate. Trying to replicate it
> in PROJ would be heartbreaking, an extra maintaince burden, and a confusion
> for PROJ user
I think it should check the "type" value. My "maybe this could work" concept
was something like:
--- a/gdal/frmts/nitf/nitffile.c
+++ b/gdal/frmts/nitf/nitffile.c
@@ -2150,6 +2150,8 @@ static char** NITFGenericMetadataReadTREInternal(char
**papszMD,
const char* pszName = CPLGetX
Further, manual tests suggest that it is in GDAL 2.4.3 -- 20 threads
performing transformations on the same OGRCoordinateTransformation instance
and ensuring that the result is within 1e-4 of the correct result.
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
Hello All!
I know that this question has been asked before, but not recently, and I
haven't found a satisfactory explanation.
Is OGRCoordinateTransformation threadsafe such that multiple threads can
call Transform on the same instance in parallel?
If not, why not? If so, where is this documented
Looking at the code, it appears that GDAL actually hard codes any TRE that
takes anything that cannot be parsed as a string (e.g. nitfimage.c
NITFReadICHIPB). So, for BANDSB with its EXISTENCE_MASK and SCALE_FACTOR would
need to be hard coded as opposed to being defined just within the
nitf_spe
