This article describes the LuciadLightspeed WFS Server API, which provides its users with an easy framework for setting up a Web Feature Service. The WFS API provides a lot of core features out-of-the-box. The framework offers a WFS servlet complete with all required request handling facilities, GML format support, and an implementation of the OGC Filter specification.
The main configuration task that remains for the user of the API is to implement the server-side data store for the WFS. The user may choose to read geographic data from files, retrieve it from a database, or use any other method to get data.
To get started with the configuration of a WFS, the main entry point in the API
is the class
ALcdOGCWFSCommandDispatcherFactory. This abstract class serves to initialize the WFS during server startup. You must implement the abstract methods that:
Set up the server-side data store
Determine the formats of the data that the server can send to the client
Initialize the filtering support
You can also override some protected methods to customize how the server handles transactions and locking. You may need to do so if a server wants to use capabilities provided by its data store to guarantee persistent and atomic updates.
The following paragraphs describe each of the command dispatcher factory methods. For implementation details, see the API reference documentation or the included samples.
The WFS server uses the
ILcdOGCModelDecoderFactory interface to load
data. A model decoder factory uses a given data source name and returns an
ILcdModelDecoder that can read data from that source. The command
dispatcher factory must provide a valid model decoder factory, or the
WFS won’t provide any data.
The default implementation of this method uses the service lookup mechanism
(TLcdServiceLoader)) to pick up model decoders.
Once it has a model decoder factory, the server is ready to
load data. To tell the server which data to load, you must also implement
ILcdWFSCapabilitiesProvider. The capabilities provider exposes a
list of feature types that the WFS offers. Each feature type
corresponds to an
ILcdModel internally. You invoke the model decoder factory to decode these models. A typical implementation of a capabilities
provider reads a list of data file names from the server configuration
files and returns those.
The name of the feature type. The name serves as the identifier of the feature type in WFS requests, and so must be unique.
The source name, which is used with the model decoder obtained from the model decoder factory to create an
ILcdModelfor the feature type.
A spatial reference system (SRS) identifier, for instance an EPSG code.
ILcdOGCFeatureIDRetriever. The feature ID retriever returns a unique identifier for every feature of the feature type in question.
A WFS server responds to requests by sending geographic data back to the client.
ILcdModelEncoder generates that data, because it’s capable of encoding a model to the format specified by the WFS client.
ILcdWFSClientModelEncoderFactory defines the available model encoders. This factory receives the
desired output format parameter from a WFS request, and returns a corresponding
By default, the WFS server uses
TLcdWFSClientModelEncoderFactory, which supports encoding a model to a
GML application schema according to GML version 2, 3.1 or 3.2. or to GeoJSON.
The capabilities document also specifies the SRS for every available feature
type. By default, references are formatted as an EPSG code. You can override this
behavior by registering extra
You can register more reference formatters by having the
registerModelReferenceFormatters() method call
addModelReferenceFormatter() for each new reference formatter you wish
to register. If more formatters are available, the server tries the last registered format first, then the next to last, and
continues until it finds a formatter
that can successfully format the model reference. If none of the
user-specified formatters are successful, the server falls back to the
default EPSG reference formatter.
A request handler, created for the
"Transaction" request name, handles incoming transactions. Figure 1, “An overview of the classes involved in transaction handling.” shows how it interacts with the
ALcdWFSTransactionHandler class. It also shows how the default implementation of
ALcdWFSTransactionHandler can retrieve locked features from an
ALcdWFSLock, or unlocked features from the
ILcdWFSFilteredModelFactory. When a transaction is committed, it requests a model encoder from the
ILcdWFSServerModelEncoderFactory and saves the modified model using that encoder.
Incoming GML data is automatically decoded and converted to the original format if possible. The elements of the original
format must implement
ILcdDataObject for that, and must all have the same
TLcdDataType. The WFS-T implementation supports GML-based input formats only.
To support transaction handling, a Web Feature Service must be able to commit
changes to the data back to its data store. You implement this capability in the WFS Server API through the
ILcdWFSServerModelEncoderFactory interface. This interface accepts an
ILcdModel and returns an
ILcdModelEncoder capable of saving
this model back to its original location. If you want more control over transaction
handling, you can override the
If you want your server to have more control over transaction handling, you may want to create
ALcdWFSTransactionHandler implementation. For each transaction request
received by the server, you create an
ALcdWFSTransactionHandler instance that handles all parts of the transaction request. Once it has processed all parts of the transaction, it can be
WFS-T transactions can provide data with custom SRS names. To support your own SRS names, you must register a parser to convert
the SRS name to an
You can register reference parsers in the same way as you register reference formatters. See registerModelReferenceFormatters() for a full explanation.
A Web Feature Service supports filtering based on spatial and non-spatial
constraints. LuciadLightspeed WFS performs this filtering via the
ILcdWFSFilteredModelFactory interface. Implementations of this
interface can take an
ILcdModel and, based on some constraints,
produce a filtered model. The contents of the filtered model are a subset of the original model.
The command dispatcher factory creates an
by calling the
createFilteredModelFactory() method. The default
TLcdWFSFilteredModelFactory. This class uses the
com.luciad.ogc.filter package to perform filtering. For more information about using this package, see the Using OGC Filters article in the LuciadLightspeed developer’s guide.
In your applications, you can extend
createFilterEvaluator() method to extend the filtering
support with user-defined capabilities. See the API documentation of the
com.luciad.ogc.filter package for more details.
Web Feature Services that support transactions might also require support for locking. The default implementation locks the
features within the WFS server process. This means that other processes that might access the same data don’t see the lock.
To implement a different locking approach, you can override the