<div dir="ltr"><div><br><br>On Tue, Apr 3, 2018 at 1:57 PM, Kristian Evers &lt;<a href="mailto:kreve@sdfe.dk">kreve@sdfe.dk</a>&gt; wrote:<br>&gt;<br>&gt; Markus,<br>&gt;<br>&gt;  <br>&gt;<br>&gt; Sorry for the late reply – you mail got caught by the corporate spam filter.<br>&gt;<br>&gt;  <br>&gt;<br>&gt; &gt; 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 &quot;just works&quot;.  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>&gt;<br>&gt;  <br>&gt;<br>&gt; And with my proposal to change proj_create_crs_to_crs() to allow input other than strings on the form “+init=file:key” you will get exactly what you have always had with the old API. You can definitely argue that this has never “just worked”, since using the WGS84 hub datum is rarely doing the correct thing, but for most users it is good enough.<br><br></div>For most datasets, WGS84 as pivot datum should be good enough, considering the limited spatial accuracy of many real-world datasets.<br><div><br>&gt; This will not be the case forever though. It is my hope that eventually we will have a system the really “just works”, even for users requiring high accuracy, but for now we only have the basic scaffolding that eventually will make this possible. Patience will be required :-)<br><br></div><div>FWIW, I added support for user-defined pipelines in GRASS in r.proj (r72598) and v.proj (r72599) with a new pipeline option.<br></div><div><br></div><div>Markus M<br><br>&gt;<br>&gt; &gt; 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>&gt;<br>&gt; Without having thought this through all the way to the end yet, I think this situation will be possible to handle. The idea being that if you specify an EPSG CRS on one side and a string like “+proj=merc” or whatever, we could default to a transformation with hub datum like we do today. Either by going from EPSG:xxxx to WGS84 (or something else that makes sense in the situation) and then transform from the hub datum to the custom CRS. It will be a best guess as to how to that transformation but better than nothing, and probably correct in most cases.<br>&gt;<br>&gt; I might have overlooked something, so no promises on the final implementation yet!<br>&gt;<br>&gt;  <br>&gt;<br>&gt; /Kristian<br>&gt;<br>&gt;  <br>&gt;<br>&gt; Fra: Markus Metz [mailto:<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>]<br>&gt; Sendt: 27. marts 2018 21:50<br>&gt; Til: Kristian Evers &lt;<a href="mailto:kreve@sdfe.dk">kreve@sdfe.dk</a>&gt;<br>&gt; Cc: GRASS developers list &lt;<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a>&gt;; gdal-dev &lt;<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>&gt;<br>&gt; Emne: Re: [gdal-dev] [GRASS-dev] PROJ 5 support in trunk<br>&gt;<br>&gt;  <br>&gt;<br>&gt;  <br>&gt;<br>&gt;  <br>&gt;<br>&gt; On Mon, Mar 26, 2018 at 10:51 PM, Kristian Evers &lt;<a href="mailto:kreve@sdfe.dk">kreve@sdfe.dk</a>&gt; wrote:<br>&gt;<br>&gt;  <br>&gt;<br>&gt;<br>&gt;<br>&gt; On 26 Mar 2018, at 21:21, Markus Metz &lt;<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>&gt; wrote:<br>&gt;<br>&gt;  <br>&gt;<br>&gt; There is an important difference between the PROJ4 and the PROJ5+ API/syntax:<br>&gt;<br>&gt; The old PROJ4 API uses latlong WGS84 as pivot datum for coordinate transformations like<br>&gt;<br>&gt; projection1 -&gt; latlong WGS84 -&gt; projection2<br>&gt;<br>&gt; or in &#39;+to&#39; syntax<br>&gt; projection1 +to projection2<br>&gt;<br>&gt;  <br>&gt;<br>&gt; 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>&gt;<br>&gt; Both GDAL and GRASS have implemented the new API as a simple 2-step pipeline like<br>&gt;<br>&gt;<br>&gt; 1. projection1 -&gt; some latlong<br>&gt; 2. some latlong -&gt; projection2<br>&gt;<br>&gt;<br>&gt; or in pipeline syntax<br>&gt;<br>&gt;  <br>&gt;<br>&gt; +proj=pipeline<br>&gt;<br>&gt; +step +inv projection1<br>&gt;<br>&gt; +step projection2<br>&gt;<br>&gt;  <br>&gt;<br>&gt;  <br>&gt;<br>&gt; 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,<br>&gt;<br>&gt; 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<br>&gt;<br>&gt; to what goes into cs2cs and pj_transform().<br>&gt;<br>&gt;  <br>&gt;<br>&gt; 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 &quot;just works&quot;.  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>&gt;<br>&gt;  <br>&gt;<br>&gt; 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<br>&gt;<br>&gt; 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.<br>&gt;<br>&gt; My hope is that this will land in version 6 but I won’t promise that just yet.<br>&gt;<br>&gt;  <br>&gt;<br>&gt; 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>&gt;<br>&gt; Markus M<br>&gt;<br>&gt;  <br>&gt;<br>&gt;<br>&gt;<br>&gt; 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>&gt;<br>&gt;  <br>&gt;<br>&gt; I believe we have sorted those problems out in the coming version 5.0.1. <br>&gt;<br>&gt;  <br>&gt;<br>&gt; 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<br>&gt;<br>&gt; 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<br>&gt;<br>&gt; 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<br>&gt;<br>&gt; in a more clever way using the EPSG database directly as mentioned above.<br>&gt;<br>&gt;  <br>&gt;<br>&gt;<br>&gt;<br>&gt; 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>&gt;<br>&gt; Markus M<br>&gt;<br>&gt;<br>&gt; On Sun, Mar 25, 2018 at 10:47 PM, Helmut Kudrnovsky &lt;<a href="mailto:hellik@web.de">hellik@web.de</a>&gt; wrote:<br>&gt; &gt;<br>&gt; &gt; &gt;Now (last related commit is trunk r72522) it&#39;s finished. I have &gt;introduced<br>&gt; &gt; a new GRASS API that handles both PROJ 4 and PROJ &gt;5, consisting of<br>&gt; &gt;<br>&gt; &gt; Thanks for this Update!<br>&gt; &gt;<br>&gt; &gt; Fyi See<br>&gt; &gt; <a href="https://lists.osgeo.org/pipermail/osgeo4w-dev/2018-March/003557.html">https://lists.osgeo.org/pipermail/osgeo4w-dev/2018-March/003557.html</a><br>&gt; &gt;<br>&gt; &gt; -------<br>&gt; &gt; [...]<br>&gt; &gt; The API from PROJ 4 lives on in PROJ 5, so GRASS 7.4 should be able to use<br>&gt; &gt; PROJ 5 as well. We’ve been carefull not to breaking anything with this<br>&gt; &gt; release.<br>&gt; &gt; That comes with PROJ 6 and 7. Of course there might be implementation<br>&gt; &gt; details<br>&gt; &gt; in GRASS that I am unaware of that makes using PROJ 5 impossible.<br>&gt; &gt; --------<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; -----<br>&gt; &gt; best regards<br>&gt; &gt; Helmut<br>&gt; &gt; --<br>&gt; &gt; Sent from: <a href="http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html">http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html</a><br>&gt; &gt; _______________________________________________<br>&gt; &gt; grass-dev mailing list<br>&gt; &gt; <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>&gt; &gt; <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev">https://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>&gt;<br>&gt; _______________________________________________<br>&gt; gdal-dev mailing list<br>&gt; <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>&gt; <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>&gt;<br>&gt;  <br>&gt;<br>&gt;  <br><br></div></div>