[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
beginning...
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