[Proj] PROJ 5.0.0RC6

Wed Feb 28 05:33:15 EST 2018

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
>
>-- 
>M.Sc. Matthias Gabriel
>Fakultät für Elektrotechnik und Informationstechnik
>
>Technische Universität Chemnitz
>Reichenhainer Straße 70 | R. W440
>09126 Chemnitz
>Germany
>
>Tel:    +49 371 531-34458
>Fax:    +49 371 531-834458
>
>matthias.gabriel at etit.tu-chemnitz.de
>www.tu-chemnitz.de
>
>_______________________________________________
>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/52f5cbc7/attachment-0001.htm 