Your message dated Fri, 23 Oct 2015 20:06:43 +0200 with message-id <[email protected]> and subject line Re: Bug#765463: gdal-bin: GDAL and proj4 disagree on some co-ordinate transformations has caused the Debian Bug report #765463, regarding gdal-bin: GDAL and proj4 disagree on some co-ordinate transformations to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 765463: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765463 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: gdal-bin Version: 1.9.0-3.1 Severity: normal Hi, On stable Debian, with gdal-bin 1.9.0-3.1 and proj-bin 4.7.0-2, different results are returned for the same co-ordinate transformations: $ echo '-1.3893433684943819 52.7297093932173411' | cs2cs +init=epsg:4326 +to +init=epsg:27700 441335.00 314849.00 -48.92 $ testepsg -t epsg:4326 epsg:27700 -1.3893433684943819 52.7297093932173411 0 (-1.389343,52.729709,0.000000) -> (441334.824686,314851.829623,-47.495477) The results differ by a few metres. Looking at the internal definitions, we see the following (testepsg comes from gdal-bin, cs2cs from proj-bin): $ testepsg epsg:27700 ... +towgs84=375,-111,431,0,0,0,0 +units=m +no_defs ... $ cs2cs -v +init=epsg:27700 ... # +towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894 ... The "towgs84" parameters are different - a 7-parameter version with proj4, but a 3-parameter version with GDAL. I would have assumed that both packages both used the same underlying data (which I believe is libgeotiff) on the same system, but I assume different versions of the data are bundled inside one or both of these packages, leading to this issue. I tracked the libgeotiff change down to http://trac.osgeo.org/geotiff/changeset/2023/trunk/libgeotiff/csv/gcs.csv - though I would have thought the 7-parameter version was more accurate (not sure!)? Anyway, I'm not sure if this has a solution, but it took long enough to track down (PostgreSQL using proj4, Django using GDAL, so different results depending where the transformation takes place) that I thought I'd open a report for it in case anyone else came across the same issue. ATB, Matthew -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gdal-bin depends on: ii libarmadillo3 1:3.2.3+dfsg-1 ii libc6 2.13-38+deb7u4 ii libcurl3-gnutls 7.26.0-1+wheezy10 ii libdap11 3.11.1-11 ii libdapclient3 3.11.1-11 ii libdapserver7 3.11.1-11 ii libepsilon0 0.9.1-2 ii libexpat1 2.1.0-1+deb7u1 ii libfreexl1 1.0.0b-1 ii libgcc1 1:4.7.2-5 ii libgdal1 1.9.0-3.1 ii libgeos-c1 3.3.3-1.1 ii libgif4 4.1.6-10 ii libhdf4-0-alt 4.2r4-13 ii libhdf5-7 [libhdf5-7] 1.8.8-9+b1 ii libjasper1 1.900.1-13 ii libjpeg8 8d-1+deb7u1 ii libkml0 1.3.0~r863-4.1 ii liblzma5 5.1.1alpha+20120614-2 ii libmysqlclient18 5.5.38-0+wheezy1 ii libnetcdfc7 1:4.1.3-6+b1 ii libodbc1 2.2.14p2-5 ii libogdi3.2 3.2.0~beta2-7 ii libpng12-0 1.2.49-1 ii libpoppler19 0.18.4-6 ii libpq5 9.1.13-0wheezy1 ii libproj0 4.7.0-2 ii libspatialite3 3.0.0~beta20110817-3+deb7u1 ii libsqlite3-0 3.7.13-1+deb7u1 ii libstdc++6 4.7.2-5 ii liburiparser1 0.7.5-1 ii libxerces-c28 2.8.0+deb1-3 ii odbcinst1debian2 2.2.14p2-5 ii unixodbc 2.2.14p2-5 ii zlib1g 1:1.2.7.dfsg-13 gdal-bin recommends no packages. Versions of packages gdal-bin suggests: ii python-gdal 1.9.0-3.1 -- no debconf information
--- End Message ---
--- Begin Message ---fixed 765463 gdal/1.10.1+dfsg-8 thanks Hi Matthew, Thanks for reporting this issue. Some time has passed and in the mean time we're transitioning to GDAL 1.11.3 and considering 2.0.1 after that. The issue is no longer present in jessie On 15-10-14 12:54, Matthew Somerville wrote: > On stable Debian, with gdal-bin 1.9.0-3.1 and proj-bin 4.7.0-2, different > results are returned for the same co-ordinate transformations: > > $ echo '-1.3893433684943819 52.7297093932173411' | cs2cs +init=epsg:4326 +to > +init=epsg:27700 > 441335.00 314849.00 -48.92 > $ testepsg -t epsg:4326 epsg:27700 -1.3893433684943819 52.7297093932173411 0 > (-1.389343,52.729709,0.000000) -> (441334.824686,314851.829623,-47.495477) > > The results differ by a few metres. Looking at the internal definitions, we > see > the following (testepsg comes from gdal-bin, cs2cs from proj-bin): > > $ testepsg epsg:27700 > ... > +towgs84=375,-111,431,0,0,0,0 +units=m +no_defs > ... > > $ cs2cs -v +init=epsg:27700 > ... > # +towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894 > ... The results on jessie with gdal (1.10.1+dfsg-8) & proj (4.8.0-5) are nearly identical: $ echo '-1.3893433684943819 52.7297093932173411' | cs2cs +init=epsg:4326 +to +init=epsg:27700 441335.00 314849.00 -48.92 $ testepsg -t epsg:4326 epsg:27700 -1.3893433684943819 52.7297093932173411 0 (-1.389343,52.729709,0.000000) -> (441334.998590,314848.999177,-48.920119) $ testepsg epsg:27700 ... PROJ.4 rendering of [epsg:27700] = +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 +units=m +no_defs ... $ cs2cs -v +init=epsg:27700 ... # +init=epsg:27700 +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 # +y_0=-100000 +datum=OSGB36 +units=m +no_defs +ellps=airy # +towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894 ... On testing/unstable with gdal (1.11.2+dfsg-3) & proj (4.9.2-1) we get the same: $ echo '-1.3893433684943819 52.7297093932173411' | cs2cs +init=epsg:4326 +to +init=epsg:27700 441335.00 314849.00 -48.92 $ testepsg -t epsg:4326 epsg:27700 -1.3893433684943819 52.7297093932173411 0 (-1.389343,52.729709,0.000000) -> (441334.998590,314848.999177,-48.920119) $ testepsg epsg:27700 ... PROJ.4 rendering of [epsg:27700] = +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 +units=m +no_defs ... $ cs2cs -v +init=epsg:27700 ... # +init=epsg:27700 +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 # +y_0=-100000 +datum=OSGB36 +units=m +no_defs +ellps=airy # +towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894 ... Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- End Message ---
