1

We are using GeoServer (tried on version 2.2 and 2.4) to render WMS with a PostGIS (version 1.5) data store. We set up the geometry field with all the appropriate constraints and validated/cleaned the geom. However, when publishing a specific table (srid 4326) that has regional level data geoserver computes incorrect bbox values. North, West, and South are only slightly off but the East value is off by about 1 degree. The resulting WMS cuts off the eastern part of the dataset. The strangest part is that this table renders perfectly in Qgis, ArcGIS, and the Open Layers preview in GeoServer. When we calculate the extent in PostGIS and manually add those values to the service bbox form it will then work as expected. That is fine but we are managing hundreds of services and I want to rely on the automatic bbox computation. Does anyone know why geoserver might be reading an incorect bbox?

EDIT: forgot to mention we are using GeoWebCache/geoserver for the tile cache.

7

GeoServer is probably using PostGIS' "estimated extent" function, which has a habit of under-determining the bounds. You could drop the estimated extent function and replace it the full version. The downside (and perhaps the reason GeoServer doesn't use it) is that for very large tables, the full extent calculation can take a very long time.

This effect only shows up in tables with highly variable geometry sizes and distributions, and only occasionally then (I've seen it on voting areas in British Columbia, but that's about it). So you might be fine just hand-fixing this one layer and letting the rest run through automatically.

Or, replace the existing function(s) with a no-op so that GeoServer is forced to fall back to a full scan:

 create or replace function st_estimated_extent(text,text) 
 returns box2d as 'select null::box2d' language sql;

 create or replace function st_estimated_extent(text,text,text) 
 returns box2d as 'select null::box2d' language sql;
  • Thanks Paul! We compared the values of the estimated extent and it seems your theory is indeed correct. Do you have any idea why GeoServer would read the actual extent of the same table when presented through a view? – jmapping Oct 28 '13 at 16:18
  • Symptom of same problem. The estimated extent function can only generate estimates where there's statistics available on the table. Views don't have stats. So the estimate returns NULL and then GeoServer falls back to full extent calculation. – Paul Ramsey Oct 28 '13 at 18:07
  • Which gives an even easier hack to solve your problem. Replace ST_Estimated_Extent with a function that just returns NULL. Then GeoServer will always fall back to full extent scan. As long as your tables aren't too big you'll never notice the difference. – Paul Ramsey Oct 28 '13 at 18:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.