[Proj] PROJ 5.0.0RC5
Thomas Knudsen
knudsen.thomas at gmail.com
Thu Mar 1 00:52:30 PST 2018
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/6a9810ab/attachment.html>
More information about the Proj
mailing list