[Proj] PROJ 5.0.0RC5
Thomas Knudsen
knudsen.thomas at gmail.com
Thu Mar 1 01:29:50 PST 2018
Thinking it over once again: The -10 km you run into is the distance from
your spherical reference body, down to the proper NAD83 ellipsoid. The
change in northing then, is due to a reduction in latitude by measuring it
geocentrically from the sphere, rather than perpendicularly from the
ellipsoid.
So in a sense, you get what you ask for - unfortunately, Google thinks you
should interpret it differently (computing the latitude on the ellipsoid,
then behaving as if if was defined on a sphere)...
2018-03-01 9:52 GMT+01:00 Thomas Knudsen <knudsen.thomas at gmail.com>:
> Yes, if datum is not specified on both sides, or if the two datums pass as
> identical, pj_transform() will not attempt to do any kind of datum shift.
>
> So do you imply that we have introduced a bug where specifying a non-null
> grid somehow passes as specifying a datum while specifying the null grid
> doesn't?
>
> Under all circumstances, I'm not sure how it should be interpreted: we
> claim to be on NAD83/WGS84 or whatever looks like it at the meter level. We
> will, however, insist on doing our inverse projection on a spherical,
> rather than ellipsoidal, reference surface.
>
> In the new API that kind of stuff make sense: We specify what we want
> done, and libproj does it for us, no matter how stupid it sounds.
>
> But for the old API, libproj is supposed to figure out what to do?
>
> I'm not sure this case makes strict geodetic sense, but somehow libproj
> used to do the right (for a certain definition of right) thing anyway - and
> obviously we need to convince it to keep doing that...
>
>
>
> Den 1. mar. 2018 8.45 AM skrev "Kristian Evers" <kreve at sdfe.dk>:
>
> I am not sure that is correct, Thomas. See the following output:
>
> $ echo 487147.594520173 4934316.46263998 | ./cs2cs -v +proj=utm +zone=15
> +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0
> +k=1.0 +units=m +nadgrids=@null
> # ---- From Coordinate System ----
> #Universal Transverse Mercator (UTM)
> # Cyl, Sph
> # zone= south
> # +proj=utm +zone=15 +ellps=WGS84
> # ---- To Coordinate System ----
> #Mercator
> # Cyl, Sph&Ell
> # lat_ts=
> # +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0
> +k=1.0
> # +units=m +nadgrids=@null
> -10370728.80 5552839.74 0.00
>
> $ echo 487147.594520173 4934316.46263998 | ./cs2cs -v +proj=utm +zone=15
> +datum=NAD83 +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
> +x_0=0.0 +y_0=0 +k=1.0 +units=m
> # ---- From Coordinate System ----
> #Universal Transverse Mercator (UTM)
> # Cyl, Sph
> # zone= south
> # +proj=utm +zone=15 +datum=NAD83 +ellps=GRS80 +towgs84=0,0,0
> # ---- To Coordinate System ----
> #Mercator
> # Cyl, Sph&Ell
> # lat_ts=
> # +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0
> +k=1.0
> # +units=m
> -10370728.80 5552839.74 0.0
>
> It seems to be the combination of +datum=NAD83 in the input system and
> +nadgrids=@null in the output system.
> When only one (either one) of them is present the transformation is fine.
> They are supposed to be treated as being
> the same datum, but isn’t. I have an idea where to fix this.
>
> /Kristian
>
> On 1 Mar 2018, at 08:15, Thomas Knudsen <knudsen.thomas at gmail.com> wrote:
>
> Actually, it seems related to handling of the null grid specificly: When
> using the conus grid, the 10 km jump into the lithosphere is avoided
> (although we get the 2D correction we ask for, but really don't want):
>
> $ echo 487147.594520173 4934316.46263998 0 | cs2cs -f %.16f %FROM% +to
> +proj=latlong +datun=NAD83 | cs2cs +proj=latlong +datum=NAD83 +to
> +proj=merc +R=6378137 +nadgrids=conus
>
> > -10370704.71 5552845.16 -0.00
>
> Note: Height set to negative zero... not sure yet whether this is a hint
>
>
>
>
>
>
> 2018-03-01 7:58 GMT+01:00 Thomas Knudsen <knudsen.thomas at gmail.com>:
>
>> Jeff,
>>
>> That's interesting (although annoying!)
>>
>> When I leave out the final nadgrids=@null, I get the correct result from
>> PROJ v5RC6. Can you reproduce that?
>>
>> Note, I'm not implying that this should be considered a solution or
>> workaround, merely trying to narrow in on the
>> problem, which seems to be related to datum handling.
>>
>> /Thomas
>>
>>
>>
>>
>>
>> 2018-03-01 0:38 GMT+01:00 Jeff McKenna <jmckenna at gatewaygeomatics.com>:
>>
>>> Update: I never heard back from anyone else about testing PROJ v5 +
>>> MapServer (and GDAL), so in fact I may be the only person to test this
>>> combination so far. Because this is a PROJ mailing list I first give
>>> some more feedback with PROJ utilities, then later will list results
>>> from other software for anyone interested. (in reality I first noticed
>>> the problem in MapServer but then each test in GDAL then PROJ failed as
>>> well, on Windows with PROJ 5.0.0-RC6)
>>>
>>> cs2cs
>>> =====
>>>
>>> I wanted to test PROJ v5 by using a point
>>> (487147.594520173,4934316.46263998) in EPSG:26915 (UTM Zone 15) and
>>> reprojecting that to EPSG:3857 (Google's Mercator).
>>>
>>> with PROJ 4.9.3
>>> ---------------
>>>
>>> cs2cs -v +proj=utm +zone=15 +datum=NAD83 +to +proj=merc +a=6378137
>>> +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
>>> +nadgrids=@null
>>> # ---- From Coordinate System ----
>>> #Universal Transverse Mercator (UTM)
>>> # Cyl, Sph
>>> # zone= south
>>> # +proj=utm +zone=15 +datum=NAD83 +ellps=GRS80 +towgs84=0,0,0
>>> # ---- To Coordinate System ----
>>> #Mercator
>>> # Cyl, Sph&Ell
>>> # lat_ts=
>>> # +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
>>> +y_0=0 +k=1.0
>>> # +units=m +nadgrids=@null
>>> 487147.594520173 4934316.46263998
>>>
>>> RESULT POINT: -10370728.80 5552839.74 -0.00
>>>
>>> with PROJ 5.0.0-RC6
>>> -------------------
>>>
>>> >cs2cs -v +proj=utm +zone=15 +datum=NAD83 +to +proj=merc +a=6378137
>>> +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
>>> +nadgrids=@null
>>> # ---- From Coordinate System ----
>>> #Universal Transverse Mercator (UTM)
>>> # Cyl, Sph
>>> # zone= south
>>> # +proj=utm +zone=15 +datum=NAD83 +ellps=GRS80 +towgs84=0,0,0
>>> # ---- To Coordinate System ----
>>> #Mercator
>>> # Cyl, Sph&Ell
>>> # lat_ts=
>>> # +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
>>> +y_0=0 +k=1.0
>>> # +units=m +nadgrids=@null
>>> 487147.594520173 4934316.46263998
>>>
>>> RESULT POINT: -10370728.80 5522830.15 -10484.03
>>>
>>> Discussion
>>> ----------
>>>
>>> PROJ 4.9.3 returns the correct value (I've confirmed this with many
>>> other tools including QGIS). Can someone explain why those 2 results
>>> are different? (I have reproduced this problem on Windows and also
>>> Ubuntu 14.94)
>>>
>>> GDAL
>>> ====
>>>
>>> I wanted to test PROJ v5 by using that same test point (as a shapefile)
>>> in EPSG:26915 (UTM Zone 15) and reprojecting that to EPSG:3857 (Google's
>>> Mercator), using GDAL's ogr2ogr command. (data used:
>>> https://www.gatewaygeomatics.com/dl/parcels-proj-v5-test.zip ) Below I
>>> have used the ogr2ogr command (included in the "commands.txt" file in
>>> that data download) and then ogrinfo on the reprojected file to output:
>>>
>>> with PROJ 4.9.3
>>> ---------------
>>>
>>> POINT (-10370728.7959208 5552839.74177463)
>>>
>>> with PROJ 5.0.0-RC6
>>> -------------------
>>>
>>> POINT (-10370728.7959208 5522830.1464459)
>>>
>>> Discussion
>>> ----------
>>>
>>> PROJ 4.9.3 compiled into GDAL 2.2.3 returns the correct point value, but
>>> returns a different point value with PROJ 5.0.0-RC6
>>>
>>> MapServer
>>> =========
>>>
>>> Same problems as GDAL (reprojected layer has different extents with PROJ
>>> 5.0.0-RC6, causing problems to display the reprojected layer in a map
>>> image).
>>>
>>>
>>> If you made it this far in my long email, thanks for listening (I am
>>> totally stumped on this one, again ha).
>>>
>>> -jeff
>>>
>>>
>>>
>>>
>>>
>>> On 2018-02-25 3:45 PM, Kristian Evers wrote:
>>> > Thanks for testing, Jeff. It is very appreciated. I hope you sort of
>>> your problems,
>>> > PROJ-related or not.
>>> >
>>> > /Kristian
>>> >
>>> >> On 25 Feb 2018, at 00:29, Jeff McKenna <jmckenna at gatewaygeomatics.com>
>>> wrote:
>>> >>
>>> >> Update: it seems many things were happening, causing me to look in
>>> wrong
>>> >> places. But in the end MapServer was in fact reprojecting the points;
>>> >> what caused me total confusion was that I was testing with several
>>> >> MapServer-related applications that are part of MS4W (Mapbender,
>>> >> GeoMOOSE) and one application had a totally blank opening map image
>>> with
>>> >> PROJ v5. In fact for some reason the old hardcoded map extents
>>> >> (displayed in EPSG:3857) no longer display the data (you have to now
>>> >> zoom out a bit to see the data, reprojected with PROJ v5). I'll
>>> contact
>>> >> the GeoMOOSE team to let them dive into this (still, it could be my
>>> >> Windows environment, as no one else seems to be testing MapServer +
>>> PROJ
>>> >> v5 yet).
>>> >>
>>> >> Very sorry for all this noise!
>>> >>
>>> >> Short story: all is fine with RC5 here.
>>> >>
>>> >> Thank you again Kristian for your passion driving this.
>>> >>
>>> >> -jeff
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 2018-02-23 5:33 PM, Jeff McKenna wrote:
>>> >>> Hi Kristian,
>>> >>>
>>> >>> No problems here on Windows in the MS4W environment, but I'm running
>>> >>> into odd errors when I have MapServer call PROJ 5
>>> >>> (https://lists.osgeo.org/pipermail/mapserver-dev/2018-Februa
>>> ry/015347.html).
>>> >>> Obviously an issue downstream not here, but I thought I'd at least
>>> >>> mention it here that I am testing RC5 as well :)
>>> >>>
>>> >>> Thanks for pushing this release along.
>>> >>>
>>> >>> -jeff
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 2018-02-23 3:19 PM, Kristian Evers wrote:
>>> >>>> All,
>>> >>>>
>>> >>>> I have prepared PROJ 5.0.0RC5. Downloads are here:
>>> >>>>
>>> >>>>
>>> >>>> http://download.osgeo.org/proj/proj-5.0.0RC5.tar.gz (
>>> http://download.osgeo.org/proj/proj-5.0.0RC5.tar.gz.md5)
>>> >>>> http://download.osgeo.org/proj/proj-5.0.0RC5.zip (
>>> http://download.osgeo.org/proj/proj-5.0.0RC5.zip.md5)
>>> >>>>
>>> >>>>
>>> >>>> Since RC4 problems with vertical grid installation, the Horner
>>> >>>> transformation and faulty polygon area calculation
>>> >>>> in geodesic library has been fixed. Hopefully this will be the final
>>> >>>> release candidate. I will call for a vote for
>>> >>>> promotion to final release on the 27th. Unless serious issues are
>>> >>>> discovered in the mean time.
>>> >>>>
>>> >>>> /Kristian
>>> >>>>
>>> >>>>
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> 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.osgeo.org/pipermail/proj/attachments/20180301/b2f88774/attachment.html>
More information about the Proj
mailing list