Bug#1008612: closed by Sebastiaan Couwenberg <sebastic at xs4all.nl> (Re: Bug#1008612: libspatialite7: erroneous geometry conversion using ST_Transform)
Brian Miles
selimnairb at gmail.com
Wed Mar 30 17:44:51 BST 2022
Hi Sebastiaan,
Thank you for putting in the time to test and respond.
I am a little confused as to why we are seeing different results between spatialite and proj itself for what should be the same transformation.
For example:
echo -122.338928 47.629273 | cct -c1,2 -d6 -z0 -t0 +proj=utm +zone=10 +ellps=GRS80 +datum=NAD83 +units=m +no_defs
549665.158878 5275308.476964 0.000057 0.0000
this matches the value you are getting below when PROJ_NETWORK is not set.
Incidentally, I believe I do have proj-data installed:
```
$ dpkg -s proj-data
Package: proj-data
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 26322
Maintainer: Debian GIS Project <pkg-grass-devel at lists.alioth.debian.org>
Architecture: all
Multi-Arch: foreign
Source: proj
Version: 7.2.1-1
Description: Cartographic projection filter and library (datum package)
Proj and invproj perform respective forward and inverse transformation
of cartographic data to or from Cartesian data with a wide range of
selectable projection functions (over 100 projections).
.
Geod and invgeod perform geodesic (Great Circle) computations for
determining latitude, longitude and back azimuth of a terminus point given
a initial point latitude, longitude, azimuth and distance (direct) or the
forward and back azimuths and distance between an initial and terminus
point latitudes and longitudes (inverse).
.
This package contains auxiliary projection datum grids used by the
library and tools.
Homepage: https://proj.org/
```
And I received the same result when running `cct` with `PROJ_NETWORK=ON`.
Any ideas what’s going on here?
Thanks,
Brian
> On Mar 29, 2022, at 12:11 PM, Sebastiaan Couwenberg <sebastic at xs4all.nl> wrote:
>
> On 3/29/22 17:35, Brian Miles wrote:
>> I apologize that I mis-stated my original description of the bug. It is not that the results for 26910 transforms are the same as for 32610 transforms, but that transforms to 26910 are simply incorrect for Debian/Ubuntu.
>
> I'm no projection specialist, I cannot judge whether a transformation is correct or not. The experts for that frequent the proj mailinglist.
>
>> As this is only happening on Debian/Ubuntu, it is not clear to me that bringing this upstream will result in resolution. Are there any other option to addressing this?
>
> Things that may affect the transformation result:
>
> * libspatialite version
> * proj version
> * whether proj-data grids are installed / PROJ_NETWORK=ON is set
>
> proj-data is not packaged in Debian (#952459), it is packaged in Alpine.
>
> Datumgrid availabilty makes better transformations possible:
>
> $ spatialite /tmp/test.db "SELECT AsText(point), AsText(ST_Transform(point, 26910)) FROM test;"
> SpatiaLite version ..: 5.0.1 Supported Extensions:
> - 'VirtualShape' [direct Shapefile access]
> - 'VirtualDbf' [direct DBF access]
> - 'VirtualText' [direct CSV/TXT access]
> - 'VirtualGeoJSON' [direct GeoJSON access]
> - 'VirtualXL' [direct XLS access]
> - 'VirtualNetwork' [Dijkstra shortest path - obsolete]
> - 'RTree' [Spatial Index - R*Tree]
> - 'MbrCache' [Spatial Index - MBR cache]
> - 'VirtualFDO' [FDO-OGR interoperability]
> - 'VirtualBBox' [BoundingBox tables]
> - 'VirtualSpatialIndex' [R*Tree metahandler]
> - 'VirtualElementary' [ElemGeoms metahandler]
> - 'VirtualRouting' [Dijkstra shortest path - advanced]
> - 'VirtualKNN' [K-Nearest Neighbors metahandler]
> - 'VirtualGPKG' [OGC GeoPackage interoperability]
> - 'VirtualXPath' [XML Path Language - XPath]
> - 'SpatiaLite' [Spatial SQL - OGC]
> PROJ version ........: Rel. 9.0.0, March 1st, 2022
> GEOS version ........: 3.10.2-CAPI-1.16.0
> RTTOPO version ......: 1.1.0
> TARGET CPU ..........: x86_64-linux-gnu
> POINT(-122.338928 47.629273)|POINT(549665.158879 5275308.47686)
> POINT(-122.338923 47.62927)|POINT(549665.537361 5275308.146648)
> POINT(-122.33895 47.629253)|POINT(549663.525012 5275306.240011)
> POINT(-122.392051 47.62888)|POINT(545674.479273 5275232.14496)
> POINT(-122.392038 47.62888)|POINT(545675.455944 5275232.152617)
>
> $ PROJ_NETWORK=ON spatialite /tmp/test.db "SELECT AsText(point), AsText(ST_Transform(point, 26910)) FROM test;"
> SpatiaLite version ..: 5.0.1 Supported Extensions:
> - 'VirtualShape' [direct Shapefile access]
> - 'VirtualDbf' [direct DBF access]
> - 'VirtualText' [direct CSV/TXT access]
> - 'VirtualGeoJSON' [direct GeoJSON access]
> - 'VirtualXL' [direct XLS access]
> - 'VirtualNetwork' [Dijkstra shortest path - obsolete]
> - 'RTree' [Spatial Index - R*Tree]
> - 'MbrCache' [Spatial Index - MBR cache]
> - 'VirtualFDO' [FDO-OGR interoperability]
> - 'VirtualBBox' [BoundingBox tables]
> - 'VirtualSpatialIndex' [R*Tree metahandler]
> - 'VirtualElementary' [ElemGeoms metahandler]
> - 'VirtualRouting' [Dijkstra shortest path - advanced]
> - 'VirtualKNN' [K-Nearest Neighbors metahandler]
> - 'VirtualGPKG' [OGC GeoPackage interoperability]
> - 'VirtualXPath' [XML Path Language - XPath]
> - 'SpatiaLite' [Spatial SQL - OGC]
> PROJ version ........: Rel. 9.0.0, March 1st, 2022
> GEOS version ........: 3.10.2-CAPI-1.16.0
> RTTOPO version ......: 1.1.0
> TARGET CPU ..........: x86_64-linux-gnu
> POINT(-122.338928 47.629273)|POINT(549665.036792 5275308.276363)
> POINT(-122.338923 47.62927)|POINT(549665.415273 5275307.94615)
> POINT(-122.33895 47.629253)|POINT(549663.402919 5275306.039517)
> POINT(-122.392051 47.62888)|POINT(545674.35684 5275231.954471)
> POINT(-122.392038 47.62888)|POINT(545675.333511 5275231.962125)
>
> Kind Regards,
>
> Bas
>
> --
> GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
More information about the Pkg-grass-devel
mailing list