The database has uses beyond the webmap.

Rather than putting everything in the 'postgis' schema using ':' as
hierarchy separator.

When the destination dataset is not PostgreSQL, the layers names are
prefixed using '$SCHEMA.' instead of '$SCHEMA:'

To avoid JSON-encoding on the Python side.

The Web Application doesn't need the original full/non-simplified
geometry.  After all, OpenLayers has fetched the tiles already and the
(visible part of) the geometry is already cached in the target SRS with
sensible simplification factors.

So there is really no need to transfer megabytes of high-precison data
to the client to highlight the feature.  This changes means that CGI
responses will remain small hence can be buffered.

To further speed up things one could store geometry area/perimeter/length
as generated columns (along with the list of municipality and county
codes) and serve row directly from PostgreSQL (bypassing PostGIS).  Also
since buffering is now an option the rows don't need be served in the
same order as the request, so one could batch queries using ANY[] or IN.

This causes overhead on some geometries though.  Querying 100000 random
features in each table and measuring yields the following.

Without geom_area/geom_perimeter/geom_length
============================================

nvr:SCI_Rikstackande (forced to 2D)
Time: min=0.000s, max=0.668s, avg=0.003s

ren:riks_ren
Time: min=0.000s, max=0.090s, avg=0.012s

sametinget:flyttled
Time: min=0.000s, max=0.003s, avg=0.000s

sks:UtfordAvverk
Time: min=0.000s, max=0.180s, avg=0.001s

With geom_area/geom_perimeter/geom_length
=========================================

nvr:SCI_Rikstackande (forced to 2D)
Time: min=0.000s, max=1.242s, avg=0.004s

ren:riks_ren
Time: min=0.000s, max=0.092s, avg=0.012s

sametinget:flyttled
Time: min=0.000s, max=0.016s, avg=0.000s

sks:UtfordAvverk
Time: min=0.000s, max=0.190s, avg=0.001s

And skip geometry columns other than the first one.  Some sources
(svk:stolpar, nvr:SPA_Rikstackande, nvr:OSPAR, svk:stationsomraden,
nvr:HELCOM, nvr:SCI_Rikstackande) come as 3D and we don't flatten them
during import.

Dropping the Z (and/or M) component during GeoJSON export avoids
transfering data which will anyway be ignored by OpenLayer.  The
overhead of ST_Force2D() seems negligible in comparison with
ST_AsGeoJSON().  Querying 100000 random features in each table and
measuring yields the following.

Simple query
============

    SELECT convert_to(ST_AsGeoJSON(m.*,geom_column=>'wkb_geometry',pretty_bool=>'f'),'UTF8') AS "GeoJSON"
      FROM postgis."nvr:SCI_Rikstackande" m WHERE m."ogc_fid" = %s

nvr:HELCOM
Time: min=0.000s, max=0.002s, avg=0.000s
Size: min=1.24kiB, max=24.23kiB, avg=9.47kiB

nvr:SCI_Rikstackande
Time: min=0.000s, max=0.663s, avg=0.002s
Size: min=0.84kiB, max=61613.04kiB, avg=259.67kiB
(Yes that's >50MiB, cf. SE0820430 Torne och Kalix älvsystem.)

nvr:SPA_Rikstackande
Time: min=0.000s, max=0.008s, avg=0.001s
Size: min=1.36kiB, max=392.37kiB, avg=35.23kiB

svk:stolpar
Time: min=0.000s, max=0.003s, avg=0.000s
Size: min=0.19kiB, max=0.20kiB, avg=0.19kiB

svk:stationsomraden
Time: min=0.000s, max=0.003s, avg=0.000s
Size: min=0.35kiB, max=1.22kiB, avg=0.56kiB

sks:UtfordAvverk
Time: min=0.000s, max=0.023s, avg=0.001s
Size: min=0.51kiB, max=1117.39kiB, avg=9.75kiB

Advanced query
==============

    WITH feature AS (
      SELECT m."ogc_fid",
             m.…
             ST_Force2D(m."wkb_geometry") AS "wkb_geometry",
             %s AS layer_group,
             %s AS layer
      FROM postgis."nvr:SCI_Rikstackande" m
      WHERE m."ogc_fid" = %s
    )
    SELECT convert_to(ST_AsGeoJSON(feature.*,geom_column=>'wkb_geometry',pretty_bool=>'f'),'UTF8') AS "GeoJSON"
      FROM feature

(We add `layer_group` and `layer` to the later, which adds 48bytes — the
size of `, "layer_group": "layer_group", "layer": "layer"` to the
output.)

nvr:HELCOM
Time: min=0.000s, max=0.004s, avg=0.000s
Size: min=1.21kiB, max=22.62kiB, avg=8.86kiB

nvr:SCI_Rikstackande
Time: min=0.000s, max=0.893s, avg=0.002s
Size: min=0.88kiB, max=57799.83kiB, avg=243.62kiB

nvr:SPA_Rikstackande
Time: min=0.000s, max=0.011s, avg=0.001s
Size: min=1.37kiB, max=367.70kiB, avg=33.13kiB

svk:stolpar
Time: min=0.000s, max=0.010s, avg=0.000s
Size: min=0.23kiB, max=0.23kiB, avg=0.23kiB

svk:stationsomraden
Time: min=0.000s, max=0.004s, avg=0.000s
Size: min=0.38kiB, max=1.21kiB, avg=0.58kiB

sks:UtfordAvverk (already in 2D so skip ST_Force2D() call)
Time: min=0.000s, max=0.085s, avg=0.001s
Size: min=0.55kiB, max=1117.44kiB, avg=9.80kiB

application() returns a iterator, so we serve responses immediately as
they as received from the server (no buffering).

This avoids exporting features properties and geometries as GeoJSON.
(We could do the same for tiles, but it would be too slow.)  The
downside is that the tables can't be read from while `webmap-import` is
running, so metadata lookup might briefly timeout during the daily
update.

It's still worth doing as it greatly simplifies deployment and saves
GiB of disk space.