I'm working with the TIGER shapefiles, specifically the Tract layer, and my I'm trying to read selected features via WFS using GeoServer, then save those to a new layer. However, when the shapes come out of GeoServer via WFS, they appear to get altered in a way that makes a significant number of them invalid.

In the below image, I have the exact same feature (Census Tract 41047010701). The green feature is it coming directly from PostGIS (using QGIS Database connection). The red is the exact same feature, just passed through GeoServer and output using it's WFS service. It's the exact same shape being read from the underlying PostGIS table, I haven't even copied the feature at this point.

enter image description here

I thought it could be related to reprojecting from TIGERS native epsg::4269 to epsg::4326, but I just turned that off in GeoServer and I get the same result.

This is just one example, but it happens to a ton. Below is an output of running ST_IsValidReason() on a table after features have been read through WFS and inserted into another table.

enter image description here


Thanks to @AndreaAime, I was able to determine that this was due to decimal truncation by Geoserver. This is really a duplicate of the following question.

What causes these geometry differences between original PostGIS data and Geoserver WFS?


Turn off on-the-fly simplification in your postgis datastore. This is used to speed up data display when a store is just used for WMS displays.

  • 2
    Hmmm... it it fixes things, there would be something odd going on... the simplification should be applied to WMS only, but the above report talks about WFS. Wondering if it's a matter of decimals in the output instead, how many decimals are configured for WFS? – Andrea Aime Nov 12 '19 at 13:36
  • that's another possibility – Ian Turton Nov 12 '19 at 13:37

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