<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 10:51 PM, Kristian Evers <span dir="ltr"><<a href="mailto:kreve@sdfe.dk" target="_blank">kreve@sdfe.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;line-break:after-white-space">
<br>
<div><span class=""><br>
<blockquote type="cite">
<div>On 26 Mar 2018, at 21:21, Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a><wbr>> wrote:</div>
<br class="m_4271063419176491402Apple-interchange-newline">
<div>
<div dir="ltr">
<div>
<div>
<div>There is an important difference between the PROJ4 and the PROJ5+ API/syntax:<br>
<br>
The old PROJ4 API uses latlong WGS84 as pivot datum for coordinate transformations like<br>
<br>
</div>
projection1 -> latlong WGS84 -> projection2<br>
</div>
<div>or in '+to' syntax<br>
projection1 +to projection2<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>The new PROJ5+ API no longer uses a pivot datum. The advantage is that you can directly convert from one datum to another, without going through WGS84. The disadvantage is that the user/software using the new API has to make sure that either a
 common pivot datum is used or coordinates are correctly transformed from one datum to another, e.g. with a Helmert Transform.<br>
<br>
</div>
Both GDAL and GRASS have implemented the new API as a simple 2-step pipeline like<br>
<div>
<div>
<div>
<div><br>
1. projection1 -> some latlong<br>
2. some latlong -> projection2<br>
</div>
<div><br>
or in pipeline syntax<br>
</div>
<div><br>
</div>
<div>+proj=pipeline<br>
</div>
<div>+step +inv projection1<br>
</div>
<div>+step projection2<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>
<div>This is actually exactly what the proj_crs_to_crs() function does. When I originally wrote it I had an idea that this should only be used with init-files,</div>
<div>but seeing how people need a simple way to do what they’ve always done I think it might be better to relax that requirement and allow input similar</div>
<div>to what goes into cs2cs and pj_transform().</div></div></div></div></blockquote><div><br></div><div>The challenge is that users of other software using the new PROJ API like GDAL and GRASS expect that reprojecting a dataset from one CRS to another CRS "just works".  Input and output CRS can be anything custom defined. Either PROJ or other software using PROJ must have some mechanism to decide if the requested reprojection can be done or not.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div>
<div><br>
</div>
<div>My plan for this function is that it eventually will be able to construct a transformation between CRS’s without the WGS84 pivot. This will be guided</div>
<div>by the EPSG database. I have still to work out exactly how. For now though, it works fine with already existing init files and WGS84 as a pivot datum.</div>
<div>My hope is that this will land in version 6 but I won’t promise that just yet.</div></div></div></div></blockquote><div><br></div><div>Looking forward to this function! But what if a dataset comes with a CRS definition without EPSG code? Can we expect that PROJ handles this or should applications using the PROJ API handle this?<br><br></div><div>Markus M<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div>
</div><span class="">
<div><br>
</div>
<br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>Even Rouault has done some tests and found sometimes subtle differences in the results between the old and new API/syntax. Further on, there is no mechanism (yet) in place to validate the pipeline, most importantly that the output of step 1 conforms
 to the required input for step 2.<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>
<div>I believe we have sorted those problems out in the coming version 5.0.1. </div>
<div><br>
</div>
<div>Regarding validation of input/output from pipeline steps. We can probably do some basic checks, but in the end you will always be required to know</div>
<div>what you are doing. Mind you, we are not expecting everyday users to construct their own pipelines all the time. It is a powertool for the accomplished</div>
<div>user that knows what he is doing. Most users should have their needs met by predefined transformations in init-files such as the epsg file. And eventually</div>
<div>in a more clever way using the EPSG database directly as mentioned above.<br>
</div>
<div><br>
</div>
</div>
<br>
<blockquote type="cite">
<div><div><div class="h5">
<div dir="ltr">
<div>
<div>
<div>
<div>IMHO, the implementation of the new PROJ5+ API/syntax in GDAL and GRASS should be regarded as experimental and testing by as many people as possible would be a huge benefit to PROJ/GDAL/GRASS and to all applications using these projects.<br>
<br>
</div>
<div>Markus M<br>
</div>
<div><br>
On Sun, Mar 25, 2018 at 10:47 PM, Helmut Kudrnovsky <<a href="mailto:hellik@web.de" target="_blank">hellik@web.de</a>> wrote:<br>
><br>
> >Now (last related commit is trunk r72522) it's finished. I have >introduced<br>
> a new GRASS API that handles both PROJ 4 and PROJ >5, consisting of<br>
><br>
> Thanks for this Update!<br>
><br>
> Fyi See<br>
> <a href="https://lists.osgeo.org/pipermail/osgeo4w-dev/2018-March/003557.html" target="_blank">
https://lists.osgeo.org/piperm<wbr>ail/osgeo4w-dev/2018-March/<wbr>003557.html</a><br>
><br>
> -------<br>
> [...]<br>
> The API from PROJ 4 lives on in PROJ 5, so GRASS 7.4 should be able to use<br>
> PROJ 5 as well. We’ve been carefull not to breaking anything with this<br>
> release.<br>
> That comes with PROJ 6 and 7. Of course there might be implementation<br>
> details<br>
> in GRASS that I am unaware of that makes using PROJ 5 impossible.<br>
> --------<br>
><br>
><br>
><br>
> -----<br>
> best regards<br>
> Helmut<br>
> --<br>
> Sent from: <a href="http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html" target="_blank">
http://osgeo-org.1560.x6.nabbl<wbr>e.com/Grass-Dev-f3991897.html</a><br>
> ______________________________<wbr>_________________<br>
> grass-dev mailing list<br>
> <a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">
https://lists.osgeo.org/mailma<wbr>n/listinfo/grass-dev</a><br>
<br>
</div>
</div>
</div>
</div>
</div></div></div>
______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a></div>
</blockquote>
</div>
<br>
</div>

</blockquote></div><br></div></div>