KT Doc-Hub

Appearance

Configuration of WFS ​

wsConfig.useLegacyWfsService ​

  • Type: boolean
  • Description: Flag to determine whether to use the legacy WFS service (true) or the new WFS implementation (false). When true, requests are routed to the traditional MapServer-based WFS controller. When false, requests are proxied to the new, cloud-hosted WFS backend.

IMPORTANT

When switching from the legacy service to the new implementation, there are behavioural differences that must be communicated to users. See below.

Differences Between Legacy and New WFS Service ​

  • Legacy: one layer per asset type, constrained to the asset type’s default geometry (e.g., “junction” = points, “channel” = linestrings).
  • New: supports multiple geometry types per asset type (e.g., for SuDS asset types).
  • Each asset type now exposes one layer per geometry type. For example, “junction” will expose junction_point, junction_linestring and junction_polygon
  • Backward-compatible alias: the original default layer name remains as an alias for the default geometry layer (e.g., junction → junction_point).
  • Note: Alias layers are not listed in GetCapabilities. Clients must request the alias name directly if they rely on it.

Example email to users when switching from legacy to the new WFS ​

Subject: Important Update: Transition to the New WFS Service

Dear [User/Team],

We’re upgrading from our legacy Web Feature Service (WFS) to a new, more robust WFS implementation. This change improves performance, scalability, and reliability.

Key changes:

  1. Layer structure: Each asset type may now expose separate layers for each geometry it contains (e.g., junction_point, junction_linestring, junction_polygon).
  2. Backward compatibility: The original default layer name remains as an alias (e.g., junction → junction_point). Note: Alias layers do not appear in the GetCapabilities response; request them by name if needed.
  3. Performance & reliability: The new service is designed to handle larger datasets and more complex queries with improved response times.

What you may need to do:

  • If you pick layers dynamically from GetCapabilities, update your configuration to use the per-geometry layer names (e.g., junction_point, junction_linestring, junction_polygon).
  • If you already request the plain asset layer name (e.g., junction), it will continue to work via the alias.

If you have any questions or need help updating your client configuration, please reply to this email or contact support.

wsConfig.wfs ​

  • Type: object
  • Description: Configuration object for the WFS service.
  • Properties:
    • assetTypes: string[] - List of asset types to expose via WFS (e.g., ["junction", "channel"]).
    • assetExtraFilter: string (optional) - Additional SQL WHERE filter to apply to all WFS requests (e.g., "status = 'active'").
    • assetExtraFilterReqTable: boolean (optional) - If true, the extra filter is applied only when the request includes a specific table parameter.

IMPORTANT

The wsConfig.wfs configuration in @kt-config/workspaces only applies when using the new WFS implementation (wsConfig.useLegacyWfsService = false). It is ignored when using the legacy service which uses the same configuration but defined in the puppet repo(example)