<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Peter,</p>
<p>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]] .</p>
<p>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.<br>
</p>
<p>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
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ/pull/2782">https://github.com/OSGeo/PROJ/pull/2782</a> to fix that.</p>
<p>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<br>
</p>
<p>PROJCRS["ED50 / UTM zone 31N",<br>
BASEGEOGCRS["ED50",<br>
DATUM["European Datum 1950",<br>
ELLIPSOID["International 1924",6378388,297,<br>
LENGTHUNIT["metre",1]]],<br>
PRIMEM["Greenwich",0,<br>
ANGLEUNIT["degree",0.0174532925199433]],<br>
ID["EPSG",4230]],<br>
CONVERSION["UTM zone 31N",<br>
METHOD["Transverse Mercator",<br>
ID["EPSG",9807]],<br>
PARAMETER["Latitude of natural origin",0,<br>
ANGLEUNIT["degree",0.0174532925199433],<br>
ID["EPSG",8801]],<br>
PARAMETER["Longitude of natural origin",3,<br>
ANGLEUNIT["degree",0.0174532925199433],<br>
ID["EPSG",8802]],<br>
PARAMETER["Scale factor at natural origin",0.9996,<br>
SCALEUNIT["unity",1],<br>
ID["EPSG",8805]],<br>
PARAMETER["False easting",500000,<br>
LENGTHUNIT["metre",1],<br>
ID["EPSG",8806]],<br>
PARAMETER["False northing",0,<br>
LENGTHUNIT["metre",1],<br>
ID["EPSG",8807]]],<br>
CS[Cartesian,2],<br>
AXIS["(E)",east,<br>
ORDER[1],<br>
LENGTHUNIT["metre",1]],<br>
AXIS["(N)",north,<br>
ORDER[2],<br>
LENGTHUNIT["metre",1]],<br>
USAGE[<br>
SCOPE["unknown"],<br>
BBOX[34.91,-13.87,41.88,-7.24]]]</p>
<blockquote type="cite"
cite="mid:CAMQBGmVuBLkgM1fERdgNY3trcBdOPfe+G+hmRdtxY5cBHDaJXQ@mail.gmail.com">
<div dir="ltr">
<div>
<div><br>
<div><br>
</div>
<div>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 <a href="http://epsg.io"
moz-do-not-send="true">epsg.io</a> page: "+proj=utm
+zone=31 +ellps=intl
+towgs84=-86.277,-108.879,-120.181,0,0,0,0 +units=m
+no_defs +type=crs".</div>
<div><br class="gmail-Apple-interchange-newline">
Is there some way to force this transform through the
operation context methods/pipelines?<br>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>Even<br>
</p>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>