#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 by , 13 years ago
comment:3 by , 11 years ago
Cc: | 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 by , 11 years ago
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 by , 11 years ago
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 by , 11 years ago
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.
This actually seems to be pj_get_errno_ref() not resetting between calls to pj_init