On 3/30/22 18:44, Brian Miles wrote:
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.
SpatiaLite has its own CRS definitions in the spatial_ref_sys table like
PostGIS:
$ spatialite -line
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
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
; Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
> From: Sebastiaan Couwenberg
> Subject: Re: Bug#1008612: libspatialite7: erroneous geometry conversion using
> ST_Transform
> Date: March 29, 2022 at 11:05:11 AM EDT
> To: Brian Miles , 1008612-d...@b
Package: libspatialite7
Version: 5.0.1-2
Hello,
I have discovered a bug in libspatialite7’s ST_Transform() function where
transforms from WGS84 geographic coordinates (EPSG:4326) to NAD83 UTM 10N
(26910) returns the result for WGS84 UTM 10N (32610). This appears to only be
occurring on
5 matches
Mail list logo
