[Proj] PROJ 5.0.0RC6

Thomas Knudsen knudsen.thomas at gmail.com
Wed Feb 28 06:00:21 EST 2018


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>:

> 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> 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
>>
>> 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] På vegne af Matthias Gabriel
>> Sendt: 28. februar 2018 09:13
>> Til: 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> 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
>>>>>
>>>>>  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
>>>
>>>  Specific subdirectories for the regional packages:
>>>
>>>     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/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
>>>  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/2fc89d80/attachment.htm 


More information about the Proj mailing list