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 <[email protected]> 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 <[email protected]> > 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
