|OpenLayers WFS-T Using a GeoServer Hosted PostGIS Layer|
This is an advanced OpenLayers tutorial which explains how to setup your own WFS-T example using a combination of GeoServer and PostgreSQL/PostGIS. In order to complete this tutorial, a user must have administrative access to both GeoServer and PostgreSQL running on a server. Users must also have an intermediate understanding of programming OpenLayers for developing web mapping applications. I also recommend users to install an add-on to Mozilla Firefox called Firebug, as it can be very useful when debugging the XML Posts and Responses sent by GeoServer during the WFS-T calls.
Web Feature Services (WFS) can be very useful when building web mapping applications because they allow users to overlay vector spatial data on top of thematic base layers. This protocol allows users to pan and zoom around existing spatial data, which can be used when developing maps and analyzing data. However, the WFS protocol is limited in the sense that it is used to fetch and display previously existing data, not allowing additional information to be added or included in the web mapping application. The WFS-T protocol was designed for that exact reason, as it allows for ‘transactions’ to occur. A WFS-Transaction can be used to add, remove or modify the features that are loaded, and most importantly allows for the changes to be committed back and saved to the parent source. For this reason it is important to have your data which you wish to modify to be stored within a spatial database such as PostgreSQL/PostGIS so that the transactions can be managed properly. Loading data directly from ESRI Shapefiles is not recommended when building a WFS-T web mapping application.
Before starting into the technical details, it is valuable to understand the correct flow of processes that will allow the creation of the OpenLayers WFS-T example to go as smooth as possible. Users will have to complete additional tutorials found within the GISTutor website to complete some of the following items. The following list illustrates the order of processes required to complete this OpenLayers WFS-T tutorial.
Download the sample data for the OpenLayers WFS-T tutorial
To start off you can download the sample data for this tutorial here. This shapefile contains polygons of the block boundaries found within the core of
Import the sample data into a PostGIS enabled PostgreSQL database
To import the sample data into your PostGIS database, users should follow along with the instructions described in ‘Importing Shapefile GIS Data into PostgreSQL’. Make sure to use wfst_test.shp as the shapefile name and also specify the SRID as 26910 when executing your shp2pgsql command to ensure that the projection information is properly included during the import.
Publish a new GeoServer layer
In order to use the GIS data we have just added to PostGIS in our web mapping application, we must first configure GeoServer to connect to our PostGIS spatial datasets. Once that connection has been established, you will continue by publishing a new GeoServer layer. To complete this section of the WFS-T tutorial, users must follow along with the instructions described in ‘How to Connect GeoServer to PostGIS Spatial Datasets’. Again users should be loading the wfst_test geometry from their PostGIS database, and remember to specify the SRID as 26910. When you have successfully established the connection and published the layer, your GeoServer Layer list should have a record that looks like the following table.
Configure GeoServer Apache ProxyPass and OpenLayers proxy.cgi
Now that we have our wfst_test shapefile data published through our GeoServer and PostGIS connection, it is important to start configuring OpenLayers to handle the creation of our web mapping application. One of the most common issues when loading GeoServer layers comes from XMLHttpRequest, stating that there is an issue with Access-Control-Allow-Origin. This is very common if you are trying to load data from another remote server, or if you are trying to load data from localhost. To complete this section of the tutorial, users must follow along with the instructions describe in ‘Configuring GeoServer Proxy for Public and Remote Data Access’. Users should only complete the Apache ProxyPass section if you plan on hosting your application outside of the localhost environment, ie http://yourdomain.com/geoserver/web (Recommended). This style will allow you to build a web mapping application that is available in a public location on the internet. For other users that plan on running their web mapping application from http://localhost:8080/geoserver/web, you only need to complete to bottom two sections: ‘Changing the Default GeoServer Admin Login and Password Information’ and ‘Configuring an OpenLayers proxy.cgi for Loading Local and Remotely Hosted GeoServer WFS Data’. By adding in the values of ‘localhost’ and ‘localhost:8080’ to the AllowedHosts variable array in the OpenLayers proxy.cgi, you should be able to prevent the XMLHttpRequest Access-Control-Allow-Origin issue from occurring. This is beneficial when coding the OpenLayers WFS-T web mapping application as you can specify the path to your GeoServer layer through a localhost url.
Develop the OpenLayers WFS-T web mapping application
Now that all the GIS data has been published and all the technology has been configured it is time to start coding the OpenLayers WFS-T web mapping application. The following script was developed off of the code found in the tutorial ‘How To Set Up An Openlayers Map With Spherical Mercator Base Layers and Custom WFS GIS Data Overlays’. The code has been modified to include additional controls for displaying the OpenLayers editing toolbar and also includes save strategies used to commit the changes back to the PostGIS database using the WFS-Transaction.
In a new blank text document, copy and paste the following code.
Follow along reading the code comments, take particular note to the WFS-T editable overlay section. Some important things to note are the use of a save strategy which specifies how to execute the transaction calls of the WFS-T web mapping application. Some other important information is the use of the localhost url paths. Make sure to match the featureNS to the value of your GeoServer workspace. Also verify that the correct layer name has been set for the featureType value. The schema statement also includes a variable called typename which should contain the workspace name and layer name, ex. typename=cite:wfst_test. Once you have setup the script for your server, you should be able to test it out by loading it in Mozilla Firefox.
Debugging / Error Messages
For this section of the tutorial I will discuss some common error messages and potential fixes. If you haven’t already you should install the Firebug add-on to Mozilla Firefox. Once it is installed load up your web site and right click anywhere on the screen, select Inspect Element. This will open up the Firebug interface along the bottom of your web browser. Along the top you should see a tab called Net, make sure that it is enabled. Then it will bring up some additional inner tabs, for debugging the XML Posts and Responses click on the XHR tab inside of the Net area.
Once the XHR section is active and ready, refresh your website with Ctrl + F5. You should see a POST entry appear with a url run through your proxy.cgi. Additional transactions will appear when you try to modify an existing polygon, add a new polygon, or remove a polygon and click the Save Changes button. For debugging make sure to look at the XML Responses that are sent back.
The following section will display some XML error responses found in Firebug and some potential solutions to the issue.
Mistyped Layer Name
Take a look at your WFS-T editable overlay section and confirm that you have spelled your layer name correctly in the featureType value and that typename is setup properly at the end of the schema statement. This response was sent because the name wfs_test was used instead of wfst_test.
Error when adding a new polygon
This error usually occurs when you have hosted a PostGIS layer that has an SRID value set to -1. GeoServer cannot complete the transaction because it cannot convert the real world coordinates of your polygon into an unknown spatial reference. I suggest creating a new PostGIS table schema with the correct SRID setup, then INSERT the attributes and geometry into the table and publish a new GeoServer layer under the new tablename.
Operation on two geometries with different SRIDs
This error has likely occurred because you had a PostGIS layer published in GeoServer with the SRID set to -1, then you tried to alter the SRID in PostGIS using the updategeometrysrid function. This seems to be a GeoServer issue where it still thinks that the layers SRID started off as -1, even though you have altered it to have a real SRID in PostGIS. Again my suggested solution for this issue is creating a brand new PostGIS table schema with the correct SRID setup, then INSERT the attributes and geometry into the table and publish a new GeoServer layer under the new tablename. GeoServer will recognize that it is a different layer, and it will use the SRID you have just setup in PostGIS as the Native SRID.
Below is a working example/demo of the output of this tutorial.