[Proj] PROJ 5.0.0RC5
Kristian Evers
kreve at sdfe.dk
Thu Mar 1 02:39:26 EST 2018
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<mailto: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<mailto: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<mailto: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<mailto: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-February/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<mailto:Proj at lists.maptools.org>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180301/c030c4a6/attachment-0001.htm
More information about the Proj
mailing list