[Proj] PROJ 5.0.0RC6

Wed Feb 28 00:58:15 PST 2018

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