Opened 8 years ago

Closed 8 years ago

Last modified 6 years ago

#1580 closed defect (fixed)

proj4 cache corrupted by projection error ?

Reported by: strk Owned by: pramsey
Priority: critical Milestone: PostGIS 2.0.0
Component: postgis Version: master
Keywords: Cc: caleb

Description

Look at this session:

strk=# select ST_Transform('SRID=4326;POINT(180 -90)'::geometry, 3857);
ERROR:  transform: couldn't project point (180 -90 0): tolerance condition error (-20)
strk=# select ST_Transform('SRID=4326;POINT(180 -89.99999999999)'::geometry, 3857);
ERROR:  AddToPROJ4SRSCache: couldn't parse proj4 string: '+proj=longlat +datum=WGS84 +no_defs ': tolerance condition error

The second ERROR doesn't sound right, seems to reveal a dirtiness in proj cache. It's critical because the cache survives multiple transactions making it impossible to perform future reprojections

Change History (6)

comment:1 Changed 8 years ago by strk

This actually seems to be pj_get_errno_ref() not resetting between calls to pj_init

comment:2 Changed 8 years ago by strk

Resolution: fixed
Status: newclosed

Fixed in r9194

comment:3 Changed 6 years ago by caleb

Cc: caleb added

I believe I'm having this same issue. First I get an error like:

SELECT SUM(count*ST_X(cluster_point))/SUM(count) as center_x,
 SUM(count*ST_Y(cluster_point))/SUM(count) as center_y,
 SUM(count) as count FROM "clusters" WHERE (zoom = 9 AND ST_INTERSECTS(polygon,ST_TRANSFORM(ST_SETSRID(ST_MakeBox2D(ST_POINT(26.816068571769904,89.99999737698666),
 ST_POINT(29.507718962394904,89.9999974989205)),4326),900913))) GROUP BY grid_point
PG::Error: ERROR:  transform: couldn't project point (26.8161 90 0): tolerance condition error (-20)

Then, all following transformations throw an error like:

PG::Error: ERROR: AddToPROJ4SRSCache: couldn't parse proj4 string: '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +units=m +k=1.0 +nadgrids=@null +no_defs': tolerance condition error

Only solution seems to be to restart the PostgreSQL server.

This is occurring with PostGIS 1.5. Assuming this is the same, and the above fix is the resolution: which stable version did this fix made it into?

Thanks!

-- Caleb

comment:4 Changed 6 years ago by robe

this sounds like it got fixed in PostGIS 2.0.0 and did not get backported. Can you provide the

SELECT version() || ' ' || postgis_full_version();

you are using. My guess is this isn't going to be hard to backport, but we didn't because the audience for 1.5 is diminishing significantly so if you get from a package maintainer you might have a ways to wait. If you compile yourself and its causing you serious problems we can probably patch in short order.

comment:5 Changed 6 years ago by caleb

Here you go:

PostgreSQL 9.1.9 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2, 64-bit POSTGIS="1.5.3" GEOS="3.3.3-CAPI-1.7.4" PROJ="Rel. 4.8.0, 6 March 2012" LIBXML="2.8.0" USE_STATS

I'm using the Ubuntu packaged version, but I'm happy to upgrade to 2.0 manually if that's the easiest fix (sounds like it is).

comment:6 Changed 6 years ago by robe

Given you are using packages, I would say upgrade to postgis 2.0 is your best bet since those are already available via packages. Upgrading to PostGIS 2.1 would be fine too (same effort as giong to 2.0 if your page offers it).

Just a warning going from 1.5 to 2.0 requires a hard upgrade. Going from 2.0 to 2.1 is just a soft.

Note: See TracTickets for help on using tickets.