[PROJ] Forcing Specific Transformation

[Peter Townsend]

Great, thanks for looking into it. I kinda had a feeling it was related to
it being outside of the traditional zone 31 box. I tried a few neighboring
zones to see if (42) might pop up, and looks like it does for 29
(EPSG:23029). Coincidentally where Portugal is!

I brought up the epsg.io listing because I was watching a screenshare with
a user, and they were using it as their reference. In an effort to be
accommodating and foresightful, I'm trying to pick up on any edge cases
that might pop up as a result of anyone using that site as their EPSG
reference instead of epsg.org. Even if it isn't up to date or entirely
correct.

On Mon, Jul 19, 2021 at 9:42 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> 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 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.
>
>

-- 
Peter Townsend
Senior Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210719/cb5dc869/attachment-0001.html>