[PROJ] Forcing Specific Transformation

Even Rouault even.rouault at spatialys.com
Mon Jul 19 19:42:09 PDT 2021


Peter,

PROJ doesn't propose ED50 to WGS84 (42) aka EPSG:15964 for EPSG:23031 to 
EPSG:4326 since the area of use for EPSG:15964 is AREA["Portugal - 
mainland - offshore."], BBOX[34.91,-13.87,41.88,-7.24]] whereas the area 
of use of EPSG:23031 is AREA["Europe - between 0°E and 6°E - Andorra; 
Denmark (North Sea); Germany offshore; Netherlands offshore; Norway 
including Svalbard - onshore and offshore; Spain - onshore (mainland and 
Balearic Islands); United Kingdom (UKCS) offshore."], 
BBOX[38.56,0,82.45,6.01]] .

You can notice that the areas of use of the CRS and the transformation 
don't intersect, hence the transformation isn't proposed by default.

Normally the "--crs-extent-use none" is what you would need in that 
situation to specify that you don't want the official extent of the 
source and target CRS to be taken into account when filtering 
transformation results, but unfortunately it is broken in currently 
released versions. I've issued https://github.com/OSGeo/PROJ/pull/2782 
to fix that.

A workaround is to use a modified WKT for EPSG:23031 with the BBOX of 
interest (or at least intersecting the area of use of the transformation 
you're interested in), like

PROJCRS["ED50 / UTM zone 31N",
     BASEGEOGCRS["ED50",
         DATUM["European Datum 1950",
             ELLIPSOID["International 1924",6378388,297,
                 LENGTHUNIT["metre",1]]],
         PRIMEM["Greenwich",0,
             ANGLEUNIT["degree",0.0174532925199433]],
         ID["EPSG",4230]],
     CONVERSION["UTM zone 31N",
         METHOD["Transverse Mercator",
             ID["EPSG",9807]],
         PARAMETER["Latitude of natural origin",0,
             ANGLEUNIT["degree",0.0174532925199433],
             ID["EPSG",8801]],
         PARAMETER["Longitude of natural origin",3,
             ANGLEUNIT["degree",0.0174532925199433],
             ID["EPSG",8802]],
         PARAMETER["Scale factor at natural origin",0.9996,
             SCALEUNIT["unity",1],
             ID["EPSG",8805]],
         PARAMETER["False easting",500000,
             LENGTHUNIT["metre",1],
             ID["EPSG",8806]],
         PARAMETER["False northing",0,
             LENGTHUNIT["metre",1],
             ID["EPSG",8807]]],
     CS[Cartesian,2],
         AXIS["(E)",east,
             ORDER[1],
             LENGTHUNIT["metre",1]],
         AXIS["(N)",north,
             ORDER[2],
             LENGTHUNIT["metre",1]],
     USAGE[
         SCOPE["unknown"],
         BBOX[34.91,-13.87,41.88,-7.24]]]

>
>
> I did try proj_crs_create_bound_crs with 23031/4326/15964 as the 
> base/hub/transform accordingly and it did succeed in this case, but 
> I'm not sure if this is the best solution in general. I got back the 
> PROJ.4 definition on the epsg.io <http://epsg.io> page: "+proj=utm 
> +zone=31 +ellps=intl +towgs84=-86.277,-108.879,-120.181,0,0,0,0 
> +units=m +no_defs +type=crs".
>
> Is there some way to force this transform through the operation 
> context methods/pipelines?
>
If you remove the "+type=crs" in the above PROJ.4 CRS string, you can 
use the resulting string as a valid input for a pipeline with 
proj_create() + proj_trans(). But be aware that in that situation, input 
coordinates will be in radian, and in longitude/latitude order.

Even

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210720/0e340199/attachment.html>


More information about the PROJ mailing list