Sort out ERROR: transform: couldn''t project point (180 -90 0): tolerance condition error (-20)

[strk]

Alright, enough people reported this. And I'm also getting it.

Could be just normal and fine, but I belive it is worth taking a look before going public, just in case we changed the behavior.

[strk]

Oh, this is from:

select ST_Transform('SRID=4326;POINT(180 -90)'::geometry, 3857);

[strk]

The query above should theoretically be equivalent to this:

SELECT postgis_transform_geometry('SRID=4326;POINT(180 -90)'::geometry, 
 '+proj=longlat +datum=WGS84 +no_defs', 
 '+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 +wktext  +no_defs', 
 3857);

But the latter gives this confusing error:

ERROR:  transform: couldn't parse proj4 input string: '+proj=longlat +datum=WGS84 +no_defs': tolerance condition error

Which makes no sense (it's _not_ a parse error but a projection error).

I've a kind of dejavu about this, I think I've been looking at this problem some weeks ago and was related to non-reentrant error reporting API of libproj.

[strk]

Yep, just run twice to see the issue:

strk=# select postgis_transform_geometry('SRID=4326;POINT(180 -90)'::geometry, '+proj=longlat +datum=WGS84 +no_defs', '+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 +wktext  +no_defs', 3857);
ERROR:  transform: couldn't project point (180 -90 0): tolerance condition error (-20)
strk=# select postgis_transform_geometry('SRID=4326;POINT(180 -90)'::geometry, '+proj=longlat +datum=WGS84 +no_defs', '+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 +wktext  +no_defs', 3857);
ERROR:  transform: couldn't parse proj4 input string: '+proj=longlat +datum=WGS84 +no_defs': tolerance condition error

[strk]

So, it fails projecting a point on latitude -89.999999999 (9 decimal digits) but has no problems with -89.99999999 (8 decimal digits). I wonder what would a value to clip to...

Anyway, I get same behavior with postgis 1.5 and 1.4, so not a regression of any kind. Just the confusing error message which was fixed with r9507

[strk]

For the record: same error also with proj-4.7.1 (in addition to proj-4.8.0)

[strk]

Ok, the "tolerance" is how much distance is tolerated from the pole. Up to 1e-10 off the pole is tolerated. Closer points trigger the exception. I guess this is because representing a point on the pole on mercator has infinite possibilities (all the bottom line).

[strk]

Interesting enough (for me), mapnik added a special handling for the case:

 https://github.com/mapnik/mapnik/blob/master/src/proj_transform.cpp#L54

You see they only handle WGS84 to Mercator, and only when a specific proj string is given. We could actually do better, if we wanted to go there (but I suspect we don't).

[tokumine]

Just a datapoint but we get the following:

select st_astext(ST_Transform('SRID=4326;POINT(180 -90)'::geometry, 3857));
                st_astext                 
------------------------------------------
 POINT(3.14159265358979 -1.5707963267949)
(1 row)

[tokumine]

This may be of use but running postgis_full_version() returns:

 POSTGIS="2.0.0SVN" GEOS="3.3.0-CAPI-1.6.1" PROJ="Rel. 4.7.1, 23 September 2009" GDAL="GDAL 1.8.0, released 2011/01/12" LIBXML="2.7.6" USE_STATS

[tokumine]

running on a newer build we're getting the following:

select st_astext(ST_Transform('SRID=4326;POINT(180 -90)'::geometry, 3857));
ERROR:  transform: couldn't project point (180 -90 0): tolerance condition error (-20)

 POSTGIS="2.0.0alpha5SVN" GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.7.1, 23 September 2009" GDAL="GDAL 1.9.0, released 2011/12/29" LIBXML="2.7.6" SVN_REVISION=9194 USE_STATS

[strk]

Interesting, so _same_ PROJ version (4.7.1). The difference must be in PostGIS. Can you get the the SVN revision of PostGIS installed on the first machine, somehow ?

[strk]

16:50 < tokumine> 7789 or 8481

I'll try those.

[strk]

I can reproduce the silent failure (wrong answer but no exception) with r8481

[strk]

I bisected this into r8880 being the first commit changing the result from "wrong" to "exception"

[strk]

Ok, now I see that the commit replaced a DEBUG line with an ERROR line. Probably 1.5 has always given the ERROR so only a window in development mode temporarely changed that to give a wrong answer instead.

[springmeyer]

It may not be as relevant in postgis, but for rendering you always want to remember to test proj4 behavior with and without the +over modifier.

[strk]

It looks like +over only deals with longitude wrap. The error of this ticket really also occurred with longitude 0 (it's really about latitude).

Anyway, good hint about +over. More here:  http://trac.osgeo.org/proj/wiki/GenParms#lon_wrapover-LongitudeWrapping

[springmeyer]

Okay, interesting!

[strk]

For the record, it's been reported that the "wrong" answer was given at least since r8481 Dunno how large the "silently wrong" window is. So far from 8481 to 8879