<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Thank you Thomas!</p>
    <p> its true that PROJ_LIB has not been found on Windows and thats
      why my tests failed... a warning or something like that would be
      useful, because it kind of fails silently.. Also I didn't even
      know about this file and about its functionality of setting a
      certain "global default". I agree that it doesn't really make
      things easier to understand in the beginning...</p>
    <p>Thank you again for your help!<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 28/02/18 12:00, Thomas Knudsen
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH0YoEOFWk2OCiU3yzr8=mkHqvscH4dSUxFTPieV_U8t-4kJGQ@mail.gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div dir="ltr">
        <div>
          <div>
            <div>proj=utm zone=33 does not assume input data are in a
              WGS84 *reference frame* (datum).<br>
              <br>
              But it picks up  the *WGS84 ellipsoid* as default from the
              proj_def.dat file,<br>
              if your PROJ_LIB environment variable points to the
              directory where it resides.<br>
              The error message you get could mean that this is not the
              case.<br>
              <br>
              It has been proposed (and I happen to agree) that the
              proj_def.dat file creates<br>
            </div>
            more problems than it solves. This is evidently one of them.<br>
            <br>
          </div>
          <div>Also note that the proj=longlat steps in your pipelines
            are essentially no-ops.<br>
            So the entire roundtrip thing can be done using just one cct
            call:<br>
            <br>
            cct +proj=pipeline +step +proj=utm +zone=33 +ellps=GRS80
            +step  +inv +proj=utm +zone=33 +ellps=GRS80<br>
            <br>
            Which, due to the feature of "pipeline global settings" can
            even be abbreviated to:<br>
            <br>
            cct +proj=pipeline +proj=utm +zone=33 +ellps=GRS80 +step
            +step +inv</div>
          <br>
        </div>
        /Thomas<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">2018-02-28 11:33 GMT+01:00 Matthias
          Gabriel <span dir="ltr"><<a
              href="mailto:matthias.gabriel@etit.tu-chemnitz.de"
              target="_blank" moz-do-not-send="true">matthias.gabriel@etit.tu-chemnitz.de</a>></span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div>Hi Kristian,<br>
              <br>
              thank you for your answer..<br>
              <br>
              I run your command on my Windows Installation and
              unfortunately it produces:<span class=""><br>
                <br>
                echo 12 50 306 0 | cct.exe +proj=pipeline +step +inv
                +proj=lonlat +datum=WGS84 +ellps=WGS84 +step +proj=utm
                +zone=33 | cct.exe +proj=pipeline +step +inv +proj=utm
                +zone=33 +step +proj=lonlat +datum=WGS84 +ellps=WGS84<br>
              </span>
              cct.exe: Bad transformation arguments - (major axis or
              radius = 0 or not given)<br>
                  'cct.exe -h' for help<br>
              <br>
              The error stems from the second pipeline. If I remove it I
              get the proper UTM coordinates, but the second part fails:<br>
              <br>
              echo 285015.7633 5542944.0186 306.0000 0.0000 | cct.exe
              +proj=pipeline +step +inv +proj=utm +zone=33 +step
              +proj=latlong +datum=WGS84<br>
              cct.exe: Bad transformation arguments - (major axis or
              radius = 0 or not given)<br>
                  'cct.exe -h' for help<br>
              <br>
              About the +datum modifier: I don't really understand, what
              are cs2cs modifiers and what not... Why is it implied that
              +proj=utm +zone=33 would assume "WGS84" long-lat
              coordinates as input? According to an earlier email I
              thought to have read that the assumption to be able to use
              WGS84 as an universal reference in proj4 is flawed and
              that this is the motivation for new API?!<br>
              <br>
              Thank you for your help, Regards,<br>
              Matthias<br>
              <br>
              <div class="gmail_quote">
                <div>
                  <div class="h5">On 28 February 2018 09:58:15 CET,
                    Kristian Evers <<a href="mailto:kreve@sdfe.dk"
                      target="_blank" moz-do-not-send="true">kreve@sdfe.dk</a>>
                    wrote:</div>
                </div>
                <blockquote class="gmail_quote" style="margin:0pt 0pt
                  0pt 0.8ex;border-left:1px solid
                  rgb(204,204,204);padding-left:1ex">
                  <pre class="m_-1914503853419179590k9mail"><div><div class="h5">Hi Matthias,

I just tried reproducing your problem:

echo 12 50 306 0 | cct.exe +proj=pipeline +step +inv +proj=lonlat +datum=WGS84 +ellps=WGS84 +step +proj=utm +zone=33 | cct.exe +proj=pipeline +step +inv +proj=utm +zone=33 +step +proj=lonlat +datum=WGS84 +ellps=WGS84
 12.0000000005   49.9999999996      306.0000        0.0000

Without any luck. This is on Windows, so I am not sure what is causing your problem. 

Really though, what you are trying to do is not really recommended. Instead of writing a long explanation, I'll just link to what
Thomas wrote the other day about using cs2cs modifiers such as +datum in pipelines:

        <a href="http://lists.maptools.org/pipermail/proj/2018-February/008055.html" target="_blank" moz-do-not-send="true">http://lists.maptools.org/<wbr>pipermail/proj/2018-February/<wbr>008055.html</a>

TL;DR: Don't do that, unless invoked from a init-file.

In your specific case there's a much simpler solution:

        +proj=utm +zone=33

The reason being that "+proj=lonlat +datum=WGS84 +ellps=WGS84" in the context of pipelines is just a no operation that
passes through whatever comes in unchanged.  See for yourself:

        λ echo 12 55 0 0|cct.exe +proj=lonlat +datum=WGS84 +ellps=WGS84
         12.0000000000   55.0000000000        0.0000        0.0000

Hope that clears things up a bit.

/Kristian

PS. You don't need +ellps=WGS84 when setting +datum=WGS84 

-----Oprindelig meddelelse-----
Fra: <a href="mailto:proj-bounces@lists.maptools.org" target="_blank" moz-do-not-send="true">proj-bounces@lists.maptools.<wbr>org</a> [mailto:<a href="mailto:proj-bounces@lists.maptools.org" target="_blank" moz-do-not-send="true">proj-bounces@lists.<wbr>maptools.org</a>] På vegne af Matthias Gabriel
Sendt: 28. februar 2018 09:13
Til: <a href="mailto:proj@lists.maptools.org" target="_blank" moz-do-not-send="true">proj@lists.maptools.org</a>
Emne: Re: [Proj] PROJ 5.0.0RC6

Hi,

I still have a problem using proj4 RC6 on Windows... I try to calculate 
the "round-trip" from WGS84 ->  UTM -> WGS84 using the following two 
pipelines in a unit-test:

+proj=pipeline +step +inv
+proj=lonlat +datum=WGS84 +ellps=WGS84
+step
+proj=utm +zone=33

and its inverse:

+proj=pipeline +step +inv
+proj=utm +zone=33
+step
+proj=lonlat +datum=WGS84 +ellps=WGS84

My test-values are 12.0° 50.0° 306m - of course they are converted into 
radians before. I apply the first projection, get an intermediate (UTM) 
result and then immediately apply the second pipeline and get again 
lonlat in WGS84. Then I compare both WGS84.

On Linux x64 and aarch64 that unit-test succeeds and the result of 
applying both pipelines is again 12° and 50°. On Windows VS 15 2017 
amd64 its not the case. It seems that the second a application of the 
pipeline has no effect, the PJ_COORD still contains the UTM coordinates. 
Not even an error is raised (proj_errno equals 0 for the projection ptr) 
and of course my unittest fails.

I'm not an expert on projections but as this test succeeds on linux I 
find it rather strange...

Regards,
Matthias



On 27/02/18 16:49, Bas Couwenberg wrote:
</div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #729fcf;padding-left:1ex"><div><div class="h5"> On 2018-02-27 15:11, Greg Troxel wrote:
<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"> Kristian Evers <<a href="mailto:kreve@sdfe.dk" target="_blank" moz-do-not-send="true">kreve@sdfe.dk</a>> writes:

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #8ae234;padding-left:1ex"> Thanks for you feedback, Greg. It is very appreciated.

 I think Bas has commented on most issues already so I'll skip that. I
 have updated
 the NEWS and README files to take your comments into account:

 <a href="https://github.com/OSGeo/proj.4/pull/828" target="_blank" moz-do-not-send="true">https://github.com/OSGeo/proj.<wbr>4/pull/828</a>

 Let me know if I've missed something or described things in an unclear
 way.
</blockquote> Thanks - that almost entirely addresses things.


 A further comment, and I don't mean to suggest that the release be held
 up:

 The text talks about how the regional ones are not essential but could
 be useful.  That seems fair.  But, as a user, how do I find out what is
 in them, or what I need, other than by downloading them and inspecting
 them?
</blockquote> Use the source, Luke. :-)

    <a href="https://github.com/OSGeo/proj-datumgrid" target="_blank" moz-do-not-send="true">https://github.com/OSGeo/proj-<wbr>datumgrid</a>

 Specific subdirectories for the regional packages:

    <a href="https://github.com/OSGeo/proj-datumgrid/tree/master/europe" target="_blank" moz-do-not-send="true">https://github.com/OSGeo/proj-<wbr>datumgrid/tree/master/europe</a>
    <a href="https://github.com/OSGeo/proj-datumgrid/tree/master/north-america" target="_blank" moz-do-not-send="true">https://github.com/OSGeo/proj-<wbr>datumgrid/tree/master/north-<wbr>america</a>
    <a href="https://github.com/OSGeo/proj-datumgrid/tree/master/oceania" target="_blank" moz-do-not-send="true">https://github.com/OSGeo/proj-<wbr>datumgrid/tree/master/oceania</a>

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"> As a packager, what should I do?  For now, I will include the main file
 in the package, following tradition, and not worry about the new ones.
 I am guessing that this means the grids for the important datums are
 still in the main file, even if they are a North American Datum, and
 the
 north-america file contains only more obscure datums that were not
 previously available.  I originally had the impression that all North
 American grids were demoted from the main file to the regional file.
</blockquote> proj-datumgrid-north-america includes grids for Greenland.

 The "old" NAD grids for North America are still included in the core
 proj-datumgrid package as they have been since pretty much forever.

 The filename and content of the proj-datumgrid was explicitly kept the
 same to not require any changes from packagers other than the version
 number.

 That is also why the .zip format was kept, and in addition a .tar.gz is
 available as well.

<blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #ad7fa8;padding-left:1ex"> I updated my draft 5.0.0 package to use proj-datumgrids-1.7RC2, and I
 see that this added two files compared to 1.5 (which I should have
 updated but didn't), and did not withdraw any.

 So I have convinced myself that using the main file for the package,
 and
 deferring thinking about the new files is a good approach.


 So it might help to add

    All grids that were in proj-datumgrids-1.6 remain in
    proj-datumgrids-1.7; the regional datumgrid files contain grids for
    datums not previously supported.
</blockquote> Where do you suggest to add this?

 Kind Regards,

 Bas
<hr>
</div></div><span class=""> Proj mailing list
 <a href="mailto:Proj@lists.maptools.org" target="_blank" moz-do-not-send="true">Proj@lists.maptools.org</a>
 <a href="http://lists.maptools.org/mailman/listinfo/proj" target="_blank" moz-do-not-send="true">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a>
</span></blockquote></pre>
                </blockquote>
              </div>
            </div>
            <br>
            ______________________________<wbr>_________________<br>
            Proj mailing list<br>
            <a href="mailto:Proj@lists.maptools.org"
              moz-do-not-send="true">Proj@lists.maptools.org</a><br>
            <a href="http://lists.maptools.org/mailman/listinfo/proj"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a><br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Proj mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a>
<a class="moz-txt-link-freetext" href="http://lists.maptools.org/mailman/listinfo/proj">http://lists.maptools.org/mailman/listinfo/proj</a></pre>
    </blockquote>
  </body>
</html>