Geoserver WFS-T PostGIS (PostgreSQL) Layer Read-Only

An unexpected Read-Only message is common when attempting a Geoserver WFS-T request via the Demo page.  This is also true of WFS-T on a PostGIS-backed Layer.

Here are a list of possible culprits:

1. Verify the layer is writable by the Postgres role (user account) which you've used to authenticate in Geoserver, via the Store dialog for that Layer.
2. The table must have a primary key in Postgres.  It may be necessary to "Reload Feature Type" under the Layer page > Data Tab > Feature Type Details section.  It also be necessary to "Expose Primary Keys" in the Store for the Layer.
3. The WFS-T Demos will not successfully authenticate out-of-the-box (which will probably give a different error message).  See my post on the issue, and how to resolve it.
4. If you are using my work around, linked from above, you are using anonymous authentication (for testing only, of course!).  You will need to create a write rule that applies to the anonymous role and the workspace which relates to your Layer/Store.

In my latest experience with this error, culprit #4 got me :-p

Solution, Geoserver bug with authenticated requests

Geoserver ships with a good list of helpful Demo requests -- however, the authenticated requests fail if you do not add the relevant URL path to a Filter Chain which includes a "form" authentication filter.

If you run any Demo request involving authentication without the relevant Filter Chain modification you will see the following message:

HTTP response: 401 No AuthenticationProvider found for org.springframework.security.authentication.UsernamePasswordAuthenticationToken

The same response is seen when running the request with curl, e.g.:

curl -u admin:geoserver "http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=topp:states&outputFormat=GML2&FEATUREID=states.3"

You can resolve this issue by adding the relevant URL path suffix (e.g., /wcs*  or /wfs*) to the "web" Filter Chain, which includes the "form" Authentication Filter.

Access this dialog in the Web Administration interface under Security > Authentication > Filter Chains > web.

I've commented on the bug in the Geoserver project JIRA -- to resolve this bug this issue should be either noted or the underlying xml's changed -- otherwise the Demos fail.

Georeference a non-referenced image with gdal_translate

This technique is useful for georeferencing an image that you could be getting from a WMS server.

To get an image from a WMS Server, first do a capabilities request via the URL.  This will return an XML with parameters.  The result will look something like this (you could also substitute your target WMS, layer, bbox, etc.

http://imagery.pasda.psu.edu/arcgis/services/pasda/PAMAP_cycle2/MapServer/WMSServer?service=WMS&version=1.1.0&request=GetMap&layers=11&styles=&bbox=-77.16641161363148171,39.76300177722033169,%20-77.16220203861050209,39.76481826348722137&width=800&height=400&srs=EPSG:4326&format=image/jpeg

change the format parameter to image/tiff to download

if gdal isn't already installed, do so now, and navigate to the gdal bin directory, if it isn't on your path

gdal translate will require input file, output file, the desired spatial reference system, and ground control points (gcp) which you will calculate from the bounding box you entered above and the image pixel size (800 by 400).  These correspond to the corners of the image (coordinates differ from above slightly, not intended).

gdal_translate c:\temp\WMSServer.tiff c:\temp\aerial.tif -of GTiff -a_srs EPSG:4326 -gcp 0 0 -77.16694 39.764799 -gcp 800 400 -77.161927 39.763017 -gcp 0 400 -77.16694 39.763017 -gcp 800 0 -77.161927 39.764799

Use gdal_warp for further transformation, if a simple scaling wasn't adequate.  This is particularly necessary for Geoserver.  In that case, also use the -co tfw=yes parameter to create a world file, since Geoserver doesn't recognize srs in the standalone GTiff.

It looks like this: gdalwarp c:\temp\aerial.tif c:\temp\aerialw.tif -of GTiff -co tfw=yes -t_srs EPSG:4326