<html><head></head><body>Hi Kristian,<br>
<br>
thank you for your answer..<br>
<br>
I run your command on my Windows Installation and unfortunately it produces:<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>
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">On 28 February 2018 09:58:15 CET, Kristian Evers <kreve@sdfe.dk> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi Matthias,<br><br>I just tried reproducing your problem:<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> 12.0000000005 49.9999999996 306.0000 0.0000<br><br>Without any luck. This is on Windows, so I am not sure what is causing your problem. <br><br>Really though, what you are trying to do is not really recommended. Instead of writing a long explanation, I'll just link to what<br>Thomas wrote the other day about using cs2cs modifiers such as +datum in pipelines:<br><br> http://lists.maptools.org/pipermail/proj/2018-February/008055.html<br><br>TL;DR: Don't do that, unless invoked from a init-file.<br><br>In your specific case there's a much simpler solution:<br><br> +proj=utm +zone=33<br><br>The reason being that "+proj=lonlat +datum=WGS84 +ellps=WGS84" in the context of pipelines is just a no operation that<br>passes through whatever comes in unchanged. See for yourself:<br><br> λ echo 12 55 0 0|cct.exe +proj=lonlat +datum=WGS84 +ellps=WGS84<br> 12.0000000000 55.0000000000 0.0000 0.0000<br><br>Hope that clears things up a bit.<br><br>/Kristian<br><br>PS. You don't need +ellps=WGS84 when setting +datum=WGS84 <br><br>-----Oprindelig meddelelse-----<br>Fra: proj-bounces@lists.maptools.org [mailto:proj-bounces@lists.maptools.org] På vegne af Matthias Gabriel<br>Sendt: 28. februar 2018 09:13<br>Til: proj@lists.maptools.org<br>Emne: Re: [Proj] PROJ 5.0.0RC6<br><br>Hi,<br><br>I still have a problem using proj4 RC6 on Windows... I try to calculate <br>the "round-trip" from WGS84 -> UTM -> WGS84 using the following two <br>pipelines in a unit-test:<br><br>+proj=pipeline +step +inv<br>+proj=lonlat +datum=WGS84 +ellps=WGS84<br>+step<br>+proj=utm +zone=33<br><br>and its inverse:<br><br>+proj=pipeline +step +inv<br>+proj=utm +zone=33<br>+step<br>+proj=lonlat +datum=WGS84 +ellps=WGS84<br><br>My test-values are 12.0° 50.0° 306m - of course they are converted into <br>radians before. I apply the first projection, get an intermediate (UTM) <br>result and then immediately apply the second pipeline and get again <br>lonlat in WGS84. Then I compare both WGS84.<br><br>On Linux x64 and aarch64 that unit-test succeeds and the result of <br>applying both pipelines is again 12° and 50°. On Windows VS 15 2017 <br>amd64 its not the case. It seems that the second a application of the <br>pipeline has no effect, the PJ_COORD still contains the UTM coordinates. <br>Not even an error is raised (proj_errno equals 0 for the projection ptr) <br>and of course my unittest fails.<br><br>I'm not an expert on projections but as this test succeeds on linux I <br>find it rather strange...<br><br>Regards,<br>Matthias<br><br><br><br>On 27/02/18 16:49, Bas Couwenberg wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> On 2018-02-27 15:11, Greg Troxel wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Kristian Evers <kreve@sdfe.dk> writes:<br><br><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.<br><br> I think Bas has commented on most issues already so I'll skip that. I<br> have updated<br> the NEWS and README files to take your comments into account:<br><br> <a href="https://github.com/OSGeo/proj.4/pull/828">https://github.com/OSGeo/proj.4/pull/828</a><br><br> Let me know if I've missed something or described things in an unclear<br> way.<br></blockquote> Thanks - that almost entirely addresses things.<br><br><br> A further comment, and I don't mean to suggest that the release be held<br> up:<br><br> The text talks about how the regional ones are not essential but could<br> be useful. That seems fair. But, as a user, how do I find out what is<br> in them, or what I need, other than by downloading them and inspecting<br> them?<br></blockquote> Use the source, Luke. :-)<br><br> <a href="https://github.com/OSGeo/proj-datumgrid">https://github.com/OSGeo/proj-datumgrid</a><br><br> Specific subdirectories for the regional packages:<br><br> <a href="https://github.com/OSGeo/proj-datumgrid/tree/master/europe">https://github.com/OSGeo/proj-datumgrid/tree/master/europe</a><br> <a href="https://github.com/OSGeo/proj-datumgrid/tree/master/north-america">https://github.com/OSGeo/proj-datumgrid/tree/master/north-america</a><br> <a href="https://github.com/OSGeo/proj-datumgrid/tree/master/oceania">https://github.com/OSGeo/proj-datumgrid/tree/master/oceania</a><br><br><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<br> in the package, following tradition, and not worry about the new ones.<br> I am guessing that this means the grids for the important datums are<br> still in the main file, even if they are a North American Datum, and<br> the<br> north-america file contains only more obscure datums that were not<br> previously available. I originally had the impression that all North<br> American grids were demoted from the main file to the regional file.<br></blockquote> proj-datumgrid-north-america includes grids for Greenland.<br><br> The "old" NAD grids for North America are still included in the core<br> proj-datumgrid package as they have been since pretty much forever.<br><br> The filename and content of the proj-datumgrid was explicitly kept the<br> same to not require any changes from packagers other than the version<br> number.<br><br> That is also why the .zip format was kept, and in addition a .tar.gz is<br> available as well.<br><br><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<br> see that this added two files compared to 1.5 (which I should have<br> updated but didn't), and did not withdraw any.<br><br> So I have convinced myself that using the main file for the package,<br> and<br> deferring thinking about the new files is a good approach.<br><br><br> So it might help to add<br><br> All grids that were in proj-datumgrids-1.6 remain in<br> proj-datumgrids-1.7; the regional datumgrid files contain grids for<br> datums not previously supported.<br></blockquote> Where do you suggest to add this?<br><br> Kind Regards,<br><br> Bas<br><hr><br> Proj mailing list<br> Proj@lists.maptools.org<br> <a href="http://lists.maptools.org/mailman/listinfo/proj">http://lists.maptools.org/mailman/listinfo/proj</a><br></blockquote></pre></blockquote></div></body></html>