[Proj] PROJ 5.0.0RC6

Matthias Gabriel matthias.gabriel at etit.tu-chemnitz.de
Wed Feb 28 13:17:33 EST 2018

Thank you Thomas!

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 

Thank you again for your help!

On 28/02/18 12:00, Thomas Knudsen wrote:
> proj=utm zone=33 does not assume input data are in a WGS84 *reference 
> frame* (datum).
> But it picks up  the *WGS84 ellipsoid* as default from the 
> proj_def.dat file,
> if your PROJ_LIB environment variable points to the directory where it 
> resides.
> The error message you get could mean that this is not the case.
> It has been proposed (and I happen to agree) that the proj_def.dat 
> file creates
> more problems than it solves. This is evidently one of them.
> Also note that the proj=longlat steps in your pipelines are 
> essentially no-ops.
> So the entire roundtrip thing can be done using just one cct call:
> cct +proj=pipeline +step +proj=utm +zone=33 +ellps=GRS80 +step  +inv 
> +proj=utm +zone=33 +ellps=GRS80
> Which, due to the feature of "pipeline global settings" can even be 
> abbreviated to:
> cct +proj=pipeline +proj=utm +zone=33 +ellps=GRS80 +step +step +inv
> /Thomas
> 2018-02-28 11:33 GMT+01:00 Matthias Gabriel 
> <matthias.gabriel at etit.tu-chemnitz.de 
> <mailto:matthias.gabriel at etit.tu-chemnitz.de>>:
>     Hi Kristian,
>     thank you for your answer..
>     I run your command on my Windows Installation and unfortunately it
>     produces:
>     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
>     cct.exe: Bad transformation arguments - (major axis or radius = 0
>     or not given)
>         'cct.exe -h' for help
>     The error stems from the second pipeline. If I remove it I get the
>     proper UTM coordinates, but the second part fails:
>     echo 285015.7633 5542944.0186 306.0000 0.0000 | cct.exe
>     +proj=pipeline +step +inv +proj=utm +zone=33 +step +proj=latlong
>     +datum=WGS84
>     cct.exe: Bad transformation arguments - (major axis or radius = 0
>     or not given)
>         'cct.exe -h' for help
>     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?!
>     Thank you for your help, Regards,
>     Matthias
>     On 28 February 2018 09:58:15 CET, Kristian Evers <kreve at sdfe.dk
>     <mailto:kreve at sdfe.dk>> wrote:
>         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:
>         http://lists.maptools.org/pipermail/proj/2018-February/008055.html
>         <http://lists.maptools.org/pipermail/proj/2018-February/008055.html>
>         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:
>         proj-bounces at lists.maptools.org
>         <mailto:proj-bounces at lists.maptools.org>
>         [mailto:proj-bounces at lists.maptools.org
>         <mailto:proj-bounces at lists.maptools.org>] På vegne af Matthias
>         Gabriel Sendt: 28. februar 2018 09:13 Til:
>         proj at lists.maptools.org <mailto:proj at lists.maptools.org> 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:
>             On 2018-02-27 15:11, Greg Troxel wrote:
>                 Kristian Evers <kreve at sdfe.dk <mailto:kreve at sdfe.dk>>
>                 writes:
>                     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:
>                     https://github.com/OSGeo/proj.4/pull/828
>                     <https://github.com/OSGeo/proj.4/pull/828> Let me
>                     know if I've missed something or described things
>                     in an unclear way. 
>                 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? 
>             Use the source, Luke. :-)
>             https://github.com/OSGeo/proj-datumgrid
>             <https://github.com/OSGeo/proj-datumgrid> Specific
>             subdirectories for the regional packages:
>             https://github.com/OSGeo/proj-datumgrid/tree/master/europe
>             <https://github.com/OSGeo/proj-datumgrid/tree/master/europe>
>             https://github.com/OSGeo/proj-datumgrid/tree/master/north-america
>             <https://github.com/OSGeo/proj-datumgrid/tree/master/north-america>
>             https://github.com/OSGeo/proj-datumgrid/tree/master/oceania
>             <https://github.com/OSGeo/proj-datumgrid/tree/master/oceania>
>                 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. 
>             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.
>                 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. 
>             Where do you suggest to add this? Kind Regards, Bas
>             ------------------------------------------------------------------------
>             Proj mailing list Proj at lists.maptools.org
>             <mailto:Proj at lists.maptools.org>
>             http://lists.maptools.org/mailman/listinfo/proj
>             <http://lists.maptools.org/mailman/listinfo/proj> 
>     _______________________________________________
>     Proj mailing list
>     Proj at lists.maptools.org <mailto:Proj at lists.maptools.org>
>     http://lists.maptools.org/mailman/listinfo/proj
>     <http://lists.maptools.org/mailman/listinfo/proj>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180228/fddf8c65/attachment.htm 

More information about the Proj mailing list